home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!wupost!uwm.edu!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
- From: nickh@CS.CMU.EDU (Nick Haines)
- Newsgroups: comp.compilers
- Subject: Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code
- Keywords: optimize, performance
- Message-ID: <93-01-049@comp.compilers>
- Date: 8 Jan 93 15:46:10 GMT
- Article-I.D.: comp.93-01-049
- References: <93-01-041@comp.compilers>
- Sender: compilers-sender@iecc.cambridge.ma.us
- Reply-To: nickh@CS.CMU.EDU (Nick Haines)
- Organization: School of Computer Science, Carnegie Mellon University
- Lines: 59
- Approved: compilers@iecc.cambridge.ma.us
-
- Good grief; comp.compilers suddenly doubles in bandwidth. I won't bother
- to quote all of Paul Robinson's posts, but will reply to them all
- together.
-
- 1. You seem to have a preoccupation with x86 architectures. Please do not
- assume that this is shared by most readers of comp.compilers. In
- particular, writing "we are inventing the wheel all over again ..." is
- assuming such a "we." The readers of comp.compilers include people who
- originally invented this wheel.
-
- 2. Compilers that precompile or tokenise code during an editing phase are
- _not_ "cheating;" they are merely making best use of machine resources
- when the processor load is particularly low - you have to wait a million
- or more machine cycles for that next keystroke in an editing session.
- They are unusual outside of the PC market because almost everyone uses an
- unbundled editor (emacs, gnu-emacs, vi, etc) and because people want to
- share code with others who don't use the same environment. They are
- sometimes found in integrated compiler/environment packages, but these are
- expensive.
-
- 3. Almost everyone who sells (or gives away) compilers _does_ have a
- "double vision" version; it's called optimization. Switch it off and your
- code compiles faster but runs slower.
-
- 4. Use of a language with a good type system eliminates the
- edit-compile-bomb-edit cycle, replacing it with an
- edit-typecheck-edit-typecheck cycle. Typechecking is (in general) much
- faster than compilation because it includes no optimisation or code
- transformations. An SML program which successfully typechecks will not
- bomb at runtime.
-
- 5. The problem with developing a uniform convention for argument passing
- is that the requirements of different languages are fundamentally
- different. For instance, it is a natural optimization in SML to keep
- function code addressses in closures and to pass the closure of a function
- to it in a register, as a hidden argument. This is a completely alien
- concept to FORTRAN ("closure? What's a closure?"). There are many other
- examples of different requirements. There are mixed-language systems,
- such as Poplog, which provides POP-11, Prolog, Common Lisp, SML (and
- another language). I have no idea how they manage (say) the SML/Prolog
- calling convention; I see no trivial solution.
-
- 6. You suggest that because compiler writers often work for compiler
- companies rather than hardware companies, they either (a) don't know how
- to tweak the hardware in the best way or (b) can't be bothered. (a) is
- almost never true these days: hardware specs are very good and working on
- a compiler for an architecture is one of the best ways to learn that
- architecture inside out (working on an OS is even better). (b) is
- occasionally true, but is surely a consequence of insufficient resources:
- it seems users are happy to settle for compilers that don't tweak the
- hardware as much as they might; if users demanded the best possible
- performance they would have to pay more but would presumably get it (this
- does in fact happen, and is why some compilers cost a _lot_ more than
- others).
-
- Nick Haines nickh@cmu.edu
- --
- Send compilers articles to compilers@iecc.cambridge.ma.us or
- {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
-