Boost logo

Boost :

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.


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!



[*] 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at