Cannot override Fixnum operators

Does anyone have a work-around or a patch for this? It's a blocker for my project.

I think this is optimization Charlie put in.

I'd like Diony and Nels to explain what they're doing with Fixnum that they need to redefine Fixnum operations. I think all impls are going to be trending toward having Fixnum ops always be the Fixnum versions, so there may not be a future for whatever you're doing.

You can, however, turn this behavior off in JRuby by specifying -Xcompile.fastopts=false:

~/projects/ruby ➔ jruby -Xcompile.fastops=false -e "class Fixnum; def +(a); puts a; end; end; 1 + 1"
1

The optimization makes a tremendous perf difference for math algorithms, so we're unlikely to reverse it. I'd still like to know why you feel you need that behavior.

I am sensing resistance. I now doubt that this will get fixed, and it will likely be a waste of my time to comment further.

I can find plenty of examples on the web of Fixnum operator overloading in Ruby.

My particular use case and application is somewhat obscure – so I expect it would not be productive to discuss it in this context.

IMHO, it is not my responsibility to justify a request for a bug fix to functionality that has clearly worked in previous versions of JRuby, and current versions of Matz's Ruby.

In the very least, the optimization changes should fail fast. When the Fixnum class is reopened and its operator methods redefined, an exception should be raised at that point.

Currently when JRuby Fixnum methods are overloaded there are no errors, as expected. During runtime, however, JRuby inexplicably and mutely fails to invoke the new operator method definitions.

Overloading operators in every other class in JRuby seems to work as expected. So it should be made clear that Fixnum is a special case.

Do you have plans to eliminate the ability to overload unary operators as well? Because currently Fixnum#-@ is still overload-able as of JRuby 1.6.0. Is that because it is inherited from Numeric? Do you plan to optimize the operator overloading out of Numeric as well?

Finally, to which impls, specifically, are you referring? Can you please provide a citation for your claim that Ruby implementations are trending towards eliminating the ability to overload operators on one particular class in the language – Fixnum.

Currently, both the latest versions of Matz's Ruby (1.8.7 and 1.9.2) fully support the overloading of operators on the Fixnum class.

I feel compelled to express my dismay to learn that code execution speed is more important than compatibility with the reference Ruby implementation.

My perception of JRuby as a faithful implementation of the Ruby language has been compromised.

-Nels

We made this move largely because at least one other implementation made the same change long ago: Rubinius. Up until JRuby 1.6, we had continued to leave Fixnum operator dispatch doing a full dispatch cycle.

Now we certainly could tweak the fast logic to dispatch if Fixnum has been modified, which would cover your case. It would involve including an additional test in the fast path, which may or may not impact performance.

I hope you will understand we are governed not just by compatibility, but also by trying to make a better and better implementation. The scenario goes like this:

• People complain about Ruby performance in some area.
• We fix that are, making those people happier.
• In the process, we make others sad because we trade exact compatibility for better perf.

Do we sacrifice the good of the majority for the good of the minority?

All that said, I will play with an additional check to see if it's low-cost. I would accept a minimal hit.

Thank you for your analysis and explanation. I understand your algebra here.

However, I cannot say that the sting of disappointment is at all soothed.

This 1.6 version of JRuby, and your initial response to this bug report, is an eye-opener for me. It is also personally embarrassing for me, because I have been evangelizing JRuby as a superior, as well as faithful, implementation of Ruby.

I can no longer do that with any confidence. Serves me right for indulging idealism.

Early signs don't look great; it seems like any attempt to be faithful to Fixnum operator dispatch will impact performance. For your case, that may not matter. I would like to understand why you're reopening Fixnum, so I can better empathize with your position.

• Simply using the inline caching logic we had before appears to degrade performance about 16% on a simple benchmark like fib(35).
• Adding logic to confirm whether +, -, < have been overridden seemed to degrade performance 100%, probably do to all the extra compares and memory accesses versus simple inline caching.

