Apple and x86 Questions, Part 1

I've been chewing my way through your x86 questions (there are a few pages of them), and as we learned in Under the Iron, ask me a question and you can kill an afternoon. Yes, it's that way in real life, too. So I'm going to break them up, in order of the ones that help kill off others.

For warning, I have a habit of lumping things together when it's just easier that way, so 'x86' will be used to denote the instruction sets that make up, well, x86 chips, and IA-32 and the 64-bit extensions added on will be broken out only when necessary.

First of all, thanks for your great blog. After someone pointed it out to me last year, it quickly went from being one I sometimes read, to one where I read all the articles posted. :-)

Quick question when you're looking into the whole Intel situation: will Classic be supported? In my (cursory) reading of various information, no one seems to have addressed this. On current Macs, I can still run both OS 9 and even _68k_ binaries (from they System 7 or maybe even 6 era).

Will one or both of these abilities be removed? I certainly hope not (it comes in useful sometimes). Beyond this, I personally don't care what processor a computer is using. I just don't want to lose functionality.

Jolin M. W.

Classic appears to be dead on x86 hardware, and already going cold. Apple didn't come out and say it, and people don't really want to confirm it, but you can read between the lines in their documentation. Rosetta just won't be able to handle it, or anything below Mac OS 10.0, and that's the only way you'd end up with bits of PowerPC assembly running on x86.

It's going to make things a little interesting as the transition goes on. Personally, I haven't used OS9 nor classic on any of my computers in years, but I know people who do. Just the other day someone I know bought a new book to study for an upcoming test, and the software disc that came with it only ran in Classic which meant I had to get it back on their computer.

I know a lot of schools make heavy use of it, and it's not something I discount as people using Classic are part of the 'long tail' of the userbase. They do add up.

It's a situation where Apple cares very little about people using Classic, and developers at this point don't care about people using Classic at all as they're more interested in the software they have than the software they'll be buying for it. Only users do, because they don't want to lose that investment, or what they want to use isn't available anymore.

Apple only cares because people could well put off sales of newer hardware if they know they'll also be buying new software, but I think they're very much less interested in their traditional base and much more interested in being a Remora on the Windows base.

If running older software is important to you for some reason, you probably won't be running it on an x86 Mac -- except perhaps through a third party emulator -- and should probably plan accordingly.

Something everyone seems to be overlooking: Steve's demo at WWDC Keynote was done on a Pentium-IV. Last time I checked, those are 32-bit chips. Nobody's said anything about any 64-bit "roadmap" (to steal a phrase).

'ledge'

People aren't saying much about it because there:

  • Isn't that much known, so there's not much to say, and to my knowledge if you have a 64-bit app that you're trying to get working on Apple's preview release for Intel you're banging your head against the wall.
  • The answer is probably going to kinda suck, and no one really wants to talk about it right now.

Here's a dirty little secret that surprises more people than it should: Mac OS X is already fairly warped when it comes to 64-bit computing. It works, and it's there if you're willing to jump through a bunch of hoops, but you'd have to be remarkable in your definition of what a 64-bit OS was to give the moniker to OS X as it currently stands.

A quick breakdown:

  • On a 32-bit Mac OS X, a process can suck up 3-ish gigabytes of RAM and the entire system can address 4 gigabytes... My understanding is that the limit is more of an artifact of the OS and other things rather than what can be done. There can be ways to fudge around this, but they're enough trouble that people rarely deal with it.

  • On a 64-bit Mac OS X, a process can suck up anywhere from 4 gigabytes of RAM to more than 16 million terabytes, otherwise known as 'God's Box'. Apple currently limits their machines to 8 or 16 gigabytes of RAM, something like that, while others that are more high-end can go up to terabytes. All the limits are artificial, because the supporting chips to deal with that much RAM would be... pricey.

