On Tue, Mar 5, 2013 at 11:56 PM, Philippe Waroquiers <philippe.waroqui...@skynet.be> wrote: > On Tue, 2013-03-05 at 18:54 +0100, Lionel Cons wrote: >> (1) in https://bugs.kde.org/show_bug.cgi?id=197915#c9 is a joke: >> >Julian Seward 2010-07-12 15:58:25 UTC >> > As per comment #0, adding support for 80-bit floats is low priority, >> > because (1) AIUI the majority of floating point code is portable >> > and restricts itself to 64-bit values, >> >> The majority of _consumer_ software uses using double (aka 64bit >> float), but the majority of _scientific_ software (for example the >> whole NIH bioinformtics software stack or 99.9% of CERNs simulation >> software) is relying on long long double aka 80bit or 128bit floats >> (depending on platform, AMD64 uses 80bits). valgrind is useless for >> such software. > I am not too sure about the proportion of consumer software > versus scientific software. Assuming there is more consumer software, > the note (1) above is not such a joke at the end :). > > Reading the gcc manual, wouldn't it be a good idea to have the > scientific software to be rewritten (or at least compilable) > so as to use sse ? > gcc manual tells for `sse' > The resulting code should be considerably faster in the > majority of cases and avoid the numerical instability
What does 'numerical instability' mean? Unless 387 has bugs I don't know about I think this refers to the general limitations of floating point being implemented using a fixed-width datatype - which wider-than-64bit-double datatypes can partially work around (at least the amount of work to compensate using algorithms like the Kahan summation can be greatly reduced, for example using a Kahan derivative for 64bit floating point requires a 370% overhead to compensate while using a 80bit floating point datatype reduces this to less than 120%). Remember SSE, together with MMX, fall into the category of multimedia accelerators (i.e. designed for throughput and low precision calculations) and are not designed for high precision calculations. This is not an option. Otherwise you have to compensate using the Kahan summation algorithm or similar, which puts the performance win ad absurdum. > problems of 387 code, but may break some existing code that > expects temporaries to be 80bit. It's not the temporaries which have to be 80bit. I think Lionel is referring to the fact that scientific software usually requires the maximum precision available. 64bit double usually will NOT work, at least not with extra work. > > This is the default choice for the x86-64 compiler. > > And as a bonus, you can run it under Valgrind on x86/amd64 :). > If this scientific code is fully portable, Where does the claim come from that this is more portable? If the platform doesn't have a long long double which is wider than double than this is very unfortunate and requires a LOT of extra calculations, but if the platform (like AMD64) supports a wider datatype then it is of course used at all costs. > then you could also decide > to run it under Valgrind e.g. on ppc32/ppc64 systems. > > Note: at my work, we are using Ada/gnat/gcc on x86/amd64. > The application code is compiled with sse. > We contemplated recompiling and/or changing the > Ada runtime to use sse only and fully avoid the 80 bits. > However, as at the end, we found very little impact (at least for > our apps) of running the 80 bits runtime on Valgrind, we have kept > the default gnat runtime (which uses 80 bits floats here and there). > As long as these 80 bits computation are "ok" if computation is > in reality done with 64 bits float, then not much impact. > YMMV. Uh. The impact here is DATA CORRUPTION, caused by doing calculations to be meant using 80bit datatypes being done with 64bit datatypes and the remaining bits filled with garbage. If this can't be solved or is not going to be solved then valgrind should ABORT instead of causing a silent corruption of data. Irek ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
