-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck,
On 4/25/16 4:54 PM, Caldarale, Charles R wrote: >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Subject: Re: OT if/else or not if/else > >> If you use else-less-if, then there is never an opportunity for >> parellelization, since the program is going to assume that those >> predicates are (a) independent and (b) ordered in a way that the >> programmer intended. > > Not quite true. Modern compilers and CPU cores will speculatively > execute code sequences in parallel that may later be abandoned when > the results of predicate evaluation are available; this can be done > for both the if-else-if and the else-less-if forms. Regardless, the > if-else-if form is much preferred, in terms of providing both the > compiler and the maintainer with more information (and is certainly > not premature optimization, by any stretch of the imagination). Unless the JIT can prove that there are no side-effects, it's not going to perform any speculative computations for a possible branch. Many structures are of the form: if(somethingIsTrue()) { ... } elseif(somethingElseIsTrue()) { ... } ... and it's not easy to decide if either of those two methods have any side-effects. If the method is private or final in the declared type, it can be evaluated completely, but that's a somewhat rare case. 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). 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. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlcfjI4ACgkQ9CaO5/Lv0PBqvwCgiap/UoI6/slICwUCQtZOYjjq af0AoJZ8e5qy9yUy3shqblCJJ2cRL2Ls =TTKq -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org