Related articles |
---|
Compilers and Performance dstubbs@garden.csc.calpoly.edu (1995-10-18) |
Re: Compilers and Performance pardo@cs.washington.edu (1995-10-23) |
Newsgroups: | comp.compilers |
From: | pardo@cs.washington.edu (David Keppel) |
Keywords: | performance, optimize |
Organization: | Computer Science & Engineering, U. of Washington, Seattle |
References: | 95-10-095 |
Date: | Mon, 23 Oct 1995 21:22:12 GMT |
dstubbs@garden.csc.calpoly.edu (Dan Stubbs) writes:
>[3:1 ratio of performance of simple code with ``full'' optimization!?]
Two observations:
The quality of code from an ``optimizing'' compiler depends on lots of
things including the age of the compiler. For example, some vendors
ship an ``old but reliable'' default compiler, charging extra for the
one with the modern optimizer. At any rate, you don't say which
compilers you're using; if it's the latest `gcc' against the vendor
`/bin/cc' on a machine you bought 5 years ago, you may be comparing a
1985 compiler against a 1995 compiler, and I wouldn't be too suprised.
Second, it is my experience that tighter inner loop are more sensitive
to minor variations in optimization. That is, various optimizing
compilers tend to do better on some constructs and worse on others.
An inner loop of 1,000 instructions will tend to have enough variety
that optimizer variations. In contrast, a single ``mistake'' in a
simple inner loop can cost dearly. I recall one inner loop of about a
dozen instructions on a machine with superscalar issue; the difference
between -O1 and -O2 with one compiler was that a single instruction
was moved. Unfortunately, -O2 put it at the place that hurt
superscalar issue and thus cut overall performance by about 5%.
Riddle: What are the three most important things about code and data?
Answer: Location, location, location.
;-D on ( Or was that ``plastics''? ) Pardo
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.