Announcement

Announcement Module
Collapse
No announcement yet.

A64 vs P4 udah biasa.. EM64T vs AMD64?

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • A64 vs P4 udah biasa.. EM64T vs AMD64?

    Intel masih seperti biasa, nggak kapok. Kenceng di synthetic.



    Tapi buat realworld?

    Hueuehehe.. yang ini aneh.. 64 bitnya lebih pelan dari 32 bit di Intel.. Mungkin karena dia pake data lebih gede..




    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.


    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/e...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.../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/fedo.../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?

  • #2
    Re: A64 vs P4 udah biasa.. EM64T vs AMD64?

    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

    Comment


    • #3
      Re: A64 vs P4 udah biasa.. EM64T vs AMD64?

      btw, di windows and linux, cara ngeliat tipe prosesornya gimana ya ?
      ada tulisannya EM64T -nya nggak ?


      thx

      Comment


      • #4
        Re: A64 vs P4 udah biasa.. EM64T vs AMD64?

        Originally posted by loeqmanito
        btw, di windows and linux, cara ngeliat tipe prosesornya gimana ya ?
        ada tulisannya EM64T -nya nggak ?


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

        Comment


        • #5
          Re: A64 vs P4 udah biasa.. EM64T vs AMD64?

          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

          Comment

          Working...
          X