PDA

View Full Version : A64 vs P4 udah biasa.. EM64T vs AMD64?



Magician
21-02-2005, 09:34
Intel masih seperti biasa, nggak kapok. Kenceng di synthetic.
http://www.xbitlabs.com/images/cpu/x86-64-rc1/charts64/sandra-1.png
http://www.xbitlabs.com/images/cpu/x86-64-rc1/charts64/sandra-2.png

Tapi buat realworld?
http://www.xbitlabs.com/images/cpu/x86-64-rc1/charts64/povray.png
Hueuehehe.. yang ini aneh.. 64 bitnya lebih pelan dari 32 bit di Intel.. Mungkin karena dia pake data lebih gede..

http://www.xbitlabs.com/images/cpu/x86-64-rc1/charts64/minigzip.png
http://www.xbitlabs.com/images/cpu/x86-64-rc1/charts64/mandelbrot.png

Inget yang gue bilang mengenai implementasi 64 bit yang benernya udah telat? Kenapa game larinya segitu gitu aja? Ganti CPU yang lebih kenceng juga udah nggak ada guna? Ini sebabnya.
http://www.xbitlabs.com/images/cpu/x86-64-rc1/charts64/blobby-2.png

Terus, mengapa di sample pertama Intel lebih lambat? Si XBit Labs gue heran bisa nggak tahu... Masalah ini udah terkenal soalnya
Dari Red Hat: http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/release-notes/as-amd64/RELEASE-NOTES-U2-x86_64-en.html


· 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.

Dari Debian: http://lists.debian.org/debian-amd64/2004/12/msg00070.html


Paolo Alexis Falcone wrote:


On Thu, 02 Dec 2004 15:41:10 -0600, Jin Zhao <jzhao@qcorps.com> wrote:



I am currently faced with choosing one of them as our forthcoming 64 bit
platform. So far I read a couple of reviews, most of which seems favor
AMD64 a little bit. I also did some initial testings on an opteron box
with Debian pure64 unstale. So far it looks good.
The price differrence is not a big issue. The most important are
performance, reliability and compatibility, esp on Linux, most likely
Debian. We will use them to run server side java applicaitons.
Redhat mentioned this in their realease statement:
"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."
This issue may affect database usage, but probably not a java
applicaiton server. There might be other unkown issues as well. I am
eager to know what are the Debian team and users' point on these two
platforms, esp those who already used them.



AMD's original implementation of their AMD64 architecture is gauged as
superior engineering-wise by many hardware reviewers.
The Intel implementation still suffers from bandwidth starvation as
the same bus architecture as of old is still being used. This causes
problems when you get more processors and memory, which the AMD
implementation solves by making each processor have its own set of
memory and resources.

LWN: http://lwn.net/Articles/91870/?format=printable


Kernel memory allocations specify (implicitly or explicitly) the zone from which the memory is to be obtained. On 32-bit systems, the DMA code can simply specify a zone which matches the capabilities of the device and get the memory it needs. On 64-bit systems, however, the memory zones no longer align with the limitations of particular devices. So there is no way for the DMA layer to request memory fitting its needs. The only exception is ZONE_DMA, which is far more restrictive than necessary.

On some architectures - notably AMD's x86_64 - an I/O memory management unit (IOMMU) is provided. This unit remaps addresses between the peripheral bus and main memory; it can make any region of physical memory appear to exist in an area accessible by the device. Systems equipped with an IOMMU thus have no problems allocating DMA memory - any memory will do. Unfortunately, when Intel created its variant of the x86_64 architecture, it decided to leave the IOMMU out. So devices running on "Intel inside" systems work directly with physical memory addresses, and, as a result, the more limited devices out there cannot access all of physical memory. And, as we have seen, the kernel has trouble allocating memory which meets their special needs.

One solution to this problem could be the creation of a new zone, ZONE_BIGDMA, say, which would represent memory reachable with 32-bit addresses. Nobody much likes this approach, however; it involves making core memory management changes to deal with the shortcomings of a few processors. Balancing memory use between zones is a perennial memory management headache, and adding more zones can only make things worse. There is one other problem as well: some devices have strange DMA limitations (a maximum of 29 bits, for example); creating a zone which would work for all of them would not be easy.


Fedora: https://www.redhat.com/archives/fedora-devel-list/2004-December/msg00880.html




Re: ia32e, er EM64T that is...



From: Mogens Kjaer <mk crc dk>
To: Development discussions related to Fedora Core <fedora-devel-list redhat com>
Subject: Re: ia32e, er EM64T that is...
Date: Wed, 22 Dec 2004 08:23:36 +0100
Alan Cox wrote:
On Mon, Sep 06, 2004 at 10:11:51AM -0700, Jesse Keating wrote:


I guess a better question: With kernel 2.6, is there any need to have a specific ia32e vs amd64 kernel? Are all the differences worked out at runtime and thus a non-issue? Thanks.

em64t as Intel currently call it is pretty close to the x86-64 architecture
so its not too bad a clone. It lacks prefetch/prefetchw which can also be used by some fancy user space stuff like image processors. It also lacks
a hardware IOMMU so you may have performance problems going above about 3.5Gb
of RAM depending on your other hardware.


Sorry for following up on an old thread...

I have a Xeon/EM64T machine with 4G.

FC3-32bit installs without problems, 4G available.

FC3 x86-64 doesn't install, no disks are found.

If I boot FC3 x86-64 installation with mem=3072M,
there are no problems.
I have to add mem=3072M to grub after the installation
to get a running system.
The funny thing is, if I write mem=4096M, it still
boots, but only 3G memory is available.
I can see from /proc/iomem that there are devices
starting at the 3G address, so my guess is that
I've run into the problem described above.
Is there any way to get a x86-64 kernel to use all
4G?

arro8380
21-02-2005, 11:22
Nama nya jg "clone", biasanya masih lebih hebat yg aslinya.
Lagian sih, teknologi 64 bit nya ada yg di sunat, jd kayak 32 bit, max RAM 4 GB
:D

loeqmanito
21-02-2005, 13:57
btw, di windows and linux, cara ngeliat tipe prosesornya gimana ya ?
ada tulisannya EM64T -nya nggak ? :confused:


thx

HiBiKi
21-02-2005, 16:54
btw, di windows and linux, cara ngeliat tipe prosesornya gimana ya ?
ada tulisannya EM64T -nya nggak ? :confused:


thx
pake software aja, misalnya cpu-z, crystalcpuid, dsb...

Magician
22-02-2005, 09:25
Kedetectnya kayaknya bukan EM64T de. Gue nggak tahu yang revisi sekarang, tapi di WinXP 64 kedetectnya sebagai AMD64. Kalo di Linux kedetectnya x86_64.
Terus, processor Intel nggak ketauan yang EM64T apa engga, kecuali dari codenamenya.. Seri 4x1 bisa EM64T, tapi masih disabled. Seri 8xx yang bisa EM64T tapi belom release