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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,25aa3c7e1b59f7b5 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-01-07 10:10:20 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!newsfeed.direct.ca!look.ca!brick.direct.ca!brie.direct.ca.POSTED!not-for-mail Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed From: FGD MIME-Version: 1.0 Message-ID: <3C39E62F.3020504@look.ca> NNTP-Posting-Date: Mon, 07 Jan 2002 10:07:00 PST NNTP-Posting-Host: 209.148.72.68 Newsgroups: comp.lang.ada Organization: Look Communications - http://www.look.ca References: Subject: Re: A case where Ada defaults to unsafe? User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us X-Complaints-To: abuse@look.ca X-Trace: brie.direct.ca 1010426820 209.148.72.68 (Mon, 07 Jan 2002 10:07:00 PST) Date: Mon, 07 Jan 2002 13:17:19 -0500 Xref: archiver1.google.com comp.lang.ada:18615 Date: 2002-01-07T13:17:19-05:00 List-Id: Ted Dennison wrote: > In article , Gautier > Write-only-address says... > >>>If I use "and" and I'm wrong in assuming that the order doesn't matter, >>>then I have introduced a subtle bug. If I'm right, then I haven't gained >>>anything. So why not always use "and then"? >>> >>The short circuit is not always the faster. A good compiler >>can much more aggressively optimize an "x>=0 and x<=xmax" than >>"x>=0 and then x<=xmax"; in addition "and then" introduces >>branch(es) in the machine code, this is a performance >>penalty on processors like the Pentiums. >> > > Except that processors like the Pentiums also have branch prediction and > speculative execution. So it might not matter much after all. :-) > > It gets really hairy doesn't it? That's why the best decision is to usually let > the compiler (and thus the CPU optimization experts) deal with it, rather than > trying to use the more restrictive option to hand-optimize the sources yourself. Branch prediction and speculative execution work only for frequently taken jumps which consistently take the same branch. So, in general, the only benefits are in loops and not in if statements. In fact, it is better to reduce the number of conditional branches on machines with branch prediction: more branches => more chances of misprediction => performance penalty. Modern CPU are faster not smarter :-) The short circuit and prevents the compiler from doing some basic optimizations. The commutative and is more permissive as simplification of boolean expressions is only possible with this and. In C, it's the programer's job to optimze those expressions so the default short circuit and is not so bad; but in Ada, the compiler does this job as only the end result matters, so the presence of both ands is necessary. If Ada were to default to short circuit operators as in C, it would have to obey strict associativity rules as in C. These are not present in Ada and for good reason: how many bugs has this caused in your old C code? Any way you look at it, better performance is obtained when short-circuit and is used only when absolutely necessary. It's only natural for Ada to "default" to the commutative and. -- Frank