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: 107f24,6f568a2e6507575 X-Google-Attributes: gid107f24,public X-Google-Thread: f891f,6f568a2e6507575 X-Google-Attributes: gidf891f,public X-Google-Thread: 103376,6f568a2e6507575 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-25 19:17:07 PST Path: newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.mel.connect.com.au!news.unimelb.edu.au!mulga.cs.mu.OZ.AU!njn From: njn@cs.mu.oz.au (Nicholas James NETHERCOTE) Newsgroups: comp.lang.ada,comp.lang.functional,comp.lang.misc Subject: Re: Thoughts and Opinions or something like that Date: 26 Apr 2001 02:12:35 GMT Organization: Computer Science, University of Melbourne Message-ID: <9c806j$kt4$1@mulga.cs.mu.OZ.AU> References: <9c642e$of323@news.kvaerner.com> <9c6evg$em1$1@marduk.litech.org> NNTP-Posting-Host: toaster.cs.mu.oz.au X-Trace: mulga.cs.mu.OZ.AU 988251155 21412 128.250.22.135 (26 Apr 2001 02:12:35 GMT) X-Complaints-To: usenet@cs.mu.OZ.AU NNTP-Posting-Date: 26 Apr 2001 02:12:35 GMT Xref: newsfeed.google.com comp.lang.ada:6941 comp.lang.functional:5308 comp.lang.misc:1142 Date: 2001-04-26T02:12:35+00:00 List-Id: jmv16@cornell.edu (Jeffrey M. Vinocur) writes: >Tarjei T. Jensen wrote: >> >>As far as instructions are concerned I always fancied deviding branch >>instructions into two groups: Those who branch most of the time and those >>who seldom branch. The idea was that one could skimp on branch prediction on >>the CPU. For a while or for loop one would use the former type of >>instructions. Since I have heard of nobody who have done this I assume that >>the idea is not particularly good. >Well, the goal isn't to lessen branch prediction -- the silicon >is there either way -- but rather to reduce mispredicted >branches. The most basic approach, I guess, is assume all >backwards branches will be taken -- this gets loops. One >not-very-complicated approach is to cache whether a branch was >taken last time through and predict the same. This approach, >however, does exactly what you suggest; it gets loop iterations >2,3,4,...,n-1 all correct. I remember seeing a suggestion somewhere for a pragma in a C-- implementation that allowed you to estimate the probability that a condition succeeded. So it sounds like it must be a worthwhile idea, assuming your estimates are accurate. -- Nick Nethercote njn[AT]cs.mu.oz.au