Not too long after IBM just released the Hurricane chipset for Xeons,
which took the crown away from Opteron, a 4-way dual-core Opteron system
came out swinging. An IBM Hurricane 4-way xSeries 366 does 150704
transactions per minute, while an HP DL585 4-way dual-core Opteron does
187296 TPM in the TPC-C tests.

Looks like the battle continues.

The Linux Beacon--Battle of the X64 Platforms
http://www.itjungle.com/tlb/tlb051005-story02.html

Yousuf Khan

On Wed, 01 Jun 2005 08:48:57 -0400, Yousuf Khan <(E-Mail Removed)>
wrote:

>Not too long after IBM just released the Hurricane chipset for Xeons,
>which took the crown away from Opteron, a 4-way dual-core Opteron system
>came out swinging. An IBM Hurricane 4-way xSeries 366 does 150704
>transactions per minute, while an HP DL585 4-way dual-core Opteron does
>187296 TPM in the TPC-C tests.
>
>Looks like the battle continues.
>
>The Linux Beacon--Battle of the X64 Platforms
>http://www.itjungle.com/tlb/tlb051005-story02.html
>

That article says many more interesting things than that a dual-core
Opteron 4-way beats at Xeon single-core 4-way by a wopping 20%.

Interesting speculation about the origins of the x86-64 instructions
sets (could be Intel's, after all, eh, George).

Even more interesting comment about the difficulty of going beyond
dual core on a single die, no explanation, other than hand-waving
about cache hierarchies as to why.

If you can't expand the number of cores and you can't speed up the
clock, then, that's it, we're done, before the end of Moore's law
(short of a completely new architecture. I like obvious expansability
of the Cell architecture, myself.)

RM

"Yousuf Khan" <(E-Mail Removed)> wrote in message
news:59ine.13397$_(E-Mail Removed)...
> Not too long after IBM just released the Hurricane chipset for Xeons,
> which took the crown away from Opteron, a 4-way dual-core Opteron
> system came out swinging. An IBM Hurricane 4-way xSeries 366 does
> 150704 transactions per minute, while an HP DL585 4-way dual-core
> Opteron does 187296 TPM in the TPC-C tests.
>
> Looks like the battle continues.
>
> The Linux Beacon--Battle of the X64 Platforms
> http://www.itjungle.com/tlb/tlb051005-story02.html
>
> Yousuf Khan

How does a 32 way opteron do compared to a 32 way X3 x366? And isn't
there a dual core Xeon coming on down the road from your buddies at
Intel? Pretty tough to beat opteron until it runs out of HT links. :-)

del cecchi

Robert Myers wrote:
> Interesting speculation about the origins of the x86-64 instructions
> sets (could be Intel's, after all, eh, George).

There's only so many ways to skin a cat. Extending x86 out to 64-bit
can be done in a number of ways, all of which would end up looking
similar -- it has to be /x86/ in the end, afterall. One thing that
could've been done different would be whether to retain segment
registers in the extended instruction set. Another change that was
entirely upto the designers was whether to extend the number of general
purpose registers or not.

> Even more interesting comment about the difficulty of going beyond
> dual core on a single die, no explanation, other than hand-waving
> about cache hierarchies as to why.

It just sounded like all he was saying was that it quickly gets to a
situation where there are too many threads to go around. Lots of
execution units (multiple cores with multiple threads), but not enough
programs to run on them. But I can't agree with that assessment, even
in a desktop system you have tons of background processes always
running. If you can run each of those simultaneously without the need
to timeslice them as much, then you'll get a more responsive feeling
system, even if none of these background processes uses a lot of CPU
time.

Yousuf Khan

On Wed, 1 Jun 2005 11:45:13 -0500, "Del Cecchi"
<(E-Mail Removed)> wrote:

>
>"Yousuf Khan" <(E-Mail Removed)> wrote in message
>news:59ine.13397$_(E-Mail Removed)...
>> Not too long after IBM just released the Hurricane chipset for Xeons,
>> which took the crown away from Opteron, a 4-way dual-core Opteron
>> system came out swinging. An IBM Hurricane 4-way xSeries 366 does
>> 150704 transactions per minute, while an HP DL585 4-way dual-core
>> Opteron does 187296 TPM in the TPC-C tests.
>>
>> Looks like the battle continues.
>>
>> The Linux Beacon--Battle of the X64 Platforms
>> http://www.itjungle.com/tlb/tlb051005-story02.html
>>
>> Yousuf Khan
>
>How does a 32 way opteron do compared to a 32 way X3 x366?

We'll have to wait until EITHER of those systems are available before
we can know for sure

> And isn't
>there a dual core Xeon coming on down the road from your buddies at
>Intel?

Dual-core Xeon for 1 and 2 processor workstations should be out late
this year or early next year. The dual-core version of the XeonMP
used in the above-mentioned x366 is probably more than a year away
from release.

> Pretty tough to beat opteron until it runs out of HT links. :-)

