Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.6
    • Fix Version/s: JRuby 1.6.2
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Issue Links

        Activity

        Hide
        Nels Nelson added a comment -

        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.

        Show
        Nels Nelson added a comment - 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.
        Hide
        Hiro Asari added a comment -

        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.

        Show
        Hiro Asari added a comment - 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.
        Hide
        Marcus Brito added a comment - - edited

        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.

        Show
        Marcus Brito added a comment - - edited 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.
        Hide
        Charles Oliver Nutter added a comment -

        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).

        Show
        Charles Oliver Nutter added a comment - 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).
        Hide
        Charles Oliver Nutter added a comment -

        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.
        Show
        Charles Oliver Nutter added a comment - 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.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Diony Medrano
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: