Next year's 10.6 reference release of Mac OS X promises to deliver technology updates throughout the system without focusing on the customer-facing marketing features that typically sell a new operating system. Here's a look at what those behind-the-scenes enhancements will mean to you, starting with new 64-bit support.

The move toward 64-bit computing is often generalized behind the assumption that "more bits must be better," but that's not always true. In some cases, expanding support for more bits of memory addressing only results in requiring more RAM and computing overhead to do the same thing. However, Apple's progressive expansion of 64-bit support in Snow Leopard will bring performance enhancements across the board for users of new 64-bit Intel Macs. Here's a look at why, along with how it is that every version of Mac OS X since Tiger has advertised "64-bit support" as a key feature.

Follow up segments take a more detailed look at the issues related to the amount of RAM that can be installed and actually used by the system, how much memory a specific app can reserve for itself, how the OS gets faster with 64-bit addressing despite the additional overhead involved, how the market for 64-bit apps is unfolding, and how Apple is pioneering 64-bits on the desktop.

Through the 1980s, personal computers rapidly moved from 8-bit to 16-bit to 32-bit architectures, with each advance enabling the operating system and its applications to address more memory and more efficiently handle the memory available to them. The 8-bit computers of the early 80s could only directly address 64K, the upper limit of their 16-bit memory addressing; early Apple II systems switched between two banks providing 128K. DOS 8086 PCs with 20-bit addressing could handle a whopping 1MB of RAM, but overhead effectively limited them to using 640K of it. These early machines also highlight the fact that a CPU's architecture, memory address bus, and its data registers (used to load and store instructions) may all have different bit widths.

Similarly, the 1984 Macintosh jumped to using a 32-bit 68000 processor with 24-bit addressing, allowing the theoretical use of "only" 16MB, although at the time that was far more RAM than anyone could afford. That seemingly high limit eventually became a problem for memory hungry applications, particularly with the increased demands required by graphical computing and multitasking.

By the end of the 80s, Apple had delivered full 32-bit hardware with the Mac II's 68020 processor and the "32-bit clean" Mac System 7 software, which together enabled applications and the system to theoretically use as much as 4GB of directly addressable memory. By 1995, Microsoft was shipping its own 32-bit Windows API with WinNT and Win95 to take advantage of Intel's 32-bit 80386 and 486 CPUs.

More bits here and there

A decade later, the 4GB limit of 32-bit memory addressing would begin to pinch even home computers. To accommodate that inevitability, Apple began its migration to PowerPC in 1994 to make progress toward 64-bit computing and break from the limitations of the Motorola 680x0 processors it had been using. PowerPC offered a scaled down version of IBM's modern 64-bit POWER architecture, with 32 individual 32-bit general purpose registers; Intel's 32-bit x86 was a scaled up version of a 16-bit processor, and only offered 8, 32-bit GPRs. The lack of registers on x86 served as a significant constraint on potential performance and complicated development.

In order to attack the RAM limitation problem in advance of moving to 64-bit CPUs, Intel added support for "Physical Address Extension" or PAE to its 32-bit x86 chips, which provided a form of 36-bit memory addressing, raising the RAM limit from 4GB to 64GB. Using PAE, each application can still only address 4GB, but an operating system can map each app's limited allocation to the physical RAM installed in the computer.

Being able to use more than 4GB of RAM on a 32-bit PC requires support for PAE in the OS kernel. Microsoft has only supported this extra RAM in its Enterprise, Datacenter, and 64-bit versions of Windows; the standard 32-bit versions of Windows XP, Vista, and Windows Server are all still constrained to using 4GB of physical RAM, and they can't provide full access to more than about 3.5GB of it, making the limit an increasingly serious problem for desktop Windows PC users.

In the late 90s, Windows NT was ported to 64-bit architectures such as Digital's Alpha, MIPS, PowerPC, and Intel's ill-fated Itanium, but this also only benefitted high-end workstation users. Apple's own mid-90s PowerPC transition prepared the Mac platform for an easier transition to 64-bit computing, but it wasn't until 2003 that the PowerMac G5 introduced real 64-bit hardware. The G5 processor delivered 32 individual 64-bit GPRs and a 42-bit MMU (memory management unit) for directly addressing 4TB of RAM, although the PowerMac G5 hardware was limited to 8GB.

