not sure who said what, but
the main Intel x86 line is firmly focused on desktop/mobile with some provision for high volume servers.
(Of course, there is or will be Atom, Tolapi, Larrabee and probably a few others)

One needs to distinguish between the core, and IO (from core to core or memory, not disk or network). The core mostly impacts single socket performance. IO (and cache) mostly influences scaling.
So Intel is quite happy to build a very powerful core, but is hesistant to do super massive IO.
This is why Core2 leads (by a wide margin) the pack on SPEC CPU int (haven't looked at FP recently)
but Power4-6 has outstanding scaling on the fat pipes (and other work)

Barcelona with the 4 full-HT or 8 half links, allowing direct proc-proc connections in an 8-way
(what does Nehalem have?)
It probably possible to do 16 half HT links, but I don't think AMD will pursue that market, and neither will Intel with Nehalem. If Intel wants Itanium to survive, it should.

>>However, it appears to me that the time is coming when commodity x86 will be able
>>to scale up far enough to meet almost everyone's needs.
>>It seems possible to me, that once x86 overcomes it scalability problems, it may
>>dominate the high end in the same way it dominated PCs, workstations, and low-end servers--and for the same reasons.

On this matter, I don't see mainframe shops wanting to move, nor x86 or even risc shops wanting to go mainframe.
1. it would obsolete the people,
2. porting software is very expensive
my question is: how many young people (RCG) are training in mainframe? I don't know, but what will happen when the current old timers retire.
This would be like the nuclear power industry. Many people joined the work force upto the early 80s. but nearly none after, now that its back, there is huge gap between the retirees and new people

>>The places I've worked recently, there has always been tremendous resistance to
>>that single big box which had a different architecture and OS from all the other
>>servers in the place. It was not solely a matter of upfront costs. It was also a
>>matter of lock-in, need for different admins to adminster the big box, incompatibility,
>>uncertainty about the future of the proprietary platform, >etc.
>
>