Article: Escape From the Planet of x86
By: David Wang (dwang.delete@this.realworldtech.com), June 20, 2003 7:52 pm
Room: Moderated Discussions
Bill Todd (billtodd@metrocast.net) on 6/20/03 wrote:
---------------------------
>David Wang (dwang@realworldtech.com) on 6/20/03 wrote:
>---------------------------
>>AMD's best SPECint numbers as reported on spec.org seems to be the 1095 base and
>>1170 peak numbers. Beating those numbers would also seem to be well within reach
>>of the 1.5 GHz Madison, and that would support Arcadian's "modest claim" of "beating".
>
>No, since they were made in the immediate context of Fred Weber's report of a SPECint
>score of 1202 for the 2 GHz part: that's the score Madison needs to beat for Arcadian's
>statement to stand (and with a bit of compiler advance it well may) - and even then
>it needs to remain standing for the next six months.
I expect the 1.5 GHz Madison to exceed 1202, that's not a substantially higher bar over above and beyond 1170.
As to "it needs to stand for the next six months", I don't see that as a necessity. The Itanium 2 system chipset inherited from McKinley based platform is in need of a minor overhaul. If this overhaul comes anytime soon, that could kick up the SPECxxx scores another half of a notch even without kicking up the processor frequency.
AMD may "take back the crown" in SPECint for brief periods of time, but as long as Madison leads for substantially longer period of time in 2003 or Madison ends 2003 leading then I'd give support to the claim of "beating".
>>At least until AMD could ship 2+ GHz Opterons and/or perhaps get better compiler support to pull those numbers up.
>
>Exactly. And in this case advances in compilation would seem to be at least as
>applicable to Hammer 64-bit performance as they are so often claimed to be to getting EPIC up to speed.
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. Whether Intel and its friends can advance the compiler enough to extract out most of the "potential performance" is an open question. What is not an open question is the size of Intel's warchest in being able to fund R&D in all areas, including compiler development. The warchest will in my opinion give the advantage in compiler advancements to Intel. The "potential headroom" may be "just as applicable", but compiler support should at least be enjoying a small step function jump in this stage of the EPIC/Itanium platform's development, roughly a year after McKinley shipment date.
---------------------------
>David Wang (dwang@realworldtech.com) on 6/20/03 wrote:
>---------------------------
>>AMD's best SPECint numbers as reported on spec.org seems to be the 1095 base and
>>1170 peak numbers. Beating those numbers would also seem to be well within reach
>>of the 1.5 GHz Madison, and that would support Arcadian's "modest claim" of "beating".
>
>No, since they were made in the immediate context of Fred Weber's report of a SPECint
>score of 1202 for the 2 GHz part: that's the score Madison needs to beat for Arcadian's
>statement to stand (and with a bit of compiler advance it well may) - and even then
>it needs to remain standing for the next six months.
I expect the 1.5 GHz Madison to exceed 1202, that's not a substantially higher bar over above and beyond 1170.
As to "it needs to stand for the next six months", I don't see that as a necessity. The Itanium 2 system chipset inherited from McKinley based platform is in need of a minor overhaul. If this overhaul comes anytime soon, that could kick up the SPECxxx scores another half of a notch even without kicking up the processor frequency.
AMD may "take back the crown" in SPECint for brief periods of time, but as long as Madison leads for substantially longer period of time in 2003 or Madison ends 2003 leading then I'd give support to the claim of "beating".
>>At least until AMD could ship 2+ GHz Opterons and/or perhaps get better compiler support to pull those numbers up.
>
>Exactly. And in this case advances in compilation would seem to be at least as
>applicable to Hammer 64-bit performance as they are so often claimed to be to getting EPIC up to speed.
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. Whether Intel and its friends can advance the compiler enough to extract out most of the "potential performance" is an open question. What is not an open question is the size of Intel's warchest in being able to fund R&D in all areas, including compiler development. The warchest will in my opinion give the advantage in compiler advancements to Intel. The "potential headroom" may be "just as applicable", but compiler support should at least be enjoying a small step function jump in this stage of the EPIC/Itanium platform's development, roughly a year after McKinley shipment date.
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 |