Path: utzoo!mnetor!uunet!husc6!necntc!ima!johnl
From: johnl@ima.ISC.COM (John R. Levine)
Newsgroups: comp.arch
Subject: Re: taken -vs- untaken branches, Fortran FREQUENCY declaration
Message-ID: <839@ima.ISC.COM>
Date: 8 Jan 88 19:31:14 GMT
References: <496@cresswell.quintus.UUCP> <638@l.cc.purdue.edu> <836@ima.ISC.COM> <645@l.cc.purdue.edu>
Reply-To: johnl@ima.UUCP (John R. Levine)
Organization: Not enough to make any difference
Lines: 32

In article <645@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>In article <836@ima.ISC.COM>, johnl@ima.ISC.COM (John R. Levine) writes:
>> [The Fortran FREQUENCY statement made little difference on the IBM 70[49]X
>> machines, was little used, and was dropped from the language.]  The lesson
>> here seems to be that the compiler should make its branch predictions
>> automatically based on the code or perhaps iteratively based on information
>> gathered from profiling a previously compiled version.
>
>...  On many machines, a transfer can cost 15-100 instruction
>times.  On many which attempt to look ahead, even an untaken transfer can
>cost 8 instructions.  Thus it is important that the programmer (algorithm
>designer) be able to tell the compiler which way things are going, and for
>the hardware to be able to charge ahead when there is a possibility of a
>rare branch.

Let me try to clarify my point; then I promise to shut up. I realize that
modern computers have different performance tradeoffs than a 704 did. There's
certainly no doubt that branch prediction can be a big win on pipelined
architectures. What I doubt is that it's a good idea to expect the programmer
to put into the source code explicit hints about which way a branch is
expected to go.

It seems to me that in most cases static analysis by the compiler can figure
out which is the preferred direction, e.g. branches that close loops are
likely to be taken. In the cases where that doesn't work, I'd expect profiling
and recompiling to produce far better hints that a typical programmer would
put in. Perhaps if you're that concerned about code tweaking, you should write
that part of your program in assembler (0.25 :-))
-- 
John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something
Gary Hart for President -- Let's win one for the zipper.