Good afternoon. There has never been a better time to be a Mac developer. Now, why is that? Well, because we've been selling tons and tons of computers. In fact, if you look at our growth rate, the Mac growth rate compared to the PC industry, we've outperformed the PC industry for the last two years. And it's kind of like 3X or 4X for the last couple of quarters.

And so the net result of this is that we have a lot more people using Macs and using Mac OS X. In fact, if you look at the installed base of Mac OS X, it's been going up and up and up to 27.5 million. This is active users, people who use Mac OS X day in, day out. And if you step back and look at the earlier years of Mac OS X, the growth was due to people coming from 9 and upgrading to Mac OS X. While in the last few years, the growth has come from people using Windows switching to a better OS to Mac OS X.

So Mac OS X is doing great as a software platform. And this is really fantastic because there are not too many software platforms out there. Now, maybe the ancestor of software platforms was Unix in the '70s. Unix was very strong for doing backend kind of applications, but a little weak in the UI, of course. And with the Mac in 1984, we created a new software platform, one that enabled GUI applications, the kind of applications that you like to write, of course.

Now then Windows of course came in the 90s and that was kind of the establishment of the Win32 API. And quite frankly Apple was a little bit in turmoil in those days but we finally got our act together and at the turn of the century we designed Mac OS X of course.

We evolved Mac OS X and over the years it has totally replaced the original Mac. Now seeing the success of Mac OS X of course the giant up north worked on something called Longhorn. That was very ambitious, actually, quite frankly, but didn't quite pan out, so they shrank it down to something called Vista. And now some people are making a business out of removing Vista. Let me get that kind of bigger.

This is a store in New Hampshire that charges to remove Vista. So this Vista thing wins 32 forever, I guess, for better or for worse. So here we are at the beginning of 2008 with three major software platforms. That is platforms with millions of users and a great market for your application. And I think this is a year to remember because of course we introduced a new platform. That's the iPhone with the iPhone OS.

And there are not so many times in history or in the short history of computer science when a new platform kind of gets introduced like that. So, of course, I'm going to focus on the Mac, but I also talk about the iPhone OS because those two platforms share a lot in common. In fact, if you look at the technologies, a lot of the technologies underlying Mac OS are also underlying iPhone OS.

So this is going to be what I'm talking about today. I'm going to cover a number of technologies. Now, when I dive into a technology, I will try to tell what is the principles, the philosophy, kind of the methodologies that we've used, the goal for a given technology.

Then I'll give an overview of the technology because I know that there's a lot of new attendees this year, new to the Mac or new to the iPhone or new to both. So I'll give an overview to kind of state where we stand very briefly. And then I'll talk about some of our future direction in that technology area.

So this is our world of technology, and let me dive into the first technology area that's also a software platform. And of course, I want to talk about Unix, because it is kind of a well-kept secret that the Mac is actually Unix. And when you think Unix, you may have in mind a computer like this one. That was my first Unix computer, a VAX, way back then. And you may wonder, so why did we pick Unix as kind of the basis of Mac OS and then of the iPhone OS? And of course, we did that because Unix provides a number of key advantages.

The first one is reliability. Unix, after all, is what powers the Internet. The vast majority of servers on the Internet are Unix servers, which also plays in another strength of Unix, which is network. Networking was invented kind of for Unix machines and Unix machines to do networking, right? Those two things have been hand-in-hand for many years.

Now another strength of Unix is security. This is obviously becoming more and more important each year. And this is a strength of Unix because for the critical pieces of code that control the security of a system, those pieces of code have been scrutinized by a lot of people and have been iterated so they are really safe. Now, Unix also has these interesting characteristics, notably because it's so weak in UI, that it forces you to really separate the UI from the non-UI. So it forces you to have a proper layering of your application. And this actually, I think, is turning into a big advantage.

Now, Unix also provides kind of the meat and potatoes of APIs. So all the basic APIs that you use when you program are in Unix. You know, all the APIs to access the file system, to allocate memory, even basic sorts, you know, all those things are Unix APIs.

So despite its age, Unix is still very active and dynamic. There's a lot going on in the Unix space. And this is because of open source. The open source movement had totally added new vitality to Unix, and lots of innovation is taking place there. And we like to take a lot from the open source world. In fact, all of our base systems, the non-UI, is open source.

But we also like to contribute back to the open source world. And in recent years, we've added a number of key APIs back into the open source. The one that I think you know about is Bonjour, which is a way to have services discovery, easy, zero configuration, a way to administer your services or not administer them.

We've added something called NotifyD, which is to solve the problems of notifications. It's fast notifications, point-to-point notifications, or broadcast notifications to invalidate all your caches. And recently we've added LaunchD, which is the process that launches other processes. And it has a number of facilities to provide reliability, to provide timing services, to provide laziness. It is the mother of all processes. That's PID number one.

