Laurent, I have marked the array as volatile to force compile to bypass those kind of optimisations and the results were different. I actually had to reduce the amount of iterations to only 10000 otherwise it would take too long to complete.
I had results of ~130ms for the standard settings and ~102ms for optimised settings. Apparently there was a ~20% improvement with that simple example. Then I have used a more complex example. Instead of that simple array elements multiplication, I started using my own Delay and Reverb units which represents most of the processing time during the audio callback. For this, I have created a 1024 items array filled with a random number between 0 and 1 and passed this sequentially to delay and reverb. With standard settings I have ~3.8us of processing time, however, with optimised settings the results tend to zero. This makes me believe the code is not running as expected. In order to confirm this I need to process an actual sound file and save the result to an output file to ensure that I’m listening something mean full. Question: what can cause code to break if compiled with hard float settings? In some of my earlier experiences with hard float settings my app wasn’t even opening, or it was behaving very wrong. This is the first time I testing it with more simpler cases. Thanks in advance, Regards, Nuno > On 05 Jun 2016, at 19:21, Laurent de Soras <laurent.de.so...@free.fr> wrote: > > Nuno Santos wrote: >> >> I’m struggling with performance questions on Android. >> https://groups.google.com/forum/#!topic/andraudio/zuXnnmZyePk > > Your results tell that your program computes 10^9 operations > in a few dozen microseconds. There is definitely something > wrong here because even the most advanced ARM processors are > not known to be multi-teraflops CPUs. > > Actually the compiler might think it can keep only one loop, > or even none, given that the result of each loop will always > be the same, and this result isn’t even used somewhere else > in the program. You should introduce slight dependencies in > your test in order to defeat this kind of optimisation. > > The difference between the compiler settings you tried are > most likely caused by variations in initialisation sequences, > scheduling glitches or timer inaccuracies. > > _______________________________________________ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp _______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
