No 64bit iTunes in Snow


Recommended Posts

I read this in an article in the September issue of Mac Life, I believe, then after quick googling I read the entire iLife Suite will not be 64bit. My question is why?! Why, especially with iMovie, though not near as sophisticated etc, but iTunes, with large libraries of files and other features of the iLife suite that would benefit, in my opinion from becoming 64bit. This is just surprising to me since they are converting MANY of the included applications to 64bit.

Link to comment
Share on other sites

iTunes isn't part of iLife anymore. iTunes is written in Carbon, which is why it isn't in 64-bit, but the rest of the iLife apps...I'm not sure. iMovie '08 was a rewrite so that should be Cocoa and quicker to get running in 64-bit, iDVD is dying, and I don't see any reason to believe iPhoto and GarageBand are Carbon.

Link to comment
Share on other sites

But would they not want iTunes (now separate) and iLife to be rewritten, just to keep with their move to 64 bit? It couldnt take THAT long to do. They know the general outline and have been working with those programs for a long time. There might not be as much a performance boost, seeing as they are rather simple apps and mostly user-input oriented rather then needing mass computing power such as a 3d rendering program, but still think it would be nice. But I guess its what we get for $29 upgrade.

Link to comment
Share on other sites

iTunes and iLife are updated independently of Mac OS X. Apple has quite a lot to port over, and if I had to guess I'd say they're prioritising their Pro apps (Final Cut, Logic etc...) as they're much larger and the users are more likely to need 64-bit.

Link to comment
Share on other sites

Why, especially with iMovie, though not near as sophisticated etc, but iTunes, with large libraries of files and other features of the iLife suite that would benefit, in my opinion from becoming 64bit.

Given the way memmaping files work you'd need an astronomical library for there to be a gain in performance by going 64-bit based exclusively on the number of files in your library. A typical song is about 1.5k in the least efficient version of the iTunes library. To hit a 4 gigabyte library you'd have to have a library of about 2.7 million items. When you look at the binary representations of the same data you'd need more songs than exist in the iTunes Store to see a benefit.

Every couple of months people say that "64-bit (or Cocoa) iTunes will be so much better" with these nebulous claims that the technology used is playing a significant role in how well a program works. Eventually iTunes will be updated and it might even be faster/better than the current version but that won't be simply because they've used a different framework or compiled with different flags.

But would they not want iTunes (now separate) and iLife to be rewritten, just to keep with their move to 64 bit?

Maybe they do, but what makes more sense:

  • Rushing out an update to a product for an OS where there's no perceptible difference for an end user
  • Working on features, improving performance, fixing bugs, etc. on a platform that already works well enough.

Keep in mind that because iTunes is the front end to the iPod, Apple's backward-compatibility requirements stretch much further than they do with Mac OS X. Maintaining cross-platform compatibility is also an important goal.

IMO, in terms of "things that should be re-written to suck less" - the Windows version of iTunes trumps the Mac version and it makes much more business sense for them to focus attention there first.

It couldnt take THAT long to do. They know the general outline and have been working with those programs for a long time.

Programming is hard. The details and testing matter and you lose all of the work you spend on those things when you re-write.

For a business-critical application like iTunes I wouldn't expect a full re-write to take less than 8 months with a dedicated team. If they plan to have their front end to coincide with back-end changes to the app store/music store then it could substantially longer.

The only people that ever say "That's easy" or "it can't take that long" have never had to write code that matters.

but still think it would be nice. But I guess its what we get for $29 upgrade.

iTunes is free, but if it wasn't: end users don't pay for code clean-ups, they pay for features.

You'd be hard pressed to find a feature that somebody would care about just by re-implementing iTunes in Cocoa even by Apple's "has new wallpaper = feature" standards.

iMovie '08 was a rewrite so that should be Cocoa and quicker to get running in 64-bit, iDVD is dying, and I don't see any reason to believe iPhoto and GarageBand are Carbon.

otool -l shows iPhoto still imports carbon.framework. I've not got the time to figure out how much of it is using cocoa over carbon. I have last years version of iDVD at work - it's showing a whole pile of old frameworks including carbon.

Edited by evn.
Link to comment
Share on other sites

