davidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/26/88)
While I am generally against the addition of keywords into the
language, I am in favor of having some way for the programmer to specify
things which will make the program run faster, and to do so in a
portable way. Since alias and volatile effect the optimization process,
these are good things to specify, and if not with keywords then some
other (portable) way.
This can and does make a diference in real programs. Ignoring keywords
by use of the -Oa option in the Microsoft compiler generated code which
was up to 10% faster in some cases. I looked at the generated code, and
I could see why it was done one way or the other. I'm using this as an
example, since that compiler allows me to control the functioning of
that feature.
Instead of fighting about this or that keyword, and why something
is/isn't needed, perhaps some of the people who have not joined the
screaming match could suggest a way in which this information could be
supplied to the compiler. There is still a premium on speed and size in
the commercial software market, and anything which would allow portable
specification of characteristics would benefit the programmer (larger
market) and the user (more software). How about some solutions, rather
than opinions.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -merobison@uiucdcsb.cs.uiuc.edu (04/28/88)
For a language which incorporates optimization information very cleanly,
look at the FX language[1][2]. It introduces the notion of an "effect system"
which describes side effects in a manner analogous to the way a type system
describes types. The effect system allows very aggressive but safe
optimization, documentation of side effects, and polymorphism.
FX programs can be strongly type checked and effect checked, that is
the effects are not just advice but checkable assertions.
Disclaimer: I've only read the reference manual and haven't used FX yet.
But its the first LISP-like language I've seen which should
run on stock hardware as fast as C.
References
[1] John M. Lucassen and David K. Gifford, "Polymorphic Effect Systems",
Proceedings of the Fifteenth Annual ACM SIGACT-SIGPLAN Symposium
on Principles of Programming Languages (January 1988).
[2] FX-87 Reference Manual, David K. Gifford et al., MIT LCS TR-409,
MIT Laboratory for Computer Science, September 1987.
Arch D. Robison
University of Illinois at Urbana-Champaign
CSNET: robison@UIUC.CSNET
UUCP: {ihnp4,pur-ee,convex}!uiucdcs!robison
ARPA: robison@B.CS.UIUC.EDU (robison@UIUC.ARPA)dsill@nswc-oas.arpa (Dave Sill) (04/28/88)
Bill Davidsen writes: >There is still a premium on speed and size in >the commercial software market, and anything which would allow portable >specification of characteristics would benefit the programmer (larger >market) and the user (more software). How about some solutions, rather >than opinions. It's been suggested before. What's needed is some mechanism for the standardization of `#pragma's. Personally, I like the approach used by the ISO for the registration of escape sequences (ISO2375). ISO appoints a Registration Authority which maintains a register of the the meanings assigned to various escape sequences. They receive proposals, examine them to make sure they meet the appropriate standards, circulate the proposals, consider comments on them, and, if the proposal is accepted, distribute it in its final form. ========= The opinions expressed above are mine. "Premature optimization is the root of all evil." -- Donald Knuth
ray@micomvax.UUCP (Ray Dunn) (05/04/88)
In article <10575@steinmetz.ge.com> davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > > While I am generally against the addition of keywords into the >language, I am in favor of having some way for the programmer to specify >things which will make the program run faster, and to do so in a >portable way. At the risk of upsetting the Fundamentalists [we seem to have had a new net buzzword coined], but living, like you, in the real world, I agree. > Since alias and volatile effect the optimization process, >these are good things to specify, and if not with keywords then some >other (portable) way. > ... > Instead of fighting about this or that keyword, and why something >is/isn't needed, perhaps some of the people who have not joined the >screaming match could suggest a way in which this information could be >supplied to the compiler... > ...How about some solutions, rather >than opinions. The solutions in the world you are talking about already exist, but not unfortunately, portably. We don't need another solution for "volatile", it is there already (do I hear someone ask what all the noise was about?). On the subject of "noalias", it is unfortunate that ANSI defined it in such an ambiguous way that it was rightly bound to disappear from the standard. It will not however disappear totally from the *implementations*, where, as you know, it will continue to be supplied in various sensible and less-sensible forms (the -Oa of MS 4.0 (global "noalias") requires a corresponding "aliased" keyword or pragma to be really safe and useful - I've never fancied the idea of collecting together code I could safely compile with -Oa). All other things being equal, a portable solution is better than a non-portable one, but a non-portable one is better than none at all. If you want to screw out the last drops in a particular well defined environment, you have to use these ad-hoc features provided by your friendly compiler supplier who understands your marketplace. And, as most people who live in the real world know, in the short term, you don't worry too much about portability as the prime reason d'etre, when you are competing in a *specific* market. Again this in non-Fundamentalist doctrine, but I live in the street, not the 'C'hurch. The CEO of Lotus does not make $26,000,000 a year ensuring his IBM PC Lotus 123 was written portably but missed its market window or performance requirements! Now he *has*, he can probably take the time to port to whatever followup he desires, and can afford to pay the hacks to do the conversion! *head ducked between shoulders and asbestos suit firmly in place* -- Ray Dunn. | UUCP: ..!{philabs, mnetor}!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090