Processor C_OPT Flags


#1

Anyone out there have an optimization set of flags the cortex-a9?

I have -mcpu=cortex-a9


#2

assuming you saw

https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

and

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

I don’t remember any magic flags to improve performance aside from the normal optimization levels… unless the code is written specifically to use something like NEON on the a9.


#3

i’ll check for Neon. FFtease is faster about 20% =, lyon potpourri the same and I’m testing soundhack this weekend. Ideally the soundhack externals could be patched with more than just themselves. i think the first time they were set with OLD linux flags Erbe set. Thanks

pp


#4

ive changed the title, as atom processors are x86 not arm.

yes, you want to use neon, you will also probably want things like loop unrolling (which is not a default of O3 anymore)

be aware that many options will already be detected anyway, so are unneeded (you can check this by getting the compiler to report the default flags). also as eluded to by @oweno , optimisation is not just a matter of chucking on a couple of flags, it partly depends how code is written, its quite easy to make code perform worst by adding some optimisations.

there are a number of issues with porting code written for desktop over to arm

  • they often use doubles (64 bit) , and quite a few chips including the one used for organelle, do not have fpu processing for 64bit, its much better to use floats , but then the accuracy may affect the behaviour
  • desktops externals etc , often are optimised for SSE not NEON, often when I look at their code, I find that the developer will have an SSE optimisation, and then default to non optimised float for non x86 platforms… this is why it often compiles but performs poorly

also bare in mind, that things like fft often work better on large buffer sizes, and are pretty cpu intensive, so really benefit from using … if you look at the fftease docs, you will see if specifically says to raise the block size.
this means, that for some of the fft based patches, you might be able to use the new pdopts feature of my beta, to increase the block size for these patches.


#5

Do you mean alluded to? :slight_smile:

Yeah until i re-compiled some of them would just crash organelle completely finally i got the one i really wanted to use for a project to open without pooping the bed, So we’ll see

Thanks for the pointers