Article: Escape From the Planet of x86
By: Vincent Diepeveen (diep.delete@this.xs4all.nl), June 22, 2003 5:24 pm
Room: Moderated Discussions
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.
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.
Topic | Posted By | Date |
---|---|---|
New Silicon Insider Article | David Kanter | 2003/06/17 03:39 PM |
Srockholm Syndrome | anonymous | 2003/06/17 03:50 PM |
Srockholm Syndrome | Nate Begeman | 2003/06/17 04:32 PM |
Srockholm Syndrome | anonymous | 2003/06/18 02:23 PM |
Srockholm Syndrome | Scott Robinson | 2003/06/20 08:25 AM |
New Silicon Insider Article | Bill Todd | 2003/06/17 09:51 PM |
New Silicon Insider Article | Alberto | 2003/06/18 07:29 AM |
New Silicon Insider Article | José Javier Zarate | 2003/06/18 10:16 AM |
New Silicon Insider Article | Bill Todd | 2003/06/18 03:10 PM |
New Silicon Insider Article | Nate Begeman | 2003/06/18 03:25 PM |
New Silicon Insider Article | Tvar' | 2003/06/18 03:41 PM |
New Silicon Insider Article | Alberto | 2003/06/18 03:58 PM |
New Silicon Insider Article | Tvar' | 2003/06/18 04:04 PM |
New Silicon Insider Article | Alberto | 2003/06/18 04:24 PM |
New Silicon Insider Article | Tvar' | 2003/06/18 04:32 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/18 04:13 PM |
New Silicon Insider Article | Tvar' | 2003/06/18 04:23 PM |
New Silicon Insider Article | mas | 2003/06/18 04:11 PM |
New Silicon Insider Article | Alberto | 2003/06/18 03:45 PM |
New Silicon Insider Article | Bill Todd | 2003/06/18 11:46 PM |
New Silicon Insider Article | David Wang | 2003/06/19 12:13 AM |
New Silicon Insider Article | Bill Todd | 2003/06/19 01:14 AM |
New Silicon Insider Article | David Wang | 2003/06/19 10:52 AM |
New Silicon Insider Article | Paul DeMone | 2003/06/18 04:04 PM |
New Silicon Insider Article | Bill Todd | 2003/06/18 11:28 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/19 12:43 AM |
New Silicon Insider Article | Rob Young | 2003/06/19 10:23 AM |
New Silicon Insider Article | Bill Todd | 2003/06/19 04:53 PM |
New Silicon Insider Article | David Wang | 2003/06/18 11:29 PM |
New Silicon Insider Article | Bill Todd | 2003/06/19 12:03 AM |
New Silicon Insider Article | José Javier Zarate | 2003/06/19 05:33 AM |
New Silicon Insider Article | mas | 2003/06/19 06:37 AM |
New Silicon Insider Article | Bill Todd | 2003/06/19 04:40 PM |
New Silicon Insider Article | David Wang | 2003/06/19 05:25 PM |
New Silicon Insider Article | Bill Todd | 2003/06/19 06:00 PM |
New Silicon Insider Article | Alberto | 2003/06/19 06:29 PM |
New Silicon Insider Article | Speedy | 2003/06/19 06:48 PM |
New Silicon Insider Article | Alberto | 2003/06/20 04:57 AM |
New Silicon Insider Article | David Wang | 2003/06/19 06:52 PM |
New Silicon Insider Article | Bill Todd | 2003/06/19 09:00 PM |
New Silicon Insider Article | Anonymous | 2003/06/20 02:20 AM |
New Silicon Insider Article | Paul DeMone | 2003/06/20 09:11 AM |
New Silicon Insider Article | Anonymous | 2003/06/22 04:48 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/22 05:49 PM |
New Silicon Insider Article | Vincent Diepeveen | 2003/06/22 06:25 PM |
New Silicon Insider Article | José Javier Zarate | 2003/06/22 07:55 PM |
New Silicon Insider Article | Anonymous | 2003/06/23 09:59 AM |
New Silicon Insider Article | Paul DeMone | 2003/06/19 07:53 PM |
New Silicon Insider Article | Bill Todd | 2003/06/19 08:53 PM |
New Silicon Insider Article | David Wang | 2003/06/19 09:08 PM |
New Silicon Insider Article | Bill Todd | 2003/06/20 02:28 AM |
New Silicon Insider Article | David Wang | 2003/06/20 11:35 AM |
New Silicon Insider Article | Paul DeMone | 2003/06/20 12:29 PM |
New Silicon Insider Article | Bill Todd | 2003/06/20 07:10 PM |
New Silicon Insider Article | Marc M. | 2003/06/21 06:06 AM |
New Silicon Insider Article | Bill Todd | 2003/06/21 12:07 PM |
New Silicon Insider Article | Bill Todd | 2003/06/20 07:01 PM |
New Silicon Insider Article | David Wang | 2003/06/20 07:52 PM |
New Silicon Insider Article | Bill Todd | 2003/06/20 08:53 PM |
New Silicon Insider Article | David Wang | 2003/06/20 09:14 PM |
New Silicon Insider Article | Vincent Diepeveen | 2003/06/20 09:52 PM |
New Silicon Insider Article | Marc M. | 2003/06/21 08:16 AM |
New Silicon Insider Article | Vincent Diepeveen | 2003/06/22 05:24 PM |
New Silicon Insider Article | Singh, S.R. | 2003/06/21 04:39 AM |
New Silicon Insider Article | David Wang | 2003/06/21 09:10 AM |
IPF Compilers | Nate Begeman | 2003/06/21 10:10 AM |
IPF Compilers | Paul DeMone | 2003/06/21 10:45 AM |
Use ILP to extract more ILP | Paul DeMone | 2003/06/20 11:48 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/20 09:06 AM |
New Silicon Insider Article | Singh, S.R. | 2003/06/20 10:41 AM |
New Silicon Insider Article | David Kanter | 2003/06/21 04:34 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/22 03:22 PM |
New Silicon Insider Article | Bill Todd | 2003/06/20 06:52 PM |
New Silicon Insider Article | Marc M. | 2003/06/21 08:54 AM |
New Silicon Insider Article | Daniel Gustafsson | 2003/06/19 12:12 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/20 03:20 PM |
New Silicon Insider Article | Bryan Gregory | 2003/06/20 02:14 PM |
New Silicon Insider Article | mas | 2003/06/20 02:43 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/25 11:29 AM |
New Silicon Insider Article | José Javier Zarate | 2003/06/25 11:43 AM |
New Silicon Insider Article | Paul DeMone | 2003/06/25 11:52 AM |
lol, amazing coincidence :-) (NT) | mas | 2003/06/25 04:15 PM |
New Silicon Insider Article | Yoav | 2015/04/01 04:43 AM |