From: Akshay S. <aks...@gm...> - 2013-04-19 19:41:02
|
Hello, I was wondering if there was interest is adding MPFR along with GMP ? I know bigfloats (as Maxima calls them) is not defined in the standard, but it'd really help systems like (more so than just having bignums through GMP) Maxima and Matlisp (or atleast the one that is in development :) Akshay |
From: Stephan F. <cri...@cs...> - 2013-04-20 06:24:32
|
Hi Akshay, 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. Regs, Stephan |
From: Akshay S. <aks...@gm...> - 2013-04-20 16:02:14
|
Yes, that is a much simper way, but then the trouble is that one can't trivially write one numerical function and use different precisions later on. Using CLOS to shadow #'+, #'- ...(and math functions) is probably going to be quite slow, and one would then have to resort to writing macros which can check for types and then do compile-time "dispatch". I wonder if MOP can be tweaked to achieve this ? Akshay On 19 April 2013 23:24, Stephan Frank <cri...@cs...> wrote: > Hi Akshay, > > 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. > > Regs, > Stephan > |
From: Paul K. <pv...@pv...> - 2013-04-20 10:00:29
|
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 |
From: Pascal J. B. <pj...@in...> - 2013-04-20 10:46:07
|
Paul Khuong <pv...@pv...> writes: > 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. Well with respect to compliance, AFAICR, there's nothing in the Hyperspec saying that the precision of floating point numbers must be constant during program execution. But even if you expect that for conforming code, the letter of the specification is definitely that the precision can change from one implementation to another, and why not, from one invocation of a program to another. So if you set the precision of long floats once for all in a session, it should be 100% guaranteed 100% conforming (as long as it's bigger than the precision of double-float). -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |
From: Akshay S. <aks...@gm...> - 2013-04-20 16:11:39
|
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 <pv...@pv...> 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 > |
From: Stephan F. <cri...@cs...> - 2013-04-20 16:56:58
|
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 <pv...@pv... <mailto:pv...@pv...>> 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 > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Anton K. <an...@sw...> - 2013-04-20 20:40:52
|
"Pascal J. Bourguignon" <pj...@in...> writes: > Well with respect to compliance, AFAICR, there's nothing in the > Hyperspec saying that the precision of floating point numbers must be > constant during program execution. Except LONG-FLOAT-EPSION, that is documented to be constant but has to vary if the floating point precision varies. (That's what we see in CLISP: LONG-FLOAT-EPSION changes when you set (EXT:LONG-FLOAT-DIGITS)). -- Regards, Anton Kovalenko <http://github.com/akovalenko/sbcl-win32-threads/wiki> +7(916)345-34-02 | Elektrostal' MO, Russia |
From: Nikodemus S. <nik...@ra...> - 2013-04-21 16:09:51
|
On 20 Apr 2013 23:43, "Anton Kovalenko" <an...@sw...> wrote: > > "Pascal J. Bourguignon" <pj...@in...> writes: > > > Well with respect to compliance, AFAICR, there's nothing in the > > Hyperspec saying that the precision of floating point numbers must be > > constant during program execution. > > Except LONG-FLOAT-EPSION, that is documented to be constant but has to > vary if the floating point precision varies. (That's what we see in > CLISP: LONG-FLOAT-EPSION changes when you Presumably the same holds for other fp constants as well (most-positive... etc)? This is one of the reasons I wonder if it might be better to implement long floats as regular CMUCL-style 128 bit floats and variable/infinite precision as an extension using the potential number syntax. (Which would also be a neat opportunity to open NUMBER for subclassing, which in turn would open door for supporting units... but that is neither here or now, I guess.) |
From: Paul K. <pv...@pv...> - 2013-04-21 17:31:54
|
Nikodemus Siivola wrote: > On 20 Apr 2013 23:43, "Anton Kovalenko"<an...@sw...> wrote: >> Except LONG-FLOAT-EPSION, that is documented to be constant but has to >> vary if the floating point precision varies. (That's what we see in >> CLISP: LONG-FLOAT-EPSION changes when you > > Presumably the same holds for other fp constants as well (most-positive... > etc)? > > This is one of the reasons I wonder if it might be better to implement long > floats as regular CMUCL-style 128 bit floats and variable/infinite > precision as an extension using the potential number syntax. (Which would > also be a neat opportunity to open NUMBER for subclassing, which in turn > would open door for supporting units... but that is neither here or now, I > guess.) IIUC, rtoym didn't implement quad floats as much as double doubles: they're not "just" floats with 128 bits of significand+exponent+sign, but rather unevaluated (and normalised) sums of two 64 bit doubles. The advantage is that double doubles are easy to implement fairly efficiently on top of hardware double floats. The problem is that they're not exactly like IEEE floats. For one, the exponent range is that for doubles, rather than the one recommended for 128 bit floats. More fundamentally, the precision of the significand varies: in the worst case, we have a sum that covers only 106 bits of precision, but it can go almost arbitrarily high (since any two doubles can be "added" without any loss of precision). That means that there is no universally correct value for long-float-epsilon if long floats are implemented as double doubles. In short, double doubles can't really respect the standard either. Paul Khuong |
From: Nikodemus S. <nik...@ra...> - 2013-04-22 02:45:15
|
On 21 April 2013 20:31, Paul Khuong <pv...@pv...> wrote: > IIUC, rtoym didn't implement quad floats as much as double doubles: they're not "just" floats with 128 bits of Oh, that's interesting. I didn't follow his work in any sort of detail beyond being aware of it. Doesn't really change my stance on arbitrary-precision floats being better an entirely new subclass of NUMBER rather than LONG-FLOAT... Read an interesting discussion pro/contra double-double vs quad floats on the glibc mailing list. To quote: "No one will use software IEEE binary128 and we don't have hardware binary128." ...so there are clearly points in favor of using double-double as long-float today, but there's also a 2012 paper on a lower-cost FMA for binary128, so maybe we'll actually see hardware for it surfacing before too long? One can hope... On similar topic, a 16 bit short float would also neat as well ...but again, neither here or now. :) Cheers, -- Nikodemus |
From: Akshay S. <aks...@gm...> - 2013-04-21 19:23:37
|
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 <cri...@cs...> 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 <pv...@pv... <mailto:pv...@pv...>> > 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 > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > > > |
From: Stephan F. <cri...@cs...> - 2013-04-22 19:45:33
|
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 <cri...@cs... > <mailto:cri...@cs...>> 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 <pv...@pv... > <mailto:pv...@pv...> <mailto:pv...@pv... <mailto:pv...@pv...>>> 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 > > Sbc...@li... > <mailto:Sbc...@li...> > > 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 > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Akshay S. <aks...@gm...> - 2013-04-24 18:16:41
|
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 <cri...@cs...> 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 <cri...@cs... > > <mailto:cri...@cs...>> 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 <pv...@pv... > > <mailto:pv...@pv...> <mailto:pv...@pv... <mailto:pv...@pv...>>> 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 > > > Sbc...@li... > > <mailto:Sbc...@li...> > > > 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 > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > > > |
From: Paul K. <pv...@pv...> - 2013-04-24 18:23:04
|
Akshay Srinivasan wrote: > 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 Didn't you find 1.3k cycles to multiply bignums of ~.5 MB a bit too quick? The compiler elided that multiplication as dead code. Paul Khuong |
From: Stephan F. <cri...@cs...> - 2013-04-24 21:34:17
|
Hi Akshay, no I don't know a good heuristic for switching to GMP yet and coming up with some benchmarks is one of the next steps, though not getting cheated by the compiler and still knowing what is going on performance-wise is not so easy (as you have just seen yourself :-) Waldek switches for a result bignum-length of 40 (which is the number of words/limbs) for addition, though I find that rather large. Also exercising some random tests to check, whether all the upper bounds for the bignum result pre-allocations are correct, would be useful (since GMP does not always behave as expected wrt. to the required memory size; see e.g. my comment for fib2). Currently, I am integrating ratios, though progress is a bit slow as my work projects drain most of my mental energy. Regs, Stephan |