[pulseaudio-discuss] "Hot" function optimization recommendations

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

Replacing the optimize(#) with hot and using -O3 for the whole gives:
	hot, 310780, 0.004631

And removing the __attribute__ altogether, again using -O3 for the whole 
gives:
	<NONE>, 333013, 0.004962

Being generally a novice using a VERY simplistic wrapper of a rather simple 
function, I'm loathe to draw too many conclusions. However, this suggests that 
it might be worth using __attribute__(hot) for any serious number crunching 
functions within pulse and adopting the -O3 compiler flags as the standard.

If I can figure out oprofile or something similar, I'll try to test. I'd also 
like to hear general feedback about this since I'm just learning. Thanks, all.

Justin