So this is what we've been doing in recent years, adding those APIs. What are we working on now? What are the upcoming APIs? Well, one that I want to mention is about cache management. And caches are very important. Most of the RAMs that you have in your application is as a form of cache. But the challenge with caches, of course, is when to flush it. And we provide a mechanism to do that.

Another thing that we've added is a way to easily and quickly terminate your application. Because it's kind of a shame when you have such a powerful computer at your disposition, you press power off, and then you have to wait, okay, for the computer just to shut down. There has to be a better way. And in fact, there is. And we've added some APIs to do that.

And then the last thing that I want to mention is an event loop facility. Because when you look at all the user interface centric applications, they have an event loop. But in fact, the demons also typically have an event loop. And this event loop is not embodied by any API. There's no facility. There's no standard way to do that.

Let me dig a little further. What you want to do with an event loop is to multiplex different sources of events. You don't want to necessarily create a thread for each source, but you'd like them to be serialized and managed in a way that makes sense. And to do that, we introduce a new API that is called Grant Central Dispatch.

Now, Grand Central Dispatch, we'll also nickname it GCD, takes different event sources and multiplexes them. ��文明,我们也��为GCD,用不同的��化源,��加大它们。 But it can also manage a pool of jobs, that is, things to do, not just response to events, you know, computational things that you need to do. And what it will do automatically is to create new threads as needed to handle all the things that you have to do.

The jobs that you have can be sequential, or you can specify that they can be executed in parallel, and that's when new threads will be created. In essence, Grand Central Dispatch is a foundation for distributing all the events, but also a foundation for multi-threading. It is the mother of all threads. So we've developed a little application to visualize how GCD works. So let me show that to you.

What I have here on the left is a visualization of event sources, events as little color balls. The events come in one by one or in trends, in which case they need to be executed serially. And GCD is this thing kind of in the middle on the right that serializes the event. Okay, this is not very fancy. Let's go parallel now and let's say I have a four core machine and now you have four lanes, four tubes, there are the threads that will get created by GCD.

I can change the number of processors, which of course changes the number of lanes. And you may say, okay, so I can do all that with a P-threads library, a library on top of P-threads. And that's absolutely right. You could do that. But what you cannot do when you have P-threads is have GCD, your library, look at the state of the whole system and back off when there's kind of pressure on the CPU due to other processes.

And this is what GCD does. It has its hands with the kernel scheduler and it knows when to back off and when to actually lower the number of threads it uses dynamically to obviously optimize efficiency. And when the pressure gets released, of course, it uses the full number of threads. So this is GCD.

So GCD is a fundamental brick we're adding to Unix. And again, you know, when you think Unix, you may have in mind a really old computer. But in fact, the sexiest Unix boxes out there are of course a MacBook Air and an iPhone. So that was a brief overview of Unix. Let's dive into another technology area, one that has to do with APIs, APIs that you use day in, day out.

And I want to talk here about our frameworks and about Cocoa. Now, Cocoa is the name for our framework stack. And it's not just ordinary frameworks that we have. They are object-oriented frameworks. Hence the name Cocoa. So it still is a surprise to me how much code gets written in non-object-oriented frameworks, you know, in things like C and all that stuff.

It is well-known and it has been well-known for many years that when you write in object-oriented style, okay, with an object-oriented library, you get a major leg up. And you don't need to reinvent the wheel. You have a rich toolbox, a higher-level toolbox that provides a lot of functionality with kind of behaviors that are built in.

You can also reuse code when you have an object-oriented framework. The primary means, of course, of reusing code is subclassing, but that's kind of meta-reusing. That's kind of the patterns gets always reused. So this is definitely true in Cocoa. You always have the same patterns coming up, the same way we structure our objects, we put together our classes. And so everything is very predictable. The naming is very predictable. When you use a class for the first time, you can guess the method names, okay, directly from your idea of what the class does.

We also have a very evolved set of classes. If you count Next Step, I think this is kind of third generation. There's a little bit of Next Step. There's a little bit of the original Mac Toolbox and a little bit of knowledge that we gained over the years. And all that is in Cocoa.

To sum it up, for me, and this is a very personal view of Cocoa, but Cocoa is very elegant. It's very symmetrical. It's very orthogonal. You are not finding the same portion of API in different places of the API set. And that is very pleasing when you use those APIs.

Now, what is Cocoa made of? Okay, so at the lowest level, we have something called foundation, which is for non-UI code. Above that, we have something called the app kit that provides all the widgetry that you expect in a Mac OS application. And above that, we put a number of specific frameworks with a specific functionality.