Beyond 8 sockets you need to go to a cross-bar design for an Opteron,
and such a design might be beneficial when going beyond 4 sockets.
For the Xeon you have to go to a cross-bar design at 4 socket as well,
so really the order of things don't change much here. Only problem is
that, to date, no company has released an Opteron chipset designed to
work in a cross-bar sort of setup. Those Newisys folks have talked
about one with their Horus chip and I think they've even done a few
demos, but nothing that's available in the market yet.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

"Tony Hill" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Wed, 1 Jun 2005 11:45:13 -0500, "Del Cecchi"
> <(E-Mail Removed)> wrote:
>
>>
>>"Yousuf Khan" <(E-Mail Removed)> wrote in message
>>news:59ine.13397$_(E-Mail Removed)...
>>> Not too long after IBM just released the Hurricane chipset for Xeons,
>>> which took the crown away from Opteron, a 4-way dual-core Opteron
>>> system came out swinging. An IBM Hurricane 4-way xSeries 366 does
>>> 150704 transactions per minute, while an HP DL585 4-way dual-core
>>> Opteron does 187296 TPM in the TPC-C tests.
>>>
>>> Looks like the battle continues.
>>>
>>> The Linux Beacon--Battle of the X64 Platforms
>>> http://www.itjungle.com/tlb/tlb051005-story02.html
>>>
>>> Yousuf Khan
>>
>>How does a 32 way opteron do compared to a 32 way X3 x366?
>
> We'll have to wait until EITHER of those systems are available before
> we can know for sure
>
>> And isn't
>>there a dual core Xeon coming on down the road from your buddies at
>>Intel?
>
> Dual-core Xeon for 1 and 2 processor workstations should be out late
> this year or early next year. The dual-core version of the XeonMP
> used in the above-mentioned x366 is probably more than a year away
> from release.
>
>> Pretty tough to beat opteron until it runs out of HT links. :-)
>
> Beyond 8 sockets you need to go to a cross-bar design for an Opteron,
> and such a design might be beneficial when going beyond 4 sockets.
> For the Xeon you have to go to a cross-bar design at 4 socket as well,
> so really the order of things don't change much here. Only problem is
> that, to date, no company has released an Opteron chipset designed to
> work in a cross-bar sort of setup. Those Newisys folks have talked
> about one with their Horus chip and I think they've even done a few
> demos, but nothing that's available in the market yet.
>
> -------------
> Tony Hill
> hilla <underscore> 20 <at> yahoo <dot> ca

Sorry about the momentary lapse of reason. I was referring to the x460
which was announced today. Here is the availability stuff
--------------------------
The IBM eServer xSeries 460 is planned to be available in mid-June. The
x460 entry price starts at $18,129 in the U.S., and typical eight-way
configurations start at $72,182 in the U.S. IBM's eServer X3
architecture-based systems run new scalable 64-bit x86 operating system
software from major technology vendors including Microsoft, Red Hat and
Novell.
---------------------------------

