Am 14.05.2012 01:16, schrieb Mark Roos: [...] > So I decided that all my ints will be boxed (references), added a cache > and some special prim > methods for now and then follow Charles approach of a good indy design > to take advantage > of the optimization efforts. Based on my large scale benchmarks this is > ok so I am focusing > on other places to optimize. This also supports my automatic conversion > to/from BigInts. > > Log term I am guessing that I will follow your path of special paths > with guards, Unless I can > get the performance I want with more cores.
the special paths with guards in bytecode is actually a thing I was hoping to get rid of with indy. The current state of the implementation of indy in Groovy is, that it is slightly better than our call site caching and worse than our prim opts. In total that means, unless I combine indy with prim opts the indy versions is in general a tiny bit slower, since even the small advantage over call site caching is not always there. And call site caching in Groovy means we operate with at runtime generated classes, with call sites, that are mostly not inlined and other problems. Indy has the potential to be faster than that. Only in reality I am missing that extra of performance. And that is a bit sad. We had recently another 2.0 beta and a day later we had already people complaining why the indy version is not faster. I mean, if I find other places to optimize, then call site caching will profit from that as well, not giving indy the real advantage here. I am worried about indy getting a bad image here. 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
