September 8, 2006 4:00 AM PDT

Intel server revamp to follow AMD

(continued from previous page)

AMD has adopted the integrated memory controller in all its x86 chips, but it's not alone in endorsing the approach. IBM's Power and Sun Microsystems' UltraSparc, which compete with Intel's server line, have had integrated memory controllers for years.

With a chipset controlling memory instead of the main processor, "You basically have this middleman, and that introduces a significant amount of latency in the memory transaction," said Mercury Research analyst Dean McCarron.

An integrated memory controller not only lets main memory respond faster, it also allows cache sizes, and therefore chip-manufacturing expenses, to be reduced. Indeed, smaller cache sizes have helped AMD remain competitive with Intel, even though it's about a year behind in its transition to more advanced manufacturing with smaller circuitry elements.

Intel defends its decision to stick with the front-side bus as long as it has, arguing that the choice has given it flexibility in memory standards and that it's been able to compensate elsewhere to keep up with performance.

"Our competition had to go to an integrated memory controller because they can't get the same...amount of cache on a die as we can," Kilroy said. "And we've been able to scale the front-side bus far greater than ever thought. We're now at 1333MHz. The speculation was that we wouldn't be able to scale to that."

Lowering design barriers
CSI is designed to lower hardware barriers, making it less expensive for server makers to design servers using both chips. Indeed, the word "common" refers to the fact that Itanium and Xeon use the interface.

With CSI, a server could be designed to be totally "plug-compatible," meaning the chips would be interchangeable, Church said. "From a Unisys perspective, if a customer wants an Itanium system, we take an Itanium processor and plug it into our common platform. If they want Xeon, we plug a Xeon into our common platform," he said. "That essentially is the nirvana, and it is the goal."

Nevertheless, server makers are faced with some differences in CSI for Xeon and Itanium, Marcello said. "The CSI implementations are 95 percent the same, but there's a little bit of difference there. For that reason, we'll be close but not exactly the same," he said. However, they will be similar enough that some joint design work can be shared, he added.

Keeping up with the Joneses
Once Intel matches AMD's chip communication technologies, it will become a better competitor, Brookwood said.

"The big issue for Intel is moving from the front-side bus architecture to more of a distributed architecture," Brookwood said. "Once they get that in place and have workable schemes for managing cache coherency and memory access across processors, then they will be well-positioned to compete on almost any basis with what AMD has been doing. The Direct Connect architecture has been AMD's not-so-secret sauce for the last four years."

But AMD has plans of its own. In 2007, it will move to HyperTransport 3.0. The update increases communication speeds and enables construction of 16-processor servers instead of the eight-processor machines that HyperTransport currently permits, said Marty Seyer, a vice president in AMD's commercial business unit.

In addition, the company believes the openness of HyperTransport is an advantage. The technology is governed and licensed by the HyperTransport Consortium.

One company very interested in HyperTransport's openness is Cray. "It's a huge benefit," said Jan Silverman, senior vice president of corporate strategy at the supercomputer maker. "It's not free, but the terms are much more palatable than anything that I have seen from Intel in the past."

The openness also means Cray can use HyperTransport to connect Opteron chips to its own networking chips. And when it wants to use HyperTransport to plug calculation acceleration engines into a computer, it can buy them from a company called DRC Computer that specializes in the engines, instead of having to make its own.

AMD's Opteron years have left an impression on Silverman that Intel will have to work hard to reverse. "There was a point in time when Intel used to lead the industry. Now they're following AMD on 64 bits, following on dual-core, following on low-power consumption chips, and now they're going to follow AMD in exposing their Intel architecture," Silverman said.

Previous page
Page 1 | 2

See more CNET content tagged:
Intel server, Insight 64, Intel Itanium, Intel Xeon, Unisys Corp.

8 comments

Join the conversation!
Add your comment
Poor Cray
I think Jan Silverman's comments at the end of the article are a bit unwarrnted. AMD has done their fair share of following too.

Cray has a contract with AMD so they are not exactly a neutral source, and I know people tend to associate Cray with "supercomputers" but these days they hold only a 3.2% share (and falling) on the top500.org list. AMD systems make up 3/4's of their 3.2%.

Looking here: <a class="jive-link-external" href="http://top500.org/stats/27" target="_newWindow">http://top500.org/stats/27</a> under "proc family" you can see that Intel now powers &gt; 60% of the systems on the top500. list.

Cray has every reason to skew Intels image.
Posted by Dachi (797 comments )
Reply Link Flag
AMD used to follow then Intel had to follow...
AMD for the very reasons Silverman stated. Intel had a 32/64bit project but scrapped it because they "knew" we all wanted Itanic instead of x86.
It turned out that they just flat bet on the wrong horse.
They "knew" we all wanted RAMBUS RDIMMs so that's all they supported in their first P4 chipsets, OOPs they bet on the wrong horse again!
Even after AMD gained market share in the server area for multi-processor systems becuase they had Hypertransport, they knew that we want higher latency and wait states implementing their HUB architecture, OOPs it looks like they are finally admitting that throwing cache at the problem is not the solution.
Also the Intel spokesperson indicated that AMD didn't put more cache on their chips because they weren't at the same geometry yet, That's bunk it's because they didn't need as much cache because they weren't in as many wait states waiting for the bus arbiter to allow it to talk.

I applaud Intel for finally figuring out that their FSB HUB architecture was inferior in multi-processor systems, but just as was the case for the preceeding scenarios they are always late to the party.
This wasn't always the case but they got the "Not Invented Here" syndrome and if if wasn't then we (the consuming IT public) didn't need it. This is whay AMD gained share and Intel lost share.
Also Intel has sold more processors than AMD in all cases but the issue was not that, it was that AMD was gaining ground and Intel was not only starting to lose sales to AMD but the informed IT public knew it was a superior technology.
I will say that Intel has come a long way for their single processor systems with the Core architecture, good for them.

But throwing 16MB of cache at a server processor is admission in itself that their multi-processor architecture is nothing but a big bottleneck. What a waste of 65nM technology and die space. For the space they are putting that cache on they could probably put another two cores, L1 cache and arbitration logic.
Posted by fred dunn (793 comments )
Link Flag
big cache is still good
locality of reference is a good thing, but more difficult when the individual references consume more of the cache. To go to a 64-bit architecture with larger binaries and maintain similar levels of locality, the cache has to grow at the same rate as the binaries. Optimizations such as instruction bundling increase fetch sizes too, increasing the need for larger cache to maintain locality.

Additional hardware, cores, etc. is a brute force mechanism for improving perf that typically comes with increased production cost, lower yields (due to complexity) and higher power consumption.

Frankly, I can't believe AMD has limped along with tiny little caches as long as they have. Once they transition their register file completely, they'll have to make this change. When they do, their codegen will be simpler and their perf will improve.
Posted by Hardrada (359 comments )
Reply Link Flag
 

Join the conversation

Add your comment

The posting of advertisements, profanity, or personal attacks is prohibited. Click here to review our Terms of Use.

What's Hot

Discussions

Shared

RSS Feeds

Add headlines from CNET News to your homepage or feedreader.