GCL, GMP linkage
Richard Fateman
fateman at cs.berkeley.edu
Thu Dec 18 10:54:09 CET 2003
Camm Maguire wrote:
>.....
>Thanks for this example! Something like this is definitely doable
>(i.e. I think I know how to do it already :-). I also think a generic
>interface of this sort would be quite useful. We'd probably need to
>discuss which of a variety of similar approaches would be best,
>e.g. uffi, before working up a generic interface -- I'm therefore
>cc'ing to the list for discussion. Also have to come to a consensus
>on priority. In the meantime, of course, we can bring forward any
>particular gmp functions you or any other user might find helpful much
>more quickly. Is the set below comprehensive?
>
The set I gave is certainly not all of GMP, but it is all that I needed
for my use of GMP as
a substitute for bignum arithmetic in Allegro CL, for purposes of
polynomial multiplication
benchmarks and cache memory timings. I did not use (for example) GMP
rationals or
any of the number-theoretic functions. So it is comprehensive for my
purposes, but
not all that might be needed.
I think the bindings I use are a superset of the Python bindings, and in
particular
I found big time savings in being able to do fused multiply-add-store
kinds of things,
not possible in the usual functional language settings.
I expect eventually to link to ARPREC, which is a (free) competitor to
GMP, a
successor to MPFUN, by David Bailey. So I can compare them.
...
re loading
>
>
>
>Just wondering, I assume this happens via dlopen.
>
I do not know the mechanism. The lisp "load" function does it.
> What happens in
>Allegro when you "save the system" and restart? Is gmp4l.dll
>automatically reloaded with your bindings?
>
I think this would not be done automatically, but could be specified as
part of
the dumping process that a particular set of dlls must be loaded at restart.
Since I essentially never dump lisp systems, I relearn the process each
time, so
I don't know any details. The manual is online at franz.com. This is
one area
in which the commercial lisps may be more developed than the free ones.
> We have a gcl developer
>(Michael Koehne) working on something similar.
>
Michael: I suggest you look at the specs for Allegro's "dumplisp" or
equivalent, as well
as the Lispworks spec.
>
>>
>>(RJF:..)
>>modest sized ones? I think that huge numbers are not of much real
>>interest. (or
>>should I say rational interest...)
>>but small ones, 1 - 100 decimal digits
>>and especiall 1-6 decimal digits
>>matter a lot.
>>
>>
>Camm:..
>I agree that the case of many modest sized numbers is all that really
>matters. I basically just looked at Vadim's latest maxima benchmark,
>ratsimp((x+y+z)^500)$, using a gmp with generic x86 code and one with
>tuned SSE2 extensions. And I could not see a difference, even when
>the GBC was setup so as not to be the bottleneck. I'd be most
>interested if anyone else has encountered a real case where SSE or
>SSE2 gmp speeds up bignum processing. I've heard that clisp has a
>good gmp setup, but I've not looked into this aspect myself.
>
>
It is very hard to judge what might be of interest. Some people get very
excited about finding
the bazillionth digit of pi. (I think this is silly mysticism,
personally). I have much more
sympathy with getting excited about developing the fastest algorithm for
finding the
bazillionth digit of pi. But this still has to count as applications of
computing to pure math. Try to find funding for that!
Even if you are interested in pure math, you have to agree that the
number of practitioners
is small, and if you think that maxima or other computer algebra systems
are supposed
to be especially devoted to that percentage of pure mathematicians who
are also
interested in computation, then you have a very very small target audience.
This is OK, we all live in niches of some sort....
I have no problem with super-efficient algorithms for odd problems to be
included in
Maxima. I DO have a problem if your interest in computing with
bazillion-digit numbers
makes my counting from 1 to 10,000 slower by a large factor.
RJF
More information about the gmp-discuss
mailing list