December 04, 2007

Solid state drive goodness (via Arlo Guthrie)

Every now and then I try to share info related to hardware developments that may eventually impact Photoshop (e.g. What’s up with Photoshop & 64-bit computing?).  Lately I’ve been hearing more questions about solid state drives.  As Photoshop architect Russell Williams notes,

The access time to get a
random piece of data would be significantly less [than for traditional hard drives]. A disk has to move
the read/write head to the correct track and then wait for the right spot
on the disk to spin around (not unlike Arlo waiting for the right spot in
the chords to come around again so he could sing the chorus of Alice’s

I’ve spotted some related news that’s worth passing along:

Now, I should note that we can’t yet characterize the performance impact of using these exotic tools (the team is accepting hardware donations ;-)), but we hope to be able to share more info after we’ve done some testing.

Posted by John Nack at 10:41 AM on December 04, 2007


  • Dennis Radeke — 11:39 AM on December 04, 2007

    Ahh yes, Arlo Gutherie. One of my favorite albums as a kid (go figure). Take me back John!

  • Pedro Estarque — 6:38 PM on December 04, 2007

    I’ve been wanting to know how usb pen/thumb/key drives compare to traditional HD for a long time. I couldn’t find any definitive benchmarks but the drives I tested myself performed poorly to say the least.
    Is Adobe doing this king of benchmark ?
    I thought Photoshop’s VM system was particularly tuned for sequential reading. If so, HDs should perform better in the foreseeable future, right ? Or is Russell Williams referring to a new, random access oriented, scratch disk algorithm ?

  • Bruce Watson — 12:14 PM on December 05, 2007

    I keep thinking that a high performance solid state drive would make an excellent scratch disk. Then I think about what a patch a scratch disk is. What we really need is high performance RAM, lots of it, and high performance virtual memory managers in the OSes. With enough memory the VMM doesn’t have to page to disk and by extension, neither does Photoshop.
    If we had decent VMM with lots of RAM, Photoshop could just allocate/deallocate RAM as it needed it with no need for a separate scratch disk. That would be, I think, the best performance option for those really big multi-GB files.
    So Mr. Nack, where is Photoshop heading on this front? Is Adobe working with Microsoft and Apple to improve the VMMs so it can get out of the scratch drive business? Or do I really need to think about dedicating a fixed size solid state drive to Photoshop to use as a scratch disk? Using RAM would be a lot more efficient, but I’ve got to go the way Photoshop goes…

  • Russell Williams — 7:04 PM on December 05, 2007

    [The following comes from Russell Williams, Photoshop co-architect. –J.]
    Originally, Photoshop implemented its own virtual memory (VM) system because the Mac didn’t have VM at all. The first Mac and Windows VM systems did perform poorly. Now, however, both Mac and Windows have good VM systems. The reason we still have our own VM system isn’t because the OS VM systems are “not decent”, it’s because we need access to more than 4GB of data in a 32-bit address space.
    No matter how decent an OS VM system is, it can only provide immediate access to about 4GB of data in a 32-bit address space. Photoshop can directly access 500GB (more than that, actually — but we’ve only tested up to 500GB) of image data.
    A future 64-bit version of Photoshop could probably do away with most of its VM system, using the OS VM system for most of the work. Certainly a 64-bit Photoshop would give you the full advantage of as much RAM as you could cram into the box, whether using Photoshop’s VM system or the OS VM system. But a couple of caveats:
    1. If you just allocate memory and let the OS VM system handle it, you get scratch space for that memory allocated on the system boot disk, and that scratch space has a limited size and is shared with all other uses of the boot disk. Users often work with total image sizes (open files plus their history) that’s much larger than the available scratch space on their boot drives. All the same reasons for putting Photoshop’s scratch disk on a separate drive still apply no matter who’s managing the VM.
    So a version of Photoshop that uses OS provided VM would still have to allocate its own scratch files on the scratch disks the user specifies. It could then use the OS VM system to manage swapping to those scratch disks via the “file mapping” mechanism that all modern OSes support. That’s in fact our eventual plan.
    2. As long as there are 32-bit computers and 32-bit operating systems in the world that Photoshop has to support, the 32-bit version of Photoshop with its own VM system has to stick around. And unless the 64-bit OS’ VM system provides a significant advantage over Photoshop’s (and we have no evidence that it would), we’d be maintaining two very different chunks of code for managing big images, for no good reason.
    For this reason, our current plan is to keep our own VM system until we can completely discontinue the 32-bit version of Photoshop. If you look at the sales figures of Vista 32 vs. Vista 64, that day is a long way off.

  • Bruce Watson — 6:36 AM on December 06, 2007

    Of course. I wasn’t thinking about backward compatibility. Good thing you are.
    So… solid state drives dedicated to Photoshop for scratch disk space? It would seem on the surface to be a good performance improvement. Do the Photoshop architects have any opinions on this yet?
    [Russell replies, “We’ll be looking at SSDs now that they’re becoming more viable in other ways (like price and size). Photoshop doesn’t have to do anything to support them–they look just like any other disk; it’s just a matter of doing some performance testing and publishing some guidance based on the results.” –J.]

  • Jerry Harris — 8:38 AM on December 11, 2007

    They are just around the corner…

Copyright © 2020 Adobe Systems Incorporated. All rights reserved.
Terms of Use | Privacy Policy and Cookies (Updated)