When do you think iTunes, Front Row, Grapher, DVD Player...will become 64-bit

[celticpride678]

I admit, I was a bit surprised when not all Apple applications made the transition to 64-bit.

When do you think iTunes, Front Row, Grapher, DVD Player, iWork and iLife will become 64-bit.

My guess for iTunes is iTunes X (Saving up for a huge release), iWork and iLife will become 64-bit when the '10 versions get released. For Front Row, Grapher and DVD Player, I suspect somewhere around 10.6.4/.5

What are your thoughts? Why do you think Apple did not make these applications 64-bit from the start? Post your thoughts!

 

[iMacmatician]

Grapher I don't think they care much about the app given all the bugs in it.

 

[celticpride678]

Grapher I don't think they care much about the app given all the bugs in it.

I feel the same way. Eventually it will just be removed from the applications that come with the Mac. I have not heard of it until 2 weeks ago.

 

[Anonymous Freak]

Most of the apps have no compelling reason to become 64-bit. In the case of iTunes, which is (still) a Carbon app, it *CAN'T* become 64-bit until/unless they recompile it as Cocoa.

On Intel, compiling as 64-bit can generate a slight (up to 15%) performance boost; but only for certain tasks. For most tasks, there is no benefit at all from compiling as 64-bit.

On PowerPC, there is *ZERO* benefit to compiling as 64-bit, other than the inherent 64-bitness. Some apps can take advantage of the "inherent 64-bitness", such as high-end Math applications (where running in 64-bit mode allows for higher accuracy or similar,) and applications that can access more than 4 GB of data at once (large database apps, Photoshop, etc.)

But for the majority of apps, those two reasons don't apply. There is no compelling reason for Pages to need to access more than 4 GB of RAM; or process data in 64-bit chunks. So on PPC, compiling as 64-bit when it's not necessary just slows down an app (as all of a sudden, EVERY transfer of data to the CPU has to send twice as much data.) On Intel, the improved instruction set available in 64-bit mode offsets that 'extra data' crunch, but only just. Without doing something that really *NEEDS* the 64-bit extensions, it's going to be a wash.

 

[devburke]

When the cows come home.

…not really, I just wanted to say that.

 

[Catfish_Man]

On Intel, compiling as 64-bit can generate a slight (up to 15%) performance boost; but only for certain tasks. For most tasks, there is no benefit at all from compiling as 64-bit.

While this is true on non-Mac platforms, there are additional complications on OSX. I can elaborate if you're curious, but basically it ends up being somewhat more worthwhile (which is why I went to all the trouble of working on making Adium 64 bit clean).

 

[jaw04005]

Oddly enough, Front Row was recompiled in 64-bit despite Apple’s claims.

Office-Mac:~ user$ cd /Applications/Front\ Row.app/Contents/MacOS/
Office-Mac:MacOS user$ file Front\ Row
Front Row: Mach-O universal binary with 3 architectures
Front Row (for architecture x86_64): Mach-O 64-bit executable x86_64
Front Row (for architecture i386): Mach-O executable i386
Front Row (for architecture ppc7400): Mach-O executable ppc

 

[devburke]

Oddly enough, Front Row was recompiled in 64-bit despite Apple’s claims.

Office-Mac:~ user$ cd /Applications/Front\ Row.app/Contents/MacOS/
Office-Mac:MacOS user$ file Front\ Row
Front Row: Mach-O universal binary with 3 architectures
Front Row (for architecture x86_64): Mach-O 64-bit executable x86_64
Front Row (for architecture i386): Mach-O executable i386
Front Row (for architecture ppc7400): Mach-O executable ppc

My understanding is that the “Front Row” in the applications folder is really just a launcher for Front Row somewhere else in the system. For example, the one in Applications reports as version 1.1, but checking the version from within Front Row it says it’s 2.2.

Edit: Yep, actual Front Row resides in /System/Library/CoreServices

 

