Replacement for GMP
p.tanski at gmail.com
Wed Aug 2 01:18:58 EDT 2006
Another great instructive email! Thanks again! I will keep this
response short because I am sure you are busy and you have been more
than helpful so far. I also need to get back to working through the
> I hope my answer helps, but if it gets you more confused,
> maybe it's just because I'm confused...
No, you are just trying to understand what I am saying and since I am
new to GHC's rts internals I do not yet have the knowledge to express
my thoughts well.
> There are other nicer things about that as well - untying Integer
> (atleast mostly) from runtime/frontend and moving it more into
> domain of libraries.
> Another program? I assume you meant outside pure haskell - "call-
> have side-effects. We can get around by using unsafePerformIO,
> which doesn't really differ that much from writing it in
> C-- (and library in C), except we'd write haskell.
If the program (written in C--, C, C++, whatever) and the interface
from Haskell to that program were well-typed it would not be any
different than writing the entire program in Haskell, but the order
of execution must remain in sync with the Haskell program. If the
rts is threaded or parallel you might imagine problems cropping up.
In this case I have to evaluate whether, say, OpenSSL's BN library is
threaded (or, for Parallel Haskell, also working through PVM), not
merely thread safe and certainly not merely reentrant.
> Uhm, naturally, haskell rts needs to control lifetime of the memory.
> I am not sure what you're trying to say here, really. Is the point
> that we cannot free almost anything without permission from
> garbage collector? Because, yeah, we can't.
My problem was not with the garbage collector but with what the
garbage collector depends on: when an object is evaluated and no
longer in scope.
I am not insane enough to attempt writing high level mathematical
operations such as pow() or sqrt() as primitives in an integrated
Bignum implementation, but you might be able to imagine that at that
level it would be possible to choose when to save and when to
evaluate parts of a long equation.
> As I understand, you suggest here copying payload instead of merging
> memory handling. I don't think it's clearly, if ever, less efficient
> than ForeignPtr-based approach. But I'd guess it is *more* code
> than current solution.
>> The third alternative I suggested previously was to embed the Bignum
>> processing in GHC itself. I think it would be very difficult to
>> maintain a solution that was both optimised and portable, at least in
>> C--. (I may be way-off here; I am simply going by a rudimentary
>> knowledge of BLAST implementations.)
> I don't think it differs much from doing the same in C.
> It does seem shame to write bignum in C--, as we don't get many
> elegance-style advantages from writing it in C-- instead of C.
> <cut and paste from below>
> As for what it has to do with topic at hand, I have no idea.
> C-- is simply used as an intermediate language for the compiler, for
> convience of calling conventions and such, some low-level operations
> are written in it.
When I mentioned BLAS (not "BLAST", sorry) implementations I meant
that--as I understand it--some may contain hand-optimised code
written in assembler. Certainly I would personally prefer
implementing something in C but as you noted C-- allows GHC more
convenience. C-- may also allow GHC to manipulate fragments and
produce native code in ways that may not be possible to express in C,
including the Bignum implementation. I don't know whether GHC takes -
fasm to this extent, that is, further than patching object code from
a Bignum library, but that I think that is one of the long-term goals.
>> ... One of the big ToDo's seems to be to correct the
>> method of configuring this stuff using machdep.h or the equivalent
>> on a
>> local system, such as the sysctl-headers on Darwin. For C-- this
>> like it would be a bit more difficult than simply confirming
>> whether (or
>> how) the C implementation conforms to the current standard through
>> usual header system.
> Neither C or C-- was meant to be used to detect what system can do.
> It is simply a byproduct, which autotools takes to the extreme.
I meant that the autotools determine the correct configuration--the
big ToDo--and that C or C-- code must be written to conform to the
configuration that the autotools found. C would certainly be the
easiest; C-- would mean reaching deep into the specs. C would also
open the possibility for optimisations from compilers and system
libraries that would not be available to C--. One more reason to use
a separate Bignum library...
More information about the Glasgow-haskell-users