Opinions AMD64 vs EM64T vs Itanium II 2006-08-28 - By Paul Krizak
Back
See my comments below...
Paul Krizak 5900 E. Ben White Blvd. MS 625
Advanced Micro Devices Austin, TX 78741
Linux/Unix Systems Engineering Phone: (512) 602-8775
Silicon Design Division Cell: (512) 791-0686
Note: The opinions expressed in this message are my own, and do
not necessarily reflect the views of my employer.
Arjan van de Ven wrote:
> On Fri, 2006-08-25 at 17:56 -0500, Paul Krizak wrote:
>> While I'm obviously a bit biased, I would definitely suggest going with
>
> I'm obviously equally biased and would suggest the other solution ;)
>
> A dual Woodcrest machine just plain rocks, and anyone who reads the
> independent benchmarks (either for Woodcrest or Core 2 Duo) can see
> that. A kick-ass microarchitecture and a huge cache make these things
> just fly!
The huge cache also reduces wafer yield (raising prices) and wouldn't be
required if the cores/sockets could communicate with the RAM with lower
latency.
>
>> an Opteron-based solution. AMD64 is the original x86-64 implementation
>> (EM64T is a clone of our architecture), and thus the linux community has
>> had more time to tweak the drivers, compilers, etc. to work with AMD64 cpus.
>
> actually drivers are Intels strong point. Intel generally "owns" the
> full platform, and provides lots of tuning, tweaking and testing on the
> drivers in our boards, such as ethernet and storage. And this work goes
> on all the time, so the latest RHEL has the latest tuned drivers and
> hardware. If you get a motherboard with chipsets from other vendors.. it
> varies. For example NVidia... there is a reverse engineered network
> driver only (unless you want to go through the hell of binary only
> stuff) and a SATA driver without NVidia support, so no "advanced" NCQ
> features etc etc.
I'll give you this one on the drivers. AMD tries very hard to work with
3rd party vendors to maintain good linux support, but there are
definitely areas that are lacking. nVidia is one of those areas.
However, with AMD having just purchased ATi, I can imagine that in the
near future AMD will "own the entire platform" just as Intel does. AMD
chip, ATi chipset, ATi graphics card.
>
> Whichever CPU you decide to buy, do investigate the driver situation
> closely, for example check which drivers are needed, and then check how
> often these get updated in RHEL (the release notes for the various
> update releases are a great resource for this).
Obviously we use AMD-based systems exclusively in our compute clusters,
and we've never had any trouble with driver support. Any device listed
on Red Hat's hardware compatibility list works fine, and all Tier-one
Opteron-based servers from HP, IBM, and Sun strive to be on that list.
> As for compilers; RHEL4 is compiled for generic afaik, but either way
> both the Opteron and Woodcrest microarchitecture can deal with just
> about all code thrown at it, compilers aren't that big a deal anymore.
>
>> Also, going with AMD chips provides a long and stable upgrade path. You
>> can start with dual-core DDR2/667 chips in your blades, and then when
>> quad-core comes out, you'll be able to upgrade to quad-core DDR2/800+
>> chips and stay within the same power envelope.
>
> so I can stick a quad-core in my socket 939/940 Opteron/Athlon64? I
> didn't realize that.
That's not true; socket 939/940 is a DDR1 platform; there is a new
socket (AM2 for desktops, ??? for servers) that is DDR2 capable. Buying
a dual-core DDR2-based system today allows you an upgrade path to
quad-core/DDR2 in the future. Since the memory controller is on-die,
that means you also get the benefits of an upgraded DDR2 controller at
the same time (DDR2/667 -> DDR2/800 or faster)
>
>> AMD chips scale much better past four cores than Intel's chips,
>
> I think you meant sockets not cores.
I meant both. AMD chips use a high-speed crossbar on-die to get to the
memory controller (virtually zero latency), and hypertransport to
communicate socket-to-socket (again, very low latency, very high
bandwidth). The result is that even if a core needs to access memory
attached to a different socket, the cumulative latencies are low enough
that the aggregate performance is still just as good (if not better)
than a traditional SMP architecture.
I should qualify that last statement by saying that my experience is
purely with AMD chips and how performance has scaled moving from the
K7/northbridge architecture to the K8/on-die memory controller architecture.
>> due to
>> Intel sticking with the antiquated front side bus architecture,
>
> with the bensley/woodcrest "a FSB per CPU" architecture the difference
> isn't really there other than a name for a 2 socket machine. The big
> difference is that AMD has the memory connected to the CPU rather than
> the chipset as Intel has. This has pros and cons at the same time: Pros
> are that if you use local memory, you have a lower latency. Cons are
> that your system de facto is NUMA and that you get all the problems
> associated with that: you only get this gain if both the kernel and the
> applications are NUMA aware. The kernel mostly is, applications...
> mostly not.
RHEL3 and RHEL4 still do not support NUMA properly; we run all of our
systems in non-NUMA/SMP mode and see very good performance. Again,
haven't pitted them against an intel box, but our internal benchmarks
indicate that NUMA (when it does work) doesn't buy us much, which would
indicate that SMP doesn't hurt us much.
>
>> whereas
>> AMD has high-speed HyperTransport links between each chip. When you get
>> those big beefy 4-socket 16-core blades, rest assured that the AMD
>> variety will perform much better than an equivalent Xeon configuration,
>> even if the 2-socket/4-core performance right now favors the Intel chips.
>
> I can agree to the part after the "even if" of course ;)
>
>
I still predict that AMD will continue to pwn in the 4/8-socket arena :-)
Cheers to healthy competition!!!
-Paul
--
Taroon-list mailing list
Taroon-list@(protected)
https://www.redhat.com/mailman/listinfo/taroon-list
|
|
