FYI, given the upstart MagLev Ruby implementation (described below), I have a newfound respect for the proposed "fixnums in the VM" MLVM enhancement. On several benchmarks, especially those related to math, the constant fixnum churn has now started to become the primary bottleneck. Beyond that, our custom fixnum type obviously stands neatly in the way of several optimizations that could be applied to fixnums in general.
Reading through John Rose's "fixnums" article, it doesn't sound like adding fixnums would be very easy, though it certainly doesn't sound impossible either. I was mostly curious if anyone on this list has an interest (and more importantly, the necessary skills) in pursuing fixnum support in MLVM. And I know John and other Sun folks are in perpetual "swamped" mode, but I'd also like to hear if this ranks at all on lists of MLVM/DVM priorities inside Sun. MagLev is a very new, unreleased, untested, incomplete Ruby implementation from GemStone based on their SmallTalk VM. In early, unofficial results, it positively spanks the other implementations (including JRuby) on fixnum/math-heavy benchmarks, largely because (I assume) they have true fixnum/SmallInteger support at a VM level. Now I seriously doubt that the majority of Ruby applications depend on superfast math, given the relative ease in which someone can bail out to an extension language like C or Java, but there are plenty of mundane operations where true fixnums would really be handy (e.g. simple loops, array indexing, etc). FWIW, Ruby 1.8 and 1.9 use tagged integers for fixnum, and JRuby still outperforms both of them with a custom boxed reference type. This is almost certainly due to other parts of JRuby being substantially faster than either implementation, but I tremble to think what real fixnum support in the VM might do. And in my primitive experiments, a hand-written Java fib using our fixnum type for all integer operations performed no better than normal, dynamic-dispatched, compiled Ruby code in JRuby with all optimzations turned on, so we've pretty much turned execution and dispatch performance up as high as they can go without unboxing fixnum itself (which we will not do, given the monumental task of supporting additional primitive call paths). On a side note: any recommendations for optimizing fixnums on current JVMs? A few immediate ideas come to mind: fixnum cache (which we already have for -128..127), heavier memory ratios toward "newer" generations, and in general trying to reduce fixnum churn where possible (literal caches, static analysis to find unneded constructions...). Comments on these and others? - Charlie _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
