Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #5605
| From | Edek <edek.pieITAKNIECZYTAM@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Boost.bind and performance penalties? |
| Date | 2011-05-26 12:53 +0200 |
| Organization | ATMAN - ATM S.A. |
| Message-ID | <irlb6k$1iv$1@node2.news.atman.pl> (permalink) |
| References | <4198e173-5f6c-447d-a848-07767e446048@w36g2000vbi.googlegroups.com> <irj4cg$mv8$1@node2.news.atman.pl> <faf3ef11-f23d-42d1-9eed-efeebde9bad9@e35g2000yqc.googlegroups.com> <irl6ih$sk7$1@node2.news.atman.pl> <93dbd5fb-211e-411d-b752-c9913148a1b3@cu4g2000vbb.googlegroups.com> |
>> Which reminds me: I do not understand why replacing vector offset by >> vector of pointers should speed things up. Vector offset boils down to >> pointer + offset. > > Not quite: > > 1) ElementPointer = BasePointer + ElementOffset > 2) Element = derefernce(ElementPointer) > > while the pointer semantics is only half that: > > A) Element = dereference(ElementPointer) Not quite, if I understand your first post: 1) Pointer = deref(const_pointer + pointerOffset) 2) Element = deref(Pointer) vs. 1) ElementOffset = deref (const_pointer + elementOffsetOffset) 2) Element = deref (const_pointer + ElementOffset) ... 1 is sequencial I guess, 2 is scattered. In both cases 2 is dependant on 1. deref(pointer + offset) is a single instruction on most CPUs if not all, although somehow split into microops - still, RAM fetch is way more that address addition. And it is not even that simple addressing. 2) should be a & + member offset. v[off].x that is, or deref ([const_pointer + ElementOffset] + const-x-offset). > > In this application the difference matters. The issue is a bit > more involved than what I posted first (there might b 3 - 5 levels > of indirections through pointers to pointers). Maybe rewriting to > pointer semantics instead of vector semantics saves me 30% run time; > maybe it saves 60%. I don't know until I rewrite. I don't know. I usually think in such cases that the compiler will do such things for you, if you do not prevent it: generated assembly does not match line-by-line what is in .cpp file. It is a simple transformation. The compiler stops further transformations when faced with something it does not know for sure. Indirection might be one of them, true; a 'blackbox' call is for sure another. I still see no significant difference between returning an offset and returning a pointer, at least in a loop. Making everything a template, or just inline, makes no 'blackbox' calls; fewer indirections should help too. > > But it's that order of magnitude we are talking about. I don't want > to blow those savings or more, on an expensive function indirection. Probably boost::bind is what you need to avoid. std::for_each or any similar template would be better I guess. >>>> These are mostly rules of thumb. If you have a lot of time to spend on >>>> programming, use expression templates, or inline at least. If you >>>> cannot, use boost::bind and just don't worry. >> >>> Can't afford not to worry. Run-time is a critical factor here. >> >> Still, measure first, make a simple test, measure again. There are more >> things in the CPU than are dreamt of in programming. > > The performance factors only kick in visibly at large volumes. > No such thing as a 'simple test': either rewrite the whole thing > or nothing at all. Maybe. I use simple tests to learn the mechanisms, on large volumes. It might be easier than rewriting the whole thing and learning later that it was not the right way to go. Which by the way happens during such changes, performance is too often heuristic-like. What is clearly an advantage, is changes like O(n^2) to O(log n), but we're not talking about that now. Edek
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Boost.bind and performance penalties? Rune Allnor <allnor@tele.ntnu.no> - 2011-05-25 04:56 -0700
Re: Boost.bind and performance penalties? Edek <edek.pieITAKNIECZYTAM@gmail.com> - 2011-05-25 16:45 +0200
Re: Boost.bind and performance penalties? Rune Allnor <allnor@tele.ntnu.no> - 2011-05-25 21:35 -0700
Re: Boost.bind and performance penalties? Edek <edek.pieITAKNIECZYTAM@gmail.com> - 2011-05-26 11:34 +0200
Re: Boost.bind and performance penalties? Rune Allnor <allnor@tele.ntnu.no> - 2011-05-26 02:40 -0700
Re: Boost.bind and performance penalties? Edek <edek.pieITAKNIECZYTAM@gmail.com> - 2011-05-26 12:53 +0200
Re: Boost.bind and performance penalties? Rune Allnor <allnor@tele.ntnu.no> - 2011-05-26 04:19 -0700
Re: Boost.bind and performance penalties? Jeff Flinn <TriumphSprint2000@hotmail.com> - 2011-05-26 16:11 -0400
csiph-web