Sign in with
Sign up | Sign in
Your question

Is the Core 2 Duo a true 64bit chip?

Tags:
Last response: in CPUs
Share
November 29, 2006 6:32:41 PM

Perhaps someone here could point me in the direction of a few articles addressing this question.

AMD has had a true 64 bit CPU for some time. It seems only now MS 64bit OSs are becoming feasible for the gamer / power user.

I see all these reviews, I know the Core 2 supports 64bit instructions, but is it a 64 bit CPU? Did Intel implement some register splitting techniques to boost the 32bit performance? Will the Core 2 maintain a strong position against the AM2 even when running native 64bit code?

I've seen a few 32bit applications not run as smooth on the x64 from AMD. I've heard from others who have installed Vista RC1 64bit that everything becomes smooth and faster. Will the gap between a core 2 and X64 close with the install of a 64bit OS?

Thanks in advance for the help,

Peter.
November 29, 2006 6:50:34 PM

AMD64 Technology = EM64T

Intel addopted AMD's 64-bit extensions.

However, I would like to see Tom's start shifting toward 64-bit benchmarks as it seems quite apparant that 64-bit isn't an option, but rather the future.

Interesting Info: http://en.wikipedia.org/wiki/X86-64
November 29, 2006 7:04:16 PM

Thank you for the link....

