Tips, tricks, and other interesting Photoshop items from an engineering perspective.

Archive for December, 2006

I’ve gotten a number of questions on the beta forums as to why Photoshop CS3 won’t have a 64-bit version. It’s definitely a when question, not an if, and there are a lot of factors involved. I though I might collect some of the information together here.

First, let’s check all the 64-bit hype at the door. Being a 64-bit program means, most simply, that pointers in an application are 64 bits wide, not 32 bits. A 32 bit pointer means that an application can address 2 ^ 32 bytes of memory, or 4GB, at the most. The operating system an application runs on slices that application address space up, so that the application can actually only allocate a part of that address space for itself. Thus, on Windows XP, an application can use 2GB of address space, on Macintosh OS X 10.4, an application gets 3GB, on Windows XP 64-bit edition, a 32-bit application gets nearly 4GB of address space. Applications don’t allocate RAM on most modern operating systems – that’s a common misconception and a gross oversimplification your computer geek friends tell you because they don’t want to explain virtual memory, TLBs and the like.

A 64-bit application doesn’t have same that limit on its address space, since pointers are 64 bits – they can address a much larger amount of memory. That’s pretty much it. 64-bit applications don’t magically get faster access to memory, or any of the other key things that would help most applications perform better. Yes, the x64 instruction set has some more registers available, and that helps in limited circumstances, but the processing throughput of a memory bandwidth bound application is pretty much not going to benefit from being a 64-bit application. In fact, it gets worse in many cases because the internal data structures the application is dealing with get bigger (since many data structures contain pointers, and pointers in a 64-bit application are twice as big as in a 32-bit application). Memory bandwidth has not kept up with processor speeds, and has become a precious resource.

Let’s contrast to the old switch from 16-bit to 32-bit computing. During that switch, 16-bit applications were already not really true 16-bit applications (in order to address 640k of memory, there was a really ugly hack that meant pointers weren’t really pointers and weren’t really 16 bits) – so the data structures an application was dealing with pretty much didn’t change in size at all. Even if they did, memory bandwidth at that point in history was high enough relative to processor performance that what data structure size increases did happen were easily absorbed and didn’t affect performance significantly. Not only that, but for many operations, moving to 32-bit computing meant a lot of fixed point math could be done in a lot fewer instructions, and a lot faster. For many applications, this was such a huge win -and one of the reasons why the switch to 32-bit computing happened fast relative to the 64-bit computing switch. These days, many 32-bit processors already have math instructions for doing 64-bit fixed point math to the degree most applications need it, and many things are done in floating point. Combine the performance penalty for the data structure size increase with the lack of any sort of other performance win, and the number of situations in which an application being 64-bit are a performance win is very small.

And, in the cases where it would be a win – dealing with a very large data set (Photoshop files over 1GB is a good guess as to about where things get interesting) – having the operating system use any unused RAM to cache scratch disk reads and writes can be nearly as effective (depending on how good the operating system is at this – and there are even a few add-on products which can make it even better) as having Photoshop itself being able to hold all of scratch within it’s own address space. (Side note: a computer system is most efficient when it has nearly no free RAM – there really is no point in having RAM sit empty. An aggressive file cache is one good way of accomplishing this. Vista is supposed to be really good at this, but I don’t have enough direct experience yet to know for sure.)

Ok, so in a very limited set of cases there might be a little bit of a win for Photoshop to be a 64-bit application. But…

A 64-bit application can’t be run on a 32-bit chip or a 32-bit operating system. That means a 64-bit version of Photoshop would have to be a completely separate binary from the 32-bit version. A separate binary has a huge cost associated with it (in terms of features we can’t do because we have to spend resources elsewhere). Quality assurance is a big part of that – you essentially have to dive in and test every corner of the app for each binary, across the matrix of supported operating systems – but there are also many ancillary pieces that add to that cost as well. And given that a Universal Binary application really is two separate binaries smashed together (and accounting for the kinds of issues that an application can have going from big endian (PPC) to little endian) we already had a lot of extra cost going through this cycle. Adding the cost of adding a 64-bit version to the mix of things that were already on the have-to-do list – especially in light of the very limited benefits – and doing a 64-bit version this cycle really became an unreasonable thing to think about it.