As for performance, an 8way is said to do 250k tpmc (the press release is
at http://biz.yahoo.com/iw/050601/087845.html
) and it is "dual core capable". Goes up to a 32 way.

Del Cecchi

On Wed, 01 Jun 2005 09:43:37 -0400, Robert Myers <(E-Mail Removed)>
wrote:

>On Wed, 01 Jun 2005 08:48:57 -0400, Yousuf Khan <(E-Mail Removed)>
>wrote:
>
>>Not too long after IBM just released the Hurricane chipset for Xeons,
>>which took the crown away from Opteron, a 4-way dual-core Opteron system
>>came out swinging. An IBM Hurricane 4-way xSeries 366 does 150704
>>transactions per minute, while an HP DL585 4-way dual-core Opteron does
>>187296 TPM in the TPC-C tests.
>>
>>Looks like the battle continues.
>>
>>The Linux Beacon--Battle of the X64 Platforms
>>http://www.itjungle.com/tlb/tlb051005-story02.html
>>
>
>That article says many more interesting things than that a dual-core
>Opteron 4-way beats at Xeon single-core 4-way by a wopping 20%.
>
>Interesting speculation about the origins of the x86-64 instructions
>sets (could be Intel's, after all, eh, George).

Ha-ha never miss a chance to diminish AMD do you?:-) One thing you maybe
missed of course is that this article is an Intel mouthpiece: he knows all
the Intel CPU *and* platform code names -- in *excruciating* detail -- well
into 2006 and still calls Opteron a "Sledgehammer"... d'oh, what happened
to Venus, Troy, Athens, Denmark, Italy, Egypt?... all of them publicly
available.

Then it's a "conspiracy theorist" err, theory. Surely Intel must have
looked at some kind of x86-64 at some time prior to AMD but ISTR the word
"impossible" or maybe "impractical" being mentioned at one time when they
were trying to justify Itanium. Certainly Intel seemed to want *something*
of AMD's... or the would never have signed the cross-license agreement of
Jan 1, 2001.

It does also irk me when people refer to AMD64 as "memory extensions"...
belies a possible ignorance of the details IMO. The one thing we know
which is Intel's in AMD64 is the use of SSEx for addressable FP
registers... something which AMD adopted after the above cross-license
agreement. Recall that prior to that AMD had defined a completely new FPU
with 16 named registers.

>Even more interesting comment about the difficulty of going beyond
>dual core on a single die, no explanation, other than hand-waving
>about cache hierarchies as to why.

Well IBM said it and they are ahead of the game here.

>If you can't expand the number of cores and you can't speed up the
>clock, then, that's it, we're done, before the end of Moore's law
>(short of a completely new architecture. I like obvious expansability
>of the Cell architecture, myself.)

As we already discussed, Cell as we know it, would require a major rework
to get above 4GB memory and DP FPU - "doable" I suppose but.....

--
Rgds, George Macdonald

George Macdonald <fammacd=!SPAM^(E-Mail Removed)> wrote:

> Then it's a "conspiracy theorist" err, theory. Surely Intel must have
> looked at some kind of x86-64 at some time prior to AMD but ISTR the word
> "impossible" or maybe "impractical" being mentioned at one time when they
> were trying to justify Itanium. Certainly Intel seemed to want *something*
> of AMD's... or the would never have signed the cross-license agreement of
> Jan 1, 2001.

At the time of the Intel/HP collaboration, Intel was working on P7,
which was a 64 bit x86 processor. I do not believe that Intel (or
anyone representing Intel) would have suggested anything that
suggests that x86-64 was "impossible" or "impractical". Switching
from x86-64 ISA to IA64 was not because x86-64 was "impossible" or
"impractical". It was believed to be "better".

