Thanks for sharing your experience. That's interesting. Now that you mention it, I can kind of see how the boxing overhead doesn't affect Hanoi that much. It only deals with a small set of integers, so they'll be all quickly on CPU cache (along with the lookup table). And if I remember Hanoi correctly, the lack of constant propagation doesn't really reduce any code.
The reason I care so much about the constant propagation is that my intended eventual use of this is an HTML templating language, where I define tags with parameters (equivalent of functions), but callers very often specify constant values to those parameters. 2012/4/22 Mark Roos <mr...@roos.com>: > > From Kohsuke Kawaguchi email > > - How do other language implementers cope with this? > > We are doing a Smalltalk implementation and have seen that the handling of > 'boxed' integers is a possible performance issue. I say possible because > while > it is an obvious issue for integer intensive operations ( like Hanoi ) our > large > scale benchmarks run at a similar speed to the native versions. > > The larger issue in our use of boxed integers ( boxed in our own wrapper) is > the > object creation and collection overhead. For instance indexing over a > million element > array involves creating and discarding a million integers. Currently we use > a cache > plus a mutable integer approach to minimize this but I have yet to really > benchmark its > performance. > > The solution to this may lie in FixNums ( ints encoded in pointers ) but > that is some time > off and may not be of a form useful to us. > > regards > mark > > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Kohsuke Kawaguchi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
