Re: Optimizing Across && And ||

leichter@zodiac.rutgers.edu writes:
>[Powell's approach was ``best simple'', to generate pretty good
> code while keeping the optimizer simple, fast, widely applicable
> and correct. His compiler was very competative. This lesson
> has to be re-learned periodically.]


Opinion alert:


I think that most compiler writers understand Powell's rule, but
continue to write hairy optimizers. Why? I believe it's market
pressure, I think the pressure is real (not imagined) and that
today the lesson needs to be ``re-learned'' by the customers who
are making buying decisions based primarily on benchmarks.


I've talked with compilers folks at a couple of workstation
vendors, and they report that the spend a lot of their lives
worrying about how well their compiler does at producing code for
each of the SPECmarks. I think the reason is clear: SPECmarks
sell, and businesses need to sell in order to stay in business.
SPECmarks are a measurable metric and a tangible goal; selling
code quality to management and customers is far harder. I have
not talked much with compiler writers at the compiler vendors, but
I assume they tell the same story: customers buy their compilers
largely on the basis of code quality on benchmarks. After all, a
customer will say, if the resulting code is a few percent faster
than the competition, it's a few percent faster, right?


I think we're starting to see changes here already, but it's an
uphill battle to sell reliability, which is unpleasant to talk
about and hard to measure. Performance is less hard (but not
easy) to measure and obviously desirable.


End of opinion alert :^)


;-D on ( ImSPECable ) Pardo
--

Return to the comp.compilers page.
Search the comp.compilers archives again.