Re: Konqueror and Javascript
> What is the status?
It seems that Richard Henderson (who I understand to be the Alpha tool chain
guy from RedHat) has unofficially blocked the 'make -mieee the default on
Alpha' patch.
As he never responded after I argued, with actual hard numbers, that his
initial objections were (understandable but) unfounded, I don't think it's a
technical merit issue. Nor, considering the simplicity of the patch, do I
think it's a code style/cleanness issue.
I think Richard just doesn't like it. As that doesn't bode real well for ever
getting the patch accepted, I just dropped the issue (hey, I'm younger than
him, I'll just out live him and then slip it in the back door *grin*).
Anyway, here's the emails for any interested.
I posted the patch with an intro/description to gcc-patches on (July 17):
---- BEGIN: Tyson ----
Here's a patch (against CVS HEAD) that makes IEEE compliant math operations
(support for denormalization, nan, inf, etc) the default on the Alpha unless
it is specifically turned off with -mno-ieee.
It arose out of a discusion on the Debian Alpha port list about packages
SIGFPEing on the Alpha (see the thread 'SIGFPE and -mieee' at
http://lists.debian.org/debian-alpha/ starting in June).
I understand that -mieee is a default build switch for Alpha on Redhat, SuSe,
and Gentoo (see the aforementioned thread on the Debian lists) .
Thanks -T
---- END: Tyson ----
Richard responded (July 21):
---- BEGIN: Richard ----
I do not like this.
(1) This has been the status quo on alpha since the beginning of time.
Not just with GCC, but with DEC C as well. Why change now?
(2) Particularly with pre-ev6 cpus, this results in severe penalties
of the performance for maths.
(3) Every time I looked at a non-math user application that got SIGFPE
due to subnormals, it was due to an uninitialized data read.
I will not accept the patch as-is.
(A) At the extreme minimum, I require that -ffast-math result in
ieee math off, unless the user has explicitly enabled it for
some reason.
(B) I do not like a solution that changes the default for just one
operating system. That's a bit of inconsistency that grates.
That means you'll need to track down the other users of alpha gcc
and get agreement. I realize that this will be very difficult --
indeed, I *intend* for it to be difficult.
r~
---- END: Richard ----
I responded (July 23):
---- BEGIN: Tyson Whitehead ----
> (1) This has been the status quo on alpha since the beginning of time.
> Not just with GCC, but with DEC C as well. Why change now?
Default IEEE vs default non-IEEE compliance isn't a big deal if the OS
supplies both IEEE conformant and non-IEEE conformant libraries and the
dynamic loader links apps according to whether they were compiled with -mieee
or not (i.e. DEC Unix and DEC C).
If the OS doesn't support IEEE compliant/non-IEEE compliant dynamic linking
(i.e. Linux and probably every other OS besides DEC Unix), then the default
should match the math libraries.
The GNU math libraries (I emailed them about this and they don't intend to
change) generate IEEE 'extentions', so code compiled on systems build around
the GNU libraries should be able to handle IEEE 'extentions' (i.e. on the
Alpha, be compiled with -mieee).
For these systems it makes sense for -mieee to be a default, as nearly
everything (except integer only program, which -mieee doesn't effect) has to
be compiled with -mieee. If they are not, then apps will, on specific user
inputs, under non-esoteric conditions, crash (i.e. open up a version of
Python/Perl compiled without -mieee and try doing exp(-710.0)*2.0 or write
some C code and try erfc(27.0)*2.0, etc).
> (2) Particularly with pre-ev6 cpus, this results in severe penalties
> of the performance for maths.
I did a little test the other day on an EV56 machine. A hard coded C loop
that took 1024 complex Fast Fourier Transform of 2048 vector doubles.
Running time with -mieee was 11.4s. Without was 9.4s. Looks like -mieee
makes a difference of 20% for an application that does nothing but crunch
numbers in a tight loop.
20% is an upper bound. Most intensive numerical simulations are more complex
than FFTs or matrix inversions (i.e. have to maintain data structures for
dynamic meshing, etc). For a more average figure for a numerical number
crunching app, I timed some of the code floating around our department.
Monte Carlo option pricing; with -mieee 10.3s, without -mieee 10.2s.
Molecular Dynamics simulation; with -mieee 191.0s, without -mieee 201.2s.
Realistically then, for an intensive numerical application (assuming it can
even be compiled without -mieee -- the aforementioned Monte Carlo option
pricing code can not, otherwise it occasionally crashes when it's random
nature results in the generation of a denormalized number), we are only
taking about a 5% difference.
> (3) Every time I looked at a non-math user application that got SIGFPE
> due to subnormals, it was due to an uninitialized data read.
I decided to check our local Alpha RedHat Beowulf cluster to see how wide
spread being able to not using -mieee actually is. I did a disassemble of
the installed libraries and grepped them for the ones that performed math
operations (use FP registers other than in a store operation) without traps
(i.e. without -mieee). Only 98 of the 589 installed libraries that use the
FPU are compiled without -mieee. It seems that -mieee is required for the
correct operation of most libraries/programs.
I traced the 98 libraries compiled without -mieee back to their packages. Of
the 50 resulting packages, only one was mathematics related (the GNU
multiprecision arithmetic library). LAPACK, BLAS, etc are all compiled with
-mieee. It looks like -mieee is required for the correct operation of the
vast majority of computational libraries/programs (this is consistent with
what you learn if you do a google search for -mieee and read all the confused
emails from people new to the Alpha architecture).
Probably the situation would be different, if software routines did not
generate denormalized numbers (then we would just have divide by zeros and
such -- which are probably program bugs). This is not the case for GNU based
systems, however, so -mieee is required for the correct operation of the vast
majority of libraries/programs. It would seem reasonable then to make it a
default.
(What is the advantage of not having it as a default? Speeding up apps? What
apps? Certainly not the numerically intensive ones like LAPACK, BLAS, etc --
they all appear to have to be compiled with -mieee. Libtiff (one of the 50)
then? By what? If it only makes a 5% difference to an intensive numerical
simulation, what is it going to do to libtiff? 0.1%? 0.01%?)
> (A) At the extreme minimum, I require that -ffast-math result in
> ieee math off, unless the user has explicitly enabled it for
> some reason.
If someone knows how to do this (I would just put it in the spec file, but the
spec file doesn't not appear to be architecture specific) I would appreciate
hearing from you. Possibly something with the OVERRIDE_OPTIONS macro?
> (B) I do not like a solution that changes the default for just one
> operating system. That's a bit of inconsistency that grates.
> That means you'll need to track down the other users of alpha gcc
> and get agreement. I realize that this will be very difficult --
> indeed, I *intend* for it to be difficult.
For sure, -mieee should be the default on all platforms that don't provide
non-IEEE compliant math libraries and/or -mieee-conformant linking abilities
(I would imagine that would be all GNU based systems). I just made the patch
for Linux as that was the OS I use/am familiar with and hoped users of other
platforms would see it as a good idea and adopt it.
Later -T
PS: I guess you're the defacto Alpha GCC toolchain guy (from what I hear on
the news groups) though, so she's your call. :)
If you change your mind and think it might not be such a bad idea, I'm willing
to take a deeper look into that -ffast-math option, when I get some time, to
see what I can do.
---- END: Tyson ----
He has not yet responded (Aug 27).
Oddly enough, Matthias Klose, of the debian-gcc list, said it would be up to
Chris Chimelis or Falk as to whether it would be accepted. I never heard
peep from either of these with regards to the patch post.
Possibly I'm confused about something.
In anyevent, I can certainly repost it to the debian-gcc list and see if it
will now be accepted as a Debian specific patch. Personally, I still think,
for all the reasons I brought up with Richard, that it is the correct
solution to the Alpha SIGFPE problem.
> Was there an agreement with the Debian-KDE-Maintainers to include this
> fix in the future (at least until -mieee is the default)?
No. I never wrote any bug reports about it because I figured it was easiest
to just attack it at the source. Considering how the 'attack at the source'
has gone so far, I might yet do this. *grin*
Later -T
--
Tyson Whitehead (-twhitehe@uwo.ca -- WSC-)
Computer Engineer Dept. of Applied Mathematics,
Graduate Student- Applied Mathematics University of Western Ontario,
GnuPG Key ID# 0x8A2AB5D8 London, Ontario, Canada
Reply to: