Prior to today’s Apple announcements, John Gruber wondered aloud on Daring Fireball:
What I’m interested in is more esoteric: is the Mac version [of iTunes] still a 32-bit Carbon app? Common sense says yes, but that’s because common sense says it’s never a good time for a low-level framework rewrite. But the writing is on the wall: the future is 64-bit, and the only path to 64-bit is Cocoa, so eventually, it has to happen.
Let me be really clear: I think Cocoa is great. I think 64-bit is great. (We’re embracing both with Photoshop.) But I’m really, genuinely curious: What specifically do people believe a transition to either is going to add to their software? In the case of iTunes, I have to ask:
- Do people really have performance problems* with iTunes as it is?
- I never have. It filters my 3,000-item library as fast as I can type, does a lovely job with HD video, and whips through album art in Cover Flow. I can’t recall others complaining, either.
- Do they want iTunes to use more than 4GB of RAM?
- I think we can safely say “No.”
- Do they complain about the UI (e.g. non-standard scrollbars) and think that Cocoa will make iTunes more “Mac-like”?
- Again, I haven’t heard complaints (or rather, only ridiculous ones).
So what, then? Let me put it another way: If you were directing the iTunes team’s efforts, why would you–as a customer–tell them to spend their time on Cocoa and/or 64-bit, at the expense of doing other things customers want?
I don’t know why I feel compelled to scratch this itch. See, a smarter, lazier, and/or more cynical product manager than I would simply kick back, shut up, and say, “Photoshop CS-X is 64-bit and based on Cocoa, so you should buy it!” If anyone dared ask how these facts might benefit her, I’d just loudly repeat, “But it’s COCOA! and 64-BIT! So that’s, like, AUTOMATICALLY AWESOME!”
For better or worse, that’s not how I roll. I want people to buy my (and our) work based on real value, not due to lack of information. I suppose I can take some weird solace in the fact that no matter what I say, many people will go on happily believing whatever they want.
So, out of honest curiosity I ask: If you’re pining for iTunes 64, why (specifically)?
*Not, of course, that 64-bit is any kind of panacea.
If you have 3000 songs, you’re right, you don’t notice any slowdown. When you have 15-20,000 songs, you do start to see an effect. Given that I’ve met people with 50,000 song libraries, you can see where I’m going in terms of seeing potential improvements.
Honestly, I wouldn’t expect to see any massive improvements by switching to 64 bit or Cocoa. For example, iTunes already does a pretty decent job of spinning off processes that would otherwise tie up the program, so even the new multithreading support in 10.6 wouldn’t necessarily add that much. I would, however, expect a number of smaller refinements that make use of some of the features that have been implemented solely in Cocoa. Also, as you pointed out, it’s going to happen sooner or later, so why not get it out of the way, so there are that many fewer features that need to be brought over?
[Actually, I didn’t say that it would happen sooner or later, though Gruber did. The change is inevitable only if you accept the idea that Apple will at some point stop allowing Carbon and/or 32-bit apps to run. I have no info about any such plans (and if I did, I’m sure I couldn’t share it). –J.]
I want 64-bit only because it’s not likely there’ll be an iTunes 10 for at least a year; and by that time I can imagine the memory problems I do have now (smart folders based on other smart folders with more than 10k items and iTunes touches 3GB) are only going to get worse. I can’t imagine a rewrite is going to come along in a 9.x update.
Also, why have a 64 bit version of System Preferences? Makes even less sense than a 64 bit iTunes.
All I can see is an automatic disadvantage, 64 bit apps tend to use more memory by default.
In the case of system preferences, on opening it uses 24.5MB of real memory in 64 bit mode, compared to 13.9MB in 32bit mode.
Well, we’ve discussed this before 🙂
There’s no need for 64 bit iTunes at the moment even with my 40,000 song library via a NAS. At some point there may be a benefit to have iTunes access more memory, perhaps with a 100,000 tune library (which one day I expect it will reach). But not yet.
That said, I’m running Windows and it needs additional layers to run both 32bit and 64bit apps (just as OS X does).
So why do I want 64 bit apps? So I can have an OS that doesn’t need to worry about running 32bit apps as well. That’s basically it. A leaner, meaner, cleaner OS as a result of only having to run native apps.
The opportunity cost has to be paid eventually, because eventually 32bit will be dropped. When we pay it is really the debate, not if.
There’s a cost to running in 64bit – nothing’s for free. But given that there are advantages and we seem to be soaking up all the extra memory being offered (not just on a per-app basis, but as a result of running so many different things simultaneously) then for mine, I’d pay it sooner rather than later and get it over and done with.
But I can live in 32bit – for now 🙂
Well, more importantly, what would drive the iTunes team to go from Carbon to Cocoa? The only thing that would force that transition is the abandonment of Carbon 64-bit support of the API’s used in iTunes. It’s the same thing that bit Photoshop squarely in the butt. I’d imagine the answer to “why 64-bit?” could be as simple as “because.”
i’m one of those people with 40,000 tracks in their itunes library. i can handle the slow-downs in the app, it’s what you get for running such a library on macbook pro. what pisses me off no end the 5 minutes it literally takes to start. (running 99% of one cpu core while it does it)
64-bit and cocoa don’t matter, fixing these performance issues one way or another do.
[Your last comment is spot on: If you have problems, bring them to developers’ attention and trust the devs to figure out how to fix them. *Don’t* browbeat the devs about technologies that may not have anything to do with the problems at hand. –J.]
Answers to your questions:
1. Yes I do have performance problems. But my situation is extreme. I have a huge library of LPs I’ve scanned. Almost 1T worth. Of course Cocoa might not help either. With large libraries the worst problem I have is trying to edit track names etc. It takes minutes sometimes for a simple edit.
2. No
3. No
My issues are all about performance. I don’t care if it’s carbon or cocoa, I just care about speed.
[Well said. –J.]
I agree that a 64-bit version of iTunes is not essential–at least not to the regular user. But I think the argument should actually be: why iTunes should dump Carbon for Cocoa. Apple has made it clear that it’s all Cocoa from here on out, so it’s only natural to wonder when one of their flagship applications will complete the transition too.
Your argument is essentially: if the users don’t see it, why bother making it better
[No, my argument is “Spend your time actually making things better, as opposed to rewriting just for buzzword-compliance.” If 64-bit and/or Cocoa make iTunes (or any other app) better, great! But don’t engage in a transition (at the expense of deferring other things) just to say you did it. –J.]
(and we all know Cocoa is better, if only because it’s the only framework Apple’s spending time improving). But that’s not how great developers think. And that’s certainly not what Apple believes–otherwise we wouldn’t have Snow Leopard.
Well they said they improved Mail a lot by going 64-bit in Snow Leopard. Maybe they can do the same tricks in iTunes.
In a way or another, both apps work with databases. Correct me if I’m wrong.
http://www.apple.com/macosx/refinements/enhancements-refinements.html#mail
Windows user here. 64bit Windows is the only way for me to have more than 3 gig of ram (8 in my case). And then, when i am running 64bit windows, i would like my applications to use full capacity of my OS / Hardware. So it is not like i am demanding 64bit software, it is just that due to using 64bit windows, i want other software to follow.
Oh ye, not to mention that some software does not run in it’s 32bit version under 64bit OS.
I need Cocoa-iTunes because whenever I connect my iPod toich to the Computer while iTunes is playing a video the video freezes.
[How will Cocoa help with that? (It won’t, but don’t let that stop you from insisting that it will.) –J.]
I mean, we live nearly in 2010 and we still have such applikations? what a shame.
Contrary to popular belief, having a 100k song library isn’t a particularly good reason for switching to 64bit.
If you’re lucky, you’ll see a few percentage points of performance gain by a plain 64bit port.
You’ll find that more can be done for performance by a number of fairly common tactics.
Offloading data access tasks to background threads makes the UI more responsive.
Parallelising data access tasks (such as searching) takes advantage of those additional cores you’ve all got.
Parallel searching against large datasets was solved decades ago.
Except in a very few rare cases – individual apps don’t need to be 64bit.
Apple writes here:
I don’t know if this applies to all 64bit apps though.
It wouldn’t be the reason for iTunes to 64bit, but at least one.
I have to totally agree with you here – updating apps to 64bit for the hell of it is a waste of time; time better spent on more productive things.
However, I’ve noticed a distinct aversion to 64bit from you in general (as is evident in your blog posts). You spend a great deal of time pointing out the flaws in having a 64bit app and I have to think that your time could be better spent too.
[I *just wrote* “I think 64-bit is great.” How is that an aversion? Or are you just hearing what you want to hear?
I just can’t bullshit people–cannot do it. And I can’t tell you that something is going to freshen your breath & make you a hit with the ladies when, in reality, it’s more limited than that. –J.]
I can understand that Photoshop has been manually tuned up for 32bit and simply changing it to 64bit isn’t going to gain a hell of a lot but there’s 1 large element of 64bit that we’re missing out on for Photoshop, After Affects and Premier and that’s the ability to use more than 4GB of RAM.
After purchasing my MacPro with oodles of RAM and the Master Collection from Adobe, I was very disappointed to discover this RAM usage limitation in, what I considered, to be the industry standard in their respective fields.
I can recall back to Apple’s switch to OS X from OS 9 where Adobe seemed to take great pleasure in pointing out to Apple who was the boss, Apple or Adobe, by dragging their heals in building a compatible Photoshop. I just hope that the same childish tactics don’t get repeated.
[I’m pointing out technical realities. Is that childish? –J.]
I think it’s not really about iTunes being Cocoa or 64-Bit. It’s about a rewrite. And talking about Cocoa and/or 64Bit implies that iTunes is rewritten.
[Converting the app to Cocoa doesn’t make it better. That effort is completely orthogonal from addressing the issues you raise. –J.]
So saying “I wish there would be a Cocoa-iTunes” is just other words for “Damn you, Apple, please rewrite iTunes from scratch”. This, of course, is just other words for “I wish iTunes would be really new and shiny and innovative and FAST”.
[You’re right. 99% of people don’t know a damn thing about how these apps are written. That’ll never stop them from telling app vendors exactly what to do. “Passion is inversely proportional to the amount of real information available.”
Yes, I DO have performance issues with iTunes, but NO, I don’t have that a big library. It’s about 5000 songs plus tons of podcast plus several videos. Not that much. And iTunes is slow, dead slow. Connecting an iPod causes a stall for severeal seconds. Copying tracks on the iPod causes stuttering in video (non HD) playback. Apart from that iTunes has grown a lot, and I think many hope that, if rewritten, there will be this fairy dust again to iTunes, that makes it a special application, one that feels “just right”. Yeah, right, this gets esoteric 😉
Thank you for this piece of common sense. It’s pretty rare these days.
You may extend your comment to the 64 bit Kernel too. They are a lots of people grumbling because they cannot boot on K64, but I didn’t found one if this person able to explain why ?
no matter what, I want 64bit iTunes and cocoa. So that it doesn’t have those shiny glossy title bar and ugly scrollbar.
[Sometimes I think I’m being punk’d with these comments… What on earth do these aesthetic decisions have to do with Cocoa or 64-bit? The answer, of course, is nothing. You’re aware that you didn’t used to have Marble-style scrollbars in iTunes, right? That Apple *added* them in (I believe) iTunes 8.0?
Your comments are inline with those I linked to above, where a guy SWORE up and down that Apple’s decision to *add* ALL CAPS section headers in Finder and iTunes was due to Carbon (ignoring the obvious fact that these apps had been shipping for years based on Carbon & without that type treatment). –J.]
I just want it to be unified and as fast as Safari and Mail. I ran my library from external drive and yes I had performance problem.
[Wanting your apps to be fast & stable, slick & solid is completely reasonable. Trying to prescribe a solution without understanding even the first level of detail isn’t. –J.]
Would a cocoa rewrite stop Fireworks taking up 10% of my processor ALL DAY even with no documents open?
[Rewriting might help, but Cocoa per se has nothing to do with it. And in any case it sounds like a bug that should be fixed regardless of framework decisions. –J.]
And would it stop your windows detaching from their content?
[I’m not sure what you mean by that. –J.]
If the answer to these is yes then a cocoa rewrite would be a big selling point to me
Well, not a coder, but it strikes me that a complete transition to 64bit is inevitable in the march forward. There may be no immediate benefits now, hell there may be no benefits in the future either, but not having to support 32bit applications I imagine is of benefit to the OS? But rewriting an application so that it’s ready for whatever gets thrown at it in the future might make sense? Why does photoshop support 64 billion gigabytes of scratch disk and PSB format support 4 billion gigabyte size?
Perhaps it’s also about it’s also about simplifying things. Write everything in cocoa, there will come a day that you no longer have to support carbon.
You just don’t want to be the last 32-bit app on the system. Because this is the app loading all the 32-bit frameworks stack.
We should have stayed in 16Bits then we could have avoided this 32 vs 64 mess.
[/sarcasm]
Craig, teams (engineers, product manager and QE’s) all want to make the best products they can. Period. That includes fastest, most modern, and most features. When it comes to business or ego, business usually wins. So any dragging of heals, is just the realities of making a huge technology shift (for no real user benefit, but lots of new costs/bugs/risks).
Any lag you see is just the reality colliding with marketing message. So marketing in one company can tell you it is easy to practically push button port and things will just work (for some 1,000 line demo shareware App). But the reality is that when you actually try to do it for ≈80M lines of code, coordinating dependencies among a few dozen teams and products, all at once, using the tools, support and API’s provided by the OS provider, that might not have had the needs of products of your scale in mind. When you’re in that reality, you find that a few years to product-shift requires a mammoth effort that can cost many cross platform software copanies about 4-8 times as much to support Macs as it does to maintain the Windows version of their products (and keep them up to date).
It took Apple from 1996 (Acquisition of NeXT) until March 2001 to come out with OS X. And a couple more versions to get good stability. That was what, 10M lines of code? Adobe is tasked with rewriting 8 times as much code, or Microsoft 3 times as much with Office, without the luxury of shpping with fewer features or breaking any of literally thousands of old and subtle behaviors that their customers rely on. So the failure isn’t in Adobe or Microsoft Herculean efforts, just in customer understanding of the relative problems that each side faced.
I just hope if they do do a rewrite in a different language it will give them the chance to fix architecture flaws that may have been too much work to fix in the past. I know I have done this in my own job while switching languages or frameworks.
Personally I find iTunes really slow with 40,000 + songs. But what I’d really like is some easy way for me to have all my songs on a NAS and have iTunes on my PC and my laptop and my macbook etc… Why should I have to have a copy of the songs in each place?
I want a Hasselblad because a Hasselblad takes sharper pictures. And yes, I am replying to the 64 bit post!
Future proofing the application. What about the users that convert videos to iPod/iPhone formats a lot? What about the day when iTunes could be able to convert dvd’s? How is going to be the performance if you are playing music, and 2 users are streaming from your library and other 2 are copying stuff from there too? and so on…
As a developer I can tell you that the number of lines of code does not necessarily mean the system/application is better than the other. Architecture, elegance and design patterns are what makes systems future proof, easier to maintain and grow and faster…
I don’t think it is so much that it will add anything to the speed, stability or any thing else of the program.
I think people want 64-bit versions of their applications because if you are investing in a system that can run a 64-bit OS and has lots of memory they last thing you really want to do is not truly upgrade your apps.
[So, even if 64-bit “won’t add speed, stability, or anything else,” not having it means not being “truly upgraded”? What?? –J.]
I have to say for myself it kind of miffs me when I see applications being installed in Windows 7 in to the 32-bit folder.
This is even knowing that most applications are not going to benefit from being 64-bit. It doesn’t matter. 64-bit is where it is going and all applications need to be 64-bit.
Those companies that don’t embrace it as consumers do are destined to get nagged and hagged about it until they do.
[Out of ignorance? That sucks. –J.]
Robert
There’s the engineering view, and the business view.
A good design pattern doesn’t make for a good Application. There are many well written, but completely useless Apps out there. Engineers and academics that get to caught up in the how, usually lose fact of the why. It’s like the difference between OOD and procedural code. The zealots will tell you Object-Oriented-Design cures all evils, and just makes code better. The experienced engineers will tell you it is one tool among many to get the job done. Better for some things, worse for others, and most of it just falls back to the implementation (or the users of the tools, rather than the tool itself).
Which brings us full circle. If you have a working and stable Application, what is the motivation to rewrite it into a less stable, less rich and less mature codebase, thus destabilizing your product (by introducing bugs and omitting features)? From a business point of view, very little. Sometimes you just have to. But the point is that going from something like mature Carbon to Cocoa, or from 32 to 64 bit, or from QuickTime to QuickTimeX, or moving from CodeWarrior to XCode, etc., doesn’t by you anything by itself — and in fact costs you in quality, time and features during the transition.
Someday the refactoring should pay off, and you may not have a choice. But the change for changes sake adds no value in and of itself. It’s what you do with the opportunity that matters. But in business everything is about opportunity costs. And the time you take doing such ports takes away from time/energy you could have spend making useful features or improving quality in other areas. I with the rules of math and business didn’t apply, but every change comes with risks/costs.
Echoing the large library complaint, especially w/r/t startup time, 22,000 songs and 123 GB (5 short films and nothing else). This is on a brand new, top-of-the-line 24″ iMac (3.06GHz, 4GB Ram).
If there were a compelling alternative, I’d try it in an instant – but everything I’ve tried ends up either slower (database issues) or relying on iTunes database. Sound fidelity on iTunes also isn’t the greatest (but a rough point to argue whilst listening to high-VBR mp3s). No other program has a tight integration with the iPod (my preferred player) & its siblings – so we’re stuck with iTunes.
We want the underlying frameworks to be 64-bit sooner rather than later, so the bits in the box can be pushed more efficiently. And is too much to wish that Apple could leverage Grand Central in a 64-bit Cocoa iTunes as a demonstration of its power?
There is no such thing as future proofing an application. To do so, would assume the future is not going to change further.
And yes, consumers will nag when you don’t use all the latest terms that they barely understand. On the other hand, they’ll nag about features you don’t have, because you spent all that time and resourcing adding those things (and the cost of stability and features elsewhere). So I think the lesson is that consumers need to try to understand the tradeoffs being made.
We sometimes use the $100 question. Here’s $100, and here’s a list of features/technologies. Now you decide how much money you want to put in each area. (That will dictate the time it takes to get something cool that offers little/no value to customer, versus the features that they want). It is amazing seeing attitudes shift when they have to pay for the tradeoffs or make the decisions.
John, maybe the reason isn’t iTunes itself but a (necessary) 64bit Quicktime framework, that would be better integrated with a 64bit iTunes?
Martin
64bit iTunes because it is in dire need of a rewrite; because it is one of the few remaining standard (non-Pro) Apple apps that is still 32-bit.
[But WHY DO YOU CARE?? Seriously, did I start speaking Dog or something? When I say, “Please tell me *specifically* why/how 64-bit will make this app better,” a legitimate answer isn’t “It Just Will.” –J.]
Here’s my concern: Is it possible that at some point Apple could completely drop 32-bit support? If so, then I want the apps I use to be 64-bit as soon as possible. That’s basically the extent of my concern over bits.
Meanwhile, give me a cocoa iTunes. I’m sick to death of iTunes having glitchy window-resizing and half-assed respect for the dock.
I agree the change for change’s sake is totally pointless!
But lets look at the background of Apple’s new 64bit OS and the Cocoa language…
[Cocoa isn’t a language. –J.]
It’s been WELL documented many years ago that the future of the Apple platform is going to be Cocoa; This is NOT A SURPRISE and Adobe had since around CS2 (or earlier – I can’t remember the specific time but it was CS2 at least) to move down the cocoa and 64bit path but it WAS a surprise for the users that Adobe seemed to have made no movement towards it at the time of CS3.
And here we are at CS4 and Adobe seem to be trying to convince everyone that Cocoa and 64bit apps isn’t a good thing and that’s why they’ve not done it yet.
[It’s amazing that in response to my saying, “I think Cocoa is great. I think 64-bit is great,” you say that Adobe is “trying to convince everyone that Cocoa and 64bit apps isn’t a good thing.” Actually, it isn’t amazing. I should just accept that people will say and hear whatever they want, regardless of any and all evidence to the contrary–including evidence on the same page that you’re currently reading. –J.]
I’m sure that all the Photoshop code is as efficient as it can be and it will not make much speed difference to run it on 64bit, but I have to say that having the ability to use more than 4GB of RAM would improve any large file for Photoshop, After Effects and Premier for me.
[Did you know that you can dedicate 32GB of RAM to After Effects and/or Premiere Pro CS4 on your Mac? –J.]
Even entry level laptops are supplied with 4GB of RAM so it’s shocking that Adobe still has this restriction on it’s PRO apps who need as much RAM as possible!
[What’s shocking is how little people know. –J.]
iTunes *is* significantly more resource hungry than many other music managers. Now John is arguing that per se, 64bit may not help, and has been heaping doubt on the benefits of 64bit which is fair enough.
But then we have many good examples of an enhancement; i.e. that the Finder was rewritten to be cocoa and 64bit, and *has* greatly benefitted — this is not an app that requires huge memory address space, and was probably an optimised 32bit carbon app already. So a fair conclusion is that the rewrite to modern Cocoa (which includes the 64bit transition) technologies will benefit iTunes immediately.
As an amazing performance aside, diglloyd’s Snow Leopard performance summary is spectacular: http://macperformanceguide.com/SnowLeopard-Performance.html — even with 32bit apps the 64bit kernel makes clear performance improvements. That is probably due to the transfer lookaside buffer (TLB) problems with 32bit apps on OS X.
Out of interest, why do you think that the combined benefit of TLB improvements, 64bit registers, the advantage of memory randomisation for security are not worth it??? You have argued that 64bit registers don’t benefit PS, but what about for less optimised code?
@So a fair conclusion is that the rewrite to modern Cocoa (which includes the 64bit transition) technologies will benefit iTunes immediately”.
Why that would be a fair conclusion? How do you know that it’s just the rewrite part rather than Cocoa or 64 bit what makes the Finder faster? Or some other known optimization technologies, like multithreading, sorry, I mean revolutionary optimization technologies like Grand Central Dispatch?
If iTunes is only 64-bit, it won’t run on any devices built with Intel’s Atom processor, which is 32-bit. A lot of devices are being made with the Atom because of its low power usage.
If Apple were to make iTunes 64-bit only, and then release a Macbook Helium ( lighter than Air ) that used the Atom, then they couldn’t ship iTunes with it – it wouldn’t run.
64-bit isn’t the only path forward as some posts here claim.
I don’t think there are any ARM chips that are 64-bit, and there are more and more devices using ARM chips. Some people posting here may have a device with a 32-bit ARM chip, it’s called an iPhone.
Does an iPhone need to be 64-bit just to be ” better ? ”
I don’t know about mac, but on windows even with 50 songs iTunes is just a pig and is so slow even with 64 bit.
But I think all software should be embracing 64 bit anyway, it is where we are at, and by the time they accept that we will be at 128 bit and start the cycle all over again.
[You want all software to spend time moving to 64-bit (as opposed to doing other work you’ve requested), but you cite any concrete, practical reason why? That’s a recurring theme, to say the least. –J.]
My two bits: I want the software to be as efficient and stable as possible on the current OS. How the software is made to do that, and any concerns over future compatibility or portability, is best determined by the developers.
[Cocoa isn’t a language. –J.]
…Sorry – wrong terminology
[This isn’t a small matter, and it does suggest that you don’t have a meaningful familiarity with the technologies being discussed. (It’s not your job to have such a familiarity, by the way, and I’m not asking that you take on that burden. I’m am asking that if people don’t know the details, they refrain from telling us how to do our jobs.) –J.]
[It’s amazing that in response to my saying, “I think Cocoa is great. I think 64-bit is great,” you say that Adobe is “trying to convince everyone that Cocoa and 64bit apps isn’t a good thing.” Actually, it isn’t amazing. I should just accept that people will say and hear whatever they want, regardless of any and all evidence to the contrary–including evidence on the same page that you’re currently reading. –J.]
…Yes, you did say that above yet your most recent blog posts have been a teaching exercise in why 64bit doesn’t mean better
[Where did I say that it didn’t mean better? I’ve said repeatedly that under the right circumstances, 64-bit can make Photoshop 10 times faster. But I’ve tried to set expectations very carefully about what those circumstances are. I think that’s the right thing to do for customers, even if they find it difficult to accept. (As I noted, it would be far easier for me to sit back and let people enjoy their ignorance.) –J.]
and that’s why there’s no 64bit Photoshop yet etc.
[A. There is a 64-bit Photoshop shipping now–has been for nearly a year–but it’s not on Mac. B. It’s absence on Mac has nothing to do with our lack of belief in the importance of 64-bit. It’s simply a matter of Apple having killed Carbon 64. (It’s the same reason the new Final Cut Pro is 32-bit-only as well.) –J.]
You may not have specifically said ‘I hate 64bit’ but the feel of your recent posts on the subject now that Apple has released Snow Leopard have been pretty negative – possibly in response to people continually asking why Photoshop isn’t 64bit yet. In general, I would agree and I’m 100% behind you on the subject of iTunes …but then our ideals differ beyond that.
[I should just accept that people will say and hear whatever they want, regardless of any and all evidence to the contrary–including evidence on the same page that you’re currently reading. –J.]
…So where’s the evidence that Adobe HAS been moving towards 64bit?
[How about the fact that Adobe has sold more 64-bit Mac software (OS-included utilities aside) than any other vendor? How about a little credit for bringing 64-bit pro software–Lightroom 2.0–to the Mac *far* in advance (12+ months) of Apple shipping a single 64-bit pro app? –J.]
Why hasn’t Adobe been ‘proactive’ in moving to 64bit then? Because all I’m hearing is ‘would you like us to make more features in Photoshop or would you prefer that we spend {waste} our time converting the app to 64bit?’
[Where are you hearing that? Specifically? (Ah, right–I never said it.) I *have* said that there are lots of ways to skin the performance cat–spending time on multi-core optimizations, making better use of the GPU, etc. 64-bit is one arrow in the quiver, with specific costs and benefits. I want people to think more clearly about what they need instead of just mindlessly jumping on a bandwagon. –J.]
[Did you know that you can dedicate 32GB of RAM to After Effects and/or Premiere Pro CS4 on your Mac? –J.]
…no I didn’t so thanks for that.
[What’s shocking is how little people know. –J.]
…so does Photoshop not need a lot of RAM in your opinion then? At what version did Photoshop cease to ‘need as much RAM as humanly possible’?
[At this point I’m not sure what you’re talking about. I’d like you to spend a little time reading what I’ve written instead of putting words in my mouth.
I’ve said quite clearly that some people use large images that require a lot of RAM, and those are the people who’ll see a large speedup from 64-bit mode. I’ve also said quite clearly that for the large majority of people who don’t need or want to assign more than 4GB of RAM to PS, the gains to be had from 64-bit mode are much smaller (on the order of an 8-12% speedup–welcome, but hardly revolutionary).
I’m afraid it doesn’t really matter whether you like hearing this news. It’s the truth, and that’s what I feel our customers deserve. –J.]
—-
By the way I liked your quick U-Turn you did after informing everyone that Adobe doesn’t test older versions of it’s software with newer OSs so you’ve not even tried Photoshop CS3 – but then after criticism, it turns out that Adobe’s done ‘extensive’ testing and has worked closely with Apple to iron out anything that crept up.
[The company as a whole could have handled communications on this point much better. The Photoshop team had indeed tested CS3 on Snow Leopard & had indeed filed numerous bugs against the OS (which Apple then addressed, as I reported). The Creative Suite FAQ was written more generally, covering a dozen apps, so it took a lowest-common-denominator approach (i.e. if not all apps were tested as much as PS was, then we can’t say the Suite was tested). In the wake of customer feedback, other teams did go back and perform more testing, and they’ve been posting updated technotes documenting whatever issues they find. So, I’m not sure whether you’re being sarcastic, or whether you actually do like that A) Photoshop was tested, and B) other teams heeded customer requests. –J.]
Is this to point where you’re about to unmask a 64bit Photoshop?
I have not been begging for Cocoa or 64-bit (in iTunes or Photoshop), but I’m delighted by Snow Leopard’s Finder, which was updated to those two technologies without any headline feature changes, and has gained quite a bit of performance and stability in the process. Are those gains _because_ it’s a 64-bit Cocoa app, or because making it a 64-bit Cocoa app prompted the team to do a lot of code review and general fixing, or because the team did a lot of code review and general fixing at the same time with no relation to making the app 64-bit and Cocoa? I know it’s not #1, but since Apple (like Adobe) is a proprietary and fairly opaque company, I have no clue how much is #2 and how much is #3.
On my work machine running Leopard (Mac Pro 4×3.0, 9 GB RAM, OCZ Vertex SSD), there were three apps that tended regularly to hang, unresponsive, for seconds at a time without progress indicators or any other indication of what they’re doing: Finder, iTunes and Creative Suite. It’s this behavior that makes these apps seem outdated, crufty, bloated; pick your insult of choice.
Finder doesn’t do this any more in Snow Leopard; it may take a while to populate a window with lots of files over the network, but it doesn’t beachball or make other windows unresponsive. So it’s down to iTunes and Creative Suite. When everything on the system is 64-bit and Cocoa except the two apps that are grumpy, it’s easy to connect the dots to their 32-bit Carbon status, whether it’s true or not.
In summary, I think the desire for a 64-bit Cocoa iTunes (and likewise, a 64-bit Cocoa Photoshop) is a stand-in for anxiety about performance and certain aspects of the app’s behavior that seem out of place (iTunes 8’s odd Zoom button, nonstandard scrollbars; Photoshop’s weird palettes, Spaces problems, and all the interface bugs in CS4).
I expect some of the 64-bit whining to die down with iTunes 9, because it’s _dramatically_ faster and fixes some odd behaviors. My fervent hope is that Photoshop CS5 is also dramatically faster and a better Mac citizen. I think that’s what most of the people asking for a 64-bit Cocoa rewrite really want, too.
As an end-user, i have NO idea what overall benefits may be gained by migrating an application to the cocoa framework and extending to 64 bits.
As a developer, YOU have to determine if there is benefit in the long run in your ability to continue delivering quality products, in a timely manner, that meet your financial goals.
Why would you, as a developer, ask something of an end-user, to which we do not know the answer to?
What would you get now? Not a lot.
But Apple has made it very clear that any new improvements in UI, Core Animation, QuickTime, or any new widget-whatsits like CoverFlow, are all going to be done in Cocoa, not Carbon.
As such, an iTunes Cocoa rewrite isn’t going to be needed so much for 64-bit as it is to take advantage of forthcoming features and changes in the OS X code base.
Changes that you’d expect a flagship product (ahem) to have as a matter of course.
Lots of good comments.
Yes, I have performance issues. No, I don’t think the 64-bit transition itself is the cure. Yes, I think their could be interface improvements. No, I don’t think the 64-bit transition itself is the cure.
And I don’t think Apple should view it that way, nor do they. 64-bit can improve some things, and Apple almost has complete, good libraries for everything they need in both 32-bit and 64-bit. They have a 32-bit kernel running nearly complete 64-bit libraries and 32-bit libraries that are complete but showing some age. Where 32-bit is more effective (and/or provides compatibility over 64-bit, in some cases), use it. When 64-bit is more effective (and/or provides a compatible path towards better code), use it.
Parts of iTunes need performance and interface improvements whether it be 32-bit or 64-bit. It seems to teeter-totter between performing extremely well or sluggishly (during use at various intervals or with specific features/tasks) and through its various upgrades)… between having an ideal, simple interface and a busy one.
It would be nice if Apple could get iTunes moving forward in almost all respects… like it seems to be doing with many of their other apps. I’m not sure how you fix it. I have some ideas and am sure their are ways I haven’t thought of or seen in other apps. A complete rewrite isn’t necessarily the way, but…
But Apple does seem to want to get everyone to the full 64-bit API as soon as possible…
…and the work with Finder seems impressive. (There are some bugs, but that is true of the old Carbon Finder.) That indicates Apple’s potential capability to address the massiveness that is iTunes. They rebuilt Finder completely and mostly from scratch. Even if that took the last seven years, they’ve at least got the building blocks now to do the same with other apps. I think.
It already seems like 9 is a decent improvement in many regards. (But again, it teeter-totters on the good and bad in such weird, indescribable ways sometimes.) The biggest improvement, surprisingly, seems to be on Windows 7 for me.
Btw, I do find iTunes the best in terms of performance (at least, how I want it to perform) and UI, and am perfectly happy with it, as is, AND want it to improve. Every type of grouping, playlist, auto playlist, individual selection, syncing, browsing, importing… everything is efficiently fast, responsive, and error-free. (Most of the time.) Do I want some additional features? Sure. Do I experience half-second to many second delays from time to time? Yes, but only when “changing track” on my media choices… which is a perfectly normal delay. Like fast-forwarding a cassette tape through some seconds of empty space to hear the other side, the turning of a knob to browse radio stations, placing the needle on the groove of an LP and hearing blank grooves. The delays I experience in iTunes are never really frustrating.
Not a major problem, but iTunes has its problems, and Apple should be working on them.
It seems like they can bridge 32-bit/64-bit, Carbon/Cocoa pretty successfully. iTunes is already (I think) using both QT7 and QT X, No?
Let’s see iTunes improve in some way.
Wouldn’t mind some bug fixes for PS, AI, FL, and DW either.
Can wait for 64-bit, Cocoa CS… I hope for the best.
Compilers for 64-bit might also have a different level of maturity than the 32-bit ones. From what I remember, the JIT and NGEN for .NET uses a different code base for 32-bit and 64-bit, and the latter doesn’t have all the optimizations of the former. (I don’t know if it’s “completely different” or just yanked around with #ifdefs or moral equivalents — beyond that which would be necessary for the architecture differences of course.) Even if you could potentially get a few percentage points of performance, that doesn’t mean the compiler will take you there.
I like geeking out on huge hordes of RAM — my overclocked Core i7 at home has 12GB. But, when it comes time to choose 32-bit or 64-bit Windows for a family member’s new system, you can bet I’ll make sure their printer driver works first. Even if one of their apps is accidentally faster on 64-bit, it would have to be a 50% difference for them to even notice. And you can reach that delta much more easily by installing an SSD or a CPU with more cores (depending on the app, of course). When iTunes is playing music in the background, it doesn’t matter if it’s using 1% or 2% of CPU — it’s negligible, effectively 0%, on a dual-core or HyperThreaded system. 64-bit can’t improve that. CD ripping is mostly bound by the drive limiting rotational velocity in an attempt to avoid melting the disc. (I’m not discussing ‘foreground’ use of iTunes in this paragraph — that’s another story, one that I care less about.)
Then again, if a kid (me) over in Seattle can convert Paint.NET to 64-bit in 6 weeks (circa 2006), then what is wrong with the guys at Apple! Seriously, they are years behind! /sarcasm
I worked on another project that needed to work on 64-bit Windows Vista after having been in the market as a 32-bit only solution. We (or rather, one developer on our team) did a ton of work and analysis and chin scratching and blood pressure medication (kidding) and finally decided that we’d still run with the 32-bit binaries. We didn’t need the memory, wouldn’t benefit from using fewer CPU cycles (if that even were to be the case), and certainly couldn’t/wouldn’t afford the cost of larger binaries (memory use or download bandwidth). Our hard blocks for native 64-bitness were some 3rd-party COM components who either refused to port, or basically flipped us the bird unless we paid tons of money for the newer version (which had features we wouldn’t use). And that’s how we shipped, and everyone was happy. Customers weren’t concerned, no features or quality were compromised, and we saved a ton of money.
And CDostale is right — because of the Atom, 32-bit will be here for awhile yet. Both because they’re 32-bit and because they usually only get 1 or 2 GB RAM tops. From what I remember, only the “nettop” version of the chip has 64-bit support. It’s a curiosity … you could probably cool it by resting a few quarters on top of it, it’s dual-core, and has HyperThreading. Perfect for a low-end performance testing box sitting next to the monster workstation with gigs of RAM and active cooling. Certainly helps to keep *me* honest.
Now that I think of it, 64-bit does have one (potentially) major benefit for less memory hungry apps: increased virtual addressing space. Running out of memory due to heap fragmentation is, statistically, a thing of the past.
I don’t care if it’s constructed with Cocoa or Cocoa Puffs.
[Hah–that’s the quote o’ the day. –J.]
What I do care is that they find a way to make it stop beach-balling on my octo Mac Pro with 10 GB of RAM and dual RAID arrays.
Most of my beach balls come from my choice to tend my library like a zen garden.
So for example, I’m going through my library and notice that the genre of the new album I downloaded doesn’t match the one I used for all the other stuff by that artist. So, I click the first song, shift-click the last, Cmd-I, change genre, hit Return, and then sit back for a minute while it rewrites a few dozen KB of data on disk, hiding behind a modal dialog. Okay, let’s be charitable and assume it has to rewrite the entire AAC file for some stupid reason instead of just the ID3 tag….is that a reason I can’t be working in some other part of the library? No, in iTunes world, I have to wait until it’s re-genre’d that album until I can do anything else. Meanwhile, iTunes is taking only a fraction of one of my 8 CPUs. Really?? This is the state of the art in 2009??? What the Bloody F?!?
Now I decide to load a bunch of old QuickTimes up into iTunes, which previously lived outside its influence, so I can watch them on my Apple TV. They load up just fine, but guess what, Apple TVs don’t play all QuickTimes. So, here we go again: click the first, shift-click the last, right-click the group, and say “Make Apple TV version”. Off it goes, reencoding all the videos. Nice. But no, not nice: it’s still using just one CPU. Note well that I’m not even asking for multi-threaded encoding on a single file. I’ve got enough files here to keep each CPU busy with a single-threaded encode, but iTunes can’t do even that much for me. I’m stuck here waiting 8 times longer than is actually required by the technology. Wallowing in a sea of lameness, here, Apple.
I’ve got dozens of these examples.
You’d have thought that a new .0 version of iTunes that came out a week after GCD and OpenCL were made available might have made some use of those technologies, but no. Looks like I’ve got another few years of beach balls to look forward to.
[A. There is a 64-bit Photoshop shipping now–has been for nearly a year–but it’s not on Mac. B. It’s absence on Mac has nothing to do with our lack of belief in the importance of 64-bit. It’s simply a matter of Apple having killed Carbon 64. (It’s the same reason the new Final Cut Pro is 32-bit-only as well.) –]
…As that is the case, I humbly apologise – I was puzzled over the 32bit Final Cut Pro too. Is CS5 going to be released as a 64bit app for the Mac or is a longer period required for that?
[How about the fact that Adobe has sold more 64-bit Mac software (OS-included utilities aside) than any other vendor? How about a little credit for bringing 64-bit pro software–Lightroom 2.0–to the Mac *far* in advance (12+ months) of Apple shipping a single 64-bit pro app? –J.]
…I was also puzzled over the release of this before (as Mac version of) Photoshop.
[Where did I say that it didn’t mean better? I’ve said repeatedly that under the right circumstances, 64-bit can make Photoshop 10 times faster. But I’ve tried to set expectations very carefully about what those circumstances are. I think that’s the right thing to do for customers, even if they find it difficult to accept. (As I noted, it would be far easier for me to sit back and let people enjoy their ignorance.) –J.]
…This had been sounding very defensive on the whole subject as for why a 64bit app for the Mac isn’t available yet. I’m one of those people who deals with large images and I’m eager to utilise as much hardware as the app would allow.
In fact, I need to apologise regarding pretty much ALL of the comment as they were far too ‘confrontational’ and based on a little knowledge (a little knowledge can be a bad thing …a VERY bad thing!) – it was during the recovery of one of my migraines where the only colour seen tends to be red. So I humbly apologise – as humbly as humanly possible.
…and look forward to a 64bit Photoshop for my large images.
Craig
John, could you for the sake of sanity of us all explain to us what EXACTLY is the difference between running 32 bit PS on 64 bit OS, and 64 bit running on 64 bit.
Because many people do not understand that most operating systems had to go 64 bit, due to increased amount of RAM. So the OS is 64bit now, and there is no two ways about it. Then, lets see what happens when i run 32bit PS and 64bit PS under 8 gig of RAM 64bit OS …
Thanks.
Well, due to the utter opacity of the Apple development process we can’t know how much the significant improvement is due to any of these.
But when Gruber says it is still not cocoa and 64bit, I infer he implies an overall rewrite, and the evidence of all of Apples legacy apps are that *they will improve*, whatever the blend of 64bitness or modern cocoaisation is responsible.
John, you are still not addressing to technical points of the TLB improvements, the potential benefits of 64bit registers (for apps perhaps not optimised as PS is), and the memory randomisation.
And as mentioned above, if the rewrite to cocoa and 64bitness causes the Apple team to refactor and use other modern cocoa frameworks, as they’ve had to do for Finder, isn’t that a win whatever small percentage of improvement is due to the extra bits?
John
Interesting piece, as always. I’m no expert, but can see that 64 bit and Cocoa isn’t going to revolutionise the user experience.
But what’s your view on Grand Central Dispatch and OpenCL? Will they make a noticeable difference? And can you/ will you use them in CS5?
Chris
Running 32-bit Photoshop on a 64-bit OS means you’re using the processor’s 32-bit compatibility mode, which has all the limits of a 32-bit processor: only 4 GB easily addressable, memory dealt with in smaller chunks, etc. You could run two copies of Photoshop on an 8 GB 64-bit system and get full use of the system’s RAM, but a single instance can’t take full advantage of that system.
A 64-bit Photoshop can take full advantage of a 64-bit OS. It can allocate all available RAM if needed, and it gets access to any 64-bit APIs.
Another thing you often get with 64-bit systems has to do with the requirement for OS backwards-compatibility. Fully 32-bit systems have been common for 15 years now, which makes for huge amounts of inertia. You might have a program that was last updated a decade ago but still works. Say it’s using an old API that the OS vendor replaced years ago. The OS vendor won’t actually remove the old API immediately, to give old programs time to move to the new one, but abandoned programs are stuck in the era they were designed in. There’s a natural tension between moving forward with better APIs and backwards compatibility.
The question is, when to make the switch? A change to a very different processor architecture is a good time because that change breaks so many things already. Adding a few more breakages to the list isn’t going to make a big difference. 64-bit versions of both Windows and OS X do this: there are old APIs that still work in the 32-bit version that they finally removed in the 64-bit version.
Sometimes this just means old programs break, but other times it means new programs get better behavior on the new OS. This is where the improved security on 64-bit Windows and OS X comes from. The OS gets the freedom to change things for the better that would break old programs. New CPU architecture, new rules.
How about a tipod? 🙂
Sounds like the arguement I used to hear from the Apple addicts when the PPC chip first came out as a 64 Bit chip. The addicts would proclaim that Apple computers were 64 bit. The fact that the OS was 32 bit seemed to escape them. 4 is bigger than 2, 8 is bigger than 4. If something has a bigger number it must be better, right? Not.
I have tremendous iTunes performance issues, and though I know 64-bit isn’t a cure-all, I sure do wish Apple would do whatever it can to improve iTunes speed and, especially, its ability to multi-task.
I know that to some degree, my situation is exceptional (I have 126k+ songs in my library, plus many GB of video; the whole thing is about 2.5 TB), but my issues go beyond slow scrolling. To wit:
1) Well, the scrolling is slow, but maybe that’s to be expected.
2) iTunes seems incapable of downloading while playing video. This is a problem for me because I subscribe to several video podcasts, so I might be watching one video when all of a sudden, another starts downloading in the background, causing iTunes to freeze playback.
3) Editing the metadata of my music is a painfully slow experience.
Now, obviously with a library this big, I have to store it on external drives, and I understand that there’s an I/O performance hit in doing so. But the multitasking issue really drives me crazy. Re-writing iTunes in Cocoa would allow it to take advantage of Grand Central Dispatch, which might resolve much of my issues.
When it comes to consumers they get something in their heads and it sticks right or wrong. What is about to get stuck in their heads is that I spent the money for 64-bit I want everything 64-bit. They have no idea why? They just know they have it and now everything has to be 64-bit.
Humans seldom make sense. This is why I am from Mars. 🙂
iTunes doesn’t need porting, but it does need re-writing.
I’ve had a library with around 25,000 tracks for several years now. I go through a lot of podcasts, and have dozens of smart folders and scripts to manage them. What ran relatively smoothly on my PowerMac 2x2GHz 3 years ago had become tear-your-hair-out slow by the start of this year as iTunes has bulked up and slowed down.
I still get a lot of beachballs on my new Mac Pro 2x4x2.8GHz with 10GB of RAM.
Porting to Cocoa for the sake of it may not make sense, but iTunes definitely needs extensive re-structuring and re-writing. There’s no reason the UI should become unresponsive when scripts are running in the background or new library items are added, nor should the UI block when metadata is being altered.
IMO, iTunes is creaking under the weight of its own features and is ripe for a re-write. So it might as well be re-written in Cocoa, using Grand Central, perhaps Core Data, too. Certainly, the new WebKit-based iTunes Store would make the re-write a good bit simpler.
Apple may revolutionize interface, and it may come around the time that more things use 64 bit, but that doesn’t mean that 64 is the reason they revolutionize interface. 😉
GCD is a higher level way to manage threads. It’s kinda like “threads for dummies”. If you aren’t highly threaded, it’s a great way to get there. If you’re a highly threaded and tuned App like PS is, then it doesn’t give you much.
OpenCL is a way to utilize the GPU for GPGPU stuff (having normal code run on the GPU cores). Think of it like Altivec/SSE on steroids. Again, PS already uses some OpenGL, and uses SSE for some things. So an App like PS is likely to get less return than something that comes from further back on the technology curve. But there’s still a lot more headroom.
The issue with OpenCL is that it is not yet a mature technology. We’re looking at a first generation API, that’s running on a small subset of hardware for now. Long term, this API gives a lot of potential and is definitely an improvement — but you still have to time markets, make sure the investment into features is going to have a big enough market to justify the investment. So it’s probably not an “if”, but more of a “when” technology at this point.
iTunes definitely has performance issues for me. (530 gigs of music (well more than 100,000 items), about 300 gigs of Audiobooks (I don’t remember how many items.)
I’m an edge case now, but I won’t be for long. Media libraries are going to get bigger and bigger for most people.
I’ve actually submitted my library files to Apple twice with crazy slow-down bugs that only happen with large libraries. Rocking 2 gigs of memory on a 2 ghz Core Duo here. Not the screamingest but it ought to be able to handle what amounts to a database.
Even find-it-while-you-type operates in much less than realtime.
No, I don’t care if they make it Cocoa or what. I just think it’s odd that you’d argue iTunes is fast when you have a rather small library.
(As for a “rewrite,” iTunes needs to be split into separate programs. Jack-of-all-trades monolithic programs are silly. We need an iSync for the new tomorrow.)
Asking the question about iTunes seems a bit disingenuous.
[Well, I didn’t mean it to be. There’s no ambiguity about why people want Photoshop to be a 64-bit app. I was largely trying to shine a light on the naivety & wishful thinking that accompany the subject generally. –J.]
Photoshop needs to move to 64-bit because one day my Mac will have 32GB RAM and my pocket camera will take gigapixel images.
Hope that doesn’t sound snippy – your blog is fantastic! I’m learning an awful lot from it!
[Cool, thanks. –J.]
I think the only convincing technical reason to move Apple’s remaining apps to 64-bit is simple virtual memory use.
It’s not so much the apps themselves as it is the system libraries and frameworks. The code pages for these libs are shared across all processes that you have open.
If you run a “mixed” system with both 32-bit and 64-bit coexisting, then you’ll always have two copies of each lib loaded (one 32-bit, one 64-bit). That’s a performance cost to that — it takes roughly 2x the virtual memory pages, it can create some L2/L3 cache pollution, and the biggest thing is that it may take a significant amount of I/O time to page them in and out.
If you could run a “64-bit clean” system, then the OS will never need to load the 32-bit versions of those libs. Snow Leopard is the first system where this is even a possibility. Most users won’t do this today — because of iTunes and 3rd party software — and I doubt Apple expects anyone to. Still: The first step to making something common is to make it possible.
iTunes should be rewritten in Cocoa because A) this is an app which I am pretty sure Apple intends to be around in some form or another for a very long time, and B) Apple has indicated the long-term future is going to be Cocoa. This being the case, a re-write will need to happen sooner or later, so they might as well get on with it. Postponing this rewrite (which I imagine will be somewhat painful) will only make things more difficult later.
I also think a rewrite in Cocoa does bring benefits, not necessarily because its 64 bit, but because its Cocoa. It will bring more unified UI behaviours to iTunes – most Mac users regard this as a pretty important thing. For example, appearance and handling of the source lists, access to System Services (which have become a lot more powerful in 10.6), list selection behaviours, contextual menu handling. iTunes will also benefit from Cocoa performance improvements (I think its pretty clear that Apple will be devoting the bulk of its performance tune-ups to Cocoa now, and not to Carbon). See the recent follow-up post by Gruber for some of these points.
I recognize that really, these are more arguments for porting to Cocoa, but since the future of Cocoa is 64 bit, it also follows that these are arguments for porting to 64 bit.
So, to summarize, A) this port will need to be done sometime, so they might as well get on and do it now, B) I would argue that it the port by itself does have some benefits, and C) if they were smart (and I’m sure they are), they will take the time to sketch out a more modern, extensible architecture that will serve them well for the next 5, 6, 7+ revisions of iTunes. I think most people would agree that the current incarnation of iTunes is very different from iTunes 1.0, and the app would benefit from a new, stronger foundation.
Yes, I want iTunes in 64-bit cocoa. Why? Because its the future. Period.
Now, Adobe, quit this idiotic “64-bits is not that great” train and start working. No one is going to be convinced that their premier, several thousand dollar software package shouldn’t use their ultra modern, several thousand dollar hardware to the fullest. We aren’t biting.
[Well, that’s handy, because no one ever said it shouldn’t. (Thanks for making up stuff, then scolding me based on what you’ve made up, though.) –J.]
All these people with 40k plus tracks complaining about slow down etc in iTunes need to perhaps think a little differently.
When you hold down option for OS X or shift for windows and start iTunes you get the option to create a new iTunes library folder or use a different existing folder.
I have two different iTunes libraries on my laptop one for my phone and another for my iPod touch the touch library has podcasts and applications the phone library is only music.
Put all your classical in one library, jazz in another, rock in a third and perhaps a library for the children.
Perhaps a lossless library for two channel stereo and a lossy library for your phone will be more appropriate.
Everyone has different needs and will organise differently.
The thing to do is keep your current library and import new music into it then transfer to the ancillary libraries.
Remember too there is a check box which says yes or no to copying music to each library, unless you have large amounts of free hard drive space I would not duplicate your music.
I hope you find this useful.
iTunes will continue to use the last library opened until you choose another.
Sorry about the reply to my own post.
The option key trick works for iPhoto too.
I want a 64bit iTunes because iTunes is one of the very few 32 bit apps on my system, and the only one I am running constantly. That means it brings in the complete 32 bit stack (32 bit Cocoa, DiscBurning, etc). That is actually a significant amount of extra ram for one program.
Admittedly parts of the 32 bit stack are brought in for limited circumstances (mdworker32 for legacy Spotlight plugins, the quicktime and webkit plugin helpers, etc), but those are much more limited sets of frameworks, and I don’t have them running all of them time in the background like iTunes.
In other words, on my system, once iTunes moves to 64 bit I get back 30+ megs of ram used by frameworks only iTunes needs.
Does TextEdit need to be 64-bit?
Apple seems to think so.
In fact Apple just released an entire OS with few user-facing features, and (if we’re honest) modest performance increases, with the goal of preparing for the future.
Only Apple knows what will be required of iTunes tomorrow. In the longterm 64-bit might prove essential. If Apple (or any company) can build it into their roadmap, I think they should.
So yes, I welcome 64-bit iTunes.
RE: Photoshop. Any idea why the Open GL drawing has a refresh issue? Sometimes you have to zoom in and out to get it to redraw. I’m running a 2009 2.66GHz iMac with the 9400m chip.
It isn’t a negative to me that iTunes 9 is not 64-bit, however I think it needs to go 64-bit sooner than most of us think.
All the iTunes media right now is lo-fi, squeezed as small as possible so you can download the files, yet the smallest movie files are 1-2GB. If you are playing 1 and downloading another, that’s 3-4GB of data just for standard definition movies at today’s low/early quality. iTunes could also be syncing a 64GB iPod touch at the same time. If your Mac has 8GB+ of RAM, which is common now, then you want iTunes to be able to put the whole 3GB movie you’re watching into RAM so it’s really responsive even though iTunes is also writing another movie and iPod backup to your storage at the same time.
In short, iTunes 9 isn’t hurting for 64-bit, but if iTunes 10 is 64-bit there is a lot of room for iTunes to grow into the bigger space.
So
I agree that, right now, I don’t care whether iTunes is 32-bit of 64-bit.
OTOH, what iTunes *does* need immediately is to get all of the ancillary threads *out* of the main process. Since the UI work has to be on the main queue, anything not related to that (or other core functionality) needs to be spawned to run as a background process. Syncing to any iPod/iPhone, getting data from the iTMS, encoding AAC/MP3/etc., organizing the library (e.g. file I/O); these all need to be spawned to asynchronous threads and not impact the UI user experience (the infamous beachball of death).
Fortunately, snowkitty has GCD (Grand Central Dispatch) built-in to take care of most of the plumbing, developers just have to implement it intelligently in their applications. Siracusa’s tome at Ars on snowkitty is really worth the 23 page read, or at least the three pages (+/-) that cover OSX concurrency and GCD.
BTW, this doesn’t only go for iTunes but IMO also goes for Logic, Lightroom, and Photoshop. (And a lot of other applications, I’m sure, but those are the ones I use on a regular basis).
Of course, GCD being *mostly* OSX-specific (I read today it has been open sourced for *nix use), the question is whether Adobe, etc. will take advantage of this important built-in functionality that, for the most part, doesn’t readily exist for use with the application’s Windows counterpart. Any thoughts on this, John?
The other reason that most (if not all) applications will need to be ported to 64-bit/Cocoa is because that’s the only way to get access to new OSX features and functionality. Apple isn’t updating Carbon to support the new libraries and APIs (i.e. per the Gruber blog entry from today, Objective-C 2.x is 64-bit only).
Making up a hypothetical example: Sooner or later there might be an enhancement to managing huge amounts (talking GBs here) of text in a display. That enhancement will be 64-bit/Cocoa only. @mattie, at that point TextEdit will almost certainly need to be 64-bit, if only because that will be the only way to get access to the new built-in OSX features. Mind you, not because it has to be that way, but because Apple dictates it will be that way (dragging developers to the 64-bit world kicking and screaming if necessary).
FWIW, I still think the OSX approach to the 32-bit/64-bit problem is cleaner for the end-user than what we have with Windows (two separate versions with currently no true upgrade path between them).
No Performance issues? Have you used the bleeding thing at all?
It’s incapable of downloading and playing video podcasts at the same time. As soon as the download finished the whole app (including the video playback) freeze for around 5-10 sec. And that is on a Mac Pro…
People need to consider the cold hard truth that a full re-write of iTunes is going to result in older, less used, features disappearing. Rarely is an app re-written to preserve all functionality of older releases. There are many scripts and supporting apps that will break in the process. There will be an assortment of new bugs. Is it really worth it just to see 64-bit in Activity Monitor?
My library is 104.30gB, 1430 albums, 81.8 days of music. iTunes memory usage? 127MB (out of 8GB total)
1st post here, but I constantly lurk: great blog, please keep it up.
Speaking of performance, isn’t 32-bit Carbon better performing then 32-bit Cocoa anyway?
Carbonized: In theory, maybe. In practice it does not seem so. An average Cocoa program *feels* snappier. And as several persons have iterated, all new stuff comes to cocoa/64-bit. Carbon will just look worse and worse in comparison the years to come. Frankly it has looked out of place for years now.
About rewrite, I think iTunes needs some big work both under the hood and with the UI. My pet peeves are the modal dialogs especially when doing some long operation, just decorate the changes in UI and do the work in the background.
The fact it is a multi platform software (windows, several versions of OS X) and that it is of strategical importance to Apple in many ways makes big changes much harder to do. Gruber’s theory about going more and more into direction of Webkit sounds interesting.
I have 130,000+ tracks in iTunes, with over 130 playlists. The performance is dismal. Albeit this is on a G5 Dual 2.7 with 6gb RAM). Sometimes clicking on a song to play it beachballs for 4-7 seconds. Deleting a track from a playlist can also take over 5 seconds. And don’t even try to do any of the above when it’s importing a CD.
So there is still room for a lot of performance improvements under the hood.
Cocoa will come and with it 64-bit. I don’t think anyone doubts that, and I agree that it isn’t a necessity right now.
I think the professional apps are much more priority for Apple to convert to Cocoa so they can take advantage of more than 4GB RAM at once. Namely FCP and Aperture. Just look at Lightroom for an example of a professional app that is 64-bit.
I think too many people think that the rewriting in Cocoa is merely a simple update or recompiling. Finder is a relatively simple app in comparison to iTunes and it took Apple awhile to get it to function and look like the Carbon Finder through the SL Betas.
Then there is QuickTime X, which was very buggy for many SL Betas and has very few features that the previous QuickTime 7.6 has. It doesn’t even have any preferences to access. Maybe this is how Apple wants it to be, but I think that features will be added to QuickTime periodically to match the previous QuickTime that was in development for decades. Finder *had* to be complete and fully functional for the Snow Leopard release.
I think iTunes X is going to look and feel like iTunes 9 does now, for the most part, but that it’s a work in progress that will take the better part of 2010 before we see it released. It’s just too complex of an app to have been completed so quickly, and as stated it’s not a priority app.
I expect Apple to release this app and their professional apps as Cocoa sometime before 2011. I also expect the more foolish Windows enthusiasts to state that Apple’s OS and SDK must suck if it takes this long to produce a 64-bit app when iTunes for Windows has been 64-bit for years.
Actually, your comment reminded me of the old dark days of Windows 3.1/DOS and the up and coming Win95 …. oooh aaah … All this Win-32 stuff …
Many people didn’t care or understand the difference between 16-bit and 32-bit, but it happened, and if I remember correctly, it happened rather fast.
I view the current 32/64 bit situation as exactly that. It’s inevitable; it’s necessary, and it’s overdue. 64-bit processors have been shipping for the past three years. Software has been lagging. It’s time to get up to speed.
And I want to applaud John Nack for this quote: “I want people to buy my (and our) work based on real value” … However, sadly this “value” has been lacking in ALL Adobe Products since Bruce Chizen became CEO.
A wise man once told me that “every religion dies along with its prophet” referring to the fact that most of us have no idea what Moses or Jesus said; all these anecdotes are probably made up and fake.
I believe Adobe died with John Warnock’s exit from the company. What followed during Chuck’s era was trails of glory from the past, and the rest was just pure crap. Bruce was the worst thing that happened to Adobe. And after that was Macromedia.
So John Nack : please add some value to Photoshop, and have the guts to take some stuff away 🙂
[How/what, specifically? –J.]
Sinister Joe – what hardware are you running your iTunes on? How many playlists do you have? I really need to improve the performance of my iTunes library (slightly bigger than yours, but just slightly) but I’m still on an old G5 (dual 2.7). Ram doesn’t seem to be the issue.
“…and look forward to a 64bit Photoshop for my large images.”
Why not use Windows 64 then? 64bit PS has been available for a while on Win now and Windows runs really fast on a Mac too.
I personally think all the performance issues people are having with iTunes is related to XML parsing, not Cocoa vs. non-Cocoa or 64-bit vs. 32-bit. I agree with one post above that recommends the GUI be decoupled from other processes for better performance, but that is also orthogonal to using Cocoa and being 64-bit.
“Do they complain about the UI?”
Yes, *they do*. And I’m sure by bringing this up I’ll be labeled as an edge case and the exact type of user that software companies shouldn’t care about … but I thought I’d least try to offer the perspective.
iTunes has long been an outsider to the UI. Finder as well. Don’t get me wrong, Apple has done an incredible job making iTunes and Finder behave like the rest of the OS, but it never *really* got there. I understand saying *for free* when talking about some of the advantages of Cocoa is a little naive, but no one can deny that even playing with the Finder, it *feels* more native now. Could it have achieved that with Carbon? Yes. Would it have been deemed to costly for the benefit it gave? Obviously.
John, I don’t think Cocoa or 64bit is a silver bullet. And in my day-to-day work in Photoshop, I’m probably not going to notice the difference. But I’m *hoping* I will. I’m hoping that Cocoa, or even just the effort of converting to it, will allow Adobe to pay attention to details often overlooked, and hopefully begin using native controls that behave how I expect as someone who spends 100% of their time in one OS. Not two. I’m talking about UI appearances, the way text boxes work, etc…
Sure, these things could be written to behave just as badly in Cocoa as they were in Carbon. But I’m hoping, and I’ve always believed, that the interface mistakes in a product like Photoshop were not due to Carbon, but due to a very old and mature product that has a budget like any other product. And that during this transition, the costs of making the UI consistent with the OS will be way down, because they’re shared with the cost of the transition in the first place.
So as for the UI, yes, people complain about it. Look at iTunes 9. It’s completely different from the ground up. Chrome, buttons, column headers, text selection, not respecting aqua/graphite, preferences window & behavior, background grid colours, scroll bars, etc… I love it all, it’s beautiful, but I love consistency even more. I love knowing what to expect when I go to do something. If they changed the system to look like iTunes, that’s great. If they changed iTunes to look like the system, that’s great too. But having apps that look/behave differently is a bummer for the user (or at least for this OCD user who notices things no other sane human being probably does/should).
I realize that the transition to 64bit and Cocoa doesn’t inherently mean *any*of my UI gripes will be addressed.
[To be blunt, it may mean fewer will be addressed (at least in the short term), because resources need to go to translating to Cocoa instead of making other changes. It’s an opportunity cost. Hopefully it’ll pay off in the long run, as we can avoid things like the Carbon-related bugs in Spaces. –J.]
But I’m hoping what it does mean is that the App will be experiencing so much churn in every facet that correcting those gripes will be easier, relatively cost effective & prioritized. Okay, enough rambling.
Thank you for working hard on a product that I use every day and makes my job immeasurably easier. Thank you for working hard on a product that allows me to be creative. And thank you for working on a product that has no doubt contributed in a massive way to the beauty I see around me every day. The request the app behave/look more like a OS X citizen could certainly be characterized as “nit picky” but it would be cool.
[Thanks for the feedback, Josh, and thanks for caring. –J.]
If it would allow me to manage my 28,695 songs, 324 Movies and 1000 TV Shows, without requiring the power of a Mac Pro, then yes, I’d love a 64-bit version. 🙂
too damn many posts to read all, but just have to throw this in:
I don’t care a damned bit about iTunes 64bit, I care a great deal though about Quicktime 64 bit, why?
I do 3D, and I like to use my 3d ddc apps under 64bit utilizing as much of my systems memory as possible, I also might like to be able to render my animation to .qt, but in the 64bit versions of the tools I have, for some interesting reason, there doesn’t seem to be rendering to .qt support…
Well in the Windows environment. iTunes absolutely sucks.
My wife and I have had nightmare issues with it on three different machines (XP, Vista, Windows 7).
It is the most non-responsive application I’ve ever used. Always “Not Responding”. Hates trying to connect to the NAS.
And I am always having the most funky things happen with iTunes and my iPhone. Like it deciding to suddenly install 20 apps I removed months ago.
It’s ridiculous. The headache of iTunes/iPhone maintenance has just about made me swear off any future Apple product purchases.
The last thing I had this much headache with was a corrupt SVN library.
And of the last 10 times I’ve stayed up late mucking with my computer – eight of those have been iTunes/iPhone related.
I’m hoping that Cocoa, or even just the effort of converting to it, will allow Adobe to pay attention to details often overlooked, and hopefully begin using native controls that behave how I expect as someone who spends 100% of their time in one OS.
I hope you’re right, but look at Lightroom. At its core Lightroom is, I believe, a cocoa app, but its GUI is built using Lua, so it basically looks and feels nothing like a native OS X app.
This may seem late (I stumbled on here… from a google search).
I’ll admit I actually don’t know if there is an inherent benefit of recompiling a 32 bit app to 64 bit app, (Basicly the ram swap for system calls that OSX made when it was 32 bit… does it still happen when the OS kernel is 64 bit but the app is 32?).
As for iTunes, something to think on… it is possible with the right codecs for iTunes to manage not just music but videos as well, this includes video > 4GB in size. Of course the part I am not familiar with is if iTunes opens the video file and plays it back using the QuickTime API or if it opens Quicktime inside itself…. anyhow that alone would be reason to port to 64 bit since it could then feasibly load the entire video at once in ram and still have room for the gui. Granted the example I gave also requires that the 64 bit part of Quicktime can open the file. (If its Divx… it would not help currently).
who ever wrote this article loves conflict.
As a programmer myself, I say: it’s a proxy for software quality.
I have no idea how good or bad the Photoshop or iTunes source code is. Seeing how many times it crashes is a very poor metric, in part because it’s such a small sample size, and in part because of the nature of software (an excellent architecture might well have a minor bug that causes a rare crash, while I might happen to avoid all the crashers in a poor architecture). Seeing the UI design is also a very poor metric: when a UI is bad, it could be because the architecture is bad and it would be too hard to fix, or it could be that their designers thought it would work better this way, or it could be they use the software completely differently than me so it actually is better for them.
But it’s hard to fake 64-bit Cocoa. Really hard! If a product team makes a 32-to-64 transition, it means either they kept architecture-specific assumptions to a minimum all along (good work!), or they invested heavily in fixing it now (nice!). Software that is compiled on a new architecture virtually always finds bugs in itself there.
Debian, for example, famously ships on 12 architectures. I’ve seen countless packages that work great on 32-bit x86 be accepted into Debian, where they immediately find a few dozen bugs when the autobuilders try compiling it on ARM and PPC and Itanium and PA-RISC and so on.
If somebody has software that ships on even 3 or 4 platforms, I’m impressed. It leads me to believe that the software has met some threshold of quality that most software has not.
So we’re not saying we want 64-bit for the bits. We’re saying we want you to clean up your code! Mac OS X 10.6 was advertised as “0 new features”, and people loved it. It’s been 10 years since there was an Adobe release that I bought for the features — it’s always because the version I have no longer supports the new OS. If I could buy versions of Illustrator 10 and Photoshop 7 which were 32/64 x86/PPC Universal apps, and which had no new features but only bug fixes, I would more gladly pay money for that than any other software I’ve ever paid for.
The “new features” incentive is a canard. Nobody says “Photoshop seems OK, but it just doesn’t have enough features”. At this point I’d pay for fewer features, if I could get bug fixes in the deal.