The mainstream PC remained stuck at 32-bit conventions until AMD released its 2003 Opteron CPU using an "AMD64" architecture that turned out to be a more practical alternative to upgrading into the world of 64-bits than Intel's entirely new Itanium IA-64 design. The new 64-bit PC, also called x86-64 and x64, largely caught up to PowerPC by suppling 16, 64-bit GPRs, and potentially a 64-bit memory bus to address 16EB (16 million TB) of RAM. AMD's x64 processors can theoretically address 48-bits, or 256TB, in hardware. In practice, no PC operating system currently supports more than 44-bits, or 16TB of virtual memory, and of course considerably less physical RAM.

On page 2 of 3: The challenge of moving to 64-bits; Windows and 64-Bits; and One step back two steps forward.

The challenge of moving to 64-bits

There's currently no immediate need for such vast amounts of RAM among home users, but consumers are running into the 4GB barrier of 32-bit PCs, while facing additional problems that prevent mass migration to x64. The main problem is that the potential of the hardware has to be exposed by operating system software. There are two problems: the first is simply addressing more than 4GB of total RAM for the entire system, and the second is allowing RAM-hungry applications to individually access large amounts of RAM.

Even with the 64-bit Power Mac G5 hardware, there were still software limitations in 2003's Mac OS X Panther; the 32-bit OS allowed the system to support more than 4GB of memory but still corralled each application into its own 32-bit, 4GB space. With 2005's Mac OS X Tiger, Apple enabled desktop apps to spin off processes and servers that could handle enormous memory addressing of their own: up to a theoretical 16 EB of 64-bit virtual memory and a conceptual 42-bits or 4TB of physical RAM, although shipping Macs still could only support 8GB of RAM.

To enable this, Tiger supplied a 64-bit version of libsystem, the system library handling most of its Unix APIs. This followed the LP64 model to allow broad compatibility with 64-bit versions of Linux and commercial Unix. It also delivered a 64-bit PowerPC ABI (application binary interface) for accommodating native 64-bit apps on the G5. Tiger still used a 32-bit kernel (although it was not limited to 32-bit memory addressing, so it could actually make use of the 8GB of RAM installed in G5s), and it was also still missing a 64-bit version of the Cocoa or Carbon APIs, which meant apps with a user interface had to be 32-bit.

However, a 32-bit graphical app on Tiger could spin off a faceless 64-bit background process to perform number crunching on a vast data set requiring a 64-bit memory space, which could then communicate the results back to the 32-bit foreground app running in parallel. Apple also delivered a mechanism for deploying applications using a bundle of both 64-bit and 32-bit code, allowing the system to automatically run the appropriate version for the Mac hardware in use. Tiger itself also supplied both 32- and 64-bit underpinnings, allowing one OS to run on any Mac. This has made it easier for Apple to rapidly migrate Mac users toward 64-bit hardware.

Windows and 64-Bits

In contrast, a separate 64-bit version of Windows is required to run 64-bit Windows apps on 64-bit x86 PCs, and any 32-bit apps have to run in a special compatibility environment (below). There is no slick mechanism for deploying bundles of mixed code that "just work" on both architectures, and 64-bit Windows itself lacks the ability to run on either type of PC. This has had a chilling effect on the popularity of and the momentum behind 64-bit Windows that parallels the problems with Vista.

This is particularly unfortunate because the advances delivered in the x64 PC are more desperately needed by PC users to gain the same benefits that Mac users and developers gained from the move to PowerPC over a decade earlier. The 32-bit PC is particularly hampered by a lack of GPRs and the 4GB RAM limit imposed by the desktop versions of 32-bit Windows. In addition, 32-bit Windows itself eats into that 4GB to only leave 3.5GB of RAM or less for apps and the system to use, and typically limits individual apps to a tiny 2GB address space.

Software compatibility, a lack of drivers, and other problems have also complicated the move to 64-bit Windows, leaving mainstream Windows users stuck at 32-bits. Windows 7 was initially supposed to move users to 64-bits in perhaps 2010, but reports indicate that it too will be delivered in separate 32- and 64-bit versions.

One step back two steps forward

When Apple began migrating to Intel in 2006 it actually had to take a step backward, as it only initially supported 32-bit Intel systems with the Core Solo and Core Duo CPUs. Apple had to cope with the same 32-bit PC limitations Microsoft had been dealing with. in the Intel transition, Mac developers lost the features supplied by PowerPC, including its liberal supply of registers. However, Intel's new 32-bit Core Duo was fast enough in other areas to skirt around the problem, particularly in laptops where the aging G4 was holding Macs back.

By the end of the year Apple had widened support to include the 64-bit x64 PC architecture in the new Mac Pro and Xserve, and subsequent desktop Macs using the Core 2 Duo also delivered 64-bit hardware support. With updates to Tiger, Apple delivered the same level of 64-bit support for x64 Intel processors as it had for the PowerPC G5.

Within the course of one year, Apple had not only adroitly moved its entire Mac product line to Intel but also paved the way forward to rapidly push its users to 64-bits, narrowly escaping the disaster of being left the last member of the desktop PowerPC party. In its spare time, the company also threw the iPhone together while also working to develop its next jump in 64-bit operating system software.

On page 3 of 3: The 64-bit GUI in Leopard and The 64-bit Kernel in Snow Leopard.

The 64-bit GUI in Leopard

In Leopard, Apple expanded 64-bit support further, adding 64-bit support in the higher levels of Carbon and Cocoa. Apple delivered its own Xcode app in Leopard with support for both PowerPC and Intel in both 32-bit and 64-bit versions, all within the same application bundle. The entire OS is now a Universal Binary as well; it automatically runs on whatever hardware it is installed on. Incidentally, one of the biggest issues in getting Mac OS X to run on generic PC hardware is the need to turn off PAE in the kernel for older CPUs that don't support it.

While all of Cocoa is now 64-bit, Apple chose not to deliver full 64-bit support in Carbon's user interface APIs (including legacy parts of QuickTime), forcing developers to migrate their apps to use the modern equivalents in Cocoa in order to deliver full 64-bit applications with a user interface. Carbon can still be used to build faceless 64-bit background apps that interact with a 64-bit Cocoa front end, similar to how Tiger supported 64-bit background apps. Earlier, Apple had added transitional support for mixing Cocoa into Carbon apps to make this move easier.

Apple's decision to withhold the development of 64-bit Carbon caused Adobe to announce this spring that its upcoming Creative Suite 4 would only be delivered as a 64-bit app on Windows. Because CS4's legacy code is based on Carbon, Adobe said it wouldn't be able to deliver a 64-bit version of its Mac apps until at least CS5, because it will require porting the interface code of Photoshop and its companion apps to Cocoa in the model of Photoshop Lightroom. Most desktop apps don't necessarily demand 64-bit support, but Photoshop's use of extremely large image files makes it a good candidate for porting.

Currently, Mac OS X Leopard hosts both 32-bit and 64-bit apps on top of a 32-bit kernel (below). Using PAE, the 32-bit kernel can address 32GB of RAM in the Mac Pro and Xserve; Apple's consumer machines only support 4GB RAM, but unlike 32-bit operating systems they can use the entire 4GB (with appropriate hardware support). Leopard's 32-bit kernel enabled Apple to ship 64-bit development tools to give coders the ability to build applications that can work with huge data sets in a 64-bit virtual memory space (and port over existing 64-bit code), without also requiring an immediate upgrade to all of Mac OS X's drivers and other kernel-level extensions. That transition will happen with Snow Leopard.

How big of a deal is the move to 64-bit apps? As Apple's developer documentation points out, "To put the difference between 32-bit and 64-bit computing into perspective, imagine that you are working with a dataset in which the road area of the Golden Gate bridge can be represented in a 32-bit address space. With 64 bits of address space, you have the ability to model the entire surface of the Earth at the same resolution."

The 64-bit Kernel in Snow Leopard

Apple is expanding its 64-bit support in Snow Leopard down into the kernel. This will enable Mac systems to accommodate more than the 32GB of RAM currently available via 32-bit PAE. With kernel support for full 64-bit memory addressing, Apple can add as much RAM as users can afford. Of course, if you're buying RAM from Apple, upgrading a Mac Pro to 32GB of RAM currently costs $9,100, so it might be some time before home users decide they need more than that much RAM.

While Leopard's 32-bit kernel can run both 32- and 64-bit apps, a 64-bit app can not load 32-bit plugins or shared libraries, and vice versa. The 64-bit kernel similarly requires 64-bit kernel extensions and drivers, as it can't mix 32- and 64-bit code either. The move to a 64-bit kernel will therefore require an across-the-board upgrade for all kernel drivers in Snow Leopard.

Snow Leopard will also require developers who write any plugins for Mac OS X apps to recompile their code to 64-bit. This includes everything from System Preferences panes to web plugins. The reason for the massive upgrade will be that Apple will also deliver the entire system compiled as both 32- and 64-bit, from the Finder to iTunes to Safari. On 32-bit Macs, Snow Leopard will run normally, but on x64 Macs, everything will get a significant boost as every app on the system will benefit from the advantages of x64, particularly the extra registers supplied by x64 and missing from the 32-bit PC.

That advantage will outweigh the additional overhead caused by moving to 64-bits and the resulting use of larger data items. In contrast, there would be no real advantage in recompiling Snow Leopard and its apps for 64-bit PowerPC G5s, as the G5 is not currently constrained by the register problem of 32-bit x86; the 64-bit G5 has the same number of registers as the G4, because the G4 already had plenty. The G5 actually runs 64-bit apps slightly slower because of the increased overhead imposed by 64-bit addressing. For that reason, Snow Leopard will apparently be Intel-only.

He's a quick summary for people who can't be bothered reading the long and boring article: It doesn't matter for most people.

People who care are: those who want photoshop to use more than 4GB of memory (keep waiting guys, should be here in a couple of years) and people who run memory hungry server applications.

It's a technicality that makes little impact on most things right now, especially desktop users.

I think your comment is a wee bit silly. The same sort of short sighted and limited view could have been taken at any one of the various mile stones in Apple's history. To single out one motivating fact and saying it is all that matters is myopic to say the least. There will be a myriad of users who will find this latest progress beneficial, of that I am certain.

