[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gm2] REAL precision
Re: [Gm2] REAL precision
Thu, 25 Jun 2009 20:57:46 +0100
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Andreas Fischlin <address@hidden> writes:
> I fully go along with this argumentation and want only to add that we are in
> exactly the same position. Using here compiler options may be a very good way
> out, giving possibly all the flexibility needed for everyone. Although that
> option would result in repercussions for any binary distributions, which would
> have to come with several library variants for standard numeric libraries.
> SiTex Graphics wrote:
> Our applications store huge numbers of REALs and perform many, many
> floating-point operations. I'd like the handling of floating point
> arithmetic to be as efficient as possible. Doubling the storage
> requirements for REAL is not an acceptable option for us.
> I can of course search/replace and switch REAL-> SHORTREAL and
> LONGREAL->REAL. Then I have to add type casts for calls to the ISO
> RealMath functions and any other standard libs that expect REAL
> values. Then we're still probably taking a performance hit for
> double-precision computations in cases where the extra precision is
> not needed. Anyone else trying to port an application that makes
> heavy use of REALs will face the same issues.
> On the other side of the issue, is anyone actually using long double
> arithmetic in GM2?
> As a prospective user of GM2, support for existing code compatible
> with other M2 compilers is far more important than a new feature that
> I can't even consider using until our existing code compiles and
> performs reasonably.
> What about adding a LONGLONGREAL type for long double (with
> LONGREAL=double and REAL=float)? That convention would provide
> compatibility with existing code and access to extended precision. It
> would also leave SHORTREAL available for some day supporting the new
> 16-bit half precision type.
Hi Andreas and Scott,
thanks for the feedback on REAL/LONGREAL. I've been looking into some
of the possibilities of changing gm2:
(i) leave things as they are. Not really satisfactory as has been
outlined above.. however at least we don't have
incompatible binaries on the same system.
(ii) provide options to ./configure which determine the mappings
of REAL/SHORTREAL/LONGREAL. Could be done at some cost -
particularly testing and future bug reporting become
problematic. In reality it passes the problem we are
discussing to the distros..
(iii) provide command line switches (less bad than (ii) but we
will need to double the copy of the libraries binaries).
Bug reporting and maintainance will be harder.
(iv) change gm2 so that LONGREAL maps onto C double
REAL maps onto C float
LONGLONGREAL maps onto C long double
the LONGLONGREAL is a little unsightly :-), and we loose
SHORTREAL. But at least the code only maps onto one set
of data types.
(v) How about introducing more short library modules, so we have
MathLib0.def exports all REAL intrinsics
SMathLib0.def exports all SHORTREAL intrinsics
LMathLib0.def exports all LONGREAL intrinsics
FpuIO exports all REAL io routines
LFpuIO exports all LONGREAL io routines
SFpuIO exports all SHORTREAL io routines
RealMath exports all REAL intrinsics
LongMath exports all LONGREAL intrinsics
ShortMath exports all LONGREAL intrinsics
for any math library provide a Long, Short, Real
Finally provide a LegacyMath.def which contains the
DEFINITION MODULE LegacyMath ;
REAL = SHORTREAL ;
after which a user module only needs to have its imports
changed to access the appropriate floating point routines
and an additional FROM LegacyMath IMPORT REAL ;
The advantage with this approach is that we do not have
incompatible binaries on the same system from the same source
files. Also SHORTREAL library
routines and intrisincs will be very efficient and require
no conversions to higher precision counterparts. The extra
work involved is also pretty minor?
anyway I put this email out as food for thought, I'm not ruling out
(i)..(iv) but I would like to explore whether (v) is acceptable
or whether the volume of legacy code makes this impracticable