[markmat]

So are 64 bit Macs dead? Why did Apple pick a 32 bit chip? Yes the new chips are fast, but you can only have 2 GB of ram with 32 bit chips. Are 64 bit chips going to be back?

[mduell]

I think you meant to post in the iMac forum, since the PowerMacs are still G5 based.

Intel's 32-bit chips support 4GB RAM, so it's actually a step up in terms of RAM capacity from the 64-bit G5 iMacs (which supported 2.5GB RAM).

Apple is expected to switch the PowerMacs to Intel's upcoming 64-bit chips (Conroe and Woodcrest) when they're released in summer or fall.

[Big Mac]

Apple's Intel machines are only 32 bit because the 64 bit desktop chips Intel currently offers are outperformed by the Core Duo, especially in the low power spectrum that Apple requires (and which supposedly prompted the defection to Intel to begin with). The next generation Core chips should have EM64T, although in truth EM64T is a limited 64 bit implementation.

[Lateralus]

Originally Posted by mduell

I think you meant to post in the iMac forum, since the PowerMacs are still G5 based.

Do not report posts because you feel they are misplaced, leave it to us to determine. And please refrain from barking commands like "Move to iMac forum" in your reportings as well.

[tooki]

Now, now. Though I fundamentally agree with your stance, your response is kinda rude.

tooki

[Simon]

Originally Posted by Lateralus

Do not report posts because you feel they are misplaced, leave it to us to determine. And please refrain from barking commands like "Move to iMac forum" in your reportings as well.

Ooooh, sounds like somebody has moderator envy.

[harrisjamieh]

The only product that has moved from 64 bit down to 32 bit is the iMac. The Mac Mini & PowerBook G4s were 32 bit anyway.

[rhashem]

Originally Posted by eggpro

So are 64 bit Macs dead? Why did Apple pick a 32 bit chip? Yes the new chips are fast, but you can only have 2 GB of ram with 32 bit chips. Are 64 bit chips going to be back?

It's an interesting question. There are a number of issues to consider:

1) The Core Duo is a transition chip for a line that desperately needed an update.
2) Mainstream x86 will be 64-bit from here forward. Athlons are already 64-bit chips, while Merom and all of its descendents will be ground-up 64-bit designs.
3) Apple's 64-bit implementation sucked, and will likely take some time to improve.

Ideally, Apple would've just skipped 32-bit x86 and jumped directly to amd64 chips running a fully 64-bit version of OS X. However, it seems that neither OS X nor Intel were ready for such a move. The majority of OS X's userspace is still not 64-bit clean, as evidenced by the fact that even after three years of the G5 the kernel and the majority of libraries are still 32-bit binaries in OS X. Combine this with the fact that Merom won't be out until late this year, and Apple probably figured it was worth it to transition to an intermediate chip.

Of course, point (2) above means that 64-bit Macs will be back, eventually. We'll probably get back up to the hacky OS X on G5 level of support as soon as the new Conroe-based Macs ship in Q3, but it'll probably be a longer wait until we see a version of OS X that is as fully 64-bit as Windows x64 or Linux amd64.

[Catfish_Man]

Basically, in the iMac (which was the only 64->32 transition), the 64 bitness provided about a 0.001% benefit; specifically, a few scientist/math geek types with mathematica could run it in 64 bit mode and work with very large numbers.

I wouldn't call that a huge loss. 64 bit is much more important in the PowerMac where you can actually have >2GB of ram, which is why they won't be using the 32 bit Intel chips in it.

[Hal06]

Well, being honest I don't think users would care that much really… and if they care about 'gimme 64 bits power, gimme it now!' they need a wider view of the whole thing… is not like getting a 64 bits CPU would make suddenly all your computer subsystems freaking fast in no time… they better spend more time creating more friendly OSes & apps, is still irritating how dull are some major OSes & apps nowadays…

It is all about the whole package, the whole experience it provides to you… being the computer 64 bits and apps giving me a good headache… I would drop the thing out of the window in no time.

Never-mind… back to topic, x86 architecture generally sucks when it comes to the number of general purpose registers, and the 64 bit extension to x86 adds a lot more. Because there are more of these registers, fewer things have to be pushed in and out of memory, which is much slower than moving things between registers.

Unfortunately, this gives most PC users the (wrong) belief that 64 bit applications are better/faster. For better designed instruction sets that already had a good number of general purpose registers, there is usually a slowdown.

So, CPUs have two primary busses:

* A data bus: This is used to transfer data - it's width determines the number of bits that can be moved in one clock cycle.
* An address bus: This is used to specify the memory address that data is being transferred - it's width determines the amount of memory the processor can access.

Generally, the width of the data bus and the address bus are the same.

As the processor executes code, it uses these two busses to load instructions from RAM. These instructions include memory addresses.

When a 64 bit processor is running 32 bit code, it will still load 64 bits at a time. This means it can load two addresses from main memory in a cycle.

