is the g5 + tiger REALLY 64bit?

E

Elliotjnewman

Registered
All this time I have thought that apple have a true 64bit solution with the hardware (G5) and the OS (tiger).

However, I was in a meeting today at work and we where discussing a 3D paint program (maxon.com). We had a rep in from maxon, and we got into discussing this program on XP, Linux, and OSX. He said they have a beta version available for "XP64", to which I replied "so is it 64bit under tiger?" and he, and a few of my work colleages replied "well, apple arent any where near 64bit yet, so no"

I work in a leading post production visual effects company, and the people I am working with know there stuff... So what I dont get is, well I was convinced that the mac platform is true 64bit, and now, I just dont know what to think...

Can anybody elaborate on this for me?
 
Tiger is capable of running apps in either 32 or 64 bit modes. When an app is executed, itself and any libraries it links to and uses must be in the same mode.

Apple has not yet made the user interface libraries (Carbon, Cocoa) 64-bit. Thus, developers are unable to make a full-blown 64-bit application that has a graphical user interface. Developers are however, able to make command-line applications that run in the Terminal or in the background, and take advantage of 64 bitness.
 
And http://en.wikipedia.org/wiki/64_bit .
Mac OS X has supported 64 bit applications ever since the G5 was released, but there can't be 64 bit code in the same executable as the GUI, so everything 64 bit must be compiled as separate targets.

The problem can be addressed by having the 32 bit GUI application communicate with the 64 bit non-GUI backend. Quite straight-forward for simple applications, but might not be trivial for more complex programs like Cinema 4D, and that would explain Maxon's decision to make up a quick excuse for the lack of 64 bit support in Mac OS X:

maxon.com said:
Note for Apple users
Even though the G5 processors of the Apple Power Mac series are 64-Bit CPUs, 64-Bit applications are not entirely supported by the OS X operating system. Only command line based programs can take advantage of the 64-Bit memory adressroom. Programs with a graphical user interface (GUI) can only run in 32-Bit mode. Therefore we can unfortunately not offer a 64-Bit version of CINEMA 4D for Macintosh. More information on this topic can be found here:
http://developer.apple.com/macosx/64bit.html
Click to expand...

And - tihi - they're linking to the very page where Apple explains how to do what Maxon states to be impossible in their information text :p
 
So ok, I think I understand what is being said here. Basically, OSX isnt 64bit for applications that heavily use a gui such as cinema 4D or Maya or Lightwave or any other program not just animation. The only way to access the memory advantages of OSX 64bit is to run programs from the command line? i.e. command line shake? or command line rendering in Maya?

What have apple said in that link? That you can run a gui program like maxon's in true 64bit? If thats the case then why would maxon say otherwise? I cant locate that part of the apple article that contradicts what maxon are saying, can somebody highlight where it says "you can run gui based apps in 64bit"...

Also, the guy from maxon today said that there are versions available for 64bit XP - what? I thought thats what apple beat them to with tiger 64bit? So how come there is a company saying "we have 64bit betas of our software running on XP64 but the OSX tiger version is only 32bit"...

I feel that apple have failed to explain the true picture, I mean, I follow them as a company, ok I dont go into huge depth over every minute specification, but I was totally lead to believe that their software and hardware was all 64bit capable. I mean, I dont run any apps from the command line, so what I am hearing now means that OSX tigers 64bit support means jack to me.
 
The back-end 64 bit application can be completely transparent to the user if properly implemented. A user wouldn't even have to even see or touch command line to use a 64 bit application on the Mac. Note that although rendered graphics appear immediately on the screen, they need not be rendered by the GUI application itself, but for example by a 64 bit backend sharing its memory with the GUI app.

See Adding a GUI to a 64-bit Application in the Apple article.

The lack of 64 bit support for Mac OS X is due to Maxon's laziness and profit-driven business model. Their Windows customer base is obviously large enough for them to justify a 64 bit conversion, while their Mac user base is seemingly not.
 
Add to the fact that it isn't exactly trivial to take an existing code base, and separate out the non-gui stuff into a separate executable, no?

I think Maxon just doesn't want to invest the time and money into making a port. Guess that's justified, given the recent developments in Apple land.
 
Viro said:
Add to the fact that it isn't exactly trivial to take an existing code base, and separate out the non-gui stuff into a separate executable, no?
Click to expand...
Trivial? What does that mean? Separating the GUI and non-GUI stuff is standard operating procedure for writing cross-platform applications. You certainly don't want to entangle GUI and non-GUI components if your application is deployed across the Mac, Windows, and various flavors of UNIX and Linux.
 
So ho does XP64 work then? is it 64bit GUI?

To me, tiger and the G5 being 64bit is useless is companies have to completely change the way their software works to take advantage of it.

