BigNum optimizations

Time for multiplication of BigNums grows quadratically with number of
digits (ruby 1.8.7). And in ruby 1.9 is lower than in ruby 1.8:

require 'benchmark'

Benchmark.bmbm do |b|
  [100, 200, 400, 800, 1600].each do |n|
    num = 1123 ** n
    b.report "#{n}" do
      1000.times{num*num}
    end
  end
end

ruby -v a.rb

ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
Rehearsal ----------------------------------------
100 0.010000 0.000000 0.010000 ( 0.010418)
200 0.030000 0.000000 0.030000 ( 0.036871)
400 0.130000 0.000000 0.130000 ( 0.125760)
800 0.460000 0.000000 0.460000 ( 0.482740)
1600 1.810000 0.000000 1.810000 ( 1.903963)
------------------------------- total: 2.440000sec

           user system total real
100 0.020000 0.000000 0.020000 ( 0.008206)
200 0.020000 0.000000 0.020000 ( 0.029941)
400 0.120000 0.000000 0.120000 ( 0.115787)
800 0.460000 0.000000 0.460000 ( 0.459517)
1600 1.770000 0.020000 1.790000 ( 1.807655)

Exit code: 0

$ ruby1.9 -v a.rb
ruby 1.9.0 (2008-06-20 revision 17482) [i486-linux]
Rehearsal ----------------------------------------
100 0.020000 0.000000 0.020000 ( 0.013167)
200 0.040000 0.000000 0.040000 ( 0.046076)
400 0.150000 0.000000 0.150000 ( 0.150487)
800 0.540000 0.010000 0.550000 ( 0.589719)
1600 2.200000 0.000000 2.200000 ( 2.258581)
------------------------------- total: 2.960000sec

           user system total real
100 0.000000 0.000000 0.000000 ( 0.009808)
200 0.040000 0.000000 0.040000 ( 0.037194)
400 0.140000 0.000000 0.140000 ( 0.144723)
800 0.560000 0.000000 0.560000 ( 0.587338)
1600 2.210000 0.000000 2.210000 ( 2.254998)

Exit code: 0

+1 for making it faster, i.e. N log N.

