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. But on a larger scale, I think the whole problem is worth discussion and resolution; we have benchmarks now that appear to be limited by the cost of dealing with all those Fixnum objects, rather than the math itself. > Kawa does pretty well on optimizing arbitrary-precision integers. > It wins over java.math.BigInteger by using just two fields, one > which is an int and on is an int[]. The latter is only non-null > when the value of the integer doesn't fit in the bounds of int. > I think this would be a worthwhile optimization for BigInteger. > The various operations "fast-path" the common case when the values > fit into an int (and thus the int[] is null). 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. > Kawa also does preallocate the number -100 .. 1024. I haven't > done any measurements to see if this is a good range to > pre-allocate - that might be useful to get some numbers on. We do -127 to 128. I've bumped the range larger and it seems to have only a small impact on performance at the cost of a larger startup time to initialize the values. The current size is based on java.lang.Integer from OpenJDK, and I would expect quickly diminishing returns for anything outside that range. - Charlie _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
