 | | | Opinions AMD64 vs EM64T vs Itanium II | Opinions AMD64 vs EM64T vs Itanium II 2006-08-26 - By Kostas Georgiou
Back
On Sat, Aug 26, 2006 at 09:12:28AM +0200, Arjan van de Ven wrote:
> On Fri, 2006-08-25 at 17:56 -0500, Paul Krizak wrote:
>
> > 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.
I assume that the following comment from the RHEL3 U2 update is still valid or
has something changed with woodcrest?
???Software IOTLB ??? Intel EM64T does not support an IOMMU in hardware while
AMD64
processors do. This means that physical addresses above 4GB (32 bits) cannot
reliably be the source or destination of DMA operations. Therefore, the Red Hat
Enterprise Linux 3 Update 2 kernel "bounces" all DMA operations to or from
physical addresses above 4GB to buffers that the kernel pre-allocated below 4GB
at boot time. This is likely to result in lower performance for IO-intensive
workloads for Intel EM64T as compared to AMD64 processors.???
> 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.
True I don't buy anything with an NVidia chipset for this reason. But NVidia
isn't the only option for an Opteron motherboard.
> 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).
You should also benchmark *your* application under each CPU. For our workloads
raw cpu power (even under unoptimized code) is the only real factor so we
can live with suboptimal drivers for IO for example in our computing nodes,
for the storage nodes the situation is reversed of course.
> > 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.
Well if your application cares about memory latency it might make
a huge difference. It all depends on what you do.
I haven't got any woodcrest machines yet (I'll have some in a couple
of weeks) but I have seen some reports that memory performance is
worst than expected in woodcrest.
Have a look at this beowulf thread for example.
http://www.beowulf.org/pipermail/beowulf/2006-August/016131.html
Cheers,
Kostas Georgiou
--
Taroon-list mailing list
Taroon-list@(protected)
https://www.redhat.com/mailman/listinfo/taroon-list
|
|
|