The only things in iTunes that would benefit from 64bit would be the audio encoding, nothing else is stressing the system (filling rectangles, reading in a file, that's all very simple)

...

Every couple of months people say that "64-bit (or Cocoa) iTunes will be so much better" with these nebulous claims that the technology used is playing a significant role in how well a program works. Eventually iTunes will be updated and it might even be faster/better than the current version but that won't be simply because they've used a different framework or compiled with different flags.

...

People seem to think Cocoa is this magical thing that makes programs run better and look better.

As an example, Firefox, people keep saying it's so "un-mac like" and would run better if it used Cocoa. But it does use Cocoa, of course it also uses Carbon because Cocoa isn't the end all and be all, some things require Carbon to be done (Firefox still uses some Carbon API calls on 10.4 because Cocoa versions were only added in Leopard)

Link to comment
Share on other sites

There's been rumors that Apple has been looking to completely rewrite iTunes. At which point, I'd expect them to make the jump to 64-bit iTunes. I don't expect that will happen for a few more years.

As evn said, Apple would have to do something to address the backwards compatibility issues, PowerPC systems, old iPods, and so on. Sure, they can say iTunes XX will be the last version to support "classic" iPods. I wouldn't expect to see that happen with iTunes 9... 10 maybe, but unlikely.

Snow Leopard is only the start of the push towards the 64-bit Mac world. They've provided the foundation, now the app developers can catch up. Heck, some developers still haven't updated their apps from PowerPC.

A typical song is about 1.5k in the least efficient version of the iTunes library. To hit a 4 gigabyte library you'd have to have a library of about 2.7 million items. When you look at the binary representations of the same data you'd need more songs than exist in the iTunes Store to see a benefit.

Sure, if you look only at music. But if you factor in movies, TV shows, podcasts, apps, audiobooks, pdfs, HD content, iTunes+ music files and other things available to iTunes it takes far less items.

I have a library with less than 10,000 items, however size wise it is over 100 GB.

Link to comment
Share on other sites

I assume evn means the actual database, each song/video/picture in the library is stored on disk and handled separately.

My mother's library with 150 albums in it is only 131KB on disk.

Link to comment
Share on other sites

The only things in iTunes that would benefit from 64bit would be the audio encoding, nothing else is stressing the system (filling rectangles, reading in a file, that's all very simple)

People seem to think Cocoa is this magical thing that makes programs run better and look better.

As an example, Firefox, people keep saying it's so "un-mac like" and would run better if it used Cocoa. But it does use Cocoa, of course it also uses Carbon because Cocoa isn't the end all and be all, some things require Carbon to be done (Firefox still uses some Carbon API calls on 10.4 because Cocoa versions were only added in Leopard)

Cocoa does not magically turn your applications into good applications... that's true if you're a low-end programmer on the Mac and don't care at all about optimization and you're not aware of all the APIs that exist.

If you actually do care and you're optimizing your stuff, and you add these easy-to-add animations, yes it will magically turn your applications into good ones.

I hate Firefox on the Mac because in fact I was the 1st one to wonder if it was Cocoa or Carbon, but people keep saying it's Cocoa so I will believe them, even if I don't know how to verify this myself. But come on, the programmers did a really bad job for Firefox. They didn't really care.

--

Now, a 64-bit iTunes in Cocoa is inevitable, but when will it happen? I really HOPE it's going to be iTunes 9 in September, because even if I'm on a Mac, at the moment I can confirm that iTunes is one of the applications that's not optimized. Some things take a lot of time when it really shouldn't be. This sluggishness might just go away when the programmers at Apple (who DO care) do their job to convert it.

Link to comment
Share on other sites

I assume evn means the actual database, each song/video/picture in the library is stored on disk and handled separately.

Correct.

Sure, if you look only at music. But if you factor in movies, TV shows, podcasts, apps, audiobooks, pdfs, HD content, iTunes+ music files and other things available to iTunes it takes far less items.

I have a library with less than 10,000 items, however size wise it is over 100 GB.

My library at work contains just a few short of 30,000 songs - the iTunes library is 46.1mb as XML and the binary version is 8.5 MB.

Itunes stores URIs for media in the file and loads them on demand. There's not going to be a performance gain on files that small that are represented as NSXML trees. The library points to about 400gb of data stored on disk which is loaded on demand.

See for yourself by watching disk activity for the itunes process using instruments.

Cocoa does not magically turn your applications into good applications... that's true if you're a low-end programmer on the Mac
Your own argument is "If you wrote some extra stuff then the program would be better" - sure, I'll accept that.

But then it's not a question of Cocoa vs Carbon it's a matter of "program x with features a,b,c" and "program x with a,b,c,d and e". It's not the API that matters but the code people wrote.

If you actually do care and you're optimizing your stuff, and you add these easy-to-add animations, yes it will magically turn your applications into good ones.

Bolting on animation is not optimization. Would firefox be a better program if they bolted on some animation?

How much animation do I need to add to QuarkXpress before it becomes a good application?

Link to comment
Share on other sites

That's just iTunes with 64-bit Windows drivers.

Ah well. It doesn't make a difference to me in the least bit since I use Mediamonkey and don't really have any problem accessing all my 7000+ songs in a few seconds.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.