Am 09.02.2012 03:51, schrieb John Rose:
On Feb 8, 2012, at 3:00 PM, Charles Oliver Nutter wrote:
I have been creating specific versions for long and double RHS because
it does save some overhead to not construct the box or get a cached
box. I think it's worth it for common cases (int, long, float, double)
at least.
Hotspot has some optimizations for collapsing box/unbox pairs, as in
(int)(Integer)(int)n.
> I forget when they kick in, sorry.
but will this work with a guarded methodHandle in the chain?
Meanwhile, you can sometimes arrange for exactly one generic routine to
automatically specialize in different caller contexts, based on the types at
the call site. That was the outcome of this experiment:
http://blogs.oracle.com/jrose/entry/an_experiment_with_generic_arithmetic
The key is to make the type tests in the generic function be transparent enough
to the JIT.
Example:
Object plus(Object x, Object y) { // we expect this function to inline and
customize
if (x instanceof Integer&& y instanceof Integer) return (int)x + (int)y;
return slowPlus(x, y); // slow path is out-of-line
}
Will a method like this:
public Number addImpl(Number left, Number right) {
return Integer.valueOf(left.intValue() + right.intValue());
}
be ok as well? I mean will the JIT still be able to remove the boxing?
The function must be kept simple to encourage the JIT to inline your fast path,
> but not get scared away by a complex slow path.
in my case that is a different selection. Or are you telling me that it
is better to have it with a fast and a slow path instead of a special
function I replace? I mean I can see that this avoids replacing the
callsite and as such is surely better in those terms, but in Groovy you
can replace int+int and the usage of for example double might be also
used very much.
[...]
I would try to rely on JIT customization of a generic.
yeah... if those JIT optimization wouldn't be so difficult to see through ;)
[...]
The motivation for these cases comes mainly from loop control and array indexes.
> (...In languages where those are your iteration tools; sigh.)
Well currently I am working on my fibonacci benchmark with indy and I
try to somehow get the indy implementation near (performance wise) my
primitive optimizations work I have done for 1.8. But since those are
not much slower for this case, there are a lot of strings to be pulled.
bye Jochen
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com.
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
