3 ms·

My impression was that ruby symbols were defined once and mapped to the same memory space. If I am correct in my assumption, wouldn't it be more efficient to pa

My impression was that ruby symbols were defined once and mapped to the same memory space. If I am correct in my assumption, wouldn't it be more efficient to pass the arguments in as pointers and compare the equality of the pointers?

djur 12y ago
That's actually what they're doing. VALUE is a typedef for uintptr_t, so rb_obj_equal is just testing whether the pointers are the same.
- mrinterweb 12y ago
  Thanks for looking into that, Matt. It has been a long time since I did any real C programming, and I could not believe that they would be passing by value for this kind of equality check. The word "VALUE" is a little deceiving considering that it is actually a uintptr_t.
  - riffraff 12y ago
    it's not, really, VALUE may alternatively contain an immediate value or a pointer, i.e. a couple bits are used for type tagging and the rest is used to hold an int/float/nil/boolean. and avoid an extra struct.
  - stormbrew 12y ago
    It is uintptr_t in size, but it's actually a bit more complicated than that. If the 'value' is a fixnum, the low bit is set to 1 and the bottom 31 or 63 bits of the integer are shifted to the left and stored directly in the VALUE [1]. And then there's a few other bit patterns (all with the low bit set to zero) that also mean embedded values [2], including symbols, where they're actually an index into a string table rather than an actual object pointer. So a lot of the time, VALUE is anything but a misnomer. Also, the name for this pattern is tagged pointer. It's one of the most notable things ruby borrowed from emacs lisp [3]. Also, the entire point of symbols is that they don't need to be dereferenced (or strcmp'd) to compare them. That's not the slow part of symbol comparison. [1] https://github.com/ruby/ruby/blob/trunk/include/ruby/ruby.h#L234 https://github.com/ruby/ruby/blob/trunk/include/ruby/ruby.h#... [2] https://github.com/ruby/ruby/blob/trunk/include/ruby/ruby.h#L383 https://github.com/ruby/ruby/blob/trunk/include/ruby/ruby.h#... [3] https://www.gnu.org/software/emacs/manual/html_node/elisp/Object-Internals.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Ob...
cliffordheath 12y ago
It's not the comparison that's slow, it's the method lookup. String equality bypasses method lookup, so the slightly slower comparison is irrelevant. Also, very small strings are inlined into the object and will have been loaded along with the cache line that accessed the object, so the string bytes themselves are already in cache - and the slow comparison doesn't matter much.

djur 12y ago

That's actually what they're doing. VALUE is a typedef for uintptr_t, so rb_obj_equal is just testing whether the pointers are the same.

mrinterweb 12y ago
Thanks for looking into that, Matt. It has been a long time since I did any real C programming, and I could not believe that they would be passing by value for this kind of equality check. The word "VALUE" is a little deceiving considering that it is actually a uintptr_t.
- riffraff 12y ago
  it's not, really, VALUE may alternatively contain an immediate value or a pointer, i.e. a couple bits are used for type tagging and the rest is used to hold an int/float/nil/boolean. and avoid an extra struct.
- stormbrew 12y ago
  It is uintptr_t in size, but it's actually a bit more complicated than that. If the 'value' is a fixnum, the low bit is set to 1 and the bottom 31 or 63 bits of the integer are shifted to the left and stored directly in the VALUE [1]. And then there's a few other bit patterns (all with the low bit set to zero) that also mean embedded values [2], including symbols, where they're actually an index into a string table rather than an actual object pointer. So a lot of the time, VALUE is anything but a misnomer. Also, the name for this pattern is tagged pointer. It's one of the most notable things ruby borrowed from emacs lisp [3]. Also, the entire point of symbols is that they don't need to be dereferenced (or strcmp'd) to compare them. That's not the slow part of symbol comparison. [1] https://github.com/ruby/ruby/blob/trunk/include/ruby/ruby.h#L234 https://github.com/ruby/ruby/blob/trunk/include/ruby/ruby.h#... [2] https://github.com/ruby/ruby/blob/trunk/include/ruby/ruby.h#L383 https://github.com/ruby/ruby/blob/trunk/include/ruby/ruby.h#... [3] https://www.gnu.org/software/emacs/manual/html_node/elisp/Object-Internals.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Ob...

cliffordheath 12y ago

It's not the comparison that's slow, it's the method lookup. String equality bypasses method lookup, so the slightly slower comparison is irrelevant. Also, very small strings are inlined into the object and will have been loaded along with the cache line that accessed the object, so the string bytes themselves are already in cache - and the slow comparison doesn't matter much.