Paul,

As we all know, Ruby
Integers are 32-bits or 64-bits wide, but Fixnums are somewhat smaller.
They get transparently promoted by Bignums as needed.
Similarly, a 64-bit VM could define SmallFloats.  These would be a floats
few bits
short of 64-bits that are promoted to a full Floats as needed.
This video presentation of Allan Ottis at RubyConf 2008 explains
what gemstone did in their proprietary MagLev VM:

http://rubyconf2008.confreaks.com/ruby-persistence-in-maglev.html

Listen to the topic "Special Objects" beginning 35 minutes in.

It's little more than extending object tags to include floats and
a persistent store.  Seems pretty straightforward to do just the floats
on a 64-bit machine.  Big win for a small effort as I see it.

Could you explain how an Object pool would address this issue?

- brent


Paul Brannan wrote:
> 
> Floats are 64-bits wide, and need at least 1 bit to indicate that the
> object reference holds a float.  To make a float an immediate object,
> one would then need at least 96 bits for each object reference (vs. 32
> bits now on a 32-bit platform).
> 
> This is doable, but does the performance gain outweigh the cost of the
> additional memory required for applications that don't use Floats?  Or
> would a solution like an object pool produce a happier medium?
> 
> Paul
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A20190--Behavior%3A-autoload-calls-rb_require%28%29-directly-tp20777164p20861312.html
Sent from the ruby-core mailing list archive at Nabble.com.