Having a programs GUI run is 32bit and its code run in the background in 64bit sounds like a bottleneck to me. Why cant the GUI be 64bit aswell? and are there any operating systems GUI 64bit? - Irix? Linux 64? if so, why cant OSX be done this way too?
 
MisterMe said:
Trivial? What does that mean? Separating the GUI and non-GUI stuff is standard operating procedure for writing cross-platform applications. You certainly don't want to entangle GUI and non-GUI components if your application is deployed across the Mac, Windows, and various flavors of UNIX and Linux.
Click to expand...

You'd be surprised at how many applications are written :).
 
Elliotjnewman said:
Having a programs GUI run is 32bit and its code run in the background in 64bit sounds like a bottleneck to me. Why cant the GUI be 64bit aswell? and are there any operating systems GUI 64bit? - Irix? Linux 64? if so, why cant OSX be done this way too?
Click to expand...

In Linux and Windows, everything is 64 bit. The question you need to ask yourself, is will a 64 bit GUI bring you any advantage over a 32 bit GUI? A 64 bit GUI will take more memory, but it will not give you any visible advantages.
 
Viro said:
The question you need to ask yourself, is will a 64 bit GUI bring you any advantage over a 32 bit GUI? A 64 bit GUI will take more memory, but it will not give you any visible advantages.
Click to expand...

Ooh Ooh I know because you want it to run slower too!

Sorry, I could not resist.

P.S. for those who don't know a program that only needs 32bits will run sower in 64 bit mode because basically every operation carries an extra 32 bits of zeros around.

P.P.S. This does not hold with AMD64 because they added registers to the 64 bit mode fixing the x86's traditional register starvation woes. PPC wasn't broken in that way so it doesn't see those gains.
 
ksv said:
The lack of 64 bit support for Mac OS X is due to Maxon's laziness and profit-driven business model. Their Windows customer base is obviously large enough for them to justify a 64 bit conversion, while their Mac user base is seemingly not.
Click to expand...
That's complete and utter FUD.

And to everyone else wondering why not just do as Apple says, have the back-end processing run in a seperate non-GUI app: it's called IPC. Inter Process Communication.

This is not even about "seperating GUI and non-GUI code." With an IPC software model, you'd have to develop a protocol for the 2 processes to communicate with each other. The overhead will defeat any benefit of 64-bitness.
 
Lycander said:
That's complete and utter FUD.
...

This is not even about "seperating GUI and non-GUI code." With an IPC software model, you'd have to develop a protocol for the 2 processes to communicate with each other. The overhead will defeat any benefit of 64-bitness.
Click to expand...
Talk about FUD! It is bad programming practice to entangle your GUI with your computational engine. The Mac develop model since 1984 and the NeXT model which followed naturally separates the two. Unless it is the most God-awful piece of programming you ever saw, an application's GUI requires very few clock cycles compared to its non-GUI computation engine. Apple's recommendations to commercial 64-bit application developers are the exact same recommendations it makes to scientists and engineers who want to do high-performance computing on Apple hardware. To these scientists and engineers, performance isn't everything; it's the only thing. With its 32-bit/64-bit hybrid model, Apple provides it.
 
Just a note on the IPC costs, they really can be negligible. This is done through shared memory so nothing is transfered over IPC beyond some synchronization events. At a low level this is equivalent to the communication between AppKit and the Window Server.

If you want a parallel think about X11 and sending all the GUI traffic over a network pipe. That can be a burden so when possible shared memory is used via the MIT_SHM extension. That makes things infinitely faster (for finite values of infinity).

There is no technical problem with this sort of an architecture that would limit the performance of the GUI. Now there may be a "we have GUI spaghetti code infecting our whole app and no way to deal with it" syndrome but that is more of a personal problem than a technical one.
 
MisterMe said:
... an application's GUI requires very few clock cycles compared to its non-GUI computation engine. Apple's recommendations to commercial 64-bit application developers are the exact same recommendations it makes to scientists and engineers who want to do high-performance computing on Apple hardware.
Click to expand...
Cinema 4D is not like those scientific applications. It's a digital content creation app that's driven by the GUI, first and foremost. Although the GUI requires fewer clock cycles, latency does play a role in "perceived" performance.

It's the same problem faced with multi threaded programs. Put your GUI code on one thread, then your back-end processing code on a seperate thread. The upshot is the GUI responds to user input much smoother. The down side is the actually feed back might not be in sync with the user's input. Now, rather than a seperate thread you're saying a seperate process. Even if latency for IPC is negligible, it's still a "hack" solution for the interim before a fully 64-bit OSX comes out.
 
ok, ok. so does XP64 exist in "fully 64bit"? or does it too have to rely on a 32bit gui?

I mean, the only thing I can think of that programs like cinema 4D can take advantage of with OSX's 64bit is with command line rendering. If the gui becomes slower to work with because effectively the program is split into to, then this will be a degrade since these apps rely heavily on fast gui performance.
 
You must log in or register to reply here.
Back
Top