[MacRuby-devel] [MacRuby] #159: "%d" with large integer argument gives conversion error
MacRuby
ruby-noreply at macosforge.org
Tue Jan 5 17:45:02 PST 2010
#159: "%d" with large integer argument gives conversion error
---------------------------------+------------------------------------------
Reporter: jamis@… | Owner: lsansonetti@…
Type: defect | Status: new
Priority: major | Milestone:
Component: MacRuby | Keywords:
---------------------------------+------------------------------------------
Comment(by lsansonetti@…):
Looking at the changes, I have the following comments:
* The "strict" code paths should be enabled by default, because we must be
compatible with the upstream implementation of Ruby. At the very least,
"nan".to_f should (unfortunately) return 0.0, like Ruby 1.9. I believe the
%a and %A string formatters can be callable by default, since these are
additions and do not break existing behavior.
* In RoxorCompiler::compile_conversion_to_ruby(), the optimization that
was inlining the code to convert a C float into a Ruby float disappeared.
It is now compiling a call to rb_vm_float_to_rval() every time. This isn't
good performance-wise, we must bring the inline optimization back.
* On some simple benchmarks (such as a "i=0.0; while i<100000000.0; i+=1;
end" loop), the new code is about 3 times slower. It's because the
compiler generate C calls when creating floats, according to Shark, such
as rb_vm_float_value(), rb_float_new_retained(), and
rb_vm_effective_immediate_bits() (which should be inlined). Also, probably
because of rb_float_new_retained(), boxed floats are apparently never
released, which leads to memory leaks (a simple loop demonstrated that).
I am attaching a patch of your changes against MacRuby trunk (as of r3193)
so that others can try them. But at this point I'm not confident to merge
all of it.
--
Ticket URL: <http://www.macruby.org/trac/ticket/159#comment:12>
MacRuby <http://macruby.org/>
More information about the MacRuby-devel
mailing list