At the moment the AXP Linux is in VERY EARLY stages of
development, first relatively easy to use packages have
been made, but not all kinks of the systems have been
ironed out. Also a lot of things fail in more or less
spectacular fashion when implied assumtions of 32-bit
machine environment do not hold true.
> Well, here are the bad news:
>
> 1) Please study the stuff below - I get this error on EVERY program
> I tried. The system came with RedHat 2.1 - so I installed a complete
> RedHat 3.0.3 on top - no change. I took the sources and compiled libc
> with -mieee and recompiled f2c - no change. I noticed a bunch of
> warnings of 'pointer cast to integer of different size' or so when
> compiling f2c.
The f2c assumes a bit too much of
sizeof(int) == sizeof(arbitary*)
which is ok at 32 bit machines...
> 2) time in /bin/tcsh is broken and so is /usr/bin/time - the times
> come out ridiculously low, so I relied on 'date'. 'ps' by the way
> gives funny numbers too. Using 'date' on a P6-200 and on the AXP
> 21064A-275 I get:
A bit of glitches at libc and/or kernel interfaces.
sizeof(time_t) != sizeof(long)
It will be fixed, when the GNU-Libc gets made for AXP systems.
> PentiumPro-200 9 seconds
> AXP 21064A-275 24 seconds
>
> Another program:
>
> PentiumPro-200 29.7 seconds (this program times internally)
> AXP 21064A-275 40.2 seconds
> (this was around 23 seconds on a 21164-300).
rather consistent between AXP versions there.
> Both machines are about equal on SPECfp 92/95 and the code is
> predominantly floating point. On the AXP I compiled with -O2,
> -O and -O3 were slower, -O3 a little, -O a little more.
The GCC for AXP produces rather abysmall FP code.
If you can compile the code at a DEC OSF/1 with
KAP Fortran, and link it into a static binary,
THEN you will see quite different performance figures.
Recently I benchmarked one High-energy physics program
(serious convoluted FP mathematics) at a SuperSparc-II (50 MHz),
and AXP 21064A-266 -- the binaries were produced with the
best compilers I could get my hands on for the machines,
and then I unleashed the runs in front of audience watching
my screen from a video projector -- by a mistake I had
injected one too many zero at the AXP iteration parameter,
effectively making the task 10 times as large as it was
with the SPARC. When we spotted that, AXP had just completed
the run (it was started a few seconds AFTER the SPARC),
and we still had to wait a few more seconds for the SPARC.
Thus between those two machines the performance ratio was
something like 10-15 -- our theorethical physicist looked
very happy (he had bought the machine for running calculations)
> My summary: I give up - I'll get two PentiumPro instead, maybe
> even dualPPro - one program is parallelized using PVM and works
> very nicely on a dual P5-100 running SMP linux (cache contention
> is a problem, but should not be for the P6). In a year or so I
> may be contemplating an Alpha again (21164A-500 maybe ?-).
Indeed, by that time the GCC should be able to produce
far better code -- and GNU-Fortran has real support for
AXP systems (native Fortran is always better, than f2c+cc,
due to flow-information passing that f2c scrambles.)
> My question: has anyone ever used the RedHat 3.0.3 (or 2.1) linux
> f2c on the Alpha successfully (for non-trivial programs)? Has anyone
> an idea what is wrong - you obviously see what makes f2c fail in
> the code.
Tried, without success. Then I gave them a way to
compile binaries at DEC OSF/1, and run them at Linux...
> Arno
...
> x.f:
> MAIN x:
> Warning on line 3 of x.f: local variable fii never used
> Compiler error line 3 of x.f: floating exception during
> constant evaluation; cannot recover
The f2c needs to be compiled with -mieee, I recall.
/Matti Aarnio <mea@utu.fi>