[racket] 80-bit precision in Racket
Your plan sounds workable, but I wonder whether you'll want the JIT to
unbox extnums in the same way that it unboxes flonums. That's not as
easy as the rest of the plan, but generalizing Racket's unboxing
machinery to deal with more types is something that we can consider.
At Fri, 09 Nov 2012 17:56:08 +0400, Dmitry Pavlov wrote:
> Hello,
>
> First, congratulations with Racket 5.3.1 release.
> We are using Racket for our research project in
> astronomy and we are very satisfied with it.
>
> However, now we have come to the point where we
> need extended precision (80-bit) for floating-point
> numbers. We have seen some work done by Neil Toronto
> in his development branch on "bigfloat" numbers based
> on GNU MPFR library. But MPFR has poor performance as
> opposed to native 80-bit calculations, so we need
> something that is translated to native code--something
> like flonum-s and flvector-s, but for 80-bit numbers.
> Let us call them extnum-s and extvector-s.
>
> We need extnums and extvectors badly and we are
> considering to implement them in Racket on our own,
> i.e. fork Racket and hack it to support extended precision.
>
> Some preliminary technical information:
>
> * It is unlikely that we will be able to (or need to)
> change Racket's real-number primitives to extended
> precision, nor alter the behavior of arithmetic
> operations like +, and sin/cos/etc. We will rather
> add a new set of operations called ext+, extsin etc.,
> and their "unsafe-" counterparts, and also
> real<->extnum conversion.
>
> * We plan to add the necessary functionality to Racket JIT
> to make it handle 80-bit numbers. Racket JIT relies
> on GNU Lightning, and currently it handles real numbers
> with jit_*** instructions. Lightning can translate
> these instructions into FPU or SSE instructions, depending
> of the flags Lightning itself was compiled with. Lightning
> currently can not do 80-bit instructions. We are going to
> implement 80-bit instructions in Lightning, and to avoid
> messing up the behavior of Racket's reals, we will do a
> new set of jit_fpu_*** instructions, separate from jit_***,
> and devoted to 80-bit numbers exclusively.
>
> * Racket's runtime currently sets FPU to "standard" mode,
> which makes 64-bit floating-point operations
> IEEE-compliant (i.e. no internal 80-bit operations).
> Obviously we can not do 80-bit computations in standard
> mode, so we will have to set the FPU to "extended" mode
> instead. That can make existing Racket programs give
> /slightly/ different results with floating-point
> computations. In case that is an issue for users, it
> seems that we can work it around by forcing the 64-bit
> calculations to be done with SSE. That is, we can set
> MZ_USE_JIT_SSE *and* --mfpmath=sse when compiling Racket,
> and then all 64-bit fp operations will be done on SSE
> and not FPU, so they will be IEEE-compliant. 80-bit
> operations will be done on FPU anyway as SSE can not
> do them.
>
> * Our primary platform is Linux on x86, but we want to
> make extnums available on Windows, too. It is known
> that MSVC does not support 80-bit "long double" type.
> So we can not use MSVC for our Racket build. The other
> options are:
> - cygwin: seems to be supported currently by Racket, but
> can not provide native Windows controls etc.
> - mingw: probably should compile Racket with its gcc
> (given that Racket compiles with cygwin's gcc), and
> *can* provide native Windows controls etc.
> - Intel C compiler: probably gives the best performance
> for floating-point computations, yet it does not miss
> Winapi, but it is not known whether it is able to
> build Racket.
>
>
> We have a full-time person for the job, and we tend to
> think that it will take a month or so.
>
> Questions to you noble gentlemen:
>
> 1. Does the plan look realistic to you?
> Are there any difficulties we have missed?
>
> 2. Maybe we are cutting blocks with a razor here?
> If there is any simpler way to have native 80-bit
> floating point in Racket (say Racket->ASM compilation,
> Racket->C, LLVM, anything), please do tell me.
>
> 3. If the work is done, will you merge it into the
> upstream Racket? We will be extremely pleased if
> extnums become available in the official distribution.
>
> 4. Does anybody have any experience in building Racket
> with mingw or Intel?
>
>
> Best regards,
>
> Dmitry
> ____________________
> Racket Users list:
> http://lists.racket-lang.org/users