irb(main):001:0> true.object_id
=> 20
irb(main):002:0> false.object_id
=> 0
irb(main):003:0> nil.object_id
=> 8
The values for true and nil were respectively 2, 4 in 1.9.3 and 1.8.7,
but have been changed to 20, 8 in ruby2.0.0 - even though the id of
false remains the same i.e. 0 and the ids for Fixnum maintains the same
old 2n+1 pattern.
What’s the reason behind this object_id change?
Why was this change made? How is this going to help developers?
The full question can be seen here:
thanks!
your question was already answered at stackoverflow:
Seems to be something to do with “flonums” – a technique for speeding up
floating point calculations on 64-bit:
ruby/include/ruby/ruby.h at v2_0_0_0 · ruby/ruby · GitHub and
ruby-forum.com/topic/4404164.
Hans M. wrote in post #1102392:
your question was already answered at stackoverflow:
Seems to be something to do with “flonums” – a technique for speeding up
floating point calculations on 64-bit:
ruby/include/ruby/ruby.h at v2_0_0_0 · ruby/ruby · GitHub and
ruby-forum.com/topic/4404164.
I have tried to read it, but the presentations given in that link are
written in Japanese, and I couldn’t understand what Flonums are why they
are implemented.
Know any place where I can read them in English to understand why it was
changed?
ruby-forum.com/topic/4404164 specifically states why it was changed.
Its a speed thing.
Hans M. mailto:[email protected]
March 20, 2013 2:03 AM
floating point calculations on 64-bit:
ruby/include/ruby/ruby.h at v2_0_0_0 · ruby/ruby · GitHub and
ruby-forum.com/topic/4404164.
–
D. Deryl D.
“The bug which you would fright me with I seek” - William Shakespeare
- The Winter’s Tale, Act III, Scene II - A court of Justice.
hm the forumtopic i linked was in english …
hm okay, Flonums may be not the reason because they are only in 2.1dev
a = 1.1 + 1.2
b = 1.1 + 1.2
p(a.object_id == b.object_id)
this shows true on 2.1, its false on 2.0p0
Hans M. wrote in post #1102451:
hm okay, Flonums may be not the reason because they are only in 2.1dev
a = 1.1 + 1.2
b = 1.1 + 1.2
p(a.object_id == b.object_id)
this shows true on 2.1, its false on 2.0p0
This shows true in my system too, but my ruby -v is ruby 2.0.0p0
(2013-02-24 revision 39474) [x86_64-linux], not 2.1.
On 20 March 2013 14:27, D. Deryl D. [email protected] wrote:
ruby-forum.com/topic/4404164 specifically states why it was changed. Its a speed
thing.
I’m interested (as is Hans, I think) in understanding the specifics of
the implementation and why this leads to better performance. Looks
like someone would have to translate the Japanese, though.
On Wed, 20 Mar 2013 17:22:57 +0100, Bharadwaj S.
[email protected] wrote:
(2013-02-24 revision 39474) [x86_64-linux], not 2.1.
This only should be true on 64bit Ruby 2.0.
Bartosz Dziewoński wrote in post #1102469:
On Wed, 20 Mar 2013 17:22:57 +0100, Bharadwaj S.
[email protected] wrote:
(2013-02-24 revision 39474) [x86_64-linux], not 2.1.
This only should be true on 64bit Ruby 2.0.
Yes.
On 32 bit systems the object_id didn’t change at all.
Because immediate values have no overhead. It takes memory and cpu
cycles
to create an object instance; it takes no (extra) memory if the value is
stored in the reference (ie the object id is the value, albeit
slightly
modified), and far fewer cycles to shift and OR some bits.
Sent from my phone, so excuse the typos.
Well, there is a new answer on Stack Overflow.
Gentlemen over here might want to take a look:
Seems legit… but I am not sure how can something like this lead to
better perfomance? Any comments?