When Intel finally decided to do the 64 bit extension to x86, it
could well have done whatever it wanted to do in terms of
programming model extension. The problem is ofcourse the guy
up in NW part of the US put his foot down and says that he'll not
support yet another ISA from Intel. It would be an interesting
power struggle, but if BG wants to be bullheaded about it, he wins
by default. Nothing Intel can do.

> As we already discussed, Cell as we know it, would require a major rework
> to get above 4GB memory and DP FPU - "doable" I suppose but.....

IBM taped out a new CELL processor with a new PPE. The die size
grew from 221 mm^2 to 235 mm^2. Compared to that effort, any memory
system re-work needed to get more memory capacity support is relatively
minor.

Also, DP FPU is already in both the PPE and SPE, so I'm not sure what
you mean by "and DP FPU".


--
davewang202(at)yahoo(dot)com

George Macdonald wrote:
> Ha-ha never miss a chance to diminish AMD do you?:-) One thing you maybe
> missed of course is that this article is an Intel mouthpiece: he knows all
> the Intel CPU *and* platform code names -- in *excruciating* detail -- well
> into 2006 and still calls Opteron a "Sledgehammer"... d'oh, what happened
> to Venus, Troy, Athens, Denmark, Italy, Egypt?... all of them publicly
> available.

Oh, I don't know, the article seemed relatively even-handed, even if he
was more familiar with Intel technology than AMD ones. For example, he
went into tremendous historical background about Intel's power
management technologies and how they ended up in its server chips. But
then he sort of just said AMD's Powernow technology has been in
production in Opterons for a long time now, so it's nothing new for AMD.
Yes, it was much less verbiage for AMD, but not dismissive in any way.

Oh and he did refer to AMD64 by its previous name of x86-64, while
easily remembering to call Intel EM64T. Yes, definitely more familiar
with Intel technology it looks like.

> It does also irk me when people refer to AMD64 as "memory extensions"...
> belies a possible ignorance of the details IMO. The one thing we know
> which is Intel's in AMD64 is the use of SSEx for addressable FP
> registers... something which AMD adopted after the above cross-license
> agreement. Recall that prior to that AMD had defined a completely new FPU
> with 16 named registers.

I get the feeling that AMD was playing the same game as Intel in that
case. There was tremendous speculation about whether AMD would adopt
Intel's SSE2 specs for K8-generation processors, much like there was
speculation about whether Intel would adopt AMD's version of x86-64. In
the end, both parties did adopt each other's technology thus providing
software companies a huge sigh of relief. It was a big game of bluff.


Yousuf Khan

On 1 Jun 2005 11:16:20 -0700, "YKhan" <(E-Mail Removed)> wrote:

>Robert Myers wrote:
>> Interesting speculation about the origins of the x86-64 instructions
>> sets (could be Intel's, after all, eh, George).
>
>There's only so many ways to skin a cat. Extending x86 out to 64-bit
>can be done in a number of ways, all of which would end up looking
>similar -- it has to be /x86/ in the end, afterall. One thing that
>could've been done different would be whether to retain segment
>registers in the extended instruction set. Another change that was
>entirely upto the designers was whether to extend the number of general
>purpose registers or not.
>
As the article suggests, getting identical instruction sets, even what
you regard as narrow design constrainsts, would have been about as
likely as winning the lottery.

>> Even more interesting comment about the difficulty of going beyond
>> dual core on a single die, no explanation, other than hand-waving
>> about cache hierarchies as to why.
>

>It just sounded like all he was saying was that it quickly gets to a
>situation where there are too many threads to go around. Lots of
>execution units (multiple cores with multiple threads), but not enough
>programs to run on them. But I can't agree with that assessment, even
>in a desktop system you have tons of background processes always
>running. If you can run each of those simultaneously without the need
>to timeslice them as much, then you'll get a more responsive feeling
>system, even if none of these background processes uses a lot of CPU
>time.
>
If that's what he was saying, he wasn't very explicit about it.
Server applications have an endless supply of threads. Maybe that's
the kind of very specific application he had in mind when talking
about Niagara.

RM