From Apple ][ - to new Mac Pro I've owned them all.Long on AAPL so biased"Google doesn't sell you anything, Google just sells you!"

He's a quick summary for people who can't be bothered reading the long and boring article: It doesn't matter for most people.

People who care are: those who want photoshop to use more than 4GB of memory (keep waiting guys, should be here in a couple of years) and people who run memory hungry server applications.

It's a technicality that makes little impact on most things right now, especially desktop users.

Now I see why Apple is trying to pull all drivers in-house for everything from printers to other peripherals... it would be a serious pain to have to go find the corporate web site of every single device that's attached to my computer and download the 10.6 driver (assuming the company will provide one).

And no 64-bit Photoshop is probably going to mean a couple years of very sluggish Mac Pro sales and a stalling of some of Apple's corporate gains.

I agree. I wanted to read about Snow Leopard and it was relegated to practically the last paragraph on the last page.

Quote:

Originally Posted by digitalclips

I think your comment is a wee bit silly. The same sort of short sighted and limited view could have been taken at any one of the various mile stones in Apple's history. To single out one motivating fact and saying it is all that matters is myopic to say the least. There will be a myriad of users who will find this latest progress beneficial, of that I am certain.

That advantage will outweigh the additional overhead caused by moving to 64-bits and the resulting use of larger data items. In contrast, there would be no real advantage in recompiling Snow Leopard and its apps for 64-bit PowerPC G5s, as the G5 is not currently constrained by the register problem of 32-bit x86; the 64-bit G5 has the same number of registers as the G4, because the G4 already had plenty. The G5 actually runs 64-bit apps slightly slower because of the increased overhead imposed by 64-bit addressing. For that reason, Snow Leopard will apparently be Intel-only.

The most important contributor to the speed of Snow Leopard is barely mentioned!

Most apps don't need more than the ~3 GB addressable memory that's available with the ancient X86 architecture. In fact, on most microarchitectures (e.g., Alpha, UltraSPARC, G5), apps typically run slower if compiled for 64-bits, because some data elements become twice the size (64-bit instead of 32-bit).

The speed of Snow Leopard will come from moving apps and the OS to the X64 instruction set, which provides for twice as many GPRs. Nearly every application will benefit from more GPRs--and benefit more than the speed hit that's incurred by using larger data elements. Other, more modern microarchitectures don't provide more GPRs just because an app is compiled for 64-bits. This is only a feature of the ancient X86.

Amazingly, very few apps for Mac OS X are 64-bit. Chess is one of them, presumably because it uses a lot of CPU relative to what's needed to drive the UI. Perhaps someone here knows whether the GUI part of Mac OS X, 64-bit Cocoa, under Leopard 10.5 is for some reason slower than the 32-bit version and that's why we don't see more 64-bit GUI apps yet? Or is it just because building, testing, bundling and distributing yet another binary isn't worth it to the software manufacturers?

(By the way, later PowerMacs could address 16 GB of physical memory, not just 8 GB.)

I think your comment is a wee bit silly. The same sort of short sighted and limited view could have been taken at any one of the various mile stones in Apple's history. To single out one motivating fact and saying it is all that matters is myopic to say the least. There will be a myriad of users who will find this latest progress beneficial, of that I am certain.

Ah, where did I say it's not important for people? We obviously need to go to 64 bits at some point. Now is a good time and overdue for servers. It's just that it's a meaningless technicality right now for almost everyone, although I should have added there is an effect that people may notice - 64 bit programs will take up more memory, as in for the same document or the same work performed.

Can you actually list those people/applications where it will have an impact now?

Now I see why Apple is trying to pull all drivers in-house for everything from printers to other peripherals... it would be a serious pain to have to go find the corporate web site of every single device that's attached to my computer and download the 10.6 driver (assuming the company will provide one).

And no 64-bit Photoshop is probably going to mean a couple years of very sluggish Mac Pro sales and a stalling of some of Apple's corporate gains.

As it happens that's all Apple's fault. First they say that we'll have 64 bit Carbon, so Adobe head of in that direction, then they say no 64 bit Carbon for you! Adobe is caught half way down the former track and needs to restart development.

I guess 64 bit PS means a lot if you've just dropped 64GB of memory in your MacPro and you actually want to use it (and you mostly use PS) but surely most people will not notice the performance penalty. Those graphic artists aren't that techie surely.

I'd like to point out that having 64bit addressing is not so much about being able to assign more RAM memory to an app but the app (and the OS' resources it uses) being able to address more than 4 GB of memory AT ALL, be it RAM or Virtual Memory-based. Even if one has less RAM memory than what the dataset one wants to manage requires, at the very least the app can do it via the Hard Disk. Also, there are situations in which it's not about holding all the data in memory at once but being able to understand that data as a continuous thing instead of a series of chunks one has to swap, no matter how big or small the piece of data to manipulate actually is.

This is mostly about making the programmer's life easier and so the apps' capabilities better. 64bit allows more creative ways to map data around without having to segment things in uncomfortable and complicated ways. For example, a database app could map in a single address space a database spanning sets of entire datacenters. There are OSes in which everything: memory, storage, etc. is mapped as a single large address space. Etc.

A very informative article. Can someone please explain what really changed from a practical standpoint in the move from Core Duo to Core 2 Duo which allegedly has 64 bit support?

What do you mean "allegedly"?

Quote:

Secondly, would Apple be further along this path today if they went with AMD's architecture or is that inconsequential?

Inconsequential. While pushing Itanium, Intel maintained a skunk works project that ostensibly was cloning AMD64. Intel's version, which is called EM64_T, is nearly identical to AMD64. Generically you can call them X64.

I'd like to point out that having 64bit addressing is not so much about being able to assign more RAM memory to an app but the app (and the OS' resources it uses) being able to address more than 4 GB of memory AT ALL...

And for most apps, which don't need 64-bit addressing and don't benefit from using larger 64-bit data elements, it's all about the additional GPRs available with X64 compared to the ancient X86 architecture.

