Fixnums: last mile for JRuby math perf

Per Bothner per at bothner.com
Mon Jun 16 17:03:26 PDT 2008


Charles Oliver Nutter wrote:
> Per Bothner wrote:
>> Charles Oliver Nutter wrote:
>>> On a side note: any recommendations for optimizing fixnums on current 
>>> JVMs?
>> "Optimizing fixnums" is of course a number of different problems.
>> One is "optimizing generic arithmetic" on unknown types - most
>> of which will be fixnums.
> 
> Ok, be pedantic :) I meant optimizing arithmetic on Fixnum reference 
> types.

Not to be pointlessly pedantic, but presumably you don't know at
compile time that you're working with fixnums - otherwise one might
as well use primitive JVM ints.  So part of the cost is checking
at runtime that the operands are fixnums.  Is your assumption
this will be taken care of using invokedynamic?

> FWIW, I'm not particularly interested in the performance of 
> arbitrary-precision math...for the most part I can fake it by swapping 
> out the backing store or mimicking "better" impls in our current Bignum.

Right, but the mention of MagLev/GemStone/SmallTalk did make it
sound like you do support arbitrary-precision math - though you rightly
aren't focused on its performance.  In any case, if one *does* support
runtime-dispatched arithmetic then the extra cost of supporting
arbitrary-precision integers should be small - as long as you can
optimize for the fixnum case - which java.math.BigInteger doesn't
do very well.

A problem that annoys me is that if you use java.math.BigInteger
for all integers then that is expensive.  OTOH if you use BigInteger
only for bignums and use java.lang.Integer for fixnums then the
mapping of the type 'integer' is a union type, which neither Java
nor the JVM support.  This doesn't matter if everything is dynamic,
but if your language has possibly-optional type specifications
and/or type inference then the best you can do is java.lang.Number.
Which sucks for anyone who likes static typing.  The Kawa solution
is to use its own gnu.math.IntNum class.  (Originally, I didn't
have much choice - the IntNum class actually predates the addition
of java.math.BigInteger in JDK 1.1 ...)
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/



More information about the mlvm-dev mailing list