* Similar tools builds show markedly different performance?
@ 2008-01-09 15:44 Rick Mann
0 siblings, 0 replies; 2+ messages in thread
From: Rick Mann @ 2008-01-09 15:44 UTC (permalink / raw)
To: gcc-help
A little more information: there seems to be a difference in the
resulting binary's floating point (which would go a long way to
explaining what I'm seeing). The ELF built with the more recent tools
results in this:
$ xscale-elf-readelf -h h.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x80100000
Start of program headers: 52 (bytes into file)
Start of section headers: 448508 (bytes into file)
Flags: 0x602, has entry point, GNU
EABI, software FP, VFP
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 25
Section header string table index: 22
The ELF built with the older (faster) tools results in this:
$ arm-elf-readelf -h h.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x80100000
Start of program headers: 52 (bytes into file)
Start of section headers: 411484 (bytes into file)
Flags: 0x402, has entry point, GNU
EABI, VFP
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 1
Size of section headers: 40 (bytes)
Number of section headers: 26
Section header string table index: 23
The relevant change is in the Flags: field. The new tools include
"software FP", the old tools don't.
Now, the processor doesn't have hardware floating point, yet the code
runs in both cases, so some kind of software floating point code is
being emitted.
TIA,
Rick
(original post below)
> I've been building tools targeting the Marvell Xscale processor a
> lot lately. A set of tools I build a few months ago seem to generate
> much faster code on our target hardware than tools I built more
> recently. There were some significant differences in the way the
> tools were built, but it doesn't seem like that's enough to explain
> the difference. Unfortunately, I don't remember exactly how I built
> the older toolchain, so I'm hoping someone can help me determine
> what it was by looking at the build result.
>
> Old tools:
>
> $ arm-elf-gcc -v
> Using built-in specs.
> Target: arm-elf
> Configured with: ../configure --prefix=/usr/local/arm3 --target=arm-
> elf --with-newlib --with-cpu=xscale --enable-languages=c,c++
> Thread model: single
> gcc version 4.2.1
>
> $ arm-elf-ld --version
> GNU ld (GNU Binutils) 2.18
>
> How do I tell what version of newlib is installed (I think it's 1.15)?
>
> Built using a multistep process, where I first built binutils, then
> gcc, then newlib (I don't recall if I did a stage 1 GCC build first,
> but somehow I got it all working).
>
>
> The latest tools are slightly different, and built with a combined
> tree build:
>
> gcc-4.2.2
> binutils-2.17
> newlib-1.15
>
> $ xscale-elf-gcc -v
> Using built-in specs.
> Target: xscale-elf
> Configured with: ../combined/configure --target=xscale-elf --disable-
> nls --with-newlib --prefix=/usr/local/gcc-xscale-elf --disable-
> newlib-supplied-syscalls
> Thread model: single
> gcc version 4.2.2
>
>
>
> I'm sorry I can't provide better information, but I'd really like to
> figure this out. The code doesn't call into the standard C library,
> but does make use of a lot of floating point code. Is it possible
> that this code is better with the other tools (either built more
> optimized, or generally different)? I don't know I'm just
> speculating. It is C++ code (bouncing balls on a screen, the balls
> are object instances).
>
> Thanks for any help!
>
> --
> Rick
^ permalink raw reply [flat|nested] 2+ messages in thread
* Similar tools builds show markedly different performance?
@ 2008-01-09 15:16 Rick Mann
0 siblings, 0 replies; 2+ messages in thread
From: Rick Mann @ 2008-01-09 15:16 UTC (permalink / raw)
To: gcc-help
I've been building tools targeting the Marvell Xscale processor a lot
lately. A set of tools I build a few months ago seem to generate much
faster code on our target hardware than tools I built more recently.
There were some significant differences in the way the tools were
built, but it doesn't seem like that's enough to explain the
difference. Unfortunately, I don't remember exactly how I built the
older toolchain, so I'm hoping someone can help me determine what it
was by looking at the build result.
Old tools:
$ arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../configure --prefix=/usr/local/arm3 --target=arm-
elf --with-newlib --with-cpu=xscale --enable-languages=c,c++
Thread model: single
gcc version 4.2.1
$ arm-elf-ld --version
GNU ld (GNU Binutils) 2.18
How do I tell what version of newlib is installed (I think it's 1.15)?
Built using a multistep process, where I first built binutils, then
gcc, then newlib (I don't recall if I did a stage 1 GCC build first,
but somehow I got it all working).
The latest tools are slightly different, and built with a combined
tree build:
gcc-4.2.2
binutils-2.17
newlib-1.15
$ xscale-elf-gcc -v
Using built-in specs.
Target: xscale-elf
Configured with: ../combined/configure --target=xscale-elf --disable-
nls --with-newlib --prefix=/usr/local/gcc-xscale-elf --disable-newlib-
supplied-syscalls
Thread model: single
gcc version 4.2.2
I'm sorry I can't provide better information, but I'd really like to
figure this out. The code doesn't call into the standard C library,
but does make use of a lot of floating point code. Is it possible that
this code is better with the other tools (either built more optimized,
or generally different)? I don't know I'm just speculating. It is C++
code (bouncing balls on a screen, the balls are object instances).
Thanks for any help!
--
Rick
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2008-01-08 19:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-09 15:44 Similar tools builds show markedly different performance? Rick Mann
-- strict thread matches above, loose matches on Subject: below --
2008-01-09 15:16 Rick Mann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).