Chuck, On 4/26/16 12:18 PM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: OT if/else or not if/else > >> Unless the JIT can prove that there are no side-effects, it's not >> going to perform any speculative computations for a possible branch. > > True, but due to inlining of many methods, the side effects are often > visible. It's quite common for compilers to generate reads out of order when > it can be proven they are not impacted by any subsequent write operations. > >> it's not easy to decide if either of those two methods have any >> side-effects. > > Actually, given the JVM architecture, it is quite easy - the > compiler (the real one, not javac) has the callee method > implementation available when it's processing the caller. This is not > true with most languages. If a subsequent class definition > invalidates such a determination, the compiler deoptimizes the > generated method, and, if needed, recompiles it.
The compiler would have to invalidate that side-effect cache every time a new class was used for that particular shouldDoSomething method gets called, since it could be overridden at any time, so the callee's method cannot (always) be known in advance. This is why, below, I mentioned private and final methods. Those are known knowns, so coin a phrase. I've never written a compiler (JIT) and all of these things are great optimizations if they don't become bottlenecks, but I guess it's up to the compiler writers to decide when enough is enough. Then again, JIT work is constantly being done, so I suppose these days, they are quite smart. When you gotta compete with native C, the JIT had better be good ;) >> If the method is private or final in the declared type, >> it can be evaluated completely, but that's a somewhat rare case. > > Nope (see above). > >> Presumably, the if-without-else case would actually free the compiler >> to evaluate those predicates "early", but that wouldn't be considered >> "speculative" in my mind because those side-effects would have >> happened anyway (since all branches will be evaluated). > > Only certain reads can be issued in such instances, since any writes > are expected to be in order (unless you're dealing with the rather > bonkers C++ memory model). The predicate evaluation isn't speculative, > but reads from inside the predicated area are often lifted out of the > blocks, and it's these that are speculative. Agreed. I was more concerned with writes. Any time you can have your CPU doing anything other than NOPs, you should be. Speculative reads are pretty much always a good idea. >> The only potential problem would be with an early branch that throws an >> exception, in which case any side-effects of a later predicate would >> be ... surprising. > > If a predicate evaluation might cause a write, it pretty much > precludes looking at them out of order. Exactly. This just goes back to how much work the compiler (JIT) is willing to investigate and how complex the predicate (or branch itself) might actually be. Because not only must the predicates be read-only, anything you might want to execute ahead of time within the branch needs to be read-only as well. The smarter the compiler, the better performance you can get. Compilers these days are strikingly smart, and can prove things that even the most seasoned high-level-language (e.g. Java) programmer might stay away from because it's risky, or perhaps just plain difficult to read. That's one of the great things about languages with JITs (instead of pre-processors) instead of traditional compilers (e.g. C): the JIT can take nice, maintainable, good-looking code and turn it into a complete mess of internal code that has equivalent runtime meaning, but with better performance than a naive or straightforward implementation of the high-level language. I like Olaf's saw: "optimize for the maintainer, not the compiler." The compiler is smarter than you, anyway, so you may as well write your code so that humans can understand it. ;) -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