There’s more. Since a 64-bit application can only run on a 64-bit chip with a 64-bit operating system, just how many users could run a 64-bit version in the first place? Macintosh OS X 10.4 isn’t fully 64-bit – many of the libraries an application would need to be fully 64-bit aren’t available. So, on the Macintosh side the answer is zero. Ok, so consider the Windows side: Windows XP 64-bit edition has been out a bit. How many Photoshop customers run it? A vanishingly small percentage – there’s been a lack of compatible drivers, especially for the kinds of things that make up a Photoshop workflow, like scanner divers, monitor calibration bug drivers, and the like. Things are looking better for Vista – it comes with a wider spread of 64-bit drivers out of the box – but there are still 64-bit versions of some of the pieces of the puzzle missing there, and the expected Vista adoption rates mean that the number of Photoshop customers running the 64-bit version of Vista will remain very tiny over the next couple of years. Yes, there’s a whole look to the future thing, but even considering that, the timing just isn’t right yet.

As for the engineering part of it, well, I want to do it. I want the transition to 64-bit computing to happen sooner rather than later, I’d really like to not have to worry about address space limitations so much. Once, long ago, I ported Display PostScript to the Dec Alpha workstations (what a nice processor, sigh…), so I have a good idea of what the level of engineering work will be.

At some point, some of these things will change – certainly the number of systems capable of running a 64-bit version of Photoshop will – and at some point it will make sense to do a 64-bit version. That wasn’t this time around. But like I said, it’s a when, not an if.

It’s real. A big, public beta of Photoshop CS3. Now, if you own CS2, you can see what’s been keeping us so busy lately.

Now, you can read all about features on other sites – I don’t think this needs to be yet another me too list of features. And this isn’t the place for reporting bugs or asking questions – use the Labs forums for that, I’ll be there along with some of the other engineers, time allowing (hey, we have to finish this thing).

We are doing this mostly because we wanted to get the Macintosh Universal Binary of the product into your hands as soon as we could. It really wasn’t possible to do that with an updated CS2, it really did take that much effort, and it really wasn’t ready until recently. But then, it wouldn’t be fair to do just a beta on the Mac side and not let the Windows users along for the ride.

This is a beta, but I think it’s in pretty darned good shape. Part of why is that as a development team we broke free of the old waterfall methodology. If you’re a developer, visit Waterfall 2006. I find it pretty funny, maybe that’s just me – I’ve been living the waterfall nightmare for so long, the laughter comes from a dark place…

What it means is that we’ve kept the bug count low the entire cycle – especially the nastiest bugs. Now, your "favorite" long-time bugs and annoyances may or may not be fixed (yes, we do listen, I keep a list, and we get to as many as we can), and after all, this is still a beta, there will be dragons there, but for the most part for something still this far from release, it’s in pretty good shape – and this wasn’t a special, lots-a-pain bug-fix build, but pretty much just pulling out a daily. Yeah, I know, some of you developers will be going "but we’ve been doing things that way for a long time". Hey, around here, a lot of the groups fall right back into waterfall at the first sign of trouble. Nasty.

A couple of notes – due to the platform rules, the Macintosh version when running native on an Intel-based Macintosh will not load and run PPC-only plug-ins. You’ll have to run under Rosetta to access those old scanner plug-ins. Or better yet, just use the scanner software in stand-alone mode. Also, brush-sized cursors aren’t working when running Macintosh Intel native yet (they do work in Rosetta). With a little help from Apple, the replacement for the old framebuffer-fiddling methods are well underway, but they didn’t make the beta.

The new UI can test Windows XP video drivers a little more, so you may want to make sure you have those updated, especially if you see some problems. I like the new palette panes, but they do take getting used to, so give them a chance. There are legacy workspaces in there if you really need the floating palettes back. Vista support is in there, too.

As for performance, you should see start up times that are much lower than for CS2. We’ve really worked hard on this – there’s more to go, of course, this is just a beta. Oh, and as for comparing performance between platforms now that they use the same chip and we’re a Universal Binary on the Macintosh, well, I just don’t think such comparisons are valid – there are so many variables involved: number of processors, system memory bandwidth, disk I/O bandwidth, OS scheduling, API performance. So if you see sites claiming that one platform or the other performs better, take it with a big grain of salt – I do.

So, if you’ve got the time and inclination (and Photoshop CS2) go ahead and grab the beta from Adobe Labs tomorrow and see what we’ve been up to.

[Edit – 12/15/06 9:30amPST – The links still aren’t live on the labs pages yet. It’s being worked on. – Scott]

[Edit – 12/15/06 12:15PST – They’re live now. Visit the forums at Adobe Labs for more help and info.]