Esa,
What I have written here might not be the most useful guide to
start with, but maybe it is of help for other interested souls.
Many thanks for the notes; it would probably be better if more than
one programmer worked on it.
* The memory handling:
The idea on most bignum libs is that they have c-structure kinda
like this:
struct Big {
word size, used;
digits* payload;
bool sign;
} ;
Now, the size and used tell how much memory is allocated for
payload
and how much of it is used. sign is the sign (plus/minus).
payload is a pointer to memory that contains Integer decoded.
... Before we ...
call math-lib, we put together a temporary structure with correct
pointers. As for target variable, we have hooked the mathlibs
memory allocation functions to allocate correctly. Upon returning
Integer, we just take payload, write sign on correct place and
return the payload-pointer (possibly adjusted).
In pseudo C
digits* add(digits* din) {
Big in, out;
in.size=getLength(din);
in.used=getLength(din);
in.payload=din;
in.sign=getSign(din);
math_lib_init(out);
math_lib_add(out, in);
writeSign(out.payload, out.sign);
return out.payload;
}
Sorry to take more of your time, but what do you mean by allocate
"correctly?"
(This may sound naieve): the in { size, used, payload, sign } are all
parts of the info-table for the payload and the RTS re-initialises
the mathlib on each invocation, right?
In the thread "returning to cost of Integer", John Meacham wrote:
we could use the standard GMP that comes with the system since
ForeignPtr will take care of GCing Integers itself.
From current discussion: at present the allocation is done on the GC
heap, when it could be done entirely by the mathlib. The benefit to
letting the mathlib handle memory would be that you could use the
mathlib with another (non-Haskell) part of your program at the same
time (see, e.g., (bug) Ticket #311).
(I am making an educated guess, here.) You probably chose to allocate
GMP's memory on the GC heap because:
(1) call-outs to another program are inherently impure since the type-
system and execution order are not defined by the Haskell Runtime; and,
(2) it was a stable way to ensure that the allocated memory would
remain available to the thunk for lazy evaluation, i.e., so that the
evaluation of the returned Bignum could be postponed indefinitely,
correct? Or could the evaluation itself be postponed until the value
was called for--making operations on Integers and other Bignums lazy?
In other words, it does not seem possible to simply hold a ForeignPtr
to the returned value unless there were a way to release the memory
when it was no longer needed. If you wanted the mathlib to retain
the value on behalf of GHC, you would have to modify the library
itself. In the end you have a specialized version of the library and
a change to the procedure from:
math_lib_init ; ...
return out.payload ;
to:
math_lib_init ;
math_lib_evaluate ;
math_lib_free ;
An easier though less-efficient alternative would be to have GHC copy
the value returned by the mathlib. That would be stable and allow
other systems to use the same mathlib concurrently (assuming the lib
is thread-safe).
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.)
If I am correct about (2) above, the best conclusion I could draw
from this is that the easiest solution would be to copy the memory on
return from the mathlib.
There are tricky parts for 64bit-stuff in 32bit systems and some
floating point decoding uses bad configure-stuff that depends on
math lib stuff, but mostly it's very boring hundreds of lines of
C-- (but you can make the job much easier by using preprocessor).
I was reading through the Makefiles and headers in ghc's main include
directory about this. 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 seems like it would be a bit more difficult than simply
confirming whether (or how) the C implementation conforms to the
current standard through the usual header system.
This is why APPREC might be hard - you need to know the internal
representation.
GHC C-- unfortunately is not really near the C-- spec, it doesn't
first of all implement it all - but that doesn't matter for this
task - and then it has some extensions for casting and structure
reading, I think.
These are really great suggestions. GHC's codes (including the .cmm
files) seem very well commented.
Fast machine is useful, but tweaking build options
and having a good book/movies/other machine gets it done. It'd be
very very useful to have 64-bit platform (in practice 64bit
linux ia32_64) for testing. I'd say OS X is not a good platform
to do this devel on, but I might be wrong on that. Linux being
best tested OS, it is the most safe bet.
Yes, I have a slow machine to work with but that just means I have
more incentive to think carefully before I try something out. The
64bit part is a problem but that should be well-handled if the
configuration mess could be cleaned up. I have 32bit Linux and
Windows systems I can use (both very slow, as well) but if the fix
holds to the standards it should work...
I am not sure yet, but I might make it easier on myself by cleaning
up the configuration; the move was to Cabalize GHC, but I think that
goal was for the Haskell code since the rest would have to remain in
scripts, anyway. Would it be simpler to move to a more configurable
system like Bakefile or Scons for putting a heterogeneous
construction together?
Best regards,
Peter
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
