From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,HEADER_SPAM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: ff499,32898cca6ca4143e X-Google-Attributes: gidff499,public X-Google-Thread: 103376,32898cca6ca4143e X-Google-Attributes: gid103376,public From: Ray Dillinger Subject: Re: Compiler Optimisation? Date: 1998/12/18 Message-ID: <98-12-042@comp.compilers>#1/1 X-Deja-AN: 423668100 Sender: johnl@iecc.com References: <98-12-010@comp.compilers> <98-12-016@comp.compilers> <98-12-024@comp.compilers> X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com Organization: cognitive Dissidents Keywords: optimize Newsgroups: comp.lang.ada,comp.compilers X-FAQ-and-archives: http://www.iecc.com/compilers Date: 1998-12-18T00:00:00+00:00 List-Id: Ray Dillinger 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. ... dewarr@my-dejanews.com wrote: > 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 imperative languages. 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 is crucial. 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. Ray