Optimization flags in .debs?
I'm becoming curious about optimization flags used in all these maemo .deb files that are floating around. I wonder if .deb builders are considering -Os as opposed to -O2 or -O3. Granted, the Nokia 770's processor is not blazingly fast by any means, but its memory might be even more limiting, so perhaps -Os would be preferable.
Peaking at the maemo-gpsdrive source code, I saw zero references to -Os, but dozens of references to -O2 or -O3. I'm going to build maemo-gpsdrive and its two dependencies (libpcre3 and gpsd) in scratchbox with different optimization settings to see if I can notice any significant differences. I wonder if the scratchbox x86 runtime performance is any indicator of on-device arm runtime performance? If nothing else, I can compare bin sizes. I also noticed some useful configure flags in maemo-gpsdrive, like disabling GARMIN support, so I'll want to roll my own maemo-gpsdrive .deb anyway. Unfortunately, if the results are promising, I can look forward to hours of creating custom .debs for all of my open-source maemo apps! |
Quote:
Minor gains might be had by using properly aligned variable data, but again, nothing spectacular. I have a pile of FAQ entries to submit over at Maemo.org, just need to make the time to do so. |
And also the bigger size of -O2 or -O3 might not matter since jffs filesystem is compressed and some repating patters of code produced by those flags (inlining of code, unrolling loops) may compress well so result may be similar. har to say without test with specific executables.
On the other way I would be interested whether optimizing for specific CPU (armv5te architecture or arm926ej-s core) might help with the speed. Default 3.3.x debian compiler does not know them but the 3.4 compiler from codesourcery guys used for kernel knows -mcpu=arm926ej-s. I tried to use it for libMAD in scummvm but don't know whether it helped or not. The 'e' letter in core name means edsp instructions which can be used for mp3 audio or mp2/4 video to speed it up. But I'm not sure whether they are used directly in software (mplayer,libmad,ffmpeg) or whether gcc can generate them automatically. Probably not. |
Quote:
Quote:
|
I was looking for the options for compiling.
I managed to find http://gcc.gnu.org/onlinedocs/gcc-3....M-Options.html does anyone know which ones we should use? other than arm926ejs and armv5te? |
Try http://linux.omap.com
I'm not sure yo'll find it there, but it looks like a good place to start. |
Quote:
|
Thanks for the heads up!
I tried mcpu=arm926ejs and march=armv5te and I got the following... error: bad value (arm926ejs) for -mcpu= switch with gcc -v = Reading specs from /scratchbox/compilers/arm-linux-gcc3.4.cs-glibc2.3/lib/gcc/arm-linux/3.4.2/specs Reading specs from /scratchbox/compilers/arm-linux-gcc3.4.cs-glibc2.3/gcc.specs rename spec cpp to old_cpp Configured with: ../../work/gcc-2004-q3d/configure --target=arm-linux --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/scratchbox/compilers/arm-linux-gcc3.4.cs-glibc2.3 --enable-languages=c,c++ --program-prefix=arm-linux- --enable-shared --enable-static --with-sysroot=/scratchbox/compilers/arm-linux-gcc3.4.cs-glibc2.3 --with-local-prefix=/scratchbox/compilers/arm-linux-gcc3.4.cs-glibc2.3 --enable-symvers=gnu --with-gnu-ld Thread model: posix gcc version 3.4.2 (release) (CodeSourcery ARM Q3D 2004) anyone know what's up or where I should look? from what I checked online... that should work! Thanks |
Quote:
Also, I should note that, according to the compiler, "mcpu=arm926ej-s" and "march=armv5te" are conflicting arguments. Unlike the classic i386 case (where march=athlon implies mcpu=athlon), you must choose one or the other. I believe that the mcpu specification would provide the compiler with more information than the march specification and thus allow the compiler to produce more optimized code. |
Thanks, that worked like a charm!
|
All times are GMT. The time now is 04:46. |
vBulletin® Version 3.8.8