[PD-dev] double precision Pd: .patch files, tests and benchmarks

[Hans-Christoph Steiner]

On Oct 4, 2011, at 5:38 AM, IOhannes m zmoelnig wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2011-10-04 09:06, katja wrote:
>>
>> Yesterday I forgot to mention why it should definitely not be built
>> with -O0 (unless for debug purposes): PD_BIGORSMALL is defined an
>
> ah yes, this was indeed my fault.
> since i don't feel comfortable with editing m_pd.h to get a different
> build, i used CFLAGS="-DPD_FLOAT_PRECISION=64", which undid any
> optimization flags (which by default are "-O6", which i find a bit
> overdone; and "-g" is not set at all...)
>
> the proper way is to use CPPFLAGS="-DPD_FLOAT_PRECISION=64", which
> results in:
>
> osc-delay-perftest with 400 instances:
> debian           : 31%
> original         : 29%
> single           : 22%
> single(O0)       : 64%
> single(O2)       : 25%
> single(O2+loop)  : 22%
> single(pentium3) : 24%
> single(pentium4) : 22%
> single(prescott) : 22%
> single(core2)    : 22%
> single(core2+sse): 22%
> double           : 25%
> double(O0)       : 86%
> double(O2)       : 27%
> double(O2+loop)  : 26%
> double(pentium3) : 25%
> double(pentium4) : 24%
> double(prescott) : 24%
> double(core2)    : 24%
> double(core2+sse): 25%
>
> osc-delay-perftest with 1200 instances:
> debian           : 94%
> original         : 81%
> single           : 65%
> single(O2)       : 72%
> single(O0)       : ++%
> single(O2+loop)  : 66%
> single(pentium3) : 70%
> single(pentium4) : 66%
> single(prescott) : 65%
> single(core2)    : 59%
> single(core2+sse): 64%
> double           : 77%
> double(O0)       : ++%
> double(O2)       : 82%
> double(O2+loop)  : 77%
> double(pentium3) : 79%
> double(pentium4) : 75%
> double(prescott) : 75%
> double(core2)    : 71%
> double(core2+sse): 75%
>
> which is more inline with katja's measurements.
>
> this is (again) on an i5 650 @ 3.2GHz running in 32bit mode
> optimization flags (as far as they can be reconstructed :-))
> debian: "-g -O2" (this is what is dictated by debian policy)
> original: "-O6 -funroll-loops -fomit-frame-pointer"  (seems to be the
> default)
> single/double: ->original
> (O0): -O0
> (O2): -g -O2
> (O2+loop): -g -O2 -funroll-loops -fomit-frame-pointer
> (prescott): ->original + "-march=prescott"
> (core2): ->original + "-march=core2"
> (core2+sse): ->original + "-march=core2 -mfpmath=sse -msse2"
>
>
> so it seems like the biggest performance boost is given (on the tested
> platform), by compiling with "-g -O2 -funroll-loops
> - -fomit-frame-pointer" (which is cool because i think this can even  
> make
> it into debian, the way it is)
>
>
>> inline function (like it was already suggested by IOhannes a while
>> ago), but at -O0 nothing will be inlined. A benchmark howto would be
>> useful indeed.
>
>
> well, i usually just cram lots of the same object into a subpatch  
> (until
> i get approximately 80% in the slowest environment, in order to not  
> max
> out the CUP and get unknown side-effects), and measure it with the
> built-in load-meter (for loads <100% it behaves quite the same as top)
> nothing very dramatic.


Nice tests, thanks for that.  I would be interested to see the effects  
of auto-vectorization on these numbers.  Have you tried that?  If the  
test patch doesn't include objects that have loops vectorized, it  
won't make a difference.

.hc


----------------------------------------------------------------------------

If you are not part of the solution, you are part of the problem.