Proebsting's Law

James Davis jamesd at jml.net
Wed Dec 14 11:35:33 GMT 2005


Simon Wistow wrote:

> Really? Is that such a bad guesstimate? After all a naive compiler chain
> - simply tokenise, parse, generate an AST and then generate native code
> - is basically what gcc with no optimisations does. At best case
> scenario gcc is going to have a couple of optimsations anyway so will 
> actually be in *favour* of the compiler. 

No it won't. Think about it. If gcc with all optimizations off does more
optimizations than say an 35 year old compiler but he's expecting them
to behave identically it will *weaken* the case for compilers.

> I believ he compiled a test suite with no optimsations and then -O3 

A test suite or any other bench mark is not a real world application.

> The first Cobol compilers came about in 1959 I believe. 
> 
> 	http://www.computerhistory.org/events/lectures/cobol_06121997/
> 
> but let's assume that they go back even further. Isn't he strengthening 
> his case even further.

I know compilers go back even further than 35 years ago, that was my
point. Why pick 35 years? I doubt that compiler technology is growing at
a steady rate. Given your dates think of the difference between a 45,46
and 47 year old Cobol compiler, now thing of the differences between
that compiler in the last three years of it's use.

I seriously doubt that a 35 year old compiler produces output identical
to, say gcc, with optimizations turned off.

> Right. So, even though he's being generous and assuming that, say, GCC 
> (which is a pretty slow compiler) with no optimisations is as slow as a 
> naive compiler from the first beginnings of compiler design (which it's 
> probably not) and though he's saying compiler design began 36 years ago 
> (when in fact it was probably slightly longer than that) he's still 
> wrong?

No, I agreed that he was correct in his conclusion just not in how he
reached it.

> However, most of the time optimisation comes from improved algorithms 
> and more agressive caching. 

Yes I do realize this.

> My, and here I slip into marketing speak, take how message from that 
> page was that compiler optimisation is useful in the same way that 
> spending 200 quid modding your car to get 1 exta Bhp is. Sure, for some 
> people it's worth it but for 99% of people it

Getting 1hp extra from your Nova isn't worth it but there are people who
are interested in doing it. On the other end of the scale were people
wanting to get a little extra performance from their racing car using
ABS. At the time, who really *needed* it? After all a skilled driver
should be able to use cadence braking. But look at the spin off, we now
drive safer cars because of an invention that can give a small speed
increase. The inventor of ABS probably had no interest in turbochargers.
(this analogy isn't completely true, ABS was used on aircraft before
racing).

In the same way, a researcher may have no interest in anything but
compiler performance and design and you cannot predict the value of
insight into the problem of compiling that even the smallest
optimization might bring beyond the slight speed improvement.

> a) doesn't matter

Studying compiler design for it's own sake and a number of reasons other
than the speed at which the output executes does matter very much to
lots of people.

> b) there are easier ways of getting better performance

Yes, I didn't disagree with that point.

James


-- 
http://www.freecharity.org.uk/ - Free hosting for charities
http://jamesd.ukgeeks.co.uk/


More information about the london.pm mailing list