[jaw04005]

My understanding is that the “Front Row” in the applications folder is really just a launcher for Front Row somewhere else in the system. For example, the one in Applications reports as version 1.1, but checking the version from within Front Row it says it’s 2.2.

Edit: Yep, actual Front Row resides in /System/Library/CoreServices

Ahhh … makes sense. So they bothered to recompile the launcher? Hilarious.

 

[Cboss]

While this is true on non-Mac platforms, there are additional complications on OSX. I can elaborate if you're curious, but basically it ends up being somewhat more worthwhile (which is why I went to all the trouble of working on making Adium 64 bit clean).

Actually, I would be interested. If you don't mind.

 

[str1f3]

Most of the apps have no compelling reason to become 64-bit. In the case of iTunes, which is (still) a Carbon app, it *CAN'T* become 64-bit until/unless they recompile it as Cocoa.

On Intel, compiling as 64-bit can generate a slight (up to 15%) performance boost; but only for certain tasks. For most tasks, there is no benefit at all from compiling as 64-bit.

On PowerPC, there is *ZERO* benefit to compiling as 64-bit, other than the inherent 64-bitness. Some apps can take advantage of the "inherent 64-bitness", such as high-end Math applications (where running in 64-bit mode allows for higher accuracy or similar,) and applications that can access more than 4 GB of data at once (large database apps, Photoshop, etc.)

But for the majority of apps, those two reasons don't apply. There is no compelling reason for Pages to need to access more than 4 GB of RAM; or process data in 64-bit chunks. So on PPC, compiling as 64-bit when it's not necessary just slows down an app (as all of a sudden, EVERY transfer of data to the CPU has to send twice as much data.) On Intel, the improved instruction set available in 64-bit mode offsets that 'extra data' crunch, but only just. Without doing something that really *NEEDS* the 64-bit extensions, it's going to be a wash.

While many of what you said is true, I believe when 10.7 hits (probably a little less than two years away) the kernel will be 64bit only and ditch 32bit support. I believe this is the reason Apple has been pushing developers hard towards 64bit apps.

 

[Catfish_Man]

Actually, I would be interested. If you don't mind.

Sure. There's basically three additional factors beyond what applies on linux/windows that bring the gain for 64 bit Cocoa apps more towards the 10-20% range than the usual 0-15%*.

The first is the objective-c runtime. There's a new, backwards-incompatible version of it which is activated for 64 bit x86 apps (since there weren't any 64 bit x86 apps to be backwards compatible with). It has somewhat faster message sends (worth only maybe another couple % overall in speed, but still nice), C++ compatible exceptions, and avoids the fragile base class problem.

The second is shared framework footprint. If all the Cocoa apps (for example) currently running are 64 bit, then only one copy of Cocoa need be loaded in memory. Same if all of them are 32 bit. If they're mixed, though, you need two copies of Cocoa loaded. Not a big overhead, but it'd be nice to get rid of.

The third and most obscure is kernel/app address ranges. 32 bits gives you 2^32 (~4GB) of available address space.

Windows by default runs the kernel in 2GB of that, and the current app in the other 2GB. This means that switching from app to kernel doesn't require re-mapping addresses.

OSX, for various historical PPC-related reasons, gives apps the full 4GB of address space. This is nice in the sense that it lets apps use all available ram, but it means that each time a switch to/from the kernel is needed (for example, memory allocations larger than 128 bytes), the mapping from virtual addresses to physical memory locations needs to be reloaded with the kernel's address space ("TLB flush"). With 64 bit apps**, the system just says "ok, everything 2^32 and below is the kernel's, and the app gets everything above", avoiding this.


*numbers involving the % sign in this post have not been verified with any particular rigor at all. I've pretty much just watched the wwdc presentation that mentioned %s, and benchmarked AutoHyperlinks.

**running the kernel 64 bit gets an additional speedup for these system calls. I'm not entirely clear on what the mechanism for that is.