And then, of course, your application sits on top of this. So let me go layer by layer and talk a little more about what these things are. So let's start with foundation. So foundation provides all the basic data structures, you know, all the bag of bytes, the string, which sounds very simple, although nowadays with Unicode and collation and all that stuff, strings are no longer this very simplistic thing. And all the backpacks. So you have all the basic data structures you expect, you know, all the collections, arrays, dictionary, and so forth.

There's also in foundation access to a lot of functionalities, that system functionality, a way to localize your code, access to what computer you're running on, okay, give me some information about that computer and so forth. And that's the run loop, which is kind of the ancestor, of course, of GCD, of Grand Central Dispatch. So that's a brief overview of Foundation. Now, above it, you have the app kit.

The App Kit also proposes an application infrastructure so that you don't need to reinvent the wheel when you write an application. You can just focus on the piece of code that is unique to your application and all the rest you get via subclassing or via automatic behaviors. And many Mac OS applications are document-centric applications. And so there's also a facility, a document architecture, so that you can just subclass the generic document, and suddenly there you have your document-centric application with very little code. So that's the concept behind the AppKit.

Now moving up, we have specific frameworks, all kinds of specific frameworks, specific frameworks to access the data that is accessed by the system applications, you know, the calendar data and so forth, the address data, frameworks to access the specific kind of hardware functionality and so forth. And one question that I often get from some of you is, okay, what about functionality XYZ? Okay, why isn't XYZ available as an API on Mac OS? And so this brings a question of, okay, which frameworks do we make available? And fundamentally, it is our mission to enable your application. So we focus on enablement. I didn't say convenience here. I say enablement. That is, if you are prevented from doing something because some functionality is not there and there's no public way to get to it, we really want to solve that need.

But at the same time, we know that APIs have a very long life. APIs live forever, and we like to preserve binary compatibility at all costs. And so we want to make sure that all the APIs that we have are APIs we can maintain. And sometimes, we can't be sure of that. Maybe we know that there's some hardware that's coming up that's not going to have that hardware feature. Or maybe there's a piece of code we are not too proud of, that we haven't quite figured out how to implement it right. In that case, we have Stain.

Once we've decided to provide a functionality, we want to use it ourselves. That's the dog food principle, because we want to make sure it's just right. So we like to use that API, this framework, in our own applications, system applications, and we like to iterate with your help, with the feedback that you can provide during seeds and so forth. Fundamentally, we like to focus on quality, not quantity.

重点是我们喜欢��注于品��,不是数量。 So with that, we always add new APIs and new frameworks. We'll be adding a few. One that I want to mention, because the icon is so wonderful, is the Quick Look and the functionality, too. It's a Quick Look framework. Quick Look is this easy way when you are browsing for files in Finder, you press Paste, and suddenly you can see a preview of your document. And this is such a nice functionality that I think you should build that in a number of your applications. And we want to provide you an API to do that.

Now, we're adding entire frameworks, but we also add lots of little APIs throughout the stack. Okay, we always do that. So, for example, since we shipped Leopard, we've added already something like 750 new methods throughout the stack. This is to fill little gaps and to enable you with one functionality or another. We also have another thrust here.

We want to make sure that if you develop a Cocoa application, you'd never need to go to the old API, the old toolbox that is called Carbon. And As you know, we are putting Carbon on a path for obsolescence. And we want to make sure that your Cocoa application can be totally Carbon free.

This is what we're doing with Cocoa, a very, very high-level 10,000-foot overview of Cocoa, and this is for the Mac. Now, what about the iPhone? Well, the stack is, of course, very, very similar and shared in many cases. Instead of Cocoa, it's called Cocoa Touch. At the bottom, you have Foundation.

It's the same Foundation that provide all the same facilities. And this is really important because if you have an application that has, you know, like the Iceberg earlier, that has a lot of non-UI code, okay, that non-UI code can be exactly the same between your Mac application and your iPhone application.

Above that, the app kit turns into UI kit. Obviously, the widgetry is different because the UI is different. But it's the same paradigm, the MVC paradigm underneath it all. And so you have classes that parallel the classes that you find on Mac OS. So if you are familiar with the Mac, you'll have no trouble with the UI kit set of classes. And just like on the Mac, there's an application architecture so that you don't need to reinvent the wheel to do an application. In fact, you saw the demo that Scott did this morning where an application was built from scratch from, you know, new application in Xcode.

Now, there's no document architecture with UIKit, but of course we have other things like touch, okay? Touch built in throughout the UIKit. So that's UIKit. And on top of UIKit, you have a number of frameworks, just like for the Macs, but that are specific to the iPhone. Two that I want to mention is CoreLocation, that has been demonstrated many times this morning, and the accelerometer, again, that is -- that apparently you love using already.

So this is our stack, Cocoa, Cocoa Touch, to create Mac applications or iPhone applications. And of course, this is kind of the main focus of this conference. There are over 40 sessions that span Cocoa and Cocoa Touch. So this was frameworks. Now let's go into another technology area.

