On Thu, Jun 3, 2010 at 3:48 PM, John Cowan <[email protected]> wrote: > On Thu, Jun 3, 2010 at 2:17 AM, Charles Oliver Nutter > <[email protected]> wrote: >> Another data point for JRuby. >> >> JRuby has only two integer data types: Fixnum (implemented by >> RubyFixnum, always containing a long) and Bignum (implemented by >> RubyBignum, using BigDecimal). All Fixnum math operations have an >> overflow check, and the arbitrary-precision nature of integers will >> probably be the biggest hindrance to lifting integer math to >> primitives. > > Why bother with this? Java Longs (which is de facto what you have) > aren't that much faster than BigDecimals, and if you add overflow > checks, probably no better. Is it really a win to have more than one > integer type? Or is this something you need for CRuby compatibility?
Sorry, I meant BigInteger above. Perhaps that changes the situation? At any rate, I'll reply as though we both said BigInteger. Wow, I'd be very surprised if that's true. Big(Integer/Decimal) are enormous compared to a long, especially on 64-bit JVM, so at a minimum you have the allocation cost of all that extra data. I may be wrong, but I believe 64-bit JVMs are able to do long operations using 64-bit instructions. And add to that the fact that even on 32-bit, math operations against long are always going to be faster than those against a byte[] in Big(Integer/Decimal). I'd be absolutely dumbfounded if it weren't a major performance hit to use Big(Integer/Decimal). That said...if I end up being dumbfounded, there's no technical reason why they couldn't both be Big(Integer/Decimal) under the covers. We'd just have the object use a different metaclass (though we might still need the overflow to know which metaclass to use...). - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
