Boxed types and constat propagation

[Kohsuke Kawaguchi]

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 <mroos at 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>



-- 
Kohsuke Kawaguchi