[moreno]

from an Apple Developers note:

"It is important to note that in the Tiger release, the support for 64-bit programming does not extend throughout the entire set of APIs available on Mac OS X. Most notably, the Cocoa and Carbon GUI application frameworks are not ready for 64-bit programming. In practical terms, this means that the "heavy lifting" of an application that needs 64-bit support can be done by a background process which communicates with a front-end 32-bit GUI process via a variety of mechanisms including IPC and shared memory. "

http://developer.apple.com/macosx/tiger/64bit.html

[Eug Wanker]

Uh... That info has been up on Apple site for just about forever.

[hmurchison2001]

You have to ask yourself. "What exactly do I need 64-bit software for?"

Do drivers need to be 64-bit? Perhaps in a few small circumstances but most of us will see more realword benefits from erasing the 4GB per app limit.

Science applications would like to have the extra processing or precision that 64-bit could entail.

My suggestion is to avoid any 64-bit'ness debates. Every OS or CPU has a compromise in the chain. It's a fruitless effort.

[Millennium]

There are several OSX apps which already work this way. Shake does, for example.

[- - e r i k - -]

So what's the problem, any app likely to require 64-bits of memory addressing (likely not the kind of app me and you uses daily (without being to presumptuous I hope)) would just write a 64-bit background process to communicate with the 32-bit GUI.

[Eug Wanker]

Originally posted by - - e r i k - -:
So what's the problem, any app likely to require 64-bits of memory addressing (likely not the kind of app me and you uses daily (without being to presumptuous I hope)) would just write a 64-bit background process to communicate with the 32-bit GUI.

Yeah, but an existing GUI-ified 64-bit app, it'd be a major pain to port it to Tiger.

Fortunately, there aren't too many of those around.

Originally posted by Millennium:
There are several OSX apps which already work this way. Shake does, for example.

Shake is 64-bit?

[Millennium]

Originally posted by Eug Wanker:
Shake is 64-bit?

Not that I'm aware of, but it has a non-GUI backend which communicates with a separate frontend in the manner suggested by Apple. Many Unix apps with a GUI frontend do this, and to date any 64-bit app which stands to be ported to OSX will come from Unix. After all, Windows is not 64-bit yet, so we're not going to be getting any 64-bit apps from there.

[jamil5454]

Apple is pretty smart about this 64-bit stuff, IMO. They are gradually moving parts of the OS to 64-bit and one day it will all be 64-bit. But for now, we need the compatibility, and so most of the OS remains 32-bit. It's like a hybrid. I'm guessing that by 10.5 or 10.6 we'll be ALL 64-bit.

And, with the invention of the Cell processor, we will need to break that 4gb limit. Imagine how powerful your computer would be if it took advantage of the Cell, but only had 4gb of memory. I'm pretty sure the memory would be the bottleneck in most situations. Heck, even Quad PowerMacs would be able to saturate 8gb of memory. I'm not sure if what I said just made sense, but basically I'm saying that one day we will need the 32gb of memory to handle a Super-OS or to handle all those open applications that our CPUs are processing. Right now, the amount of memory is starting to become a bottleneck for some.

[Brass]

I hear that Tiger is being distributed on DVD not CD, therefore, if it can't fit on a CD, I would assume that it is indeed a lot more than 64-bits.

[Kristoff]

Does anyone know if the Tiger JVM allows the -d64 option?

A 64-bit server VM on OS X would be nice.

[Big Mac]

Originally posted by jamil5454:
Apple is pretty smart about this 64-bit stuff, IMO. They are gradually moving parts of the OS to 64-bit and one day it will all be 64-bit. But for now, we need the compatibility, and so most of the OS remains 32-bit. It's like a hybrid. I'm guessing that by 10.5 or 10.6 we'll be ALL 64-bit.

And, with the invention of the Cell processor, we will need to break that 4gb limit. Imagine how powerful your computer would be if it took advantage of the Cell, but only had 4gb of memory. I'm pretty sure the memory would be the bottleneck in most situations. Heck, even Quad PowerMacs would be able to saturate 8gb of memory. I'm not sure if what I said just made sense, but basically I'm saying that one day we will need the 32gb of memory to handle a Super-OS or to handle all those open applications that our CPUs are processing. Right now, the amount of memory is starting to become a bottleneck for some.

Only certain things benefit from 64-bit processing, and doing things in 64-bit means that you're using twice the memory footprint. This transition is not like the one we experienced when going from 24 to 32-bit addressing back in the early 90s. 32-bit is fine for most things; only a few specialized tasks require the extra space.

