[Openmcl-devel] Bignums using GMP.

[Waldek Hebisch]

Gary Byers wrote:
> This is great, thanks.
> 
> On Sat, 13 Feb 2010, Waldek Hebisch wrote:
> 
> > Attached are two files which together cause Closure CL to use GMP
> > for bignum arithmetic.  The routines are specific to 64-bit Amd
> > (and Intel) architecture.
...
> > Comments welcame.  In particular what is best method to
> > make sure that multiplication works OK after starting
> > from saved image.  For my purpose I modified Closure CL
> > kernel makefile to link in my C routines and GMP.  But
> > without linking GMP to Lisp kernel there is risk that
> > replacement bignum routines will try to use GMP before
> > it is loaded (IIUC saved core image will contain
> > replacement bignum routines, but have no access to GMP
> > before it is explicitely loaded).
> >
> > I wonder if there is interst to include such routines in
> > Closure CL (possibly as optional feature, if depending on
> > GMP is considered undesirable).
> 
> If GMP was bundled/preinstalled with all platforms, it'd be
> considerably more desirable than it is. (When it is bundled -
> or available via things like Cygwin/MacPorts/Fink - there
> might also be issues with version dependencies.  I honestly
> don't know whether the GMP APIs of interest change between
> releases or not.)
> 

AFAIK GMP API is relatively stable, so hope that version
changes should not be a problem.  It is worth noting that
currently Gnu C compiler uses GMP (via MPFR library),
which means that GMP should be widely available.

> Depending on it may be undesirable, but there isn't much
> downside to being able to exploit it if it's present.
> 
> I haven't looked at your code yet, but I wonder if it'd
> be possible to do that exploitation via something like:
> 
> (defvar *use-gmp* nil) ; initially
> 
> ;;; Implementation
> (defun multiply-bignums (x y)
>    (if *use-gmp*
>      (gmp-multiply-bignums x y)
>      ;; fall back to legacy, non-GMP implementation
>      ...))
> 
> ----
> (defun load-gmp ()
>    (open-shared-library *gmp-library-path*) ; may be platform/site-specific
>    (require "GMP-SUPPORT") ; (re)define GMP-MULTIPLY-BIGNUMS
>    ;; If we get this far and all is well,
>    (setq *use-gmp* t))
> ----
> (defun save-application (...)
>    (setq *use-gmp* nil)
>    ...)
> 

Yes, having flag variable should work.  There is a little tricky point:
ATM I  need to redefine current routines in CCL package, but the
code above need access to original routines.  Currently I need
access to original multiplication, so I use the following:

(if (not (fboundp 'orig-multiply-bignums))
    (setf (symbol-function 'orig-multiply-bignums)
          (symbol-function 'ccl::multiply-bignums)))

and after that I redefine ccl::multiply-bignums.

> The image-startup code will try to re-open shared libraries that
> were open when the image was saved.  If it fails, it should do
> so quietly and leave foreign functions defined in the missing
> library undefined.  If it's successful in loading libgmp and
> the lisp's GMP support is present, some other startup code
> sets *use-gmp* to true and the image should ... use GMP; if
> the gmp library isn't present, that shouldn't prevent the
> image from starting up.
> 
> As you point out, there may be some incidental bignum arithmetic in
> the startup code before we even get to this point.  Assuming that
> the idea sketched out above actually works, that incidental bignum
> arithmetic wouldn't depend on gmp's presence (if it's "incidental",
> that shouldn't matter.)
> 
> That's all secondary: the harder part (providing GMP-based implementations
> of CCL's bignum functions) sounds like it's already done.  Thanks!
> 
 
Well, for production use there is still work to be done: the code
is 64-bit and Intel/Amd specific.  32-bit logic should be simpler,
but differs a bit.  Diffferences can probably be hidden via some
simple macrology, but that is still too do.  LAP routines
must be different between 64 and 32 bit version.  And Power PC
also needs different LAP routines.  C code may need some changes
on different platforms...

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl