Robert Fischer wrote: > What optimizing efforts are worthwhile on generated bytecode given the > optimizing capabilities of > the JIT? I'm having trouble finding an explicit or definitive list of > optimizations, but trying to > be clever about method inlining is pretty clearly wasted effort. I can't > find any documentation on > it, but I'm assuming the JIT also takes care of constant folding, strength > reduction, and dead code > removal, since they're so straightforward. Or am I wrong, and the JIT > assumes the compiler author > applied those filters already?
Anecdotally, I've found that most micro optimizations to the bytecode don't make a big difference. I've got bits of Duby's compiler that will generate slightly different loop or branch logic from javac, and the performance is no different. But there are a few things that seem to be worthwhile: - General reduction in bytecode size. Simply having less bytecode seems to have a large effect on how well Hotspot is able to consume the code. There are also size limitations on inlining code, so less bytecode often means more inlining. - Reduction in numbers/complexity of branches. This also plays into total bytecode size, but I've seen improvements from simply flipping loops around or calculating jump conditions in aggregate before making a single jump. - Outline as much code as humanly possible (as opposed to inlining). JRuby's compiler originally just emitted all logic straight into the method body. This turned out pretty badly; it was very slow, and there was a tremendous amount of duplication. By pulling as much as possible into static utility methods, bytecode size was drastically reduced and performance went up substantially. > Is it worthwhile to recognize tail calls and turn them into GOTOs, or is that > another thing the JIT > will take care of? What about loop unrolling? Branch ordering? TCO is apparently "done" in the MLVM patchset, but until then avoiding the recursive call can definitely help. > And even if the JIT takes care of things, there's presumably a cost for > having it do them -- is it > worth applying the optimizations simply to save the JIT the effort and let it > focus on more involved > work? The number one way to "help" the JIT is to keep code bodies as small as possible...beyond any other technique, this is the one I recommend. I can elaborate on specific techniques if you like. We've gone through a lot of experimentation on JRuby. - 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 -~----------~----~----~----~------~----~------~--~---