I don't understand why you should include a "Typical RAM Limit" column in your table as that really makes no sense at all. Any physical constraints below the theoretical maximum are set by the hardware vendors, and they scale up across their range of platforms: increasing with cost.

Your Itanium figure is especially misleading, as the biggest Itanium system vendor (HP) have Itanum systems (Superdome) that can take up to 2TB of memory. Even the smallest Itanium system they sell (rx2660) has a max memory of 32GB. And a single width Itanium blade (BL860c) can fit 48GB of ram, with the double width (BL870c) maxing out at 96GB.

Personally I think that Apple are playing this right with 10.6. Maintaining close end user feature parity with 10.5 should hopefully slow down initial adoption of 10.6, which will be a good thing. I've been through 32bit -> 64bit OS transitions before, and lots of things can break on the way. Applications do not always make the transition unscathed just through a simple re-compile. Sloppy code that is not 64bit clean can often require quite a bit of work to find and iron out the bugs; so I would expect 10.6 to be a bit lean on functional apps to start with. I would also be very cautious about running any production systems on 10.6 when it first hits the shelves. Better to wait several months for a few bug fix releases before throwing the switch. Even then, test, test and test again before doing so.

Personally I'll wait until I know for sure that every one of my apps, printer drivers, etc are already at versions that have been certified for 10.6 before upgrading Mac OS X.

Can someone please explain what really changed from a practical standpoint in the move from Core Duo to Core 2 Duo which allegedly has 64 bit support?

Both were dual-core, but the 32-bit to 64-bit was the main change. There are some other alterations you can read about at the links below, but the ability to address more RAM was the biggest one, even though it was really only a 3GB to 4GB increase in these notebooks . However, the first C2D chips still had a 32bit controller so they still couldn't address more than 3.3GB of RAM, of which Mac OS X would only address 3GB.

Secondly, would Apple be further along this path today if they went with AMD's architecture or is that inconsequential?

On the mobile side of things, not even close. Since Apple has about 50% of the retail notebook market in the US and also uses mobile chips in their iMac and Mac MIni lines the only benefit would have been in the Mac Pro or Xserve, and even the desktop performance side is debatable.

PS: The new Montebvina desktop chipsets from Intel could allow Apple to start using faster and cheaper desktop chips while reducing heat output, instead of chips designed for mobile applications. But will they go that route or try to make the iMac even slimmer and smaller?

Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"

As it happens that's all Apple's fault. First they say that we'll have 64 bit Carbon, so Adobe head of in that direction, then they say no 64 bit Carbon for you! Adobe is caught half way down the former track and needs to restart development.

I guess 64 bit PS means a lot if you've just dropped 64GB of memory in your MacPro and you actually want to use it (and you mostly use PS) but surely most people will not notice the performance penalty. Those graphic artists aren't that techie surely.

Ironically, Apple has recently released 64bit Vista drivers for the Mac Pro, so Photoshop users who want to take advantage of 64bit Photoshop with CS4 and 4GB+ of RAM they can do so by using Windows in boot camp. So whilst this article argues the superior technical implementation of 64bit in OS X, the end user will see the exactly the opposite, Photoshop 64bit runs on Windows but not OS X. The fact that this is a result of Apple's own decision, is embarrassing for Apple.

2) Why are you here? (Curious, not judging as I do the same. Took a cruise last year and spent $400 on internet fees. I just get bored not researching something)

3) You can always disable images or use a text-based browser like Lynx (requires 10.5.1 or higher).

Hi solipsism

LOL, $400!! U R nuts too

Here as wife was off riding a horse. I will not do that until they have brakes. We are at our Lincoln, New Hampshire hideaway in the mountains. iPhone does work (Mk 1 too) we only have to hang off the balcony by the ankles to get a signal.

Re Ads; It's not the in page stuff, but a literal pop up that appears (it can take a while to load) and I have pop ups blocked on, and this behavior is limited to AppleInsider, very weird. Last time I mentioned it AI deleted my post.

OK, gotta go, the wife says I have to log off and go climb a mountain!