This is the teapot technology area. How to color a teapot, how to apply textures to a teapot, how to transform a teapot, how to modify the teapot, and so forth. Of course, I want to talk here about graphics. Now, when we designed Micro S10 back at the turn of the century, we knew we wanted to have a brand new UI, Aqua.

And we knew we couldn't do this kind of UI that didn't exist in those days without really solid graphics underpinnings. We wanted to do effects, you know, like the genie effect, never done before as part of the US. We knew that we wanted to do graphics. We knew we wanted to have a high level of compositing going on, you know, at all times.

And so we built a number of technologies like our Windows Server that manages all the windows of all the apps on the screen. Like the ability to have multiple client-side drawing libraries. And we had, in addition, some great ones. And compositing built in all this, okay, definitely from the lowest level to the highest level.

Now, we also made another bet way back then when we designed Micro S10. It's to bet on hardware acceleration because we could see coming a lot of power in those GPUs. And so, we decided to build in right into the U.S. OpenGL. And, of course, what we had in mind then was to do games, okay? And this is what you've been doing way back then is a lot of OpenGL games. But we knew that we could do a little more with that.

And, in fact, by the release in 2002, we had built OpenGL even deeper in the U.S. And we started to use the facilities that it provided to do effects like expose or like fast user switching. This was all made possible because we slight open -- we sliced OpenGL underneath the Windows server to accelerate the -- the fundamental window operations.

And in some sense, we were kind of lucky to have bet a lot of the technology on GPUs because the graph for the number of gigaflops you get from a GPU has kept going up and up and up and up. And as you know, Moore's law has kind of stalled on a mono processor. They haven't increased in megahertz every year as they used to. On the other hand, the GPUs have continued to be exponential and probably are going to do that for a while.

So along with more power in terms of raw kind of gigaflops, the GPUs turned programmable. That meant that you could download a little piece of code onto the GPU that would do the program that you want. And so we used that for a new technology that we called Core Image. And Core Image is about that.

It's about specifying on the client side what the effect that you want, the imaging effect that you want, and then downloading that code to the GPU, which gets executed really, really fast. And of course, all kinds of applications have leverage of Core Image, including a number of your applications. This is, I think, Pixelmator that uses Core Image to its advantage.

So this was great, applying effects to images. But we knew we wanted to push that even further. How about using that in time? That is, at every frame, we wanted to apply an effect. Essentially, that's kind of like making a movie in real time. We wanted to use the time dimension. And what was great is that the latest GPUs, the ones that arrived on the market a couple years ago, enabled that, enabled real time effects. And we created a new technology to leverage that. That is called core animation.

Core animation is best on all the knowledge that we've gained by doing lots of animation in lots of the system application, in some system facilities, and other apps. And we finally cracked the code here. And the code is to let people not specify, or to, by default, make the animation implicit.

That is, you set your state. And automatically, the animation happens. Rather than trying to put timers and cadence, everything that needs to happen to your scene, you just specify the state. And the system does that for you. And we've started to use that to our advantage throughout Leopard. Of course, Time Machine uses Core Animation. And there's different facilities in Leopard that use co-animation. Even other product lines started to use co-animation. Apple TV, for example, uses co-animation for its menu subsystem.

And of course, the iPhone uses Core Animation. In fact, the iPhone created Core Animation. We first did Core Animation on the iPhone because we knew that we wanted to have a very fluid user interface. And we also knew that we wanted something super efficient because the GPU that you have, the GPU cores that you have on the iPhone is nowhere near the kind of GPU that you have on a Mac. And so, co-animation provided this ease of specification of the animation with the efficiency that we needed.

Okay, so this is all kind of the past. Now, where we stand today, one teraflop is in sight. Now, this is amazing, right? I mean, who would have guessed 10 years ago that we would talk of a teraflop ability to compute data on a desktop, okay, something that you can have on your desk? So what do we want to do with that power? Well, we want to unleash that power for everyone, not just for graphics.

And so today, I'm pleased to introduce a new technology that is called OpenCL. Now, OpenCL is for any data parallel algorithm. 開CL是任何數學平��數學的數學數據。 So it's great for graphics, but it's not just for graphics. 它很棒是畫面的,但它不��是畫面的。 It's for all forms of media, audio and so forth. 它是所有��體的各種,音樂之類的。 It's for any place where you have physics. 它是任何有數學的地方。

For the language, we started with C.

So OpenCL is mostly C, C99. We applied some restrictions to pointers because GPUs cannot follow pointers very efficiently, and you cannot parallelize some pointer-based code. On the other hand, we enhanced vectors. So a vector is essentially an array of number, but we added some semantics to vectors. For example, that no one can go behind the back of the GPU, say, and change a vector when the main code is acting on it.

