These numbers are suspicious.
> suggest that all is not well. Can you enlighten me concerning gcc =
> for Alpha? I would be running principally custom built =
> neural-network simulators in C and C++. The code is =
> floating-point intensive. I've cruised the FAQ, but the =
> discussion on C/C++ does not seem to address these issues.
There has been talk of the fact that GCC does not optimize well for
the alpha. DEC's OSF compiler is reported to be better, but we aren't
using it for obvious reasons. Of course, there is hope that someone
who understands the scheduling issues will patch the alpha code
generator and give us the benefit of alpha's RISC design.
I did some timing tests of my own to evaluate the performance of a
UDB/166 (Multia) WRT a 486/100 and a P166 all running GNU/Linux. The
code is mostly floating point. While I don't have the numbers, I
recall the ratios. If the P166 was a 1.0, the 486/100 was a 0.3 and
the UDB was a 0.8. Note that the UDB's are notoriously inefficient
with diminished caches, slow hard drives, and weak power supplies :-).
If you are looking for raw power, I'm under the impression that
nothing really beats the Alphas. Intel couldn't hope to release a
500MHz PPro--there'd be too many house fires.
Are you committed to GNU/Linux already? This makes the compiler
comparison moot since GCC is uncontested for best-of code generation.
I've written much code for PCs and MS Windows and found that
performance is always better on the Linux machines. Same code,
different OS and different compiler. Even when I used GCC to generate
the EXE on Windows, I still got much better throughput on Linux.
-- Marc Singer
-- To unsubscribe: mail -s unsubscribe axp-list-request@redhat.com < /dev/null
Copyright © 1995-1997 Red Hat Software. Legal notices