|[2 earlier articles]|
|Re: Compiler Optimisation? firstname.lastname@example.org (Thomas W. Christopher) (1998-12-10)|
|Re: Compiler Optimisation? email@example.com (Andy Gaynor) (1998-12-13)|
|Re: Compiler Optimisation? firstname.lastname@example.org (1998-12-13)|
|Re: Compiler Optimisation? email@example.com (1998-12-13)|
|Re: Compiler Optimisation? firstname.lastname@example.org (1998-12-13)|
|Re: Compiler Optimisation? email@example.com (Stefan Monnier) (1998-12-18)|
|Re: Compiler Optimisation? firstname.lastname@example.org (Ray Dillinger) (1998-12-18)|
|From:||Ray Dillinger <email@example.com>|
|Date:||18 Dec 1998 12:18:21 -0500|
|References:||98-12-010 98-12-016 98-12-024|
Ray Dillinger <firstname.lastname@example.org> wrote:
> > The speed-up due to the peephole stage in my experience runs between
> > ten and twenty percent of overall speed -- Although, of course, it
> > depends on what you put into the "peephole" stage. ...
> This is misleading. Many compilers do MUCH more extensive
> peephole optimization. In particular gcc gets a FAR more
> significant improvement from peephole optimization.
Um. True. There are too many ways to interpret what I said.
Okay -- let me be a little more concrete.
Scheme (a LISP dialect), directly translated with optimizations
off, takes about 60 seconds to do something.
After LISP-specific optimizations (redundant-typecheck
elimination and constant folding of procedures) the resulting
code takes about 30 seconds to do something.
This is the rough equivalent of *unoptimized code* in most
After various algorithmic optimizations such as constant
folding of variables, lifetime analysis, register assignment
analysis, inlining of constant functions, etc, the resulting
code takes about ten seconds to do something.
Finally we get to the peephole stage, and the resulting code
now takes about 5 seconds to run.
Total: Of my original 60-second runtime, about 55 seconds
has gone away from the scheme program, ten percent or so of
which (5 seconds) was due to the peephole optimization.
But if I hadn't had to do LISP-specific optimizations, I'd
have started with a runtime of about 30 seconds and lost about
25 seconds of it -- about 20% of which (5 seconds) would have
been due to peephole optimization.
And this is what I meant when I said,
"The speed-up due to the peephole stage in my experience
runs between ten and twenty percent of overall speed."
But as dewarr pointed out, the sentence is darned ambiguous,
because I didn't say what I meant by "overall speed", which
In both cases, the code would take about twice as long to run
if no peephole optimizations had been done. In both cases,
it cut about 5 seconds from the total runtime.
Return to the
Search the comp.compilers archives again.