It looks like BigNum will be faster in next release
(http://redmine.ruby-lang.org/search/index/ruby-19?q=Karatsuba\), is it
true?
But why Karatsuba? It is only O(N**1.585) while Schönhage–Strassen is
O(N log N).

I guess it is more reasonable to implement

or take use of any GPL soft

See also talk http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/77470
dated 30 Jul 2003

Artem Voroztsov

Hi,

+1 for making it faster, i.e. N log N.

It looks like BigNum will be faster in next release
(http://redmine.ruby-lang.org/search/index/ruby-19?q=Karatsuba\), is it
true?

True.

% ruby -v a.rb
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
Rehearsal ----------------------------------------
100 0.020000 0.000000 0.020000 ( 0.024290)
200 0.070000 0.000000 0.070000 ( 0.072934)
400 0.120000 0.000000 0.120000 ( 0.123551)
800 0.490000 0.000000 0.490000 ( 0.514302)
1600 1.900000 0.000000 1.900000 ( 1.971061)
------------------------------- total: 2.600000sec

           user system total real
100 0.010000 0.000000 0.010000 ( 0.015825)
200 0.030000 0.000000 0.030000 ( 0.048896)
400 0.120000 0.000000 0.120000 ( 0.124947)
800 0.480000 0.000000 0.480000 ( 0.490557)
1600 1.900000 0.000000 1.900000 ( 1.905196)

% ruby1.9 -v a.rb
ruby 1.9.2dev (2009-03-15 trunk 22972) [i686-linux]
Rehearsal ----------------------------------------
100 0.020000 0.000000 0.020000 ( 0.030905)
200 0.040000 0.000000 0.040000 ( 0.045328)
400 0.080000 0.000000 0.080000 ( 0.084670)
800 0.250000 0.000000 0.250000 ( 0.275130)
1600 0.770000 0.000000 0.770000 ( 0.796491)
------------------------------- total: 1.160000sec

           user system total real
100 0.010000 0.000000 0.010000 ( 0.007731)
200 0.020000 0.000000 0.020000 ( 0.026167)
400 0.070000 0.000000 0.070000 ( 0.092874)
800 0.260000 0.000000 0.260000 ( 0.256951)
1600 0.770000 0.000000 0.770000 ( 0.807816)

But why Karatsuba? It is only O(N**1.585) while Schönhage–Strassen is
O(N log N).

It's matter of the resource we have. If some one would volunteer to
implement it, we'd love to merge.

              matz.

···

In message "Re: BigNum optimizations" on Tue, 17 Mar 2009 07:49:20 +0900, Artem Voroztsov <artem.voroztsov@gmail.com> writes:

It might be easier to link to a standard open-source multi-precision
library that it would be to revise the one that's built into the Ruby
interpreters. I haven't benchmarked these against each other, but the
two I know about are GMP http://gmplib.org/ and CLN
http://www.ginac.de/CLN/\. Both are GPL. GMP is available in just about
every Linux distro I know about; CLN may be a little harder to find,
but it's in Debian and Gentoo. I don't know about other platforms, but
at least GMP is "pure-enough" GNU that it should compile on Windows
and Macs and Solaris.

Ezra ... is this something Engine Yard could do for 1.8.6 / Rubinius?
I think the jRuby people are working on their Bignum performance too.

···

On Mon, Mar 16, 2009 at 4:23 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Hi,

In message "Re: BigNum optimizations" > on Tue, 17 Mar 2009 07:49:20 +0900, Artem Voroztsov <artem.voroztsov@gmail.com> writes:

>+1 for making it faster, i.e. N log N.
>
>It looks like BigNum will be faster in next release
>(http://redmine.ruby-lang.org/search/index/ruby-19?q=Karatsuba\), is it
>true?

True.

% ruby -v a.rb
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
Rehearsal ----------------------------------------
100 0.020000 0.000000 0.020000 ( 0.024290)
200 0.070000 0.000000 0.070000 ( 0.072934)
400 0.120000 0.000000 0.120000 ( 0.123551)
800 0.490000 0.000000 0.490000 ( 0.514302)
1600 1.900000 0.000000 1.900000 ( 1.971061)
------------------------------- total: 2.600000sec

      user     system      total        real

100 0.010000 0.000000 0.010000 ( 0.015825)
200 0.030000 0.000000 0.030000 ( 0.048896)
400 0.120000 0.000000 0.120000 ( 0.124947)
800 0.480000 0.000000 0.480000 ( 0.490557)
1600 1.900000 0.000000 1.900000 ( 1.905196)

% ruby1.9 -v a.rb
ruby 1.9.2dev (2009-03-15 trunk 22972) [i686-linux]
Rehearsal ----------------------------------------
100 0.020000 0.000000 0.020000 ( 0.030905)
200 0.040000 0.000000 0.040000 ( 0.045328)
400 0.080000 0.000000 0.080000 ( 0.084670)
800 0.250000 0.000000 0.250000 ( 0.275130)
1600 0.770000 0.000000 0.770000 ( 0.796491)
------------------------------- total: 1.160000sec

      user     system      total        real

100 0.010000 0.000000 0.010000 ( 0.007731)
200 0.020000 0.000000 0.020000 ( 0.026167)
400 0.070000 0.000000 0.070000 ( 0.092874)
800 0.260000 0.000000 0.260000 ( 0.256951)
1600 0.770000 0.000000 0.770000 ( 0.807816)

>But why Karatsuba? It is only O(N**1.585) while Schönhage–Strassen is
>O(N log N).

It's matter of the resource we have. If some one would volunteer to
implement it, we'd love to merge.

                                                   matz\.

--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

Hi,

···

In message "Re: BigNum optimizations" on Wed, 18 Mar 2009 04:11:34 +0900, "M. Edward (Ed) Borasky" <zznmeb@gmail.com> writes:

It might be easier to link to a standard open-source multi-precision
library that it would be to revise the one that's built into the Ruby
interpreters. I haven't benchmarked these against each other, but the
two I know about are GMP http://gmplib.org/ and CLN
http://www.ginac.de/CLN/\. Both are GPL.

We cannot link pure GPLed library to Ruby for licensing issue. Last
time I checked none of these multi precision numeric libraries
satisfied our criteria (license, portability, etc). GMP (or CLN or
whatever) can be used via extension, and we are happy to offer help if
required.

              matz.

M. Edward (Ed) Borasky wrote:

Ezra ... is this something Engine Yard could do for 1.8.6 / Rubinius?
I think the jRuby people are working on their Bignum performance too.

We're mostly just wrapping the JDK's builtin BigInteger class, which is not known for its scorching performance. BigInteger.doubleValue actually passes the number through a a String and re-parses it (a contributor implemented a replacement, for obvious reasons). There are alternative libraries, but we have not merged them in to avoid bloating the size of JRuby's distribution.

Of course almost all of them can be called directly through our Java integration layer, so if people need the performance they can do that. Java 7 is supposed to include a number of performance improvements for BigInteger as well.

We would not decline a clean-room implementation of Bignum that uses the latest and greatest algorithms :slight_smile: It would probably be easier in Java than in C.

- Charlie

Hi,

>It might be easier to link to a standard open-source multi-precision
>library that it would be to revise the one that's built into the Ruby
>interpreters. I haven't benchmarked these against each other, but the
>two I know about are GMP http://gmplib.org/ and CLN
>http://www.ginac.de/CLN/\. Both are GPL.

We cannot link pure GPLed library to Ruby for licensing issue. Last
time I checked none of these multi precision numeric libraries
satisfied our criteria (license, portability, etc). GMP (or CLN or
whatever) can be used via extension, and we are happy to offer help if
required.

I just checked ... GMP is LGPL. Would that work?

···

On Tue, Mar 17, 2009 at 5:56 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

In message "Re: BigNum optimizations" > on Wed, 18 Mar 2009 04:11:34 +0900, "M. Edward (Ed) Borasky" <zznmeb@gmail.com> writes:

                                                   matz\.

--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

Hi,

···

In message "Re: BigNum optimizations" on Wed, 18 Mar 2009 10:01:07 +0900, "M. Edward (Ed) Borasky" <zznmeb@gmail.com> writes:

We cannot link pure GPLed library to Ruby for licensing issue. Last
time I checked none of these multi precision numeric libraries
satisfied our criteria (license, portability, etc). GMP (or CLN or
whatever) can be used via extension, and we are happy to offer help if
required.

I just checked ... GMP is LGPL. Would that work?

Well, it's not impossible (i.e. 1.8 regex was LGPL), but not ideal.
Some commercial Ruby users had to replace 1.8 regex by Oniguruma only
for a license issue. I don't want to see same situation for bignums.

              matz.

How about libtommath/libtomfastmath ? there is a gem of it available:

    http://math.libtomcrypt.com/

enjoy,

-jeremy

···

On Wed, Mar 18, 2009 at 10:10:45AM +0900, Yukihiro Matsumoto wrote:

Hi,

In message "Re: BigNum optimizations" > on Wed, 18 Mar 2009 10:01:07 +0900, "M. Edward (Ed) Borasky" <zznmeb@gmail.com> writes:

>> We cannot link pure GPLed library to Ruby for licensing issue. ?Last
>> time I checked none of these multi precision numeric libraries
>> satisfied our criteria (license, portability, etc). ?GMP (or CLN or
>> whatever) can be used via extension, and we are happy to offer help if
>> required.
>
>I just checked ... GMP is LGPL. Would that work?

Well, it's not impossible (i.e. 1.8 regex was LGPL), but not ideal.
Some commercial Ruby users had to replace 1.8 regex by Oniguruma only
for a license issue. I don't want to see same situation for bignums.

--

Jeremy Hinegardner jeremy@hinegardner.org

Yeah ... the PostgreSQL community mostly uses BSD-style licenses
specifically because of the "chilling effect" of GPL on commercial
users. Actually, given that a lot of BigNum work came out of MIT, I'm
surprised there isn't an MIT-licensed BigNum library running around
somewhere. Let me dig around into what's in Sage (sagemath.org) and
what's in Python. This is a wheel we shouldn't have to re-invent or
even re-code. :slight_smile:

···

On Tue, Mar 17, 2009 at 6:10 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

>I just checked ... GMP is LGPL. Would that work?

Well, it's not impossible (i.e. 1.8 regex was LGPL), but not ideal.
Some commercial Ruby users had to replace 1.8 regex by Oniguruma only
for a license issue. I don't want to see same situation for bignums.

                                                   matz\.

--
M. Edward (Ed) Borasky
http://www.linkedin.com/in/edborasky

I've never met a happy clam. In fact, most of them were pretty steamed.

Hi,

···

In message "Re: BigNum optimizations" on Fri, 20 Mar 2009 12:07:50 +0900, Jeremy Hinegardner <jeremy@hinegardner.org> writes:

How about libtommath/libtomfastmath ? there is a gem of it available:

   http://math.libtomcrypt.com/

It's public domain. We will have no licensing problem. The only
concern is that the last release was April 2006. I hope it does not
have any issues.

              matz.