Path: utzoo!mnetor!uunet!husc6!bbn!oberon!ll-xn!ames!ucbcad!pasteur!ucbvax!decvax!decwrl!pyramid!prls!mips!mash From: mash@mips.UUCP (John Mashey) Newsgroups: comp.arch Subject: Re: FREQUENCY statements: fill a much-needed gap Message-ID: <1305@winchester.UUCP> Date: 13 Jan 88 02:29:02 GMT References: <839@ima.ISC.COM> <28200085@ccvaxa> <1267@winchester.UUCP> <2861@clash.rutgers.edu> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 70 In article <2861@clash.rutgers.edu> segall@clash.rutgers.edu (Ed Segall) writes: >> 4) Features like FREQUENCY are a crutch to fill the gap between >> what a human knows and what the compiler can do.... >> 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.) >Aaarrrggghh! Well, I thought my earlier posting might stir something up. >Yes, it would be really nice to have a compiler figure everything out >in advance, and I wish the greatest encouragement to those who can get >a compiler to figure out which branch is most likely to be taken.... >I think the missle example showed it best (to paraphrase: you don't >want to optimize for the most common case, when no missles are coming >in. You'd be better off optimizing the very uncommon case when they >are). So, in mine humble opinion, it is a Very Good Thing to have a >compiler figure out (guess, usually) which branch is going to be >executed most frequently, and to use that information, but it is a >Very Bad Thing to ignore the need for communicating as much useful >information as possible to the compiler. Sure, most such features >would go unused most of the time, often when used they would be wrong, >and the code clutter would be horrendous if they are used extensively, >(sounds like a candidate for Hypertext-style programming) but please >don't say they shouldn't be developed and used. The missile case doesn't prove it at all: a) If a thing like a FREQUENCY statement makes a difference, you are in serious trouble. Anti-missile code is hard enough. b) You can certainly pick your test cases. Everyone that I've known that worked on anti-missile stuff said they spent a lot of time simulating "here come the missiles", so presumably, data could be gathered on that case. All of this is a whole lot like profiling in the first place, i.e., if you spend a lot of apriori time tuning something, and then you profile it, you may be surprised that the time wasn't going where you thought. [this is not to say that you shouldn't do the level of performance analysis in advance that is deserved by a project, merely that tuning code without knowledge is often wasted effort.] Architecture&language design, with regard to performance feature additions seem like the same thing to me. It would be a good M.S. Thesis for somebody to modify a C compiler to take "advice" statements, annotate some useful real programs with them, and analyze the differences in performance. Hopefully, they'd start with an optimizer in the first place. I'm all for features (in cpus or languages) that help people get what they want; on the other hand, every feature costs you, and if you added every feature to C, that at least somebody has thought was a good idea, and might help some special case, C would substantially larger than PL/I. To get back to what started this, architecturally: a) Wrong-guessed branches are slow, so work very hard to guess right. b) All branches are fast. So far, b) looks awfully good to me; I sure prefer hardware that lets people get on with the job. Finally, it is interesting that FREQUENCY has been a feature familiar to people for about 30 years, and yet, it's been dropped from the original place and not picked up elsewhere. -- -john mashey DISCLAIMER: 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