[#3479] Missing .document files for ext/ libraries — Brian Candler <B.Candler@...>

The ri documentation for zlib, strscan and iconv doesn't get built by 'make

12 messages 2004/10/06

[#3492] Re: ANN: Free-form-operators patch — Markus <markus@...>

> In message "Re: ANN: Free-form-operators patch"

15 messages 2004/10/11
[#3493] Re: ANN: Free-form-operators patch — Yukihiro Matsumoto <matz@...> 2004/10/11

Hi,

[#3495] Re: ANN: Free-form-operators patch — Markus <markus@...> 2004/10/12

On Mon, 2004-10-11 at 16:16, Yukihiro Matsumoto wrote:

[#3561] 1.8.2 - what can we do to help? — Dave Thomas <dave@...>

Folks:

23 messages 2004/10/26
[#3562] Re: 1.8.2 - what can we do to help? — Yukihiro Matsumoto <matz@...> 2004/10/27

Hi,

Fwd: Re: GMP

From: "trans. (T. Onoma)" <transami@...>
Date: 2004-10-29 18:05:38 UTC
List: ruby-core #3635
Hi ---

I contacted Tomasz Wegrzanowski <taw@users.sf.net> concerning is work with 
Ruby bindings for GMP, to see what insights he could provide. Very 
enlightenting.

---- Extracted reply of Tomasz Wegrzanowski:

I included some benchmarks with Ruby GMP, which compare the performance
 against Ruby Bignum and against C GMP.

The numbers I got are here:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/29707

Ruby BigNum was faster than Ruby GMP for small bignums, probably because the
 cost of all the method calls was a lot greater than the actual bignum
 computation (bmark3.rb and bmark4.rb try to compute the point at which it's
 better to use GMP::Z than Ruby Bignum)

I don't know how much this overhead could be reduced by putting GMP closer to
 Ruby core.

Ruby Bignum also has some kind of optimization for numbers ending with
long strings of 0s. GMP doesn't have such thing. I don't think such
 optimization is important for real computations, just don't make benchmark
 testing performance of (2**n) * (2**m) multiplication.

The performance I expect:
* For "small" bignums, like 128 or even 1024 bit, using GMP::Z is going to be
 slower, unless the object overhead is seriously reduced
* GMP::Z will be much (like 10:1) faster for larger bignums, like 16k-1M
 bits, and even faster for extremely large bignums, but such bignums rarely
 occur in normal software
* If you want to do performance-sensitive computations, you need modifiable
 objects. Because Ruby numbers are all const, "natural" Ruby way of using
 GMP::Z is going to be slow. That is, a.add!(b) is much faster than a+=b
  (it's tested by bmark2-gmp.rb vs bmark2-gmp_self.rb)
* Therefore I think it wouldn't be wise to replace BigNum with GMP::Z unless
 you can greatly reduce the overhead. Even in that case, don't expect
 performance like C GMP with naive code. C++ GMP on the other hand compiles
 naive code to something almost as fast as hand-coded C library calls, by
 using template magic.
* There is no equivalent of GMP::F and GMP::Q in Ruby.
  GMP::Z also has some extra features not available for Ruby Bignums.
  Newer version of GMP library have even more such features, but I haven't
 included support for them in Ruby GMP.
  Because of this, it might be useful to include GMP::F support in Ruby core,
 whether or not GMP::Z is going to replace Bignum.

----

T.

In This Thread

Prev Next