When a 64 bit processor is running 64 bit code, it will, again, load 64 bits at a time. This means it can load only one address from main memory in a cycle.

Computers only really have two main classes of operation. Reading and writing from memory, and doing calculations. However, processors only have a certain amount of storage (called registers) from which they can perform calculations. Therefore they spend a large amount of their time transferring data to and from between registers and main memory. Each of these transfers requires an address. Every address has to be loaded into the processor from main memory. Therefore, if you can load two addresses into the processor in one cycle, rather than one, it can spend more time doing calculations and memory transfers of useful data.

A fast responsive workstation is about moving massive amounts of data internally; your (and my) multi-ghz systems are still spending the vast amount of time stroking off while waiting for disk reads, memory copies, that sort of stuff.

When you are doing scientific computing, i.e. odds are your problem isn't going to come close to fitting in cache in which case the average PC is going to spend 50% or more of its time waiting for the results of loads from memory.

[Big Mac]

Nice explanation.

[markmat]

thanks for the info everyone. I do hope the rumors are true with Leopard being able to run Windows programs without having to load windows are true.

[tooki]

I don't; unlike emulators or virtual machines or dual-booting, being able to run Win apps natively on Mac OS X really could severely endanger Mac software development. Besides, I don't wanna run Windows apps -- I want Mac apps that behave like Mac apps.

tooki

[Tuoder]

I wonder. Since there are two cores, wouldn't that just mean it can load to addresses at one time? I mean sure, it is 32-bit, but it is 32-bit dual core. I would rather have two CPs running at a somewhat lower effiency than just one higher-effiency one.

[hmurchison2001]

Originally Posted by eggpro

thanks for the info everyone. I do hope the rumors are true with Leopard being able to run Windows programs without having to load windows are true.

This will most definitely not happen. Apple would not be the architect of their own demise.

[Catfish_Man]

Originally Posted by Inside Man

So, CPUs have two primary busses:

* A data bus: This is used to transfer data - it's width determines the number of bits that can be moved in one clock cycle.
* An address bus: This is used to specify the memory address that data is being transferred - it's width determines the amount of memory the processor can access.

Generally, the width of the data bus and the address bus are the same

"Although a CPU may be 64-bit internally, its external data bus or address bus may have a different size, either larger or smaller, and the term is often used to describe the size of these buses as well. For instance, many current machines with 32-bit processors use 64-bit buses (e.g. the original Pentium and later CPUs), and may occasionally be referred to as "64-bit" for this reason." --wikipedia

Note that the original Pentium had a 64 bit data bus, despite most definitely not being able to use 64 bit pointers or ints. Most/all consumer processors after it also did, to the best of my knowledge, although modern processors have 64 bit wide DDR buses.

[rhashem]

Originally Posted by Inside Man

Never-mind… back to topic, x86 architecture generally sucks when it comes to the number of general purpose registers, and the 64 bit extension to x86 adds a lot more. Because there are more of these registers, fewer things have to be pushed in and out of memory, which is much slower than moving things between registers.

These is actually not true. Fewer registers doesn't increase the impact of memory so much as it prevents the compiler from exposing ILP. The speed advantage from moving to more registers doesn't come from "not being able to fit data in registers", but from not having enough registers to allow the compiler to expose as much parallelism as it could.