(I actually clipped out about a page's worth of text here, as breaking down why theoretically a process can address 4GB on a 32-bit system, but can't in practice is beyond the scope of this so don't get on me about it)

Now, it's worth noting, Mac OS X isn't really a 64-bit OS. The kernel itself, through a type of 3-card monty is able to address bunches of memory so if you stack your shiny PowerMac G5 with eight gigabytes of memory you can fill it up, but you can't launch Photoshop and tell it to use 6 gigabytes of RAM because the majority of the libraries and frameworks and such are not 64-bit.

I've encountered people that bought a PowerMac and threw in four gigabytes of RAM, then realized Photoshop or Final Cut wasn't going to be able to use all their RAM. Then they'll generally rant at Adobe, which is strange as they rarely rant at Apple's app for the same problem... but perhaps I've just been exposed to the wrong people. Anywho, in order for Adobe to be able to address more than 4 gigabytes of RAM in their apps, they would need:

  • Apple would need to update their frameworks for GUI apps to be able to be 64-bit. To be fair, Adobe probably has some pretty custom stuff going on and would possibly need to do some tweaking and give it recompile, but most of the onus is on Apple here. Without 64-bit frameworks for Cocoa and Carbon, the onus is on the developer...

  • Rearchitecture Photoshop so you have an app running as the GUI and an app running as a Unix app, which would communicate with each other. Since the 'unix' layer is generally 64-bit compliant, it would do all the heavy lifting in its now gargantuan RAM space. Well, I'm pretty sure this was what Apple was recommending developers do originally, although someone the other day told me they're telling people to spin it out as a process or something.

As you can imagine, the above doesn't make sense to the vast majority of developers, and most of the apps that people need that memory for don't support addressing it. If you're starting from scratch, you can pursue it as an option, but thats a pretty small amount of people and having to create your app around limitations in Apple's software that will probably go away as soon as possible seems a little goofy.

Now, Apple's side of the story is that:

  1. If they made everything 64-bit, things would slow down! You'd use up more memory, more cache, etc. It's a valid point, you certainly wouldn't see performance increase across the board with the PowerPC as you do with x86 (as it got architectural improvements at the same time).

  2. We updated a few of our libraries to be G5-optimized for an improvement! (You can do 64-bit math on a 32-bit PowerPC, but its slower than having it go native because of 3-card-monty-stuff)

  3. Well, you still have eight gigabytes of memory, so even though none of your GUI apps can actually use it all, you can run more apps at the same time.

Alright, so the last one is usually how other Mac users try to spin it into a positive when someone gets upset. The only one that has any real validity is [1], and it doesn't have that much validity. Sure, taking a speed hit is real, and using more memory (and hence, cache) is real, but not nearly as bad as some make it out to be on a system like the G5.

And really, not having a fully 64-bit system causes so many problems (in addition to the above) for developers that it just isn't happening. Buying a G5 gets you very little in the way of 64-bit goodness right now, although you do get some goodness from the other enhancements in the G5 for your 32-bit apps and code. And yes, Apple really is behind the curve here, as even Microsoft put out a 64-bit version of Windows awhile ago and Linux has lead the vanguard.

The point is, Apple isn't exactly at the vanguard of 64-bit computing as it is, and that mostly just came along with the MHz bump of the G5 and 64-bit hasn't been all that important. They'll eventually have a fully 64-bit system, probably sooner rather than later, and most developers (even those that really need 64-bit goodness) have chosen to wait for that. When Apple wants to, x86 has it.

AMD was at the vanguard with this with the Opteron (high end workstations and servers that need multiple CPUs), and pushed it into the Athlon (similar to the Opteron, but few hypertransport links). Eventually it'll make it into the Semprons (consumer). Intel has been shipping P4s with 64-bit extensions for awhile, although its been turned off by default for the most part, and will be incorporating it into its 'cooler' chips well within Apple's timetable.

Now, x86's 64-bit solution isn't anywhere near as 'smooth' as the PowerPC's, as the PowerPC really was designed to move to 64-bit as anyone who remembers the original PowerPC roadmap (and the mythical PowerPC 620) can attest to. With x86, its much more 'tacked on' and brings with it some headaches, but they wisely used it as an opportunity to flesh out some of x86's capabilities so its generally well worth a developer's time.

Basically, don't worry about it.

Apple's current support for 64-bit is somewhat weak right now, and few developers are actually jumping through the hoops to use it, and while it's unknown which product lines will first receive Intel chips, just as its unknown whether Apple will be pushing out Mac OS X as a fully 64-bit OS by then, or whether or not they'll be using 64-bit Pentiums when they do ship, but if they want to use 64-bit chips, they should be available across all the products lines Apple would want to use them for.

Now that I've fulfilled my quota for run-on sentences for the day...

I don't understand why Apple felt the need to switch, and wonder what else there is to it. The PowerPC is just hitting its stride, and everyone else is switching to it. XBox, Sony, Nintendo. What about the CELL? That is supposed to have higher FLOPS than any chip now. It doesn't make sense.

John W.

In short, the CELL was never a realistic option.

In long...

Technically this is a statement and not a question, but we'll roll with it. I think I covered most of this @ Under the Iron (search for pentium or something), but it's worth catching the end.

This talk about the CELL being an uber-chip is somewhat misguided and on a bad day could be called retarded. I don't blame you, I blame the marketing materials you read and the lack of other things you read that would have corrected what was fed to you by the marketing materials. This stuff becomes so generalized for mass consumption that comparisons become relatively worthless.

An example would be when Jobs was on stage saying that CPUs have hit a wall, but GPUs are just adding speed, so the computer is going to use the GPU more. Now, GPU chips are covered by the same laws of thermodynamics that CPUs are, so your mind should start tripping over that. GPUs are very good at what they do, but very poor at what they're not meant to do. I.E., there was a time when working with 3D meant doing all the stuff on the CPU.

Then hardware accelerators came out, and accelerated specific functions in some 3D APIs. Over time, they added more functions that were accelerated, like specific types of lighting, and people built those into their software. It's no cooincidence that almost every 3D game had a very similar 'look' to it, nor that almost every tree you'd see in a playstation game looked the same.

The heart of these chips is passing pixels through hardwired (and hence, speeded up) functions and spitting them on the screen.

The new 'programmable' GPUs allow a developer to upload a very small custom bit of code that the pixels are run through instead of what is hardwired. For more on this, I'd point you to an older post, but suffice to say a database server they ain't.

Which brings us back around to the CELL. A FLOP is a FLOP until you ask what is flopping, and while I won't beat you over the head with specifics, think of the CELL as a relatively weak PowerPC core (by today's standards) holding together a bunch of Altivec units.

That's bastardized, but you should get the impression: It will be very good at some things, and very weak at others, but it'll be very good in the areas Sony cares about and weak in many of the areas Apple cares about.

The CELL was never a realistic option.

yummy alcohol posted button Posted by drunkenbatman
    June 26, 2005, at 12:00 AM


Comments (37)




Post a comment



Anonymous comments are allowed, but please enter something for a name.

And do endeavor to appear sane.









Remember personal info?