I'm willing to entertain other options as well. It seems like specifying an option to turn off the optimization is not acceptable to you, but it is an option. And there may be other ways to check for Fixnum modification that I have not thought up yet. If you have a suggestion for how to be faithful to MRI without a substantial numeric algorithm performance hit, I'd be happy to incorporate it.

Looks like the best I can do is a 5-10% perf hit.

The current best technique adds logic into RubyModule everywhere a method table modification takes place. If the class being modified is Fixnum, we set a runtime-global flag indicating that Fixnum has been reopened. That flag is checked in the "fast" operators, and we do normal dispatch if it is set.

Here's perf of fib(35) without the check:

~/projects/jruby ➔ jruby --server bench/bench_fib_recursive.rb 10 35
9227465
  1.538000   0.000000   1.538000 (  1.477000)
9227465
  1.243000   0.000000   1.243000 (  1.242000)
9227465
  1.167000   0.000000   1.167000 (  1.167000)
9227465
  1.156000   0.000000   1.156000 (  1.156000)
9227465
  1.154000   0.000000   1.154000 (  1.154000)
9227465
  1.220000   0.000000   1.220000 (  1.220000)
9227465
  1.173000   0.000000   1.173000 (  1.173000)
9227465
  1.154000   0.000000   1.154000 (  1.155000)
9227465
  1.167000   0.000000   1.167000 (  1.167000)
9227465
  1.158000   0.000000   1.158000 (  1.158000)

And here it is with the check:

~/projects/jruby ➔ jruby --server bench/bench_fib_recursive.rb 10 35
9227465
  1.369000   0.000000   1.369000 (  1.317000)
9227465
  1.207000   0.000000   1.207000 (  1.207000)
9227465
  1.179000   0.000000   1.179000 (  1.179000)
9227465
  1.175000   0.000000   1.175000 (  1.174000)
9227465
  1.209000   0.000000   1.209000 (  1.209000)
9227465
  1.361000   0.000000   1.361000 (  1.361000)
9227465
  1.259000   0.000000   1.259000 (  1.259000)
9227465
  1.259000   0.000000   1.259000 (  1.259000)
9227465
  1.277000   0.000000   1.277000 (  1.277000)
9227465
  1.278000   0.000000   1.278000 (  1.278000)

The numbers are rather variable below 0.1s granularity on this benchmark, but in general it feels like 5-10% to do the additional check.

Just curious, what are those cases when Fixnum operator overloading really makes things simpler? I can't see any outside of complex DSLs. In fact, overloading Fixnums to do comparison with Arrays sounds like a time bomb to me. Don't hit 98% by solving a 2% problem.

My use case is indeed a DSL.

Now, if the curators of the Ruby language decide that Fixnum operator overloading is no longer a valid feature of the language, then I will acquiesce.

However, I would be surprised if this happened. Operator overloading is a celebrated feature of Ruby, AFAIK. It would surprise me if Rubyists everywhere would not react to hearing of its summary amputation in JRuby in the interest of shaving a few milliseconds off some number-crunching with eye-rolling and scoffing.

Elimination of Fixnum operator overloading is a very special-cased reduction of the Ruby language feature set, and I see no justification for it other than a "need for speed".

On the other hand, if 98% of JRuby developers are really doing serious number-crunching, and truly need this functionality, then so be it.

But my suspicion is that this 98% number is rhetorical fiction, Michael.

My perspective is that JRuby users who require that extra few milliseconds are the 2%. They should be the ones who are forced to run JRuby with a special "-Xcompile.fastops=true" runtime option.

I agree with Nels here. It took me by surprise.

Nels, setting JRUBY_OPTS='-Xcompile.fastops=false' might ease your pain somewhat. (Admittedly it is not the best workaround, but a workaround nonetheless.)

Hi Hiro, thanks for the support and suggestion. Charles has also mentioned the compile.fastops setting.

