I was looking into the code, and it looked like GMP(through the FFI) was slower than SBCL's
bignums (for bignum length's of ~50000) (for mpz-mul, mpz-add). I know that the FFI overhead costs
quite a lot if one is calling foreign functions for small arguments; and presumably GMP beats
SBCL for larger numbers.
-------------------------------------------------------------------------------------------------------------
GMP-BIGNUM> (progn                                                                                                                                                                
              (time (progn (* *a* *b*) t))                                                                                                                                        
              (time (mpz-mul *a* *b*))                                                                                                                                            
              t)                                                                                                                                                                  
Evaluation took:                                                                                                                                                                  
  0.000 seconds of real time                                                                                                                                                      
  0.000000 seconds of total run time (0.000000 user, 0.000000 system)                                                                                                             
  100.00% CPU                                                                                                                                                                     
  1,334 processor cycles                                                                                                                                                          
  0 bytes consed                                                                                                                                                                  
                                                                                                                                                                                  
Evaluation took:                                                                                                                                                                  
  0.061 seconds of real time                                                                                                                                                      
  0.060000 seconds of total run time (0.060000 user, 0.000000 system)                                                                                                             
  98.36% CPU                                                                                                                                                                      
  126,403,630 processor cycles                                                                                                                                                    
  865,584 bytes consed                                                                                                                                                            
---------------------------------------------------------------------------------------------------------------

It didn't look like the macros in mpz-mul were doing anything more that allocating
memory and freeing it; but ~0.5MB should be allocated in a jiffy in SBCL (if array
allocation is anything to go by). Am I doing something wrong ?

Stephan: Do you know at what point using GMP would be more beneficial ? I remember
vaguely that GMP uses both Karatsuba and FFT for multiplication, which would be
scale very nicely against SBCL, if SBCL's routines only use the naive O(n^2) algorithm.
I should dig through the source.

Akshay

On 22 April 2013 12:45, Stephan Frank <crimsonf@cs.tu-berlin.de> wrote:
Hi all,

since there was some interest, you can find what I have so far at
https://github.com/sfrank/sb-gmp

Note, that there is no transparent integration/replacement for the SBCL
bignum operations yet. This part is quite simple (Waldek has already
shown how for simple arithmetic operations), but we most certainly want
to do some benchmarking first to find the sweet spot wrt. to bignum size
for when to make the switch from the SBCL internal versions to the GMP
variants. Should work with GMP >=5.0

Regs,
Stephan

On 04/21/2013 09:23 PM, Akshay Srinivasan wrote:
> I can then probably start off by integrating your code for GMP with
> SBCL, and then
> start work on MPFR. That'd be very nice indeed :)
>
> Akshay
>
>
> On 20 April 2013 09:56, Stephan Frank <crimsonf@cs.tu-berlin.de
> <mailto:crimsonf@cs.tu-berlin.de>> wrote:
>
>     Well, if it helps with your decision process: I have a mostly complete
>     GMP connection for SBCL (currently only for integers, though rationals
>     should be easy to extent; that's my next step). It was a project I had
>     considered for a longer time already and Paul's GSoC description sparked
>     my interest anew. I have kept it under wraps so far (apart from some
>     communication with Paul) because I didn't want to discourage a potential
>     student from participating in GSoC.
>
>     However, looking at my project schedule at work there are several things
>     from Pauls project suggestion that will definitely not happen by me in
>     the foreseeable future: extensive unit tests; GMP algorithms in Lisp for
>     SBCL. So you might want to expand on that or take on your MPFR proposal.
>
>     Regs,
>     Stephan
>
>     On 04/20/2013 06:11 PM, Akshay Srinivasan wrote:
>     > I wonder if I can pitch the MPFR integration itself as a project for
>     > GSoC; I'm afraid this is what I'd want SBCL to have more (well the
>     > bignums are already there :), but also that it is of a much lower
>     > priority than adding GMP support.
>     >
>     > Akshay
>     >
>     >
>     > On 20 April 2013 03:00, Paul Khuong <pvk@pvk.ca
>     <mailto:pvk@pvk.ca> <mailto:pvk@pvk.ca <mailto:pvk@pvk.ca>>> wrote:
>     >
>     >     Stephan Frank wrote:
>     >
>     >         but wouldn't a library with bindings to MPFR (using CFFI) not
>     >         make more
>     >         sense? Maxima (and I suppose matlisp as well) have to
>     implement
>     >         their
>     >         own bigfloats data type anyway whereas the GMP integration
>     has the
>     >         chance of being tightly and transparently integrated with the
>     >         underlying
>     >         bignum implementation of SBCL. I could only see an
>     advantage when
>     >         tightly coupling it with CMUCL's quad-floats.
>     >
>     >
>     >     We may still do something useful with long-floats. That type is
>     >     currently equivalent to double-float, but there's nothing that
>     makes
>     >     the situation necessary. IIRC, CLISP's long floats are arbitrary
>     >     precision. I'm not completely sure what that means for standard
>     >     compliance, but I'm also somewhat open to interpreting the
>     standard
>     >     loosely if the looseness only affects long float values.
>     >
>     >     However, integrating MPFR for long floats is likely to be more
>     work
>     >     than plugging GMP in SBCL's bignums. We'd have to re-create a
>     >     long-float type, likely fiddle with numeric bounds
>     propagation, and
>     >     (this final part is much more easy) define a concrete
>     representation
>     >     for long floats and tell the GC about.
>     >
>     >     Paul Khuong
>     >
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Precog is a next-generation analytics platform capable of advanced
>     > analytics on semi-structured data. The platform includes APIs for
>     building
>     > apps and a phenomenal toolset for data science. Developers can use
>     > our toolset for easy data analysis & visualization. Get a free
>     account!
>     > http://www2.precog.com/precogplatform/slashdotnewsletter
>     >
>     >
>     >
>     > _______________________________________________
>     > Sbcl-devel mailing list
>     > Sbcl-devel@lists.sourceforge.net
>     <mailto:Sbcl-devel@lists.sourceforge.net>
>     > https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>     >
>
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
>
> _______________________________________________
> Sbcl-devel mailing list
> Sbcl-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>