We added some control flow primitives. In fact, we added one primitive, which is barriers, to make sure you can synchronize your code. And we also acknowledge the fact that in modern computers, you have different memory subsystems. You have typically one for the CPU, one for the GPU. And so we added memory address qualifiers.

In terms of the runtime, we are compiling OpenCL code down to native. And it's a just-in-time compilation, so it's all totally dynamic. Because of that, it works for CPUs as well as GPUs. So it works with one CPU, with multiple CPUs,

And also, it works with any combinations of CPUs and GPUs, because underlying OpenCL, you have the same infrastructure that is in Grand Central Dispatch. So what I'd like to do at this point is to invite John Stauffer, who is the director for graphics and imaging, to demonstrate OpenCL to us.

So thank you Bertrand. What's on the screen here is basically 16,000 stars each feeling the gravitational effects of each other. And so this is an N squared mathematical problem. Really, really computationally expensive. And the mode I'm running it in right now is what you would get if you were to take that algorithm and see, compile it and run it.

Okay. And we're getting about two gigaflops of compute power as you can see from the gauge in the right hand corner here. Gigaflops being billions of floating point operations per second. So now what we're going to do is we're going to take that piece of code and we're going to host it up into OpenCL and we're going to use the language features of OpenCL So this is still running on a single core on the CPU, but we've gone from 2 gigaflops to 11 gigaflops. Now, with OpenSeal, as Bertrand said, it's on top of Grand Central Dispatch.

So what I can simply do is just tell OpenSeal to run this across all the cores in the system. So now we've gone from 2 gigaflops to 66. But OpenSeal runs across CPUs and GPUs. I take that same code and run it on the GPU. So let's do that. So now we've gone from 2 gigaflops to 205.

And you thought that was great. It can run across CPUs and GPUs. So I've got one more. I can run it across the CPUs and GPUs at the same time going to 240 gigaflops. So I've gone 120 times faster than the original code. So, you know, we started asking ourselves, what kind of interesting things can we do with this horsepower, this computational horsepower that OpenSeal gives us? Well, one thing we did is we simulated the collision of the Andromeda in the Milky Way galaxy. And the blue dot is Earth. So thank you. We think that OpenCL is going to let you get access to all the great horsepower in the system. Thank you very much.

Thanks, John, for showing us our future. So we have a wealth of graphical technology. OpenGL, CoreImage, CoreAnimation, and now we're introducing OpenCL. But again, OpenCL is not just a graphics technology, something you can use for a wide range of computational applications. So this was kind of a little history and heads up on where we stand with graphics. There's, of course, another technology area which is very closely related to graphics, and that's how to display movies. And we usually in this conference display Pixar movies.

Of course, I want to talk about QuickTime. Now, QuickTime is really great. It's QuickTime created kind of the whole digital media kind of industry. It's the technology that was foundational many, many years ago and that we still use, that we've kept adding to over the years. So, one thing that's really great about QuickTime is that it supports all kinds of formats, you know, all the modern formats that matter, a whole bunch of legacy formats, and even some experimental formats that never really mattered.

Now, QuickTime is really good because it can do everything. It can do playback, of course, but also it can do simple editing. And that really scales all the way to high-end editing, high-end offerings that we do with our applications like Final Cut Pro. And that you use in a number of your applications.

So, there's a lot of wealth here. There's a lot of richness in QuickTime. But as you can tell, it's a little hefty. And so, when we decided to have media facility on the iPhone, we decided to start from scratch with everything that we've learned over 20 years of doing multimedia kind of systems. And we built that right into the iPhone.

And the iPhone only supports modern formats. And it only supports playback. And this stack is so efficient. It's fast and lightweight and battery efficient. It applies all the knowledge that we've gained on how to build a synchronous systems, multi-threaded systems. It's really wonderful. So, we've decided to bring that stack back to the Mac.

So what we will provide is a single API. We are not changing the API. The API remains QtKit, which is the object-oriented API to QuickTime. But there will be one more thing that we add to that API, which is the ability to specify your intent. And if your intent is playback for just modern media, then you will go automatically to the new stack, the lightweight stack, and you will benefit the extended battery life and so forth. So this is a very simple thing, at least simple for you, but it's very profound. So we decided to give it a name, and that's QuickTime 10. And we also have a new icon for it. So that's the new QuickTime.

Let's now go into another technology area, one that spans the whole set of layers of Mac OS X, one that affects all the binaries, or I should say that should affect all the binaries. I want to talk here about 64-bit. Now, right off the bat, I'm going to say this: this is just for the Mac. There are no plans to have an iPhone that's 64-bit any time soon.

