Vincent Diepeveen (diep@xs4all.nl) on 6/20/03 wrote:
---------------------------
>David Wang (dwang@realworldtech.com) on 6/20/03 wrote:
>---------------------------
>>Bill Todd (billtodd@metrocast.net) on 6/20/03 wrote:
>>---------------------------
>>>David Wang (dwang@realworldtech.com) on 6/20/03 wrote:
>>
>>>>The "headroom" that may exist in platform performance that could be extracted out
>>>>by compiler would presumably be larger on the Itanium/EPIC side as compared to the
>>>>hammer/64 bit side.
>>>
>>>Not in the short term that we're talking about. Multiple well-funded and highly-qualified
>>>compiler teams have been working on EPIC compilers for half a decade or more now,
>>>so while it's not unreasonable to speculate that there may still be a good deal
>>>more compiler potential to mine all the low-hanging fruit was picked quite some
>>>time ago and that potential is likely to be realized only gradually (if at all)
>>>over time. By contrast, my impression is that the AMD64 compiler efforts started
>>>considerably more recently and have been far less well funded: AFAIK we have only
>>>a single 64-bit SPECint result to look at so far (from the gcc compiler; nothing
>>>from either the Portland or Microsoft compilers), not a couple of generations' worth
>>>on multiple compilers as Itanic has.
>>
>>People have been working on various incarnations of EPIC/VLIW compilers for a while,
>>and there are still some serious "issues" outstanding, but there's one thing that
>>can't be beat that's different from the past year alone as opposed to all the years
>>before, and that's the availability of actual hardware to run the compiler on. You
>>can work on all the compiler issue you want, and you can check the assumptions against
>>a simulator, perhaps even one that's cycle accurate, but accurate simulators are
>>at least a couple of orders of magnitude slower than actual hardware.
>>
>>The result is that if you wanted to check the net effect of a few compiler switches
>>on the SPEC suite. You can simulate the entire run, and that will take perhaps
>>several compute-months. (or you just take a short run and pretend that it's just as good as the entire run)
>
>Trivially the brute force method is slow.
>
>With some AI and guessing techniques you can approach the effect of big changes very quickly.
>
>Whether it is 0.00001% better or 0.001% better is simply not relevant in such guessing
>techniques. All you want to know is whether it is better than the current existing bound.
>
>Doesn't take away that one needs quite some AI and hard work to such guessing techniques do very well.
>
>If i would not work with such guessing techniques, then my software would need
>millions of years to improve considerably instead of quickly :)
>
>The best guessing technique is usually done by human intelligence and experience.
>
>It's only very seldom that the brute force technique for a real new release needs to get done.
>
>However reality is that the vaste majority of such software like compilers (and
>all other products) are focussed upon small step improvements; if there is a 10
>line code change then that change gets already tested because people can write down
>in their logbooks: "i improved it this morning and now i put the machine to work
>to test the change, so this afternoon i therefore monitor the results and guess whether it works while drinking coffee".
>
>It is basically that last attitude that prevents big companies from advancing way
>faster than would be possible if such a person would be working at a small company.
>
>That slow steady progress of big companies therefore has good points for small competitors.
>
>It doesn't take away that months of calculations usually is not needed. You just
>want to know whether a modification is doing *better*. Not whether it is improving you 0.0000001% or 0.0000002%.
>
>There is substantial evidence for the above claim of mine to be the truth.
>
>May i note for that to the hard fact that from the supercomputers worldwide which
>can be used for this type of brute force simulations, 90% of the time they are idle.
>
>Of course it differs from company to company and department from a company to other
>departments of that company, but 90% is still a very polite guess.
>
>The excuse of that progress cannot be faster because of lack of calculation systemtime
>nowadays is simply a false claim with respect to compiler optimizations.
>
>A bigger problem with such products is that programmers earn less than teamleaders.
>Managers earn even more than teamleaders. Everyone tries to get promoted to the
>next rank as soon as possible. However a single brilliant programmer can progress
>a compiler really a lot. Yet he won't get paid as much as a manager to stay as a
>brilliant programmer. Instead he moves on to get a non-programming teamleader, or
>he changes company and gets a job where his brilliancy in programming for sure hardly is needed.
>
>That is what happens in the big companies. It is a bad shame, but it is the real truth...
>
>>If you had actual hardware, your assumptions could be verified or rejected on actual
>>hardware in a matter of few compute-hours. That has to be significant along the way somewhere.
>
>Best regards,
>Vincent
>

My experiance doesn't support your claims. BUT, it is well rumored that this process is what happens. I don't agree tho.

I know enough programers that have been offered a higher rung in the corporate ladder that have also refused.

Well run companies, regardless of size recognize that some ppl are suited for some jobs and not others, and they also realize that given the right incentives the managers will keep thier creative talent happy, even if it means that there is a disparity in pay compared to the rest of the corporate structure.

Intelligent and capable managers, (middle management), will get better deals for thier star personel simply becuase it reflects on the managers long term success. Middle management now has more responsibility than they did in say the seventies, even tho i wasn't there for it it is well documented how management styles have changed in the past 30 yrs.

I pass on a book that Paul D. suggested a while back:
http://www.ercb.com/feature/feature.0001.html

The relevance of the book has to do in how a big company sees the project and how a smaller company, (or indeed a single programer) sees a project.

also, as soon as i find the articles in my collection (hopefully my friend didn't take it) of publications from the Hoover institute at stanford i will add a link to it.

Marc M.