This is more or less what I expected. One issue I ran into a lot was that a
double precision real on a Sun workstation was equivalent to single
precision on a Cray.
The trick was that single precision reals were supported in hardware on the
Cray, whereas double precision were software implemented (at least when I
dealt with them). If you just copied and recompiled your Sun code on the
Cray, "double precision" would be the equivalent of quad precision w.r.t.
the Sun - usually overkill for most applications, and slow to boot because
you were not taking advantage of the Cray's hardware-implemented precision.
And you would wonder why your code was slow on the supercomputer... I am
willing to be corrected on this score if this is no longer an issue on the
Cray.
That's why I always just have a standard precision kind and an extended
precision kind and try not to overload based on then. This way I can set
both equal to the same precision if need be.
I do like the idea of _storing_ data in single precision and computing in
double; that seems like a good compromise... unless you're on the Cray,
where double will still get you a performance penalty, I guess. Really, my
concern was usually with speed, not storage.
Alvaro
-----Original Message-----
From: Fortran 90 List [mailto:[log in to unmask]] On Behalf Of
Richard Maine
Sent: Monday, March 15, 2004 1:17 PM
To: [log in to unmask]
Subject: Re: configurable default real
>On Mon, Mar 15, 2004 at 10:49:47AM -0600, Alvaro Fernandez wrote:
>
>> It would be illuminating to me at least to know
>> which applications require 64 vs 32 bit reals, for example.
>
>That's a fairly unknowable question. You can ask what people use, but
>that's partly personal taste.
as well as many other issues. For example, having some applications
that could get by with 32 bits, but others that can't, I usually just use
64 bits as a matter of course, whether I need it or not, unless there
is specific reason otherwise. Sometimes there are specific reasons;
if you have a very large array, the memory difference might be an
issue. But for most codes, it doesn't hurt much to use 64 bits even
if you don't need it. The cost of doing so is a lot less than the
maintenance
costs that result from supporting both options in all support libraries
(not to speak of the extra costs when two modules with different
sizes end up needing to work together).
|