Now, you may say, OK, so why do I care about 64-bit? Why has Apple put 64-bit capable processors for the last couple of years in every single machine? And the reason is twofold. The first reason is that 32-bit is starting to be a little too tight. We want to stuff more and more things into that address space. We have a lot of multimedia contents. And when you have a raw file at several hundred megs a pop, very quickly your address space is starting to be a little too tight here.

Now, there are techniques to solve that, like you slice your files and then you go through your files in little slices, but it's very painful. So we want to simplify applications, not make them more complex. So that's the first reason to go to 64-bit. But the second reason is, of course, performance.

Now, that's a little trickier here because unlike many other things, okay, like the increase in speed of GPUs and all that stuff, 64-bit is not necessarily win-win because your pointers are growing by a factor of two when you go to 64-bit, and some of the other data structures are also growing by a factor of two. So you consume a little more memory with 64-bit. On the other hand, the processor is really optimized for 64-bit instruction set, a lot more registers, able to crunch the information in bigger chunks, and so overall 64-bit goes faster.

To kind of convince ourselves, what we did is we measured a number of programs in both 32-bit and in 64-bit, and we compared them. We took programs across the whole spectrum, you know, things that are applications, things that are hardware, things that are hardware, things that are math centering, things that are system, and they are color-coded.

The categories are color-coded on the graph. And on the Y axis is a ratio of 64 over 32-bit. The green line is parity. And it turns out that the vast majority of everything we tried goes faster in 64-bit. In fact, the average geometric mean of the various data points that we have is around 15 percent.

Now, I don't know about you, but I think you're going to be surprised. I know of nothing that takes very little effort and that buys you 15 percent system-wide. This is a huge improvement. You know, system-wide improvements typically are 1 percent, 2 percent, not 15 percent. And this is why we're heading to 64-bit at the greatest possible speed. So let me show that to you on a small demo. demo here.

I have another data set that refines a little bit the portion. This is a portion of the brain that has an aneurysm, which is kind of conditions that you really don't want to have. This is fatal if not treated. And I can go into 3D volume rendering. And this is what doctors would have. And so now I can kind of see in 3D, I can rotate this section of the brain and get a good look at the growth here.

And there's about 75 views that are getting generated in real time from the 3D model. And this is a 32-bit application, and it takes about 17 seconds. So we recompiled that application for 64-bit. Let me run that. Same data set, same algorithm, same code recompiled. Same 75 views of the aneurysm, and it's done. 54% improvement. So this is a real life application that shows a significant improvement, and that's the reason why you want to go to 64-bit.

So over the last releases, we've moved as fast as we could to a 64-bit. If this is kind of a representation of the layers of the system, we've made sure in Leopard that all the APIs in the frameworks were 64-bit capable. Now, the way we do that is, of course, we glue together the 32-bit and the 64-bit binaries so that there's a single binary.

So you don't need to have any configuration or anything like that. It's all automatic. On a 32-bit machine, you'll run a 32-bit version of the app, and it will use the 32-bit frameworks and 64-bit equivalent. So we've done that, and this has enabled you to... create applications that are both 32 and 64.

So this is great. Okay, and I know that a number of you have started doing that. But there are two things that we haven't done. The first thing is to take our own applications, the system apps, and make them 64-bit. So we'll be doing that, and there is an application of doing that.

The implication is that if you have a plug-in to one of the system apps, you now need to be... 32 plus 64. So that affects the screen saver plug-ins, all the prep bands, the Safari plug-ins, the web plug-ins, QuickTime plug-ins, the printer plug-ins for the portion of the printer plug-ins that runs in user space, and so forth.

The other thing we haven't done is to run our own kernel in 64-bit. Now, we have to do that now because the amount of RAM you can stuff onto a computer is hitting a wall because every time you add physical RAM, you take a tiny fraction of that RAM to store your map tables, all your tables that map for the kernel to the wired memory. And so, all together, we hit a wall around 32 gigabytes of physical RAM.

So, I know that you all want to have 32 gigabytes on your portable. I'm not sure when that will occur, but at some point in the future, I'm sure this will occur. And definitely, on the high-end machine, this will occur. So, we want to enable that. And so, the consequence of doing that is that if you provide a kernel extension, you now need to be running in 64-bit as well. So, that applies for everything that touches the hardware that you provide, so a printer driver or some dongle driver or any kind of extension to the kernel, say a file system extension for those of you who have such things.

So fundamentally, this is a call to action. We want your application to be both 32 and 64. And you can do that today. And soon, we want all your plugins to be 32 and 64, whether it's your application plugins running in user space or your system plugins, your kernel plugins running in kernel space. So that's 64-bit.

Now let me dive now into another area, one that again applies to all the layers, one that I think has deep ramifications in how you program in the future. And I want here to talk about multicores. 和我想在這裡談談多重的問題 Because multicores are a fact of life. It is very clear that multicores are here to stay.

