Alpha Linux as engine for floating point calculations: compiler toolchain issues (RedHat 4.0)

Przemek Klosowski (
Tue, 19 Nov 1996 17:12:43 -0500

Some people recently discussed suitability of Linux Alpha for running
numerical codes. Of course Alpha CPU is very well suited for such CPU
load, since it has excellent ratio of FP speed to general integer
manipulation, which in itself is remarkable (SpecFP95/SpecInt95 of
11/14 for 400MHz Alpha 21164 versus 8.09/6.70 for Pentium Pro 200MHz).

We recently had run our own benchmark (a monte carlo simulation
program, spending most of time generating random numbers and running
some floating point-intensive code). We got excellent results: the
executive summary is that, if the code works, a 300MHz Alpha runs
faster than SGI's 200MHz R10000, a formidable FP engine (see below
for the explanation of the 'if' statement).

This is just one benchmark, and of course it may or may not be
representative of what would work for other people.

CPU Clock Compiled Run run comments
(MHz) on on time
------- --- ----------- ------ ----- -------------------------------
Pentium 90 Linux Linux 2.2
Pentium 166 Linux Linux 1.6 Pentia aren't too bad here; PPro/200 should halve the run time
R10000 200 SGI Irix SGI Irix 1.0 all results normalized to this machine
Alpha 166 OSF OSF 1.3
Alpha 300 Linux/RH303 Linux 1.7 effect of older, less optimized library and compiler
Alpha 300 OSF Linux 0.43 statically linked executable generated on OSF, run under Linux
Alpha 300 Linux/RH4.0 Linux 0.55 recent glibc and gcc are just 25% behind OSF compiler/libraries

Gcc and the libraries made a great progress recently! Thanks to Richard and
David and all the others who worked on it.

There are, however, some pesky issues that get in the way of happiness of
owners of RH 4.0 (gcc-2.7.2-9, glibc-0.960906-1)

- Floating constant compilation bug.

C code 'double entendre = 2.2250738585072014e-308;'
generates in the following (incorrect) assembly:
.t_floating 2.22507385850720138309e-308

the assembler compiles this to ('objdump --full-contents testfpconst.o')
0000 ffffffff ffff0f00 ........
whereas it should have been
0000 00000000 00001000 ........

Note that the above number is DBL_MIN (I wrote it explicitly to simplify the example).

In itself, this would be a nuisance, but for numbers near the ends of the dynamic
range it leads us right into another trap:

- IEEE exception support

The following code

#include <math.h>

short pants = 2;
double entendre = DBL_MIN;

if (pants < entendre) {
entendre = M_PI;
traps with a FP error in the 'if' statement. Even though the constant DBL_MIN is
not compiled properly---it is supposed to be the smallest normalized positive number,
and it ends up being denormalized---it still should calculate OK. I tried the standard
Intel trick of linking in the libieee.a library (-lieee), but it didn't change anything.

- I can't make profiling to work

Regular timer-based profiling dies at runtime

$ gcc -p -o testdebug testdebug.c
$ ./testdebug
monstartup: out of memory

which is clearly not the case:

$ cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 63406080 60293120 3112960 46735360 2990080 25772032

At the same time gprof-based profiling misses some library symbols

gcc -pg -o testdebug testdebug.c
/usr/lib/gcrt1.o: In function `__gmon_start__':
gmon-start.c(.text+0xd8): undefined reference to `_start'

- debugger (gdb 4.16 as in gdb-4.16-5 RPM): sometimes, when single-stepping a program
(compiled with -g, of course), the floating point variables aren't accessible (bogus
values are printed out). I suspect a damage is being done to the stack frame, because
single-stepping calls to printf() results in bogus values being printed out as well.
If a program is run from background to background, this doesn't occur.

I haven't been able to demonstrate it on a simple, short file; I will try this later

To unsubscribe: send e-mail to with
'unsubscribe' as the subject.  Do not send it to

Feedback | Store | News | Support | Product Errata | About Us | Linux Info | Search | JumpWords
No Frames | Show Frames

Copyright © 1995-1997 Red Hat Software. Legal notices