Reply
Thread Tools
gnuite's Avatar
Posts: 1,245 | Thanked: 421 times | Joined on Dec 2005
#1
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!
 
Posts: 48 | Thanked: 1 time | Joined on Jan 2006
#2
Originally Posted by gnuite
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.
I talked with some of the Nokia-side development folks about this a while back, and there's little-to-no-gain from using "Optimize for Size" vs. "Optimize for Speed 2 / 3 / ..." due to how the ARM9 architecture handles cache during context switch.

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.
 
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#3
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.
 
gnuite's Avatar
Posts: 1,245 | Thanked: 421 times | Joined on Dec 2005
#4
Originally Posted by fanoush
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.
I was thinking more about saving RAM, not flash, to allow running of more applications at once. jffs won't help with the RAM issue.

Originally Posted by fanoush
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.
-mcpu=arm926ejs and -march=armv5te are what I'm planning to use with gcc. I don't know if Nokia's applications are built with these (they may not even be built with gcc, who knows...), but I know gpsdrive isn't. Maybe I'll see some improvement.
 
Posts: 23 | Thanked: 0 times | Joined on Dec 2005
#5
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?
 
Posts: 78 | Thanked: 9 times | Joined on Dec 2005 @ Devon, UK
#6
Try http://linux.omap.com
I'm not sure yo'll find it there, but it looks like a good place to start.
 
gnuite's Avatar
Posts: 1,245 | Thanked: 421 times | Joined on Dec 2005
#7
Originally Posted by geekdoc
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?
mcpu=arm926ejs, march=armv5te, and -Ox should set the flags in an optimal manner, depending on the -O option you use (-O0, -O1, -O2, -O3, or -Os). You shouldn't have to worry about the other options, unless you're attempting to optimize for a specific application.
 
Posts: 23 | Thanked: 0 times | Joined on Dec 2005
#8
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
 
gnuite's Avatar
Posts: 1,245 | Thanked: 421 times | Joined on Dec 2005
#9
Originally Posted by geekdoc
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
"mcpu=arm926ejs" only works for a normal gcc toolchain with gcc >= 3.4.3. CodeSourcery, however, added "mcpu=arm926ej-s" (note the extra dash) to gcc 3.4.2, which is the version that you are using. So change your usage of "mcpu=arm926ejs" to "mcpu=arm926ej-s".

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.
 
Posts: 23 | Thanked: 0 times | Joined on Dec 2005
#10
Thanks, that worked like a charm!
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 04:41.