Re: [potato] Floating point exception
On 23 Nov 1999, Eberhard Burr wrote:
> I do not share your assumptions on how many programs are affected and
> on how much slowdown -mieee brings: judging from the documentation of
> cpml and from my own experience with my own floating-point-intensive
> program, the slowdown is really not all that much. Alpha is to my
> knowledge the only widespread architecture that does not do IEEE in
> hardware and therefore most programmers are not aware of the
> implications. If you define "not needed" as "under normal
> circumstances this program doesn't emit FP-exceptions" then maybe your
> 95% estimate holds, but I'd prefer to only compile programs without
> -mieee iff the program has it's own exception handler or other
> security measures that do _not_ rely on finite() and friends or the
> MAXFLOAT #defines from <math.h>. Those programs are rather rare.
Hmmm...point taken. I guess I come from a unique place, though, in that
ALOT of the packages that I compile for the distribution don't involve FP
at all (or very very little since I spent most of my time on the net
section). I think if I felt that the glibc/gcc combo showed performance a
little closer to that of the DU libs and compiler (which handles
scheduling a lot better than gcc does ATM), I would feel a bit better
about -mieee. In the end, though, I have no very strong objection to
compiling everything with -mieee. In fact, the gcc maintainers (which
includes me representing alpha) are thinking of lobbying for -mieee
becoming the default for the compiler on alpha.
> So what you say is that all packages should be compiled for 21066s so
> they run on any machine. Then using -mieee is a logical conclusion
> imho, because the merit is to have _working_ binaries. If a program
> turns out to be particularly slow, one has to recompile anyway.
I'm starting to think that there may be issues with 21066's and -mieee
under glibc 2.1.2, though. I have two packages that work fine on my SX,
but throw FPEs when run on EV4 systems. I'm still waiting for a report
from someone with a 21264 and 21164a, but I'm suspecting a targeting
problem with glibc (it DOES have code for IEEE math for both, but it also
has a subsection for EV5's and above, which might actually be compiled
despite the more generic target given to the configure script. Aside from
that, I know gcc has issues as well with complex support (which is the
reason I still haven't been able to get glibc 2.1.2-10 compiled yet), so
putting my faith into either right now is an "iffy" proposition.
> Anyhow, it is clear to me, that Alphas are not necessarily lightning fast.
> My SX164 did a damn good job chewing on my program but in day-to-day
> usage, it's sometimes disappointing. (particularly in XEmacs; my
> AMD-K6-200 performs better there) I think this point should be made
> clear to alpha-newcomers, that these processors have their weak sides
> too, and that the reputation they have comes from their strength in
> cleanly programmed floating-point calculations.
Hmmm...I disagree. At the current stage of Alpha development with gcc
(and partially glibc), I just can't honestly say that Alphas running Linux
take full advantage of the speed of the processors. I've found that DU
running most of the same software performs better (often by a factor of 2
or more). I'm not saying the Alpha doesn't have a weak side (it does),
but I don't think it's a fair comparison at this point.
C
Reply to: