[pulseaudio-discuss] "Hot" function optimization recommendations

[Thomas Martitz]

Am 08.04.2013 21:02, schrieb Justin Chudgar:
> On Thursday, April 04, 2013 04:08:43 PM Justin Chudgar wrote:
>> I had experimentally thrown an optimization into my module's only
>> significantly warm functions. Since I am a novice, this was a
>> just-for-kicks experiment, but I would like to know whether to optimize at
>> all beyond the general "-O2", and what platforms are critical to consider
>> since I only use pulse on systems that are sufficient to run at "-O0"
>> without noticeable problems beyond unnecessary power consumption.
>>
>>  From another thread:
>>> I'm not sure what to think about the __attribute__((optimize(3))) usage.
>>> Have you done some benchmarking that shows that the speedup is
>>> significant compared to the normal -O2? If yes, I guess we can keep
>>> them. <tanuk>
>> I don't know what to think of them either. I did a really simplist benchmark
>> with the algorithm on my core i3 laptop initially to determine if it was
>> useful to keep everything double or float. There was no benefit to reducing
>> presicion on this one system, but that attribute was dramatic. Did not try
>> O2, though, just 03 and O0. I thought about messing with vectorization, but
>> I only have x86-64 PCs and that seems most valuable for embedded devices
>> which I cannot test at the moment.
>>
>> 11: Determine optimization strategy for filter code.
>> http://github.com/justinzane/pulseaudio/issues/issue/11
>>
>>
>> _______________________________________________
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> Just some very simplistic benchmark results of
> 	"__attribute__((optimize(#))) function()"
> in code similar to a biquad filter:
> 	optimize(0), 1867570825, 27.828974
> 	optimize(1), 1017762024, 15.165836
> 	optimize(2), 951896198, 14.184359
> 	optimize(3), 952574300, 14.194463
> This is for "memchunk" analogs of single channel 2^16 doubles being filtered
> and averaged over 2^10 runs with forced cpu affinity. The benchmark itself was
> compiled with -O0.
>
> With the supporting code compiled -O2, the numbers are:
> 	optimize(0), 1436955156, 21.412300
> 	optimize(1), 1020384309, 15.204911
> 	optimize(2), 952980992, 14.200523
> 	optimize(3), 952473365, 14.192959
> Not much difference there.
>
> With the benchmark compiled -O3, there is a DRASTIC change:
> 	optimize(0), 1442046736, 21.488171
> 	optimize(1), 1017924249, 15.168253
> 	optimize(2), 954029138, 14.216142
> 	optimize(3), 374432, 0.005579
> That was such a freakish improvement, that I ran it several times, but the
> results are quite reliable on my dev system.
>


This seems wrong. Does the code still execute *correctly*, does it even 
run the benchmark at all at -O3? I suspect -O3 optimized large sections 
of code away which may (or may not) produce incorrect code, perhaps 
because because the benchmark code relies on undefined behavior or a bug 
in gcc.

Best regards.