aglew@ccvaxa.UUCP (01/10/88)
..> 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?
Second, in many cases the programmer *does* know the frequency of certain
statements, particularly if he's implementing a well known and well analyzed
algorithm. It may be impossible or expensive for the language system to
discover this automatically. Why not make it possible to use all the
available information?
Finally, it is possible that the frequency directive could be extended
in ways that are not immediately automatable, eg:
/* A computation involving Y and X */
IF x > 0 THEN
FREQUENCY y<1 ? 0.25 : 0.75
...
:: x <= 0 THEN
FREQUENCY y<1 ? 0.75 : 0.25
...
FI
This might be, for example, used to generate two different copies of code,
if y is known far enough in advance.
I think it is more likely that compilers can be built that *use* this sort
of information, than it is that a system can automatically *discover* this
sort of thing in the near future.
Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801
aglew@gould.com - preferred, if you have nameserver
aglew@gswd-vms.gould.com - if you don't
aglew@gswd-vms.arpa - if you use DoD hosttable
aglew%mycroft@gswd-vms.arpa - domains are supposed to make things easier?
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.ram%shukra@Sun.COM (Renu Raman, Sun Microsystems) (01/11/88)
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? Any day, programmer "over-drive" is better (any examples to the contrary?). It also serves as a very good pedagogical tool be it optimization, vectorization or parallelization. Now, [digressing from the main topic] I only wish these compilers have an "explain" feature too so that it can make programmers write better programs than leave everything to the compilers. [maybe this belongs to comp.software-eng or comp.compilers] >Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 --------------------- Renukanthan Raman ARPA:ram@sun.com Sun Microsystems UUCP:{ucbvax,seismo,hplabs}!sun!ram M/S 5-40, 2500 Garcia Avenue, Mt. View, CA 94043
mash@mips.UUCP (John Mashey) (01/11/88)
In article <38390@sun.uucp> ram@sun.UUCP (Renu Raman, Sun Microsystems) writes: ... >>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? > Any day, programmer "over-drive" is better (any examples to the > contrary?). It also serves as a very good pedagogical tool > be it optimization, vectorization or parallelization. Now, > [digressing from the main topic] > I only wish these compilers have an "explain" feature too > so that it can make programmers write better programs than > leave everything to the compilers. [maybe this belongs to > comp.software-eng or comp.compilers] To the contrary: a) Global register allocation in addition to "register" decls. b) Program profiling [an "explain" feature all the way] Human intuition is bad on small programs, and is ridiculous on large ones. Even if you think you understand the algorithmic behavior, you can be horribly surprised by architectural differences, and especially on current machines, by cache behavior. Classic example: a lot of people like certain bc benchmarks, as examples of large programs. This ends being total nonsense: the last time I looked, 98% of the program execution was in a 260-byte hunk of code in one funcion, with a higher percentage of multiplies and divides than one ever sees in more typical code. To paraphrase the commercial: "It's 10 o'clock. Do you know what your child processes are up to?" ANS: probably not, unless you've looked recently. Intuition is only good if you have nothing better. -- -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
aglew@ccvaxa.UUCP (01/13/88)
>>[Me] >>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? > >[John Mashey] >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************** I'm maximally in favour of compilers that do their own frequency analyses. I would just like something that I can use in the meantime. And it seems to me that the FREQUENCY statement provides a decent interface for both human and automatically specified systems. Several people have said things like "programmer's intuition is frequently wrong". Agreed. But what about formal, mathematical, analyses? Why do I always get into this fight with Computer Scientists? They say "well, if you do it right then you wouldn't need to specify things by hand. It'll all be done automatically." Sheesh! Eventually *ALL* programming will be done automatically. But in the meantime, give me the tools I need to get the job done. If your language system lets you use automatically collected profiles to direct code generation, but not FREQUENCY statements in the code, then I know that one day I am going to have to edit the "automatically collected profiles" by hand. And keeping those up to date with changing code will be a nightmare. Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@gould.com - preferred, if you have nameserver aglew@gswd-vms.gould.com - if you don't aglew@gswd-vms.arpa - if you use DoD hosttable aglew%mycroft@gswd-vms.arpa - domains are supposed to make things easier? My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.
aglew@ccvaxa.UUCP (01/13/88)
I may have noticed a basic difference in underlying model in the
discussion of FREQUENCY.
In a subsequent note John Mashey says intuition about where
programs spend there time is poor for small programs, and abysmal
for large programs, and then gives a bc example.
I agree. I rarely can estimate over more than 10 lines of code.
The point is that the FREQUENCY statement, the way I understand it,
is used for *relative* frequencies, not absolute (if it was absolute
in the original FORTRAN, then I'm greatly against it).
On a given branch I can usually figure out which is the most likely
alternative, and I'd like to be able to indicate that. But I sure as heck
do not want to have to calculate *absolute* priorities for an entire program.mash@mips.UUCP (John Mashey) (01/14/88)
In article <28200086@ccvaxa> aglew@ccvaxa.UUCP writes: .... >I'm maximally in favour of compilers that do their own frequency analyses. >I would just like something that I can use in the meantime. >And it seems to me that the FREQUENCY statement provides a decent >interface for both human and automatically specified systems. ... >Why do I always get into this fight with Computer Scientists? >They say "well, if you do it right then you wouldn't need to specify things >by hand. It'll all be done automatically." > Sheesh! Eventually *ALL* programming will be done automatically. But >in the meantime, give me the tools I need to get the job done. Either it's a languauge feature that's made standard, or a #pragma that anyone who uses it, uses it the same way, or few people will bother, since they like code to be portable (look at the hassle-level on vectorizing directives in FORTRAN variants, which CLEARLY have dramatic performance helps in some environments. If FREQUENCY were THAT useful, I'd believe you'd find it around already.) That was Software Engineer hat. :-) Now, for Scientist hat: show me some substantial data that makes me believe this really helps, and that it is general enough to be worth the cost. >If your language system lets you use automatically collected >profiles to direct code generation, but not FREQUENCY statements in the code, >then I know that one day I am going to have to edit the "automatically >collected profiles" by hand. And keeping those up to date with changing code >will be a nightmare. No: the point is to let the compiler take the profile data directly, and use it for whatever it feels like, without messing up the source code. Debug the changes, compile the program once, run the tests, and recompile. Anyway, one more time: let's see some data from somebody, and as I said before, maybe a good MS topic for someone. -- -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
howard@cpocd2.UUCP (Howard A. Landman) (01/20/88)
In article <38390@sun.uucp> ram@sun.UUCP (Renu Raman, Sun Microsystems) writes: > Any day, programmer "over-drive" is better (any examples to the > contrary?). Sure. I once profiled some code that was spending about 90% of its time in one routine. The original programmer had gone in and made several variables "register" variables, but had made a bad choice of which ones. I got a 12% speedup or so by REMOVING one "register" declaration, allowing the compiler the freedom to select its own. In fact, removing ALL the register declarations sped the routine up nearly as much. I suspect that the many C compilers which ignore register declarations do so because of incidents like this (plus a little laziness, possibly). In the hands of an extremely competent programmer, with a desperate need for performance, over-drive is sometimes better. But assembly is even better for those rare cases, so why bother? -- Howard A. Landman {oliveb,hplabs}!intelca!mipos3!cpocd2!howard howard%cpocd2.intel.com@RELAY.CS.NET One hand clapping sounds a lot like two hands clapping, only quieter.