From now on, there will always be more cores because this is how Moore's Law is expressed. It's no longer expressed for CPUs as megahertz that increases. It's expressed by more cores. Now, why is that? Well, the reason is really physics.

So, they say multicores are in our future. There's just a little problem here. And the problem is, how do you program multicores? Right? It's a big head-scratcher. And the traditional answer to that is multi-threading.

Let's take a simple example. Let's take the simplest algorithm I could find here is the sort, the classic sort. So I have an array with n kind of items, and I want to sort it. So, well, okay, I'm going to sort this half of the array, sort this half of the array, and merge. Okay? Simplest algorithm.

So let's say I want to thread this using pthreads or something like that. So the naive idea is, okay, let's take this half of the array and do that in a thread. And let's take the other half of the array and do that in a thread. Sort that in a thread. So, okay, so I need to do that. So to do that, I'm going to use the pthreads library.

I need to introduce kind of an auxiliary function because with pthreads, you need to wrap up all your arguments before you call the pthreads library. And you wrap up your arguments, pass that to pthreads, fork those two threads, and kind of gather, rejoin those two threads. So you can do it. There's just two problems with this. Okay? The first thing is that this is cumbersome. Okay? That nice, simple algorithm that was kind of sorting that anyone could read here is no longer simple.

The second problem is that the way I've done it is very inefficient. If there's anyone who is algorithmically inclined, you will realize that I forked n threads to sort my array with n items. That's not going to work great when your array is large. In fact, if you have an eight-core machine, you don't want to ever create more than eight threads. It's just a big waste.

So this is another way. Is there a better way? And we believe there is. And we call it: Grant Central. That's our codename for this strategy. And we believe that to address the multi-core problem, we need to act at several places. We need to act at the level of the language, We need to add a new runtime to the system.

And we need to add new APIs. So let's look at each of those. First, a new language feature. Let's go back to our classic sort. What you would like to do is to take those two lines, you know, the two sorts of the half of the array, and say, well, this block of code, I want to do it on its own, okay? I want to fork of thread if necessary. So you want to get a handle on those blocks of code, and you want to give those blocks of code to the runtime. So we're adding a new feature to the language that we called Blocks, which is exactly about that.

What blocks enable you to do is to take just two lines of code, put a caret in front of the block of code, and suddenly you get a handle. You get a value that you can pass around. It's a very, very simple concept. It's how to get from a block of code to a function.

Now that you have your two blocks of code, you can have runtime do all the work. That is, fork threads if necessary, execute those two blocks and rejoin. This is clearly a very, very,

And it hides all the thread creation. It will create threads automatically if needed.

Now, the beauty of GCD is that it will scale up with the number of calls that you have on your machine, but it will back off and scale down when all the calls are busy. As you saw in the visualization, when you apply pressure, it backs off. And this is something that you can only do if you have your hands into the OS scheduler itself. So that's the runtime. And of course, the last piece is new APIs. So we've taken our entire layer, and we're adding new APIs so that it's capable to do multicore. We're adding that at every layer, APIs that can do blocks, APIs that can do GCD.

So this is Grand Central, a new language feature, a new runtime, and new APIs. Now, to take an analogy with what's happening, I think it's very profound. It's very similar to what happened with networking way back then. You know, networking a long time ago used to be based on circuit switching. When you wanted to communicate to someone, you would open this circuit, And all the communication would go across that circuit.

But of course, that's a very inefficient way to deal with networking resources. And pretty quickly, people realized that instead, you should use packet switching. Even for continuous communication, like a stream of voice, you cut the voice into little packets. And the whole networking infrastructure is responsible for routing the packets, not necessarily always the same route to the end destination.

Well, I believe the same thing is happening with computing. Instead of having a dedicated processor that you use for your program and just you, or two processors or four processors, whatever you build in with traditional kind of multi-threading approach, instead of that, You just think in terms of packetized computing, little packets of computation. Those are blocks.

So this is quite a different approach. Instead of parallelizing your code, what you are doing is you are cutting your code into little blocks. This is a lot more convenient, as you saw on a very simple example. And of course, as the complexity of the code increases, it's even more convenient.

It also means that you always size things right. You don't have to know that you're running on two processors, four processors, or whatever. It's always ideal for the number of processors due to the runtime. And that enables us to have a much finer grain. You know, when you use P threads, you have a tradeoff of whether to use a new thread for something or not, which is around 10,000 and 100,000 function call equivalent. If you have less than that, there's no point in forking a thread. And we believe we can bring that down by three orders of magnitude with blocks and GCD. Thank you.

Also, Grand Central unifies the response to events, event-driven programming, and jobs, you know, things to do. In fact, when you are sorting, you know, this little sort example, you can conceivably think that you are creating a little event loop that's going to do the two halves and then rejoin. And it unifies CPUs and GPUs as we saw with the OpenCL demo. So this is Grand Central, and it's a different approach to multicores.