[Brass]

Originally posted by Big Mac:
Only certain things benefit from 64-bit processing, and doing things in 64-bit means that you're using twice the memory footprint. This transition is not like the one we experienced when going from 24 to 32-bit addressing back in the early 90s. 32-bit is fine for most things; only a few specialized tasks require the extra space.

or like the one from 16-bit to 32-bits.

24 bits... hmmm, 24 is 2 to the power of what? My maths ain't that good.

[kupan787]

Originally posted by Brass:
24 bits... hmmm, 24 is 2 to the power of what? My maths ain't that good.

That really has nothing to do with anything.

The G4 has 48 bit memory addressing (or 42, sorry can't exactly remember). There is no law saying that bits must be in powers of 2.

[CatOne]

Originally posted by moreno:
from an Apple Developers note:

"It is important to note that in the Tiger release, the support for 64-bit programming does not extend throughout the entire set of APIs available on Mac OS X. Most notably, the Cocoa and Carbon GUI application frameworks are not ready for 64-bit programming. In practical terms, this means that the "heavy lifting" of an application that needs 64-bit support can be done by a background process which communicates with a front-end 32-bit GUI process via a variety of mechanisms including IPC and shared memory. "

http://developer.apple.com/macosx/tiger/64bit.html

Pffft. Moreno: not quite savvy on the whole concept.

[- - e r i k - -]

Originally posted by Brass:
I hear that Tiger is being distributed on DVD not CD, therefore, if it can't fit on a CD, I would assume that it is indeed a lot more than 64-bits.

[sanity assassin]

Originally posted by Eug Wanker:
Yeah, but an existing GUI-ified 64-bit app, it'd be a major pain to port it to Tiger.

Fortunately, there aren't too many of those around.

This is where Windows/Linux excels at the moment, and for the foreseeable future. In the 3D world, nearly everyone is demonstrating a 64-bit port of their software. So, in the film/tv/games world, 64-bit is desired and the software companies are responding.

Guess we'll need to see how Apple responds.

[- - e r i k - -]

Originally posted by sanity assassin:
This is where Windows/Linux excels at the moment, and for the foreseeable future. In the 3D world, nearly everyone is demonstrating a 64-bit port of their software. So, in the film/tv/games world, 64-bit is desired and the software companies are responding.

Guess we'll need to see how Apple responds.

I have no idea what you are talking about. Windows 64-bits? 64-bit UIs? Why would you need that? A 3D app or visual effects app (I assume you are not talking about editing since even hours of HD content need nothing near 64-bits of memory), needing 64 bits addressing could perfectly well do it's rendering in a background process, even networked if needed (X-grid). It doesn't need a 64-bit UI. And name one 64-bit game to date, or why that would even be desirable considering the current graphic cards are the limitation, not memory addressing.

[sanity assassin]

Originally posted by - - e r i k - -:
I have no idea what you are talking about. Windows 64-bits? 64-bit UIs? Why would you need that?

Obviously.

[Don Pickett]

Originally posted by sanity assassin:
Obviously.

He's right on this one. There's no need for Tiger's UI to be 64 bit as, unlike x86 chips, PPC chips gain no extra registers going to 64. Apps can address the full 64 bit goodness with a 32 bit UI front end.

[sanity assassin]

Originally posted by Don Pickett:
He's right on this one. There's no need for Tiger's UI to be 64 bit as, unlike x86 chips, PPC chips gain no extra registers going to 64. Apps can address the full 64 bit goodness with a 32 bit UI front end.

Well, you didn't understand what I was saying. If you don't think a 64-bit GUI for film/tv/game development is necessary, then I don't know what to say. That is, just talking about the GUI, let alone anything else.

[chabig]

Apple already stated publicly (I can't remember where) that moving the GUI to 64 bits hurts performance. That's because you're moving a lot of pointers around that contain twice as much information, but the extra bits don't provide any benefit to the GUI. So that is why they didn't do it.

Windows and Linux have nothing over Mac OS X in this regard.

Chris

[Eug Wanker]

Originally posted by chabig:
Apple already stated publicly (I can't remember where) that moving the GUI to 64 bits hurts performance. That's because you're moving a lot of pointers around that contain twice as much information, but the extra bits don't provide any benefit to the GUI. So that is why they didn't do it.

That is not why they didn't do it. I'm sure they'd love to have it in Tiger, but they don't.

[mitchell_pgh]

You're missing something massively important. The reason why Apple chose not to release 64-bit versions of the UI frameworks is that they run much slower than the 32-bit versions.

User interface code is really pretty messy when you get right down to it. You're doing a lot of abstraction, moving a lot of pointers and integers around. On exactly the same G5-based computer, a 64-bit UI is going to run considerably slower than a 32-bit UI because of cache exhaustion. Because you're using pointers that are twice as big as you need them to be, you can only fit half as many of them in the various caches that are there to speed up your computer's performance. That effectively cuts your caches in half.

So Apple had two choices: Either waste a ton of Apple's time releasing 64-bit-clean versions of the UI frameworks and then tell Apple's developers not to use them, or just don't ship them at all.

Apparently, the Final Cut Pro and Shake teams were pissed off about this. Their expectation was that they'd be able to release 64-bit versions of their applications by NAB. But a 64-bit version of FCP with 64-bit Pro Kit is less interactive than the 32-bit version on the same hardware, for very marginal gains in actual utility. FCP is already very good at making use of up to 2 GB of RAM when dealing with hundreds of gigabytes of data on disk; adding 64-bit support would have helped few and hindered many.

(Paraphrased)

[sanity assassin]

Originally posted by chabig:
Apple already stated publicly (I can't remember where) that moving the GUI to 64 bits hurts performance. That's because you're moving a lot of pointers around that contain twice as much information, but the extra bits don't provide any benefit to the GUI. So that is why they didn't do it.

Windows and Linux have nothing over Mac OS X in this regard.

Chris

The issue is a little bit bigger than just Adobe, but you'd know this if you were using such things as custom display hosts in a 3d app like XSI,while pumping real-time video through the interface and generating on the fly high-rez textures with PS. That's a simplistic example.

The benefits for PS might be slight, I don't know, but in other areas, it's a huge improvement, which is why 3D/film/video application vendors are pushing hard to match this.

OS X is already lagging way behind the others in the 3D animation area, and probably film too, and with the 64-bit equation being pushed around just now, the gap will probably get bigger.


Anyway, it's all moot since OS X isn't really an option for most game companies.

[Don Pickett]

Originally posted by sanity assassin:
Well, you didn't understand what I was saying. If you don't think a 64-bit GUI for film/tv/game development is necessary, then I don't know what to say. That is, just talking about the GUI, let alone anything else.

I'm gonna copy and paste a comment from the Slashdot Tiger thread, because it says it as well or better than I could:

Please note that "64-bit" encompasses two completely different things:

64-bit integer registers and arithmetic operations on those registers

64-bit pointers

Note that you can already use 64-bit registers and do 64-bit math. This is more of a compiler issue than an operating system issue. (The only change needed to the kernel is to save the full contents of the registers on context switching, rather than only the low 32 bits.)

What would 64-bit pointers give you if you could use them?

• Ability to address more than 4 GB of RAM from within a single application (how many applications need that much RAM?)

• Larger code size, resulting in greater memory usage

• Slower performance, because less code can fit in the L1/L2 caches

• Slower performance in low memory situations because you're more likely to have to page out more often.

How many apps actually need to address more than 4GB of RAM at once? Usually they're only doing that if they are dealing with big files. A process using 32-bit pointers can do this using mmap() and if used correctly the kernel can load the whole file into RAM (if possible) and just adjust virtual memory tables so that the same chunk of 32-bit address space points at different parts of the file as needed. The app just has to make the right mmap() call to cause the kernel to shuffle around the virtual memory mappings to change which physical page is mapped onto which virtual page in that process's virtual memory.

If you do need 64-bit addressing for some reason (although it's extremely rare for it to be actually necessary, nearly everything can just mmap() files instead), then fork off a separate process and let it do whatever needs to be done with that huge amount of RAM. Use your favorite form of IPC or shared memory to talk to that process.

What does Tiger give us that's not already in Panther? Well, all apps will see some performance improvement as various system libraries now use 64-bit operations for arithmetic where appropriate. Processes using 64-bit pointers now have some important libraries available, most notably libsystem (Apple's combined libc and libm) which was not available for processes using 64-bit pointers in Panther. Not all libraries are available in 64-bit versions (Carbon and Cocoa, for example) but there's no good reason for them to be. There's no good reason for it. Apps run slower when using 64-bit addressing on current systems, so only those rare processes which really need the extra addressing space should be using it, and user interface code certainly doesn't fall into that category.

Apple's information on 64-bit computing in Tiger is available here].

So you see, the full capabilities of your 64-bit CPU are being used. 64-bit math is up to the application writer to use the appropriate compiler options (and in Tiger the system libraries will also use 64-bit math internally) whereas 64-bit addressing is already used by the kernel (even in Panther) to handle virtual memory, allowing the use of more than 4 GB of RAM (although most processes will use 32-bit addressing and will thus be limited to only 4GB each).

[sanity assassin]

Originally posted by mitchell_pgh:
You're missing something massively important. The reason why Apple chose not to release 64-bit versions of the UI frameworks is that they run much slower than the 32-bit versions.

No, you're missing my point. I'm not really interested in the general reasons for OS X's 64-bitness, I'm explicitly talking about the 3D animation and film world where the movement to 64-bit is happening at lightning pace. This probably matters more on the Linux/Windows side where the demand is so great, and no so on OS X.

Again, I am talking about a very specific area, a specialist area, one in which the the other OS/software manufacturers are making better ground than Apple.

I'm not really caring if iCal is 64-bit, if you know what I mean.

[sanity assassin]

Originally posted by Don Pickett:
I'm gonna copy and paste a comment from the Slashdot Tiger thread, because it says it as well or better than I could:

Which has little to do with what I said. You're not seeing what I am addressing here.

[Don Pickett]

Originally posted by sanity assassin:
Which has little to do with what I said. You're not seeing what I am addressing here.

I'm not. Please explain the advantages of a 64 bit UI.

[sanity assassin]

Originally posted by Don Pickett:
I'm not. Please explain the advantages of a 64 bit UI.

Read my reply a few posts up.

I'll make it simple. There is a need by many in the game/film industry to have a complete 64-bit development environment, from the OS, right down to off-the shelf software, to proprietary tools. Windows and Linux software are providing this for us at the moment, and the future development of such tools seems far more solid than Apple..

Apple is way behind this at this point in time.

[JLL]

Originally posted by sanity assassin:
No, you're missing my point. I'm not really interested in the general reasons for OS X's 64-bitness, I'm explicitly talking about the 3D animation and film world where the movement to 64-bit is happening at lightning pace.

And what does that have to do with a 64-bit User Interface?

Just because the buttons, menus, sliders and so on aren't 64-bit, doesn't mean that the underlying app can't be.

[Don Pickett]

Originally posted by sanity assassin:
Read my reply a few posts up.

I'll make it simple. There is a need by many in the game/film industry to have a complete 64-bit development environment, from the OS, right down to off-the shelf software, to proprietary tools. Windows and Linux software are providing this for us at

Apple is way behind this at this point in time.

Ah. Well, I misunderstood and must claim ignorance on this particular topic.

[sanity assassin]

Originally posted by JLL:
And what does that have to do with a 64-bit User Interface?

Plenty, depending on the situation.
You should know the benefits if you do what I mentioned above.

[JLL]

Originally posted by sanity assassin:
Plenty, depending on the situation.

Example?

[Millennium]

Quite a few software vendors design their software in a kernel/frontend way, whereby the kernel is optimized for what it needs to do, and the frontend is optimized for what it needs to do. This is the type of architecture which Apple is espousing for 64-bit apps. It has other advantages than optimization: among other things, one can make the kernel extremely portable, such that only the frontend needs any real work when going between platforms.

Shake has always had this type of architecture, and apps like Mathematica and MATLAB have done it for decades. If it is done properly, it does not make your apps "less interactive" at all, nor does it sacrifice any GUI power. This said, coding in this way is not always the easiest thing in the world, and I hope Apple has figured out a way to address that problem.

[Millennium]

Originally posted by Don Pickett:
I'm not. Please explain the advantages of a 64 bit UI.

There are no advantages, as far as the user is concerned. None whatsoever. The only advantage is to the programmer: hard-coding a GUI into the program is easier than the kernel/frontend architecture I mentioned earlier. Certainly this is a real disadvantage, but it is hardly insurmountable.

[sanity assassin]

Originally posted by JLL:
Example?

I gave one one a few posts up. Take that, and apply it to a real-world situation in which, say, a number of synoptic views in XSI are driven by a user-defined GUI for mapping out a behavioural simulation involving 10,000 characters.

[JLL]

Originally posted by sanity assassin:
I gave one one a few posts up. Take that, and apply it to a real-world situation in which, say, a number of synoptic views in XSI are driven by a user-defined GUI for mapping out a behavioural simulation involving 10,000 characters.

But isn't it the data crunching you need 64-bit for? A 32-bit interface should be able to show real time video if the data is there.

I still don't see why the interface needs to be 64-bit - it's just serving the results.

[sanity assassin]

Originally posted by Millennium:
There are no advantages, as far as the user is concerned. None whatsoever. The only advantage is to the programmer: hard-coding a GUI into the program is easier than the kernel/frontend architecture I mentioned earlier. Certainly this is a real disadvantage, but it is hardly insurmountable.

Exactly. For an end-user, there probably isn't much advantage, if any. But for a developer working in 3D, the benefits are there.

[wataru]

Originally posted by mitchell_pgh:
(Paraphrased)

You could at least give the source.

[sanity assassin]

Originally posted by JLL:
But isn't it the data crunching you need 64-bit for? A 32-bit interface should be able to show real time video if the data is there.

I still don't see why the interface needs to be 64-bit - it's just serving the results.

Imagine if the actual interface consisted of elements akin to high-res video, but it's really the GUI itself. Not just a video stream, but a fully interactive environment in which the manipulation of those elements is just like working with simple bitmap images we use just now.That's just one example, though.

[Millennium]

Originally posted by sanity assassin:
Exactly. For an end-user, there probably isn't much advantage, if any. But for a developer working in 3D, the benefits are there.

Even then, not really. In any case, it is by no means unique to 3-D developers. It could also be said that the kernel/frontend architecture has advantages which outweigh the disadvantage of being harder to code, such that the whole app could benefit from it even on other platforms. In most cases, it wouldn't even require much of a rewrite.

[Millennium]

Originally posted by sanity assassin:
Imagine if the actual interface consisted of elements akin to high-res video, but it's really the GUI itself. Not just a video stream, but a fully interactive environment in which the manipulation of those elements is just like working with simple bitmap images we use just now.That's just one example, though.

This does not require tight integration of the app and its GUI. It is more than possible with a kernel/frontend architecture. You are making the same mistake that Microsoft often makes: the fallacy that good integration means tight integration.

[Brass]

Originally posted by kupan787:
That really has nothing to do with anything.

The G4 has 48 bit memory addressing (or 42, sorry can't exactly remember). There is no law saying that bits must be in powers of 2.

You're right in saying that there is no law against it, but it makes sense to use it, since that's the way that computers do everything else and it is easier for a computer to work with.

My original point was that several years ago the Mac transitioned from 16 bit to 32 bit addressing, not 24 bit to 32 bit.

48 bit addressing? Really? Interesting, I'd not heard that.

[Big Mac]

Originally posted by Brass:
You're right in saying that there is no law against it, but it makes sense to use it, since that's the way that computers do everything else and it is easier for a computer to work with.

My original point was that several years ago the Mac transitioned from 16 bit to 32 bit addressing, not 24 bit to 32 bit.

48 bit addressing? Really? Interesting, I'd not heard that.

Nope, that is incorrect. It was a switch from 24-bit addressing to 32-bit addressing, not to be confused with 16-bit v. 32-bit data paths. You may want to take a look at this page.

[Brass]

Originally Posted by Big Mac

Nope, that is incorrect. It was a switch from 24-bit addressing to 32-bit addressing, not to be confused with 16-bit v. 32-bit data paths. You may want to take a look at this page.

Really? Foiled again!

So is Tiger 64 bit addressing, or 64 bit data pathing?

Someone just said that it's 48 bit addressing.

[frankiec]

Originally Posted by moreno

from an Apple Developers note:

"It is important to note that in the Tiger release, the support for 64-bit programming does not extend throughout the entire set of APIs available on Mac OS X. Most notably, the Cocoa and Carbon GUI application frameworks are not ready for 64-bit programming. In practical terms, this means that the "heavy lifting" of an application that needs 64-bit support can be done by a background process which communicates with a front-end 32-bit GUI process via a variety of mechanisms including IPC and shared memory. "

http://developer.apple.com/macosx/tiger/64bit.html

If you have to quote it than you don't understand it. Leave the technical stuff to people that understand it. Just use your computer to get tasks done. The Mac is great for that. Good luck!

[Chuckit]

The G5 has 42-bit addressing.

[mAxximo]

The reasons why OS X won't be a full-blown 64-bit OS for a good while, thalo.net style:
Link.

[Millennium]

Originally Posted by mAxximo

The reasons why OS X won't be a full-blown 64-bit OS for a good while, thalo.net style:
Link.

My, my. Not a single coherent thought in the whole post. "OSX isn't fully 64-bit because Aqua has useless bloat", and... that's it. Non-sequiturs abound, and it all comes down to someone who knows maybe half of what he's talking about at best, ranting in a barely-coherent manner, and of course the thaloites eat it up because it's what they want to hear, never mind whether it's even remotely plausible.

[mAxximo]

Well, that's more or less what everybody who knows something about it is agreeing with. Oh, you don't?