Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #5605

Re: Boost.bind and performance penalties?

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>

Show all headers | View raw


>> 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


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