Something interesting.. I think. We run a VERY old dos based software package called "beachcam". Interestingly enough, this package will not run on Intel Pentium systems and above. Conversely, it runs on AMD systems up to the AMD64 (haven't tested this one yet).

How is it that both x86 implementations don't work the same? How is it that the "inventor" Intel changed something that broke backward compatablity?

Do you have any links to 64bit benchmarks with these two CPUs?

Peter.
Related resources
November 29, 2006 8:41:42 PM

That's a good question. And I don't have an answer.

Does make sense though, does it?
November 29, 2006 9:02:18 PM

No it is not, more like a hybrid chip

i think there's a chip called Itanium that's true 64bit.
November 29, 2006 9:15:58 PM

For all practical purposes, it is a "true" 64 bit chip, as K8 is.
Sure Itanium is a pure 64 bit chip, in the sense that it can run 32 bit code only through emulation, while C2D and K8 run 32 bit code natively and roughly at the same speed as 64 bit (in 64 bit mode there are a few extensions though, like integer 64 bit arithmetics, and more registers).
Concerning your problems with the old dos program, if i remember correctly Intel started to cut on some legacy features from the Pentium 2 on (actually the Pentium Pro could not run 16 bit code at all), but this has no relevance nowadays.
November 29, 2006 9:37:39 PM

Sorry Pippero but i would have to disagree with you. They are not true 64bit since it was not build as 64bit the primary feature on it. And also i believe in 32bit and 64bit envioroments they perform better in 32. But that is as of this moment with current software.
November 30, 2006 1:06:53 PM

Uhh, then Athlon 64 are not even true 32bit, since they can run 16bit code just fine..
I'd agree with you with the Prescott, since they could run 64 bit code, but with a big performance penalty.
In case of C2D and K8 instead, you even get a performance boost depending on the application (when running 64 bit app on 64 bit OS).
November 30, 2006 2:26:33 PM

Quote:
Is the Core 2 Duo a true 64bit chip?


Yes.
At least as much so as any legacy chip can be.
Both Intel and AMD's offerings support legacy code, {8, 16, 32, 64}bit code can be run on either of their newest processors. However, if you had asked the question, "Is it a pure 64bit chip", then the answer is No.

Quote:
For all practical purposes, it is a "true" 64 bit chip, as K8 is.
Sure Itanium is a pure 64 bit chip, in the sense that it can run 32 bit code only through emulation, while C2D and K8 run 32 bit code natively and roughly at the same speed as 64 bit (in 64 bit mode there are a few extensions though, like integer 64 bit arithmetics, and more registers).
Concerning your problems with the old dos program, if i remember correctly Intel started to cut on some legacy features from the Pentium 2 on (actually the Pentium Pro could not run 16 bit code at all), but this has no relevance nowadays.


What you speak of is emulation of 32bit x86 (IA-32) code on the IA-64 platform (Itanium).

Are you suggesting to me that I cannot run old 16bit code?

[code:1:020df18411]mov ah, bh[/code:1:020df18411]

A very simple (and in its current form, useless) instruction that will execute just fine.

Do you know what Protected Mode Programming is?

Real mode code is still supported.

Xero
November 30, 2006 2:29:15 PM

Quote:
Sorry Pippero but i would have to disagree with you. They are not true 64bit since it was not build as 64bit the primary feature on it. And also i believe in 32bit and 64bit envioroments they perform better in 32. But that is as of this moment with current software.


No x86 Based chip is "True 64bit". But this does not disqualify them as a 64bit chip.

As far as how they perform, I will assume you are a windows user. Enough said.

Xero
November 30, 2006 5:11:40 PM

Then try to run 16 bit code on a Pentium Pro.. :roll:
November 30, 2006 6:27:45 PM

Quote:
Then try to run 16 bit code on a Pentium Pro, Mr. "I am hero".. :roll:


I suspect you have ever run Windows 95 on a Pentium before? Then you have run 16bit code. Same with DOS.

My name is Xero, please be respectful to my name, as I do not show disrespect to yours.

And I would please advise you to understand what you are speaking about. The transition to 32bit code did not stop legacy 16bit code from functioning. Its called "Real Mode", you can still run DOS on the computers today.

Perhaps there is a misunderstanding as to what you are thinking 16bit code is, if so, please explain and perhaps we can help resolve any misunderstandings.

Xero
November 30, 2006 6:49:37 PM

I'm sorry about your name.. i thought it was just a forum name, such as mine and most other people's here.
Concerning 16 bit code, i know all about real mode and protected mode, i had Windows 95 and i remember the days when you had to run a game in DOS/4GW...
And i have to admit that you're right about the Pentium Pro being able to run 16 bit code, i gave that answer just off memory...
Actually i think my misconception stems from the fact that the Pentium Pro (while a killer with 32 bit code) was actually way slower than the Pentium at running 16 bit code, and so nobody used Pentium Pros to run such applications.
Apologies.
November 30, 2006 6:55:21 PM

Quote:
I'm sorry about your name.. i thought it was just a forum name, such as mine and most other people's here.
Concerning 16 bit code, i know all about real mode and protected mode, i had Windows 95 and i remember the days when you had to run a game in DOS/4GW...
And i have to admit that you're right about the Pentium Pro being able to run 16 bit code, i gave that answer just off memory...
Actually i think my misconception stems from the fact that the Pentium Pro (while a killer with 32 bit code) was actually way slower than the Pentium at running 16 bit code, and so nobody used Pentium Pros to run such applications.
Apologies.


Actually, the Pentium Pro did execute 16bit code faster than the Pentium did.

Quote:

Performance with 32-bit code was excellent and well ahead of the older Pentium at the time, by 25-35%; however, the Pentium Pro's 16-bit performance was approximately only 20% faster than a Pentium at running 16-bit code.
---
It should be noted that many people incorrectly believe the Pentium Pro's 16-bit performance was below that of the Pentium.



Also IIRC, certain games were too dependent on DOS to run in the new Windows environment, which is why they had to be emulated later on.

Xero
November 30, 2006 7:00:05 PM

No, wikipedia should never be taken for Gospel.
See here in Ars Technica for example:
(link)
November 30, 2006 7:06:50 PM

See also Tom's HW:
(link)

BTW, the Pentium Pro didn't even support MMX.

Now, concerning issues with modern CPUs and pure DOS, se for example:
(link)
November 30, 2006 7:16:21 PM

Quote:
No, wikipedia should never be taken for Gospel.
See here in Ars Technica for example:
(link)


Perhaps I missed it as I skimmed the text, but I fail to see anything other than conjecture. A quick google search yields nothing conclusive. If you find something let me know, I would be interested in reading it. I will do the same should I come across anything.

Edit: no Wikipedia shouldn't be taken as Gospel. However luckily I am not a man of faith. Unless found otherwise, Wikipedia is typically more accurate than various "he-said she-said" arguments.
November 30, 2006 7:21:30 PM

Quote:
See also Tom's HW:
(link)

BTW, the Pentium Pro didn't even support MMX.

Now, concerning issues with modern CPUs and pure DOS, se for example:
(link)


I am curious why you decided to point out the statement "Pentium Pro didn't even support MMX"? MMX was introduced in 1997, where as the Pentium Pro was introduced in 1995. So of course the Pentium Pro would not support a technology that at the time, did not exist [to the public].

Concerning DOS: It depends on the version as well, recall DOS is very old, and really to be honest, a horribly written operating system. (even for the time). I know early DOS versions required certain execution environments, which when hard coded against causes problems. I have installed later versions of DOS successfully on various Pentiums.

I wonder if Intel would also say Linux is not a validated Operating System for that board..
November 30, 2006 7:40:34 PM

Quote:

Perhaps I missed it as I skimmed the text, but I fail to see anything other than conjecture. A quick google search yields nothing conclusive. If you find something let me know, I would be interested in reading it. I will do the same should I come across anything.

Until now, i only found that test on Tom's, showing a Pentium 225 outperforming a Pentium Pro 233 in Quake, DOS.
It's not easy to find reviews, since it's reaaaaly old history... but i'll keep on searching, i recall clearly reading on magazines (at the time) about the lackluster performance of Pentium Pro in 16 bit, but then again, my memory is far from flawless.
November 30, 2006 7:44:25 PM

Quote:

Perhaps I missed it as I skimmed the text, but I fail to see anything other than conjecture. A quick google search yields nothing conclusive. If you find something let me know, I would be interested in reading it. I will do the same should I come across anything.

Until now, i only found that test on Tom's, showing a Pentium 225 outperforming a Pentium Pro 233 in Quake, DOS.
It's not easy to find reviews, since it's reaaaaly old history... but i'll keep on searching, i recall clearly reading on magazines (at the time) about the lackluster performance of Pentium Pro in 16 bit, but then again, my memory is far from flawless.

No worries, mine is as well. What may not be included here is the execute environment they used to test these chips. Executing 16 bit code while in the 32bit environment may have slowed it down, where as in pure 16bit mode it proved faster.

Who knows.
November 30, 2006 7:47:22 PM

I found this:
At the end of 1995 when the Pentium Pro was introduced, most software was 16bit and even the new version of Windows, Windows95, was 16bit. The performance of the 32bit optimized Pentium Pro at 16bit was slower than that of a Pentium Classic.
(link)
November 30, 2006 7:53:29 PM

Interestingly they claim Windows95 to be 16bit, however Windows95 required protected mode, thus 386. hmm
November 30, 2006 8:05:47 PM

Windows 95 was a hybrid.
It would boot in 16 bit mode, but then it would run mostly in 32 bit, even though the full API and libraries of Win 3.x (16 bit) were supported.
And its DOS prompt, if i remember correctly, was true 16 bit.
Now i remember back then how a 16 bit app could simply hang the OS completely when doing something wrong.. no Task Manager could save you from those crashes, unlike with 32 bit app (obviously, since these run in protected mode and can't corrupt the kernel space).
November 30, 2006 8:08:28 PM

Quote:
Is the Core 2 Duo a true 64bit chip?


No. It's a fake. It's actually just two 32-bit cores jimmied together with duct tape and horse hair, to create a sort-of-64-bit thingummybob.

.
.
.
.
.
.

honestly - ask a stupid question why dontcha?
November 30, 2006 9:29:36 PM

EM64T is true 64 bit with a coupleof caveats. . first it will not run a 32 bit app in 64 bit compatiblity mode instead it defaults to IA32 mode and runs as a 32 bit processor. there fore if you are going to run a 32 bit game in Vsita AMD will run in 64 bit compatiblity mode Intel will not as of the last engineering conmtact I had 5 months ago. This gives you a quick synopsis of EM64T.

"Conclusions

EM64T is targeted to 64-bit operating systems. Period. If you’d like to buy a 64-bit Celeron D or Pentium 4 for when Windows 64 and native 64-bit software reach the market, go ahead. But keep in mind that you won’t be able to use EM64T exclusive features unless you run a 64-bit operating system AND 64-bit software.

"If you have a 64-bit Celeron D or Pentium 4 and Windows 64, 32-bit software will run just fine, however it will run under compatibility mode, meaning they will “see” the CPU as a regular Intel IA32 engine. If you use “heavy” applications and are thinking of moving to 64-bit computing to have more than 4 GB RAM available, keep in mind that you will need new 64-bit version of your software, or they will still access only 4 GB RAM, thus not solving your problem.

"Also keep in mind that the external address bus of EM64T-based CPUs isn’t 64-bit wide, so no Intel CPU using this technology can access 16 EB (exabytes) of RAM (2^64), as you may think. The maximum amount of RAM memory a CPU can access under 64-bit mode depends on its implementation. 64-bit Celeron D, Pentium 4 and Xeon CPUs can access up to 64 GB of RAM while 64-bit Xeon DP can access up to 1 TB of RAM. Once again, keep in mind that under 32-bit mode or 64-bit compatibility mode, the CPU accesses only 4 GB of RAM, even if it is a “64-bit CPU”."
http://www.hardwaresecrets.com/article/262/3 I have caught some static from some of the know nothings over this link. Gabriel is probably the top computer scientist in South America and teaches at the National University of Brazil and is on two IEEE computational csubcomittees. so he is no light weight.

Second there is not full compatiblity between AMD64 and EM64T as far as the compiler goes. Tom Wolfe gave about a1 1/2 hour presentation to IEEE's SC06 two weeks ago in Tampa on this topic.

"The divergence of AMD and Intel x86 implementations has created certain "challenges" for compiler vendors. Application developers would like to deliver a single binary that can execute optimally on both architectures. PGI's solution allows users to create separate versions of code for both chips, but enables them to be built into a single PGI Unified Binary. The Portland Group's Michael Wolfe describes the rationale and implementation of this technology, which he presented in an Exhibitor Forum this week at SCO6.

Wolfe: "The main differences are in the chip implementations, the detailed micro-architectures of the processor cores. For instance, Intel EM64T processors have typically been implemented with deeper instruction pipelines and higher clock rates. This increases the importance of good scheduling by the compiler in order to avoid pipeline stalls and extract maximum performance from the chip. With respect to streaming SIMD extensions (SSE) instructions, Intel EM64T chips use parallel floating point pipelines, which provide higher performance for packed arithmetic but no advantage for scalar code.

"The AMD64 implementation uses separate pipelined floating point units. This allows for faster double-precision scalar performance, but essentially means that AMD64 has the same peak performance for double-precision scalar or packed SSE instructions. There are also a wide variety of cache sizes and configurations, which are significant to how and when a compiler should generate parallel code on a multi-core processor.

"There are also temporal ISA incompatibilities. Intel introduced SSE2 instructions to the Pentium 4, and these were later adopted by AMD as part of AMD64. AMD introduced 64-bit extensions and extended register sets to the x86 architecture with AMD64, and these were eventually adopted by Intel. Intel introduced SSE3 instructions with EM64T, which AMD adopted soon thereafter, and Supplemental SSE3 instructions with Core 2 which create binary incompatibilities between Core 2 processors and current generation AMD64 processors. The PGI Unified Binary allows users to leverage these innovations as they occur, but without generating code that is sub-optimal or simply does not work on competing processors.

"For the compiler, we see five distinct categories. First, as mentioned, some instructions are introduced by one vendor, so there is a time period where the ISA is different. Second, the scheduling rules for instructions differ among the processors; typically, the schedule is more critical for the Intel processors, with its deeper pipeline. Third, instruction selection can also be important. We have cases where there are two or more instructions or instruction sequences to give the same result; due to the micro-architectural differences, different instructions or sequences will be faster for the two vendors. Fourth, the various choices for vectorizing for the packed SSE arithmetic can be very specific to the chip; this includes instruction selection and scheduling, but also involves tradeoffs in the breakpoint between scalar and vector code, whether to optimize for aligned operands, and so on. Lastly and also related to vectorization, cache optimizations can depend on the cache size, which differs between the chips and even between different revisions of the same processor."
http://www.hpcwire.com/hpc/1096734.html

Caveat Microsoft has set Xp64 and Vista to compile using AMD64. That does not mean EM64T will not run , just it will be slower due to differnces between EM64T and the compiler.
a c 96 à CPUs
November 30, 2006 11:59:46 PM

Most of what you talk about being different between EM64T and AMD64 is not actually the ISA but the architectures of the CPUs:

Quote:
Wolfe: "The main differences are in the chip implementations, the detailed micro-architectures of the processor cores. For instance, Intel EM64T processors have typically been implemented with deeper instruction pipelines and higher clock rates. This increases the importance of good scheduling by the compiler in order to avoid pipeline stalls and extract maximum performance from the chip. With respect to streaming SIMD extensions (SSE) instructions, Intel EM64T chips use parallel floating point pipelines, which provide higher performance for packed arithmetic but no advantage for scalar code.

"The AMD64 implementation uses separate pipelined floating point units. This allows for faster double-precision scalar performance, but essentially means that AMD64 has the same peak performance for double-precision scalar or packed SSE instructions. There are also a wide variety of cache sizes and configurations, which are significant to how and when a compiler should generate parallel code on a multi-core processor.


That's hardware differences, not ISA differences. You can run the exact same code on a deeply-pipelined processor like the P4 as you shallow-pipelined one like the Pentium M. That does entail different compiler flags to optimize, but nobody says that you have to do that. And in fact, it's not done all that much to keep compatibility. So most 64-bit code would be just generic x86_64 and not tuned for any specific chip. Yes, there are a few differences between AMD64 and EM64T, such as the 4GB memory limit, which IIRC Intel fixed in the Core 2. There are also differences in memory addressability between CPUs, but again, that's a hardware limit and not a software one. And anyway, that's moot as you'll never be able to physically stuff anywhere close to 64GB RAM in any board that supports a 64-bit P4.

BTW, just for hoots and grins, I wrote up a little program that tries to brute-force find prime numbers in a given range. I compiled it with -march=k8 and then -march=pentium4. The target computer was my old P4-M 2.2 Northwood laptop. The K8 version ran in 22.921 sec and the Pentium 4 version ran in 22.059 sec. There's a little difference in times to run the same code (note that the only flag was -march= ) but it's hardly a binary incompatibility. The binary incompatibility comes in if I tried to run the binary of that program that I'd made on my desktop and compiled in 64-bit mode on the 32-bit chip.
a c 96 à CPUs
December 1, 2006 12:09:16 AM

One thing that is a mantra in teaching is that something generally doesn't sink in with most students until you review it several times.
a c 96 à CPUs
December 1, 2006 12:40:35 AM

I actually have and read the AMD64 Programmer's Manual- well, mainly just the applicable parts (Linux/GCC) and the general overview. I admit that I haven't read Intel's EM64T manual, but I know for a fact that the same 64-bit code that I make on my Athlon 64 desktop runs the same (relatively speaking- an X2 4200+ is a fair bit faster than 2 2.8 Irwindales) on the lab's dual Xeon Irwindale box and that it's the same GCC working on both machines. That's only seat-of-the-pants, but it at least shows that there's decent compatibility between the ISAs.

I think that Ed's 4GB comment was about some earlier EM64T chips being limited to 4GB total between *all* 32-bit processes running on the chip while it's in 64-bit mode. Now I don't know if that's true, but he might have heard it too. I do know that in Athlon 64 and later EM64T chips that each 32-bit process gets its own 4GB address space. But to think that a 32-bit process can get more than 4GB memory addressing space is absurd. It directly violates what "32-bit" means.
!