I certainly understand that there are those JRuby users who are into the configuration and tuning of JRuby for the sake of wringing every last millisecond from their programs. My opinion is that it is they who should be required to hassle with the configuration of their jars, apps, or executable binaries. Not me.

I'd like to chirp in here and mention that performance of jruby is of the utmost important to users like me and many others. Moreover monkey patching core classes is a really stupid idea, leads to buggy software and surprises to new developers. I'd go to the extent of saying that barring reopening of the classes is a good if it brings significant performance gains. Otherwise it can be provided as an option. Rubyspec is not a holy document and is subject to change. I am sure things like this and others related to speed will be included in ruby 2.0 like optional typing.

Piyush, I am the sole developer of my program. I chose to code it in Ruby because Ruby offers me the ability to extend and manipulate the language for my purposes. It was a good fit for porting subsets of programs written in other more obscure programming languages. I chose JRuby because it offers me the ability to incorporate existing Java libraries into my Ruby program. I am not going to be on-boarding new developers anytime soon. These reasons I have outlined here are enough to nullify your arguments.

I am well aware that the Ruby specifications are not written in stone. But AFAIK, there has yet been no change to any specifications indicating that Fixnum (exclusively and specifically!?) operator overloading is to be eliminated for any reason.

Both the 1.8.7 and the 1.9.2 versions of the existing reference implementation of Ruby clearly provide this ability for developers, "stupid idea" or not.

(Not to mention that every version of JRuby prior to 1.6 supports Fixnum operator overloading, and this speed increase that is of "utmost" importance to you has been around for all of 30 days.)

For myself, I will take the power and flexibility of the Ruby language over minute performance tweaks.

Nels,

In principle, I agree with you, but JRuby has made some decisions to deviate from MRI's behavior where it made sense (forking behavior, $SAFE, Fixnum/Bignum boundaries, etc.).

The problem, in my opinion, was that we didn't communicate this change effectively ahead of time.

Since Charles is requesting more opinions about this issue, here's my comment:

This Fixnum optimization is an important one, boosting JRuby performance in a variety of scenarios, and should be on by default. Good performance should be available out of the box, not only after enabling arcane switches.

That being said, this deviation from MRI should be proeminently documented, and fail fast, as Nelson mentioned. JRuby could check for Fixnum operator overload on method definition, and throw an exception, or at least a warning, if the definition won't be applied because of active optimizations.

At the moment, I think I'm going to introduce Fixnum/Float reopening checks into the fast operator paths, to ensure they're observing changes to those classes. This appears to affect perf of e.g. fib, but only marginally. For something that's all math operators like a simple while loop, I could not see any obvious difference with the reopening checks in place (so the difference is either lost in the cost of other operations, or it's a very small difference).

I've gone ahead with the reopening check for now. It doesn't seem to damage perf noticeably in most cases (small dip in fib() perf), so it seems reasonable to stick with this for now. If at some point Rubyists are comfortable with Fixnum operators not being mutable, or that becomes "the way" with MRI, we can remove this check.

This would probably be good to get into RubySpec, if it's not already there. Can I ask you to look into that?

master:

commit 1a1864332f246cca9eaa6ea7f6959bf4f713850b
Author: Charles Oliver Nutter <headius@headius.com>
Date: Wed Apr 13 17:44:23 2011 -0500

Fix JRUBY-5674: Cannot override Fixnum operators

• Enable "reopening" checks for Fixnum and Float in fast operator paths.
• TODO: lighten the checks somehow, or invalidate fast operator call sites actively.

jruby-1_6:

commit 23c60838a1391bd025969349309e19c9dd2dcf8d
Author: Charles Oliver Nutter <headius@headius.com>
Date: Wed Apr 13 17:44:23 2011 -0500

Fix JRUBY-5674: Cannot override Fixnum operators

• Enable "reopening" checks for Fixnum and Float in fast operator paths.
• TODO: lighten the checks somehow, or invalidate fast operator call sites actively.