Comments on: Supero Followup http://enfranchisedmind.com/blog/posts/supero-followup/ programming, politics, & other religious issues Mon, 15 Mar 2010 00:31:40 +0000 hourly 1 By: bhurt http://enfranchisedmind.com/blog/posts/supero-followup/#comment-32052 bhurt Thu, 13 Dec 2007 22:25:51 +0000 http://enfranchisedmind.com/blog/2007/12/12/supero-followup/#comment-32052 An interesting set of slides on Proebstring's law and the future of optimization research <a HREF="http://www.cs.umd.edu/class/spring2006/cmsc430/lec18.4p.pdf" rel="nofollow">is here</A>. His conclusion there is, I think, fundamentally pessimistic- basically that we've hit the point of diminishing returns (at least for popular languages like C++, Fortran, and Java), and that the future of compiler optimizations is going to focus on a small segment of special users- High Performance Computing- and leave everyone else out to dry. Which is yet another interesting aspect of Supero- he's not focusing on "high dollar value" customers. I mean, his basic benchmark is word count. That's about as plebian as it gets. An interesting set of slides on Proebstring’s law and the future of optimization research is here.

His conclusion there is, I think, fundamentally pessimistic- basically that we’ve hit the point of diminishing returns (at least for popular languages like C++, Fortran, and Java), and that the future of compiler optimizations is going to focus on a small segment of special users- High Performance Computing- and leave everyone else out to dry.

Which is yet another interesting aspect of Supero- he’s not focusing on “high dollar value” customers. I mean, his basic benchmark is word count. That’s about as plebian as it gets.

]]> By: bhurt http://enfranchisedmind.com/blog/posts/supero-followup/#comment-32051 bhurt Thu, 13 Dec 2007 22:18:44 +0000 http://enfranchisedmind.com/blog/2007/12/12/supero-followup/#comment-32051 No. Ocaml actually isn't that good at optimization. I mean, it does the simple things- peephole optimization, inlining, a few others- and it has an excellent garbage collector (even for ML languages), and as a language it allows you to write non-stupid code. But compare even to GCC 2.94, it's doesn't optimize that much (let alone comparing it to GCC 4). Also, it helps that modern CPUs are surprisingly good at "optimizing" less than optimal code. The dirty little secret of the "popular" languages are that optimization doesn't help you much. Something I forgot to mention is Proebstring's Law: that increases in compiler optimization double program speed every 18 <EM>years</EM>. That's compared to the common misquoting of Moore's law that has CPU speed doubling every 18 <EM>months</EM>. And I think Proebstring's law misrepresents the situation, to the benefit of making the optimization improvements look better that they really are. The justification for Proebstring's law is that after 36 years of progress, programs are about 4x faster. But the vast bulk of that improvement was the low hanging fruit- a small selection of "simple" optimizations- peephole optimizers, register allocation, strength reduction, inlining- gives an easy 2x speed improvement, and were well known 36 years ago (1971). Which means over the last 36 years, compilers have only doubled the performance of programs- or about a 2% gain per year. Parenthetically, this is why Ocaml can still be "speedy" and not have complicated, expensive optimizations- the complicated, expensive optimizations simply don't buy you that much. It does the simple optimizations which net a lot of performance gain for (comparatively) little pain, but doesn't bother with the optimizations which are lots of pain for little gain. Then wham- out of left field comes a grad student and an optimization speeding code up by 10% to <EM>three fold</EM>. That's like 5 years to 55 years worth of compiler optimization development at current rates, all at one shot. And he's not done- there are probably (almost certainly) improvements to that to be made. No. Ocaml actually isn’t that good at optimization. I mean, it does the simple things- peephole optimization, inlining, a few others- and it has an excellent garbage collector (even for ML languages), and as a language it allows you to write non-stupid code. But compare even to GCC 2.94, it’s doesn’t optimize that much (let alone comparing it to GCC 4). Also, it helps that modern CPUs are surprisingly good at “optimizing” less than optimal code.

The dirty little secret of the “popular” languages are that optimization doesn’t help you much. Something I forgot to mention is Proebstring’s Law: that increases in compiler optimization double program speed every 18 years. That’s compared to the common misquoting of Moore’s law that has CPU speed doubling every 18 months.

And I think Proebstring’s law misrepresents the situation, to the benefit of making the optimization improvements look better that they really are. The justification for Proebstring’s law is that after 36 years of progress, programs are about 4x faster. But the vast bulk of that improvement was the low hanging fruit- a small selection of “simple” optimizations- peephole optimizers, register allocation, strength reduction, inlining- gives an easy 2x speed improvement, and were well known 36 years ago (1971). Which means over the last 36 years, compilers have only doubled the performance of programs- or about a 2% gain per year.

Parenthetically, this is why Ocaml can still be “speedy” and not have complicated, expensive optimizations- the complicated, expensive optimizations simply don’t buy you that much. It does the simple optimizations which net a lot of performance gain for (comparatively) little pain, but doesn’t bother with the optimizations which are lots of pain for little gain.

Then wham- out of left field comes a grad student and an optimization speeding code up by 10% to three fold. That’s like 5 years to 55 years worth of compiler optimization development at current rates, all at one shot. And he’s not done- there are probably (almost certainly) improvements to that to be made.

]]> By: Robert Fischer http://enfranchisedmind.com/blog/posts/supero-followup/#comment-32023 Robert Fischer Wed, 12 Dec 2007 23:09:38 +0000 http://enfranchisedmind.com/blog/2007/12/12/supero-followup/#comment-32023 Your mark-up is broke. This is pretty cool that it's being applied so widely, but I kinda expected this out of functional languages. So much is known at compile-time that I'd expect huge gains -- in fact, I guess I was implicitly thinking that this was happening in OCaml, which is part of the reason it's so speedy. Your mark-up is broke.

This is pretty cool that it’s being applied so widely, but I kinda expected this out of functional languages. So much is known at compile-time that I’d expect huge gains — in fact, I guess I was implicitly thinking that this was happening in OCaml, which is part of the reason it’s so speedy.

]]>