Friday, August 28, 2009

Snow Leopard: It's Built for the Future.

[If you parle français, then congrats on being a polyglot! Also, you may have already read this interview I did with For those of us stuck with Americanese, I've asked if I could post the original version here.]

Florian Innocente [MacGeneration]: From the user's perspective, what can they expect from *your* software once you have optimized them for Snow Leopard ? If any kind of optimization is planned. I mean, is there any room for visible improvements, be it in the interface or at the code level of your app (making it snappier, faster, using less RAM or CPU ?). What does 64-bit, Grand Central and OpenCL mean to your apps ?

Me: I'll certainly be optimizing Delicious Library for Snow Leopard. There are a lot of cool things in Snow Leopard for developers; it's really a release for us and for Apple, to clean up and modernize the underlying layers of OS X.
  • Grand Central is used all over in Snow Leopard, so it's hard NOT to use it if you're doing new development. In general, Apple has noted that processors can't get much faster – the energy they use, and thus the heat they create, goes up as the square of the processor speed, so we've hit a barrier where they'll burn themselves up the second you turn them on if we go any further. To counter that Intel and others have started bundling multiple processors on a single chip – imagine a kitchen with many cooks, instead of one cook who you keep asking to work faster and faster.

    But, like a kitchen, if you have many cooks you need to _manage_ them well, or most of them will sit idle and useless while a couple are tearing around hogging the blender and over or what-have-you. Grand Central makes it simple for mortal programmers to keep all the cooks busy; other operating systems (Windows, Linux, etc) have notions of "multiple threads" but leave it to the programmer to manage them manually, and threaded programming is VERY, VERY hard to get right. (OmniWeb 2.0 was one of the first commercial very-threaded programs, and believe me it was a BEAST to code.)

    In Delicious Library 2, for instance, I use a few threads (cooks) already - when you scan a barcode with the videocamera the decoding work is done on a different processor, and when you look up items or publish your collection to the web the network code is handled on a different processor, as well.

    With Grand Central Dispatch I can go a lot further with a lot less effort – for instance, I could have it so each frame from the videocamera is handled by a different processor when scanning for barcodes (instead of all of them being handled by one processor), so I could process a lot more frames per second on machines with a lot of processors. (Right now I just skip frames if I run out of time processing the previous one.)

    This gives us a great foundation against Windows in the future - as machines get 4 cores (processors) and then 8 and then 16, apps written for Snow Leopard and beyond will continue to be faster and faster, with no changes, while Windows programmers are going to be struggling to make their apps work at all.
  • 64-bit is great, because it requires very little work on my part for a lot of win. First off, it turns out that applications that are recompiled for 64-bit end up running about 15% faster, right out of the gate, just because of efficiencies gained at the processor level. I did the initial 64-bit port of Delicious Library 2 to 64-bit in about two days -- while I still have to beta test it and all that, it's pretty amazing to spend two days and get a 15% speed-up in software.

    The funny thing is that this speed-up is kind of a side-effect; the real impetus to go 64-bit was memory limits. In a 32-bit program, the maximum amount of "virtual memory" your program can use is theoretically 4GB – which means, unless the programmer goes to a LOT of effort, the user can't work with data files bigger than 4GB, no matter how much RAM and/or disk space she has available.

    And, in fact, the real limit isn't 4GB - the system frameworks and the video display memory are subtracted from that limit, so you actually get to use only about 2.5GB, ever, under 32-bit. (Under 64-bit, you can use essentially unlimited RAM and unlimited virtual memory.)

    So, for instance, loading in a 3GB image, or even three 1GB images, isn't possible (without a bunch of extra code), which is important as images get larger and richer.

    With Delicious Library 2, we have users who have tens of thousands of items and have assigned each of them a hi-res cover, and their collections have grown beyond this barrier, as well. With a Snow Leopard-optimized version of Delicious Library, collection size would only be limited by the user's available disk space!

    In a related issue, even if you have 4 or 8GB of RAM in your machine, a single program can't use more than 2.5GB of it at once under 32-bits (both RAM and virtual memory are limited by 32-bit addressing). So, for instance, if you pack 8GB of RAM in your machine, thinking, "Man, now my huge collection in Delicious Library will really scream," you're going to be disappointed under 32-bit. Under 64-bit, you're going to be blown away.
  • OpenCL is going to be harder for me to take advantage of, because it's a new language for me, and requires extensive rewrites. But, with graphics processors gaining in power MUCH more quickly that main processors, it's another very smart move for Apple to make it relatively easy for programmers to take advantage of them for general use.

    In Delicious Library 2, we might see a version of the barcode scanner that is even MORE sensitive because it runs on the graphics chip, and thus has the power to do more transformations on each frame in an attempt to wring a sensible barcode out of it.

FI: There's a lot interrogation among our readers regarding what Snow Leopard will bring in the short term for them and in their daily apps. Som expect a lot, others fear to be disappointed. It would be interesting to have your take based on the future revisions of your own products.

Me: I think short term most users aren't going to get a ton out of Snow Leopard, to be honest. It's a VERY important release that redoes the very heart of the operating system, but intentionally doesn't add a lot of features or chrome.

It's like the user is getting a new engine in her old car, that's much more efficient and much easier for mechanics to tweak in the future. It's not going to make a huge difference out of the gate, but over the next ten years it's going to be invaluable.

Or, to use another analogy, I think of this release as like going from incandescent bulbs to compact-fluorescents or LEDs - tomorrow you're still going to have light, but it's a light that's future-friendly, and every year that goes by you're going to be more happy you made the switch.

Tuesday, August 11, 2009

The time has come... update to Delicious Library 2.2. As of August 15th, 2009 (that's in four days!) Amazon is requiring all users of their data (us) to digitally 'sign' requests for information.

In English that means Delicious Library is no longer going to work unless you update to 2.2 (or 1.7 if you're still using Version 1.)

When you next launch Delicious Library (1 or 2) it should prompt you to update. Do it! If for some reason you need to download the update directly, you'll find them below.
Download Delicious Library 2.2:
Release Notes for v2.2: Delicious Library Version 2.2
Release Notes for v1.7: Delicious Library - Release Notes
Good luck, and if you have any problems, let us know!

Labels: , ,