|
Message
From: Christian Melki <christian.melki@a...>
Date: Tue, 15 Jul 2003 11:15:12 +0200 (CEST)
Subject: Re: [openrisc] or1200 code size.
Hi Matjaz.
I could try the -Os flag but i have been avoiding it
on purpose. Since i try to even out all the oddities
between architectures ( think compilers that target
different OS, with different libraries and different
versions ) i have considered the -O2 flag as standard
since all compilers should be able to handle -O2.
I don't know which compiler the OR port of gcc is derived
from ( mips perhaps? ) or if it is written from scratch.
Anyway. Here are my results.. But _please_ regard them as
very preliminary since i would like to verify
how to build a test before regarding them as viable results.
For hypercube:
chrisme@speed2: testcode/hypercube-0.4/size> find . -name total.o -exec ls
-1sh {} \;
60k ./x86-3.0.4/total.o
76k ./or32uclinux-3.1/total.o
64k ./cris-3.2.1/total.o
64k ./x86-2.95.4/total.o
84k ./sparcleon-3.2.2/total.o
chrisme@speed2: testcode/hypercube-0.4/size> find . -name total.o -exec
gzip -9 {} \;
chrisme@speed2: testcode/hypercube-0.4/size> find . -name total.o.gz -exec
ls -1sh {} \;
20k ./x86-3.0.4/total.o.gz
28k ./or32uclinux-3.1/total.o.gz
24k ./cris-3.2.1/total.o.gz
24k ./x86-2.95.4/total.o.gz
24k ./sparcleon-3.2.2/total.o.gz
For boa:
chrisme@speed2: compiled-toolchaintest-code/boa-0.94.13/src> find . -name
TOTAL.o -exec ls -1sh {} \;
130k ./x86/strip/TOTAL.o
134k ./cris/strip/TOTAL.o
166k ./or32/strip/TOTAL.o
174k ./sparc/strip/TOTAL.o
chrisme@speed2: compiled-toolchaintest-code/boa-0.94.13/src> find . -name
TOTAL.o -exec gzip -9 {} \;
chrisme@speed2: compiled-toolchaintest-code/boa-0.94.13/src> find . -name
TOTAL.o.gz -exec ls -1sh {} \;
44k ./x86/strip/TOTAL.o.gz
46k ./cris/strip/TOTAL.o.gz
54k ./or32/strip/TOTAL.o.gz
50k ./sparc/strip/TOTAL.o.gz
For secure:
chrisme@speed2: compiled-toolchaintest-code/secure/total_O2> ls -1sh
total 236k
38k cris-total.o
66k mmix-total.o
44k or32-total.o
46k sparc-total.o
42k x86-total.o
chrisme@speed2: compiled-toolchaintest-code/secure/total_O2> gzip -9 *
chrisme@speed2: compiled-toolchaintest-code/secure/total_O2> ls -1sh
total 68k
12k cris-total.o.gz
14k mmix-total.o.gz
16k or32-total.o.gz
14k sparc-total.o.gz
12k x86-total.o.gz
As you can see. The or1k generates ok binary sizes uncompressed.
But takes the on the end of the chain when compressed on a regular basis.
I know that these are ugly big blocksize listings,
but the difference becomes even more obvious when choosing a more heavy
hitting compressor like bzip2.
anyway
I have a few problems left..
Here they are:
How should i generate code with so many different versions
of compilers? uclibc/glibc/linux/uclinux etc etc.
This makes it hard if not impossible...
Ok. Choose most common unit to compile from.
*That would be *arch*-elf-(no-os-dependencies)
Ok. Find programs that does not carry to many
os dependencies ( sys/whatever.h ).
This was actually quite hard. Does anyone have any
program that is based on non os-dependant code
and is large enough?
* Boa (webserv - obligatory axis)
* hypercube (webserv, a friend of mine's)
* generic hello world for testcase
* secure (crypto program that is quite os independent)
(here comes the part that im not sure of)
Ok. Choose how to compile
* -O2 should be standard.
and:
which path? one or combination?
* Do not link... or link with null-functions/non-library-link(is it
possible??)
* Just strip all binary symbol information --strip-all.
* Mearly --strip-unneeded ( info is vital for comparision?? )
and:
* Measure on the entire object file and summarize over
all objects generated??
* Measure on code segment only? ( read out each ELF-code
segment size and summarize )
Any suggestions regarding measurement is welcome!
regards
christian
On Tue, 15 Jul 2003, Matjaz Breskvar wrote:
> One thing to try is -Os flag to the compiler, used to optimize for
> code size. Also if I understood correctly you are compareing code size
> on a pretty small project so you should be careful that what you
> meassure isn't just a messurment error (maybe on another code
> base you'd get pretty much different results). I would guess (could be
> very wrong) that a few percent difference on 100Kb binary isn't
> statisticaly meaningful.
>
> Nevertheless this is quite interesting, could you post your results...
>
> regards,
> p.
|
 |
Browse
