From: Joe Bob Spamtest <joebob@spamtest.viacore.net>
To: Fawad Lateef <fawadlateef@gmail.com>
Cc: Alejandro Bonilla <abonilla@linuxwireless.org>,
Marcel Holtmann <marcel@holtmann.org>,
linux-kernel@vger.kernel.org
Subject: Re: 4GB memory and Intel Dual-Core system
Date: Fri, 28 Oct 2005 08:56:04 -0700 [thread overview]
Message-ID: <43624A14.20802@spamtest.viacore.net> (raw)
In-Reply-To: <1e62d1370510271935o51d88c0bk7baa23ca1a75bc4d@mail.gmail.com>
Fawad Lateef wrote:
> Can you tell me the main differences between IA64 and x86_64 (Opteron)
> ? because in your one of the previous mail you said IA64 != EM64T and
> its true, but I know is EM64T/AMD64 in 64-bit mode != IA32 but you
> said that too EM64T is not really 64-bit, its a IA32 .. Can you give
> me some link which just tells the difference between IA64 (Itanium)
> and AMD64 (Opteron) ?
IA64 (Itanium [Itanic, really -- the architecture IMO is a real
disappointment IRL for something which on paper looked very impressive])
is a true 64 bit CPU. It's a new architecture built from scratch -- as
different from IA32 as SPARC is. IA64 has a "compatibility mode" which
allows it to run IA32 code natively, albeit very, very slow. Make no
mistake -- IA64 is a completely different CPU type and architecture from
IA32.
x86_64 (both AMD64 and Intel's EM64T offerings) are 64-bit extensions to
a 32 bit microprocessor. The system architecture stayed basically the
same. This is different from IA32 in the same ways PPC64 is different
from PPC32 and SPARC64 is different from SPARC32. Both CPUs use the same
set of commands as their predecessors, with the inclusion of several
more instructions and registers (as well as the registers being of
greater width).
The differences between AMD64 and EM64T are significant as well; however
from a programming standpoint the differences are almost negligible. THe
biggest difference (which may have impact on programming principles) is
AMD64 is a NUMA architecture whereas EM64T still uses the same memory
model and architecture as the IA32. Quite simply, you gain more from
AMD64 than you do from EM64T, in my opinion.
Both (really, all three) architectures have their plusses and minuses.
EM64T is Intel's idea of playing catch-up with the competition (AMD), IMO.
> With the Itanium, Intel proposes to examine
> programs when they are compiled into their executable form and encode
> concurrent operations ahead of time. Intel calls this approach EPIC,
> for Explicitly Parallel Instruction Computing, and it is the genuine
> difference between the Itanium and AMD's x86-64. EPIC's drawback is
This is so blatantly simplified it's outright wrong.
EPIC is a very clever, revolutionary design. When I first read the
Itanium whitepapers some years ago, it seemed like this technology was
definitely worth taking a look at. Apparently I wasn't the only one who
thought this: HP dropped PA-RISC for Itanium, SGI dropped MIPS, Compaq
(at the time its own entity) dropped Alpha... Everyone, it seems, jumped
on the bandwagon with the exception of Sun, who elected to wait for
AMD's offering. Turns out though, what looked good on paper turned out
to be quite a disappointment. The original Itanium, at its release, was
very disappointing in terms of performance. At the time, the 32-bit
Pentium III Tualatin could perform the same calculations as Itanium in
less time -- for a fraction of the cost. And the 32-bit codepath
compatibility? It was a joke -- some compared it to a sluggish
Pentium-II 266. HP took the Itanium specification from Intel, used its
expertise from years with PA-RISC, and redesigned Itanium, to later
release Itanium II. This offered a great performance increase over the
previous release, but the 32-bit codepath is still abysmally slow. Even
the new, improved EPIC still lacks; thus far nobody's compiler -- not
even Intel's -- can take full advantage or make full use of the features
in this CPU. Many high-performance applications are still hand-tuned in
IA64 assembler to take advantage of its offerings.
Hope this helped to clear some things up.
Cheers,
-Kelsey
next prev parent reply other threads:[~2005-10-28 15:59 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-27 20:33 4GB memory and Intel Dual-Core system Marcel Holtmann
2005-10-27 20:44 ` Roland Dreier
2005-10-27 20:51 ` Marcel Holtmann
2005-10-27 20:54 ` Roland Dreier
2005-10-27 21:00 ` Marcel Holtmann
2005-10-27 21:06 ` Roland Dreier
2005-10-27 21:08 ` Marcel Holtmann
2005-10-27 21:10 ` Alejandro Bonilla
2005-10-27 20:57 ` Alejandro Bonilla
2005-10-27 20:54 ` Alejandro Bonilla
2005-10-27 20:57 ` Marcel Holtmann
2005-10-27 21:02 ` Alejandro Bonilla
2005-10-27 21:07 ` Marcel Holtmann
2005-10-27 21:15 ` Alejandro Bonilla
2005-10-27 21:19 ` Marcel Holtmann
2005-10-27 22:26 ` Joe Bob Spamtest
2005-10-27 22:05 ` Dave Jones
2005-10-27 22:09 ` Vladimir Lazarenko
2005-11-02 16:21 ` Lennart Sorensen
2005-10-27 22:11 ` Marcel Holtmann
2005-10-27 22:12 ` Dave Jones
2005-10-27 22:17 ` Marcel Holtmann
2005-10-27 22:20 ` Alejandro Bonilla
2005-10-28 0:33 ` Bernd Eckenfels
2005-10-30 22:26 ` Alan Cox
2005-10-31 3:39 ` Alejandro Bonilla Beeche
2005-10-31 13:02 ` Alan Cox
2005-10-31 23:03 ` Martin J. Bligh
2005-11-01 5:03 ` thockin
2005-10-27 22:29 ` Joel Jaeggli
2005-10-27 22:13 ` Alejandro Bonilla
2005-10-27 22:18 ` Marcel Holtmann
2005-10-28 2:35 ` Fawad Lateef
2005-10-28 3:09 ` Joel Jaeggli
2005-10-28 7:19 ` Fawad Lateef
2005-10-28 15:56 ` Joe Bob Spamtest [this message]
2005-10-28 15:29 ` Eric W. Biederman
2005-10-28 15:45 ` Alejandro Bonilla
2005-10-28 16:09 ` Eric W. Biederman
2005-10-30 22:24 ` Alan Cox
2005-11-02 16:20 ` Lennart Sorensen
2005-10-27 22:12 ` Andi Kleen
2005-10-27 21:09 ` linux-os (Dick Johnson)
2005-10-27 21:32 ` Bernd Eckenfels
-- strict thread matches above, loose matches on Subject: below --
2005-10-28 20:58 Lukas Hejtmanek
2005-10-29 3:32 ` Dave Jones
2005-10-29 11:15 ` Marcel Holtmann
2005-10-30 6:49 ` Dave Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43624A14.20802@spamtest.viacore.net \
--to=joebob@spamtest.viacore.net \
--cc=abonilla@linuxwireless.org \
--cc=fawadlateef@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox