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


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

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 11:34 +0200
Organization ATMAN - ATM S.A.
Message-ID <irl6ih$sk7$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>

Show all headers | View raw


On 05/26/2011 06:35 AM, Rune Allnor wrote:

>> One: if they take long time, the call overhead is _relatively_ small.
>
> The functions are small. 8-10 trivial math operations.

When I was talking about time, this somehow includes scattered access 
which you mentioned before. Uncached RAM access takes long time 
comparing to couple of simple ops.

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.

You might want to consider a 'manual prefetch' if the vector fits into 
cache and large part of it is used. The rule here is that CPU has a 
hardware prefetcher, which kicks in during sequencial access; otherwise, 
manual prefetch might help. Not the first thing to try though, and a bit 
compiler specific or assembly. (I am talking about x86)

>
>> Two: how complicated they are, impacting optimizing possibilities. E.g.
>> simple multiplication can be SSE'd ('vectorized') if inline'd or
>> deducted by compiler in some other way. Such optimisations cannot be
>> done - in most cases - when the call is indirect enough that the
>> compiler cannot be sure it knows the called function body. This can be
>> significant.
>
> I suppose this is the issue I am worried about.

Make a test and measure.

>> In general bind() is not light, and even function pointers, or even
>> worse pointers to members, should not be called in a tight loop, if only
>> for the call itself, let alone missed optimisations.
>
> I'll have to think about this. The reason why the question came up
> in the first place, was that I found that I could use some of the
> same functionality I implemented for the (x,y,z) surface data stuff,
> when playing with various GUI features like points on the screen:
>
> How can I efficiently hide what type of point I play with, GUI or
> measurements, from the data? And how can I access the coordinates
> in the point types effectively without either hard-coding the
> access functions in the library or pay too large a price on
> performance?

Inline getters (would that be 'hardcoding'? ;) ), or inline MyPoint 
const& getPoint () const, or inherit from MyPoint, or template<class 
MyOp> doOpOnPoint(MyOp& op) on some point class, or ...

>
> Maybe I can accept to do only one call to fetch the data.
> Maybe I can come up with a specialization for the performance-
> critical stuff. There are several options here.

This might be a good idea. Easiest: fetch into vector, pass a vector to 
the function. The function would be locally working on a vector; but 
then, fetching is an operation too, it is simple, but takes some time. 
It depends, measure a test. I functions (ops) are separate from data, a 
wrapper can be made applying an op on a vector. I guess the options are 
limited by what you actually want to do with the result.

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

>
>> HTH
>> Edek
>
> Thanks.
>
> Rune

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