From Apple ][ - to new Mac Pro I've owned them all.Long on AAPL so biased"Google doesn't sell you anything, Google just sells you!"

It's a technicality that makes little impact on most things right now, especially desktop users.

In a sense isn't that obvious because of the lack of userland programs. Given that even now people do make use of the current level of 64 bit support. That simply to accelerate thing by the use of more memory than 4GB. Often it is the number of apps you can keep working for you in memory that makes the difference. The ability of an app to address beyond 32bits doesn't come into play.

As an overview the article is well written! Unfortunately it really doesn't get into the really interesting parts of Snow Leopard. Hopefully Insider can work out something with Apple to start publishing info on the more interesting stuff coming.

Of course after tv 3G fiasco Apple might be tighter lipped than before with respect to coming tech.

Can you actually list those people/applications where it will have an impact now?

What would be the point? I mean you have already made up your mind that an OS that addresses more than 4GB is of no use to the average user. The first problem is what is the average user. The second problem is why do you think what is acceptably to you is OK for the "average user".

As mentioned previously it is the simple reality that more memory means more space for apps and data 32 bit or not. Even todays Photoshop users are taking advantage of the OS'es ability to address memory beyond 4GB. It is all in learning how to leverage your work space by keeping data and auxilirary apps in memory.

In any event the people who really need the memory will find a way to use it all. The difference with a full 64 bit OS is that those with modest needs or limited tech knowledge can benefit from that addressable memory without stress.

I'm going to have to correct your first chart. The Motorola 68000 was a 32-bit processor (you have 24-bit) that was limited to 24-bit address bus (which you got right). And the typical RAM limit by that generation of Mac was 4 MB. It wasn't able to address the full 16 MB range as I recall because of video, I/O, ROM (can't remember which, could have been all three) memory mapping by the original Mac started at the beginning of the 5MB address space (after all who would use more than 4 MB RAM anyway?!?).

Ironically, Apple has recently released 64bit Vista drivers for the Mac Pro, so Photoshop users who want to take advantage of 64bit Photoshop with CS4 and 4GB+ of RAM they can do so by using Windows in boot camp. So whilst this article argues the superior technical implementation of 64bit in OS X, the end user will see the exactly the opposite, Photoshop 64bit runs on Windows but not OS X. The fact that this is a result of Apple's own decision, is embarrassing for Apple.

I'm guessing that Apple does not revolve it's entire development schedule around the availability of Photoshop updates or lack there of.

Rather than embarrassing Apple, it's likely going to create an opportunity for anything close to a PhotoShop competitor to advertise against them.

If you think putting up with Vista is worth running PhotoShop in 64 instead of 32 mode, you're probably not in a majority. Who knows, maybe we finally found a good use for Vista. A way to get around Photoshops inability to keep up. So you need one extra piece of bad software to avoid running another outdated piece of software. Brillant.....

...Apple can add as much RAM as users can afford. Of course, if you're buying RAM from Apple, upgrading a Mac Pro to 32GB of RAM currently costs $9,100, so it might be some time before home users decide they need more than that much RAM.

However if you are not purchasing from Apple, insane amounts of RAM are well within the reach of mere mortals.

If you have a current Mac Pro you can buy a 32GB upgrade kit for about $2400
If you have an older MacPro that uses 667Mhz RAM you can buy a 32GB upgrade kit for ONLY $1700!

I am currently running with 9GB of RAM and will be adding another 8GB when prices fall again.

I'm going to have to correct your first chart. The Motorola 68000 was a 32-bit processor (you have 24-bit) that was limited to 24-bit address bus (which you got right). And the typical RAM limit by that generation of Mac was 4 MB. It wasn't able to address the full 16 MB range as I recall because of video, I/O, ROM (can't remember which, could have been all three) memory mapping by the original Mac started at the beginning of the 5MB address space (after all who would use more than 4 MB RAM anyway?!?).

A very good article, BTW.

I was going to correct that but really the 68000 was 16bit, not 32bit. It had a 16bit data bus externally just as the address bus was 24bit externally despite it being what we'd call a 32bit processor today internally and to code for, the exception often being Microsoft who would do stupid things like using the spare byte in the address instructions for other purposes.

I also don't want to be defending Microsoft here but they've had a 32bit version of Windows out since the late 1980s - Windows/386 v2.1 allowed 32bit addressing and had a 32bit kernel, and they were 64bit in the 90s but then DEC went pop before they released the Alpha 64bit version of NT.

The Windows bashing is tiresome and doesn't shed any light on what Apple are doing with Snow Leopard TODAY or how Apple will tackle the same 32bit/64bit problems that Microsoft have had to deal with. It's nice to have a bit of history in an article, if it's correct, but I can't help but feel at this point in Apple's timeline, what it did on the 68K or what Microsoft did in the 80s has no relevance.

Now I see why Apple is trying to pull all drivers in-house for everything from printers to other peripherals... it would be a serious pain to have to go find the corporate web site of every single device that's attached to my computer and download the 10.6 driver (assuming the company will provide one).

And no 64-bit Photoshop is probably going to mean a couple years of very sluggish Mac Pro sales and a stalling of some of Apple's corporate gains.

Apple's Mac Pro sales are no longer dependent upon Adobe. This has become clear during this past year.

As it happens that's all Apple's fault. First they say that we'll have 64 bit Carbon, so Adobe head of in that direction, then they say no 64 bit Carbon for you! Adobe is caught half way down the former track and needs to restart development.

I guess 64 bit PS means a lot if you've just dropped 64GB of memory in your MacPro and you actually want to use it (and you mostly use PS) but surely most people will not notice the performance penalty. Those graphic artists aren't that techie surely.

Not really. Developers have been told repeatedly that the future is Cocoa if it wasn't obvious already.

The problem seems to be more Adobe's insistence on using a cross platform UI library.

I was going to correct that but really the 68000 was 16bit, not 32bit.

Hello, Newman :P

Quote:

I also don't want to be defending Microsoft here but they've had a 32bit version of Windows out since the late 1980s - Windows/386 v2.1 allowed 32bit addressing and had a 32bit kernel, and they were 64bit in the 90s but then DEC went pop before they released the Alpha 64bit version of NT.

Unfortunately all that cross-platform NT HAL work was abandoned in Windows 2000, and the experience didn't help Microsoft in pushing 64-bit support (or EFI support, the company also had Windows working on Itanium/EFI) to the Windows plebes. They'll still be on 32-bit Windows through Win7 (2010 through 2014?), while Mac users were silently and effortlessly migrated to 64-bits last year as an encore to the iPhone.

Quote:

The Windows bashing is tiresome and doesn't shed any light on what Apple are doing with Snow Leopard TODAY or how Apple will tackle the same 32bit/64bit problems that Microsoft have had to deal with.

There is no "bashing" involved, just a simple comparison between platforms that does exactly what you say it doesn't above.

Quote:

It's nice to have a bit of history in an article, if it's correct, but I can't help but feel at this point in Apple's timeline, what it did on the 68K or what Microsoft did in the 80s has no relevance.

How ironic you'd say that after bringing up Alpha (which was mentioned in the article), work that hasn't had any beneficial impact on Microsoft's ability to ship 64-bit software without serious compromise. 68000 and the x86 were presented for context, not to praise Apple.

I think if I made you breakfast you'd complain about the coffee not being instant.

---

Here's some benchmarks that provide additional info on why Snow Leopard will be Intel only: the referenced site's benchmarks indicate 64-bit software runs only 90% as fast as 32-bit software on PPC G5, while 64-bit software on x64 Macs runs 105-107% as fast overall. Apple says Snow Leopard's move to 64-bit across the board will provide around 115% of the speed of a 32-bit build when running on 64-bit systems.

Here as wife was off riding a horse. I will not do that until they have brakes. We are at our Lincoln, New Hampshire hideaway in the mountains. iPhone does work (Mk 1 too) we only have to hang off the balcony by the ankles to get a signal.

Re Ads; It's not the in page stuff, but a literal pop up that appears (it can take a while to load) and I have pop ups blocked on, and this behavior is limited to AppleInsider, very weird. Last time I mentioned it AI deleted my post.

OK, gotta go, the wife says I have to log off and go climb a mountain!

New Hampshire has mountains? You mean geological pimples, don't you?

Pity the agnostic dyslectic. They spend all their time contemplating the existence of dog.