Welcome to the MacNN Forums.

Eug · Sep 11, 2006, 11:06 AM

Intel's Core Microarchicture has some issues in its 64-bit implementation

Real-world benchmarks

Doesn't really matter to me since I'll probably be running pretty much all 32-bit stuff on my iMac 24" (even with so-called pro apps), but I thought some of you Xserve/Mac Woodcrest pro types might be interested.

OreoCookie · Sep 11, 2006, 11:16 AM

64 bit ≠ faster. As a matter of fact, most of the speed-up going from x86-32 to x86-64 is due to the fact that the number of registers doubles to 16.

Eug · Sep 11, 2006, 11:29 AM

The point here is that while you may (or may not) see performance gains on 64-bit on AMD products (in PCs of course), you can't extrapolate that to Intel CPUs.

In fact, you'll quite often you'll see big slowdowns on Intel hardware if you use 64-bit. That Panorama Factory bench is an example. While there is an 8% speedup with 64-bit on AMD, there is a huge 20% slowdown with 64-bit on Intel.

Big Mac · Sep 11, 2006, 11:36 AM

Won't that be a big problem with M$, which can't seem to get a handle on the 64-bit transition at all?

Eug · Sep 11, 2006, 11:38 AM

Originally Posted by Big Mac

Won't that be a big problem with M$, which can't seem to get a handle on the 64-bit transition at all?

I'm not sure what you're getting at, but this is a CPU design problem, not an OS problem.

harrisjamieh · Sep 11, 2006, 11:40 AM

Originally Posted by Big Mac

Won't that be a big problem with M$, which can't seem to get a handle on the 64-bit transition at all?

That ought to be fun

OreoCookie · Sep 11, 2006, 12:03 PM

I haven't missed the point. If you asked me for an educated guess, I think the slowdown is connected to the slower memory interface of the Intel cpus (not necessarily in terms of bandwidth, but rather access times). AMD has integrated the memory controller on the cpu, so access to main memory is faster. Intel has counteracted this disadvantage of theirs by increasing the caches.

64 bit code takes up more memory space, so more data has to be moved to execute the same commands. That's why the memory interface might be the culprit here.

Altogether, this isn't AMD's first x86-64 cpu, so they also have more expertise than Intel in this field. This is just my guesswork, so don't necessarily quote me on that

Eug · Sep 11, 2006, 12:12 PM

I don't understand the article I linked

but they seem to suggest that memory bandwidth is not the issue here. (The chips tested are Conroe, which have at least reasonable memory bandwidth, but they aren't as fast as Woodcrest.)

Also: Ace's hardware forum post of Goto's article:

- Macro fusion not supported in 64 bit long mode.
- Decoding goes from 1 cycle to 6 cycles (or 11 cycles if a 16 byte boundery
is crossed) when the instruction has an operand size override prefix (66H)
- Rex prefix reduces pre-decoding throughput.

Don't quote me on the accuracy, as it is way above my head.

I'm just the messenger...

OreoCookie · Sep 11, 2006, 01:06 PM

I didn't say bandwidth, but mentioned access time as possible cause (I've added that in parentheses).

P · Sep 11, 2006, 03:13 PM

If you've begun the wild guessing, I might as well add some...

The memory latency (access time) is Core 2's biggest weakness. Intel did not have the time to integrate the memory controller onto the chip, so their quickfix is to increase the cache and add some nifty prefetching routines. My guess is that these prefetching routines are optimized for regular 32-bit code, since that's what they're mainy going to run, and that this is art of the reason.

Macro-ops fusion is indeed not supported in 64-bit mode - I can't judge what kind of perfromance hit that gives - but the other things quoted in that post on Ace's hardware are debatable at best. The rest of the thread makes that rather clear.

Now for the really wild guessing: I think the performance loss is mainly due to the decoding performance. Historically, Intel has made one really smart decoder than can decode all ops and the rest just decode the most common ones. Considering that 64-bit ops are still rather uncommon, I'd imagine that many of these are only supported on the really smart decoder and not on the fast-but-dumb ones. Using more 64-bit ops limits performance to what the smart decoder can keep up with. If that's true, I can't really fault them for doing that - after all, most of the world is running an OS that will never ever use 64-bit ops, so including them on the fast-but-dumb decoders is not really justifiable.

mduell · Sep 11, 2006, 07:52 PM

What compiler was used for Panorama and sakura? gcc, icc, or something else?

Eug · Sep 11, 2006, 09:34 PM

Originally Posted by mduell

What compiler was used for Panorama and sakura? gcc, icc, or something else?

No idea.

In other news, Core 2 Quad-core has been tested.

kamina · Sep 12, 2006, 01:39 AM

Actually this is not Intels first processor with 64bit extensions either, it's just the first Mobile cpu. The first processors supporting the same extensions where P4's, and most of them (anything with EMT) supports the same extensions.

My first idea here was the compiler too. It could be that Intel will have the same problems under Leopard, but it could also be that there will be a performance boost.

OreoCookie · Sep 12, 2006, 02:36 AM

I know, but the first Pentium M-based cpu (I don't count Woodcrest separately, they are based on the same design).

mduell · Sep 12, 2006, 05:49 PM

Originally Posted by Eug

In other news, Core 2 Quad-core has been tested.

In better news, Clovertown (quad-in-a-socket) engineering samples have been confirmed to work in the Mac Pro.

Bring on the octo (octa?) Mac.

chefpastry · Sep 12, 2006, 08:03 PM

Originally Posted by mduell

In better news, Clovertown (quad-in-a-socket) engineering samples have been confirmed to work in the Mac Pro.

Bring on the octo (octa?) Mac.

AWESOME! Thanks for the great news! Now I've got to start saving for Clovertowns...