[QUOTE[Generally, the width of the data bus and the address bus are the same.[/QUOTE]

They haven't been the same for years. The Pentium series has had a 64-bit data bus since the original Pentium came out more then a decade ago. The address bus has been 32-bits for most of that time, and increased to 36-bits with the PPro and 40-bits with the Athlon64.

When a 64 bit processor is running 32 bit code, it will still load 64 bits at a time. This means it can load two addresses from main memory in a cycle.

This is a round-about way of explaining it. Both 32-bit and 64-bit processors can load the number of words per cycle given by the bus bandwidth. On most modern x86 processors, this is 128-bits, either as two seperate 64-bit busses or one 128-bit bus. So the processor can load 128-bits per cycle regardless of how many address bits it has. The performance hit from 64-bit code comes from the fact that pointers become larger, which makes data structures larger and thus less likely to fit in cache.

Every address has to be loaded into the processor from main memory. Therefore, if you can load two addresses into the processor in one cycle, rather than one, it can spend more time doing calculations and memory transfers of useful data.

Addresses are very often computed, not loaded from memory. For example, every global variable in a C program is addressed relative to the instruction pointer, while every stack variable is addressed relative to the stack pointer. As for being able to load 2 addresses at a time, it's almost never useful. Due to the way the bus is designed, if you do a 64-bit load, you're going to get two consecutive data words. Its unusual to encounter a data structure in which if you load a 32-bit pointer from one location, you'll find the 32-bit pointer you get with the same 64-bit load to be also useful. In any case, remember CPUs don't load 64 or 128 bits at a time any way. They do cache fills, which are 64 to 128 bytes at a time.

When you are doing scientific computing, i.e. odds are your problem isn't going to come close to fitting in cache in which case the average PC is going to spend 50% or more of its time waiting for the results of loads from memory.

If your CPU is spending 50% of its time stalled waiting for memory, something is very wrong. In deeply OOO CPUs with large caches, like modern x86 processors, the CPU doesn't stall waiting for memory so much as it only executes a very narrow stream of instructions while waiting for memory loads to resolve. So the CPU is actually doing something most clock cycles, its just that it could be doing more, talking advantage of its many execution units, if memory were faster.

[rhashem]

Originally Posted by Tuoder

I wonder. Since there are two cores, wouldn't that just mean it can load to addresses at one time? I mean sure, it is 32-bit, but it is 32-bit dual core. I would rather have two CPs running at a somewhat lower effiency than just one higher-effiency one.

Yes, two 32-bit loads can happen at the same time, but in different threads of execution. Threads of execution in a dual-core CPU are very independent. Each thread has its "thread state", which consists of its registers and some other data. In a dual-core processor, there are two independent thread states. A thread running on one processor cannot modify the thread state of the thread running on another processor. So yes, the two processors can do two loads at the same time, but that's different from having a processor that can do two loads into the same thread at the same time.

PS) Of course, when working from cache, the Core Duo and the G5 (but not the G4) can do two loads at the same time, even with one CPU.

[production_coordinator]

Also, Conroe will be 64 bit... so it is very likely that we will see the PowerMac go 64 bit -> 64 bit.

[Hal06]

Originally Posted by rhashem

Yes, two 32-bit loads can happen at the same time, but in different threads of execution. Threads of execution in a dual-core CPU are very independent. Each thread has its "thread state", which consists of its registers and some other data. In a dual-core processor, there are two independent thread states. A thread running on one processor cannot modify the thread state of the thread running on another processor. So yes, the two processors can do two loads at the same time, but that's different from having a processor that can do two loads into the same thread at the same time.

PS) Of course, when working from cache, the Core Duo and the G5 (but not the G4) can do two loads at the same time, even with one CPU.

Thanks for your input, so if one is wondering which one is a better choice, I guess the answer relies on the kind of app you are running… since a 64 bit single core CPU can operate larger values in fewer number of cycles, if you are crunching a task that couldn't be run in parallel, even trivially, like some finite element analysis problems or some materials problems, the 64 bits single core CPU would be a better choice, but if multiple calculations can be run in parallel, perhaps a Core Duo system would be OK, wouldn't?

[rhashem]

Originally Posted by Inside Man

Thanks for your input, so if one is wondering which one is a better choice, I guess the answer relies on the kind of app you are running… since a 64 bit single core CPU can operate larger values in fewer number of cycles, if you are crunching a task that couldn't be run in parallel, even trivially, like some finite element analysis problems or some materials problems, the 64 bits single core CPU would be a better choice, but if multiple calculations can be run in parallel, perhaps a Core Duo system would be OK, wouldn't?

It strongly depends on the application. In almost all situations, a 32-bit dual core CPU is preferable to a 64-bit single-core CPU*. Exceptions are:

1) Apps that need more than 4GB of RAM.
2) Apps that operate on large integers.

The cost of hitting disk in an app that has a large working set is bad enough that it'd probably outweigh the advantages of parallelism. Also, 64-bit integer support can make certain algorithms, such as infinite precision integer arithmetic, run several times faster (ie: 64-bit CPUs can do an infinite precision multiply in 1/5 as many operations as a 32-bit CPU).

That said, most scientific problems use floating-point values, not infinite precision integers, and the Core Duo is actually wider for such values (80-bits versus 64-bits). Of course, that doesn't help speed, but rather improves precision. I can imagine some image processing algorithms being faster with 64-bit integers, but in practice those things are going to be limited by memory and cache bandwidth, not the integer units, and you should be using SSE/AltiVec for those things anyway.

*) This argument is, of course, somewhat academic, since by this time next year, you probably won't have any 32-bit Macs -- the Core Duo is the last in its line of 64-bit x86 chips. The Merom/Conroe architecture is 32-bits from the ground up.

[G5man]

The Core Duo is not 64 bit, it is a 32 bit and you are saying that the newer intels are going to stay on 32 bit??? Why?

[mduell]

I believe rhashem transposed 32 and 64 in his final sentence. It should read:
Core Duo is the last in its line of 32-bit x86 chips. The Merom/Conroe architecture is 64-bits from the ground up.

[rhashem]

Originally Posted by mduell

I believe rhashem transposed 32 and 64 in his final sentence. It should read:
Core Duo is the last in its line of 32-bit x86 chips. The Merom/Conroe architecture is 64-bits from the ground up.

Yeah, what he said

[G5man]

Thank you for the clarification. I do not see a problem with no 32 bit macs around, as long as they can use 32 bit apps on 64 bit processors. that's fine. If that is not the case, you got a huge problem.