Related articles |
---|
[13 earlier articles] |
Re: Why do we still assemble? rcskb@minyos.xx.rmit.EDU.AU (1994-04-10) |
Re: Why do we still assemble? Keith.Bierman@Eng.Sun.COM (1994-04-10) |
Re: Why do we still assemble? lgc@robotics.jpl.nasa.gov (1994-04-11) |
Re: Why do we still assemble? hbaker@netcom.com (1994-04-11) |
Re: Why do we still assemble? djohnson@arnold.ucsd.edu (1994-04-11) |
Re: Why do we still assemble? mfx@cs.tu-berlin.de (1994-04-11) |
Re: Why do we still assemble? johnm@cory.EECS.Berkeley.EDU (1994-04-11) |
Re: Why do we still assemble? conway@munta.cs.mu.OZ.AU (1994-04-11) |
Re: Why do we still assemble? rcskb@minyos.xx.rmit.EDU.AU (1994-04-12) |
Re: Why do we still assemble? bill@amber.ssd.csd.harris.com (1994-04-12) |
Re: Why do we still assemble? bill@amber.ssd.csd.harris.com (1994-04-12) |
Re: Why do we still assemble? pardo@cs.washington.edu (1994-04-13) |
Re: Why do we still assemble? hbaker@netcom.com (1994-04-13) |
[14 later articles] |
Newsgroups: | comp.compilers |
From: | johnm@cory.EECS.Berkeley.EDU (John D. Mitchell) |
Keywords: | assembler, C++, performance |
Organization: | University of California, Berkeley |
References: | 94-04-032 94-04-055 |
Date: | Mon, 11 Apr 1994 21:56:35 GMT |
Henry G. Baker <hbaker@netcom.com> wrote:
>At the ACM PLDI'89 conference in Portland, there was an excellent tutorial
>on how to build fast compilers by someone from the British (?) _Cobol_
>compiler company (MicroFocus??), and he spent quite a long time explaining
>why many of the standard 'academic' approaches made for very inefficient
>compilers. (He also explained why Cobol was quite difficult to compile
>efficiently. Apparently there are an incredible number of cases to
>consider when compiling a simple A=B statement. Any undergraduate
>compiler courses teach the 'by name' option?)
Well, we did in the undergrad class that I took at UCB but that probably
is as much dependent on the professor as anything else.
An assembler for the 8086 written in GNU's Bison had it's assembly time
cut by 20-40+ percent when handling/stripping comments was special cased
in the lexer rather than being passed on in the usual ways to the parser.
>I personally made the rounds at a recent Ada conference, and compiled and
>ran the same 5,000 line benchmark Ada program on as many systems in the
>booths that would allow me. The differences were absolutely astounding.
Yeah, that's outrageous. I know that in the cases that I know about from
the insiders viewpoint, the reason for the big jumps has always been
either marketing pressure (time to market, other more important use of
engineering time on other things, etc.) or poor management. An inhouse
debugger that was fairly stable and had been used for years had certain
sections of it speeded up by 10-100 *times* after the product had been
release to outside people who complained bitterly about it's sluggish
performance (and those gains were produced in about 3 weeks worth of
effort and some profiling tools :-).
John
P.S. I find it encouraging though that a C parser written using
PCCTS was *faster* than a well done, hand written parser. So
don't count the theory people out yet just make sure they
care out resource efficiency too. :-)
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.