If i may ask, what country do you live?

Marc M. (marcmfs@hotmail.com) on 6/21/03 wrote:
---------------------------
>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.