Re: [boost] [xpressive] Performance Tuning?

Subject: Re: [boost] [xpressive] Performance Tuning?
From: Edward Grace (ej.grace_at_[hidden])
Date: 2009-07-28 13:46:13

On 28 Jul 2009, at 18:17, Joel de Guzman wrote:

> Edward Grace wrote:
>
>>> That is a *lot* more reasonable, although Spirit is still most
>>> definitely faster then the built-in functions.  :)
>>
>> That's good though - one up for Boost!
>
> My latest benchmarks for integers and floating points reveal
> a 3x speed over atoi/strtol and friend C functions. You
> mentioned a need to parse small numbers very quickly? Spirit
> does. The tests I have take that into consideration too. If you
> guys want to take a peek, it's in the Boost trunk in libs/benchmarks.

Sure.  Can you give me an exact url?  The last time I went on a code  
hunt in SVN I found the wrong thing.

> Some numbers:
>
> ////////////////////////////////////////////////////////////////////// 
> /////
> atoi_test:            0.9265067422 [s] {checksum: d5b76d60}
> strtol_test:          1.0766213977 [s] {checksum: d5b76d60}
> spirit_int_test:      0.3097019879 [s] {checksum: d5b76d60}
>
> ////////////////////////////////////////////////////////////////////// 
> /////
> atof_test:            7.3012049917 [s] {checksum: 3b7d82b0}
> strtod_test:          8.0042894122 [s] {checksum: 3b7d82b0}
> spirit_double_test:   2.6729373333 [s] {checksum: 3b7d82b0}
>
> This time, I am using the benchmarking harness by David Abrahams,
> Matthias Troyer, Michael Gauckler.

This?

http://tinyurl.com/kk858o

There's some interesting trickery in there by the looks of things for  
eliminating the optimiser nastiness - that's not something I've  
thought about much I'll take a look.

In the comments,

42 	// operation to at least update the L1 cache.  *** Note: This
43 	// concern is specific to the particular application at which
44 	// we're targeting the test. ***

that seems quite important but a little opaque out of context.

One thing I take exception to is the (effective) use of the mean as a  
measurement of central tendency - perhaps their trickery has  
eliminated the heavy tail.  I'll have to take a look and see how it  
compares to my approach.

How do your relative timings compare if you repeat them while (say)  
watching a DVD? [*]

> It's the one used in timing
> the overhead of Boost.Parameter. You are welcome to try it out
> with your timer, Edward.

Likewise, can you be specific about where to look?

Thanks for flagging this up by the way - who knows maybe I've been  
reinventing the wheel!

Cheers,

-ed

[*] This may seem a perverse question. I'm interested in robust  
performance measurement, in other words accurately working out which  
function is fastest while the machine is under choppy loading -- not  
a sanitised testing environment - so the fastest function can be  
selected by the code itself.

------------------------------------------------
"No more boom and bust." -- Dr. J. G. Brown, 1997