Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!hplabs!pyramid!mips!mash
From: mash@mips.UUCP (John Mashey)
Newsgroups: comp.arch
Subject: FREQUENCY statements: fill a much-needed gap
Message-ID: <1267@winchester.UUCP>
Date: 10 Jan 88 19:17:52 GMT
References: <839@ima.ISC.COM> <28200085@ccvaxa>
Reply-To: mash@winchester.UUCP (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 67

In article <28200085@ccvaxa> aglew@ccvaxa.UUCP writes:

>..> The Fortran FREQUENCY statement:
>..>   John Levine (paraphrased) says that the lesson is that the programmer 
>..>   should not provide the frequency hints, the system should.

>I would rather that you had said "the system should be able to",
>but "the programmer can if he really wants to".

>First, a high level directive like FREQUENCY can be generated either
>by the programmer or automatically by the language system, so why not
>make this functionality available to the programmer?

I suppose it would be OK to have FREQUENCY statements or similar
directives, although the code clutter might be awful.   In my opinion,
if much of this idea depends on human beings putting them in,
it's a *********Wrong Thing**************

1) Human beings should never supply information that computers can figure
out for themselves.  As noted earlier in this discussion, there indeed
may be cases where the computer cannot figure it out.  However:

2) If knowing the frequencies of branches (or of other things)
makes a big difference, there is a (conceptually) simple mechanism
for gathering the information mechanically, at least for user programs:
	a) Compile the program.
	b) Convert the program to a profiling version.
	c) Run the profiled version on one or more test cases to
	generate feedback files.
	d) Add the feedback files together [and note that this is important:
	some programs [Spice, for example] look very different with
	different kinds of inputs.
	e) Recompile and relink the program, applying whatever
	transforms are useful, given the information in the feedback files.
	Such transforms might include:
		1) FREQUENCY-like changes, if the architecture is actually
		helped by them
		*2) Selective inlining of procedures, at the call sites
		where it is actually worth it.
		3) Other code optimizations at compile time helped by
		frequency analysis.
		*4) Rearrangement to help cache efficiency

[MIPS software currently does a)-e) above, plus *2 and *4],
i.e., none of this is remotely theoretical.

3) Human intuition about performance is notoriously awful.  People
are often surprised when they see profile results.  If the way you
got most FREQUENCY statements was to profile something first,
why not let the computer do it?

4) Features like FREQUENCY are a crutch to fill the gap between
what a human knows and what the compiler can do.  C's "register"
declaration was such a crutch, appropriate at the time, since it
made a big difference, and optimizing compilers were not as widely
available as they are today.  Many current compilers almost ignore
"register" in favor of their own allocation.

FREQUENCY is like that, but not as useful, since it isn't spanning
much of gap, as current leading-edge software technology is quite
capable of gathering and using the needed information.
It is a feature that "fills a much-needed gap" (in the words of Ken T.)
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086