From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,db5c6b2ef47d4b9e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-20 13:15:41 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!colt.net!easynet-quince!easynet.net!out.nntp.be!propagator-dallas!news-in-dallas.newsfeeds.com!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <3B30F836.D700DAA3@raytheon.com> Subject: Re: short-circuit control forms Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Wed, 20 Jun 2001 16:15:20 EDT Organization: http://www.newsranger.com Date: Wed, 20 Jun 2001 20:15:20 GMT Xref: archiver1.google.com comp.lang.ada:8936 Date: 2001-06-20T20:15:20+00:00 List-Id: In article <3B30F836.D700DAA3@raytheon.com>, James A. Krzyzanowski says... >If using "and then" and "or else" will make our software quicker, and >then the compiler doesn't optimize any better anyway, does anybody have >a good reason why we should NOT use short-circuit control forms? First off, its *not* assured that it will always be quicker. Since you are replacing one branch with one branch for each condition, it will actually result in *more* instructions being executed if it turns out that all the conditions need to be applied. Depending on how many conditions there are and how much work calculating them all is, in some cases the non-short-circuit form will execute less code even when not all of the conditions are executed. Another thing you have to consider is that most modern processors have a branch prediction unit (BPU) that will do speculative execution to keep the instruction pipeline filled when branches are encountered. If the "speculation" is incorrect, the entire pipeline has to be flushed, which slows things down greatly. Short-circuit forms generate more branch instructions, which can amount to more chances for the BPU to guess wrong. Again, this may be trivial compared to the chance of not executing a lot of extra code. But if the code in calculating the conditions is small, or its usually all executed, then it can matter. Another important issue is maintanence. When someone unfamiliar with that code first tries to read it, they are probably going to expect that there's some *reason* that those short-circuit forms had to be used, and that there's some reason that the conditionals are in the order they are in. As an example of a problem that could cause, suppose one conditional needs to be split out for some reason. That may lead to unnessecary complication of the code to preserve that (presumed-important) ordering. My last argument against this approach is philosophical, but relates directly to all my previous points. As a general rule, you do *not* go about randomly optimizing code, at the expense of complexity or readability. Programs generally do not have their workload spread out evenly over the source, so this is an incredibly bad use of man-hours (on both ends). The proper way to optimize is to find a part that is running too slowly, find the slowest part of that, and see what you can do to speed it up (then repeat until satisfied). Hand-optimization should be done with tweezers and a microsope, not with a blindfold and a sledgehammer. So unless there is some *verified* speed problem with a particular conditional, write it the way in which it makes the most sense. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com