The last technology area I want to touch upon is tools. It's something that you interact with day in, day out, and that I know is really important to you. So tools are, of course, a missing link between the frameworks and your application. Well, no longer missing because we have a great set of tools. Now, we had in mind that we A number of principles when we designed our set of tools. One of the principles is to always make sure that your code is center stage.

So we try to reserve the maximum real estate on the screen for your code in our tools. And that's a basic principle. Another one is that we capture whatever you want to do at the highest level. We don't like, for example, to generate code that you need to hand-edit afterwards. Instead, we prefer to keep the code at the highest level or whatever specification you have at the highest level and not degrade that.

We also want to do direct manipulation as much as possible. So rather than having codes that move the window or that sizes a window, well, you just size a window, OK, obviously. Now, we use our own tools for developing the whole system. All of Mac OS is developed with our own tools. All of the iPhone OS is developed with our own tools. So we want to make sure that our tools are really, really efficient.

And of course, you benefit from that. Now, one thing is that we always strive for simplicity in the tools. Now, that's a challenge because there's a lot of you who use tools in a lot of different ways. But we always try to keep them as simple as we can.

And we believe in the power of generic tools, but also in the power of specialized tools. And so we will be talking about, you know, the top tools, but we'll also be talking during the conference of some of the second-order tools, you know, the ones that have a very specific goal in mind to do something very specific.

So briefly, what are the tools for the Mac? Talk first about that, and then about the tools for the iPhone. The top three tools are Xcode, which is our IDE that enables you to write the code. Interface Builder, where you specify the user interface. And after you've built your app, instruments to optimize your application, make sure it performs. These are the three main tools for the Mac.

What about tools for the iPhone? It's the same, right? This is fundamental. Our tool set

So that was a key message about the tools, the fact that they are the same. Okay, all the knowledge that you have applies. And of course, we cover that in a number of sessions at the conference. So that was the last technology area I wanted to cover.

There's a lot of technologies in Mac OS and in iPhone OS. And I wish I could actually talk about a lot more, but I'm going to run out of time. Because there's one more thing that I want to talk about. And it's the Mac OS releases, of course. Now, as you know, we launched Leopard last October. 現在,您知道,我們在去年10月推出了��肉 And it's been our most successful OS release we ever had.

In fact, it's amazing because here we stand roughly six months, seven months, eight months maybe now after its release, and we have already 37% of our users who run Leopard. And when you add together Leopard and Tiger, 86% of our users run those two releases. That means that, you know, quite frankly, you should not spend any time making sure your application works on anything else besides those two releases because it's a very small portion of our users who's not on the last two. And this is great.

I think it's great for us and it's great for you that our user base kind of moves along very quickly. So Leopard was the sixth release in seven years. And we've added over the years tons and tons of features. Each release had brought its share of features. In fact, over the last six releases, if you add them up, we've added 1,000 features.

So, what do we do for an encore? What's the next big cat? Well, of course, Steve and some websites have mentioned... That's the next big cat is called Snow Leopard. And you may wonder, OK, so how many features are there in Snow Leopard? Is it 200 features?

We are going to do something that is unprecedented, I think, in the industry of OSes, OS releases. We are going to have a release with no new features.

Instead, we are going to focus on technologies. Because our core asset is our stack, our software stack. We want to make sure this is as pristine as we can make it because we want to invest to go to higher heights in the future. We want to reach new foundations. We want to have a higher degree of quality, a higher degree of performance. We want to enable our release for future hardware, whether it's new multicores or new GPUs. So, no new features.

Well, actually, that's not quite true. We have one new feature.

Because there's a very interesting phenomena that's happening right now. People love the Mac that they have at home, and they want to use it at work. And there's just one issue, which is exchange support. And of course, the iPhone has provided Exchange support by ActiveSync. And this has been extremely well received. And so we'll be doing that on the Mac as well. We will add direct exchange connectivity in our free main communications application, Mail, iCal, Address Book.

This will require a recent Exchange Server, Exchange Server 2007. So when you go home, check out what is your Exchange Server. If it's not 2007, tell your IS folks to upgrade. I'm sure Microsoft will be pleased. So this is the feature of Snow Leopard. Snow Leopard will ship in about a year from now. But today, we will give you access to a developer preview.

It's a very early version of Snow Leopard, but it has all of the technologies I've been talking about. You know, things like OpenCL or GCD. And our main goal here is that you give us feedback on the new APIs, on the new facilities, so that we have time to iterate.

So I've been taking you through two of some of the technology areas that underlie Mac OS and the iPhone OS. I hope you will enjoy all those technologies, and I hope you are going to create great Mac applications and great iPhone applications on top of these two software platforms. Thank you.