WWDC2001 Session 201

Transcript

Kind: captions
Language: en
good morning welcome to session 201 how
threading can benefit your application
on Mac OS 10 my name is Mark Tozer
belches I'm the desktop technology
manager in developer relations so today
what I'd like to do is start the
conversation actually first of all I've
gotten kind of feedback from the fact
that our session title is the longest
one at the set at the conference this
year so I've been asked to take some
input at the end of the session for
title suggestion so make sure you give
me some input I need to shorten that
here is what I'm being told what I'd
like to do is kind of go over some of
the ways that Apple computer has been
working to optimize system performance
and some of the ways today we'll talk
about how you can optimize system
performance through hardware and
software so what I'd like to do is kind
of take a look at how you know we
introduced systems at these keynote at
shows like Mac world and so forth and
you know aside from the features of new
functionality design performance is one
of the key customer messages that we
deliver to our customers customers wants
to be able to say that they're gonna buy
this new piece of hardware their
applications are going to be able to run
faster right so performance is a key
message here how does Apple to address
performance aside from increase in the
megahertz well they're do different ways
we can do that we can use the processor
technology the g4 that we've migrated
throughout our product line so the most
recent addition has been the titanium
PowerBook g4 other ways we've done that
is last year at Macworld New York we
introduced dual processor systems so the
ability to now have to g4 processors
with to g4 velocity engine available to
you as well other ways is the unified
chip architecture for i/o on the bus has
also been improved so information can be
passed along the bus much more
efficiently so what are the ways that
you as a developer can take advantage of
these technologies well there are api's
that we put out there
so the NPAPI has been out for at least
three or four years velocity engine API
has also been out there so those are
ways that you can optimize your code to
take advantage of some of these hardware
technologies multitask any multi thread
multi-threaded are also ways that you
can increase performance just through
the application and not have to worry
about the processor being faster at the
root of all of this is obviously OS 10
and this is what you're gonna learn
throughout the whole week of how OS 10
provides all the functionality and
abilities for you to optimize your code
without having to worry about when is
Apple going to deliver a gigahertz
processor well today what you should be
really asking yourself is when are you
going to optimize for the api's that we
have today and increase performance on
today's processors one of the area's
also that I want to kind of clarify or
some of the definitions that we use in
this type of presentation and
conversation about optimizing for
hardware multitasking is the ability to
handle several different tasks at the
same time multi processing is the
ability of the OS to actually utilize
more than one processor at the same time
SMP or symmetrical multi processing is
the ability of the OS actually be a
little bit intelligent of how to
schedule the actual functions and that's
the execution of code across multiple
processors to actually balance the load
so to speak can we go to demo three
machine to give you an example of what
that looks like
here's QuickTime running three different
movies if you can notice the system is
actually utilizing both processors and
they're pretty well balanced QuickTime
itself is is actually threaded so
because of SMP the OS basically knows
how to hand off to each processor the
task of pushing pixels to the screen so
if we had if QuickTime itself was not
threaded if it was a single threaded
application or technology you would see
one processor being overloaded in the
second processor kind of getting some
time when the operating system actually
divvied up some of the tasks
can we go to slides please so what I
like to do is introduce Matt Watson
Coriolis engineer who will actually
deliver today's presentation on why you
should be threading your application for
Mac OS 10 thank you thanks mark so I
work in the core OS group at Apple and
we're responsible for most of the lower
level darwin source code and i
specifically work on the user level
implementation of darwin so why do you
want to use threads in your application
what Mark alluded to earlier was the
user perception of the marketing message
we've been sending out for Mac OS 10 is
it's fully preemptive support symmetric
multiprocessing so customers are going
to expect that their applications are
going to run more efficiently and scale
better on multiprocessor machines so to
take advantage of that if your
application can perform tasks
simultaneously and you're running on a
multiprocessor the customers are going
to expect that added benefit of
performance since Mac OS 10 is fully
pre-emptive you'll notice that all the
applications are getting time sliced
simultaneously and if your application
has multiple threads it's going to get
more than another application share of
that time so you're actually going to
see the benefit directly in your
application in some applications you
might notice that synchronous requests
would block the UI so we want to avoid
that we want to make sure that if you're
coding and you're using an API that
could block for an indeterminate amount
of time a an extra thread in your
application could help prevent the UI
from blocking and let that other
requests complete also polling is
considered bad on Mac OS 10 we don't
want applications to constantly check
for state and one way you can do that is
through some of the synchronization
mechanisms that I'll discuss in a little
bit where you can have a thread that's
waiting for an event to occur in the
background
and it will only continue after that
event has actually fired
so most cases your application may not
need to be multi-threaded in a lot of
instances there are some times when the
added complexity of a thread may change
the logic of your application if it was
written originally to be single threaded
and you have lots of global data your
locking mechanism may not be as robust
as you have originally designed there's
a little bit of added overhead for an
extra thread to come into your
application there's some kernel
resources that are associated with that
and you basically need to decide when
you're designing your app which portions
of your application make more sense to
be multi-threaded there may also be
other options that make sense in a GUI
application you always have a run loop
going that's polling for events and if
you can use a timer for a short-lived
task that might be a better option in
certain cases some of the overhead I was
talking about in a pre-emptive
multitasking operating system a context
switch is what occurs when the kernel
decides to go between different threads
that are running on the system and
there's data associated with every
thread basically the register state that
each thread takes up needs to be saved
and restored between threads there may
also be extra register state depending
on if that thread has used
floating-point or even the velocity
engine and that amount of data is
obviously a little bit more expensive
when you're switching extra threads
throughout your application the thread
memory footprint is also something that
might be significant in Mac OS 10 every
thread gets a virtual half a megabyte of
stack space for instance which is
controllable when you create the thread
but you have to be aware of that so if
you're creating a thread that only calls
one function you may want to reduce the
stack space and I'll discuss API is to
do that or a little bit later thread
creation in its in and of itself is a
little bit of overhead that you need to
worry about because the act of creating
a thread introduces those kernel
resources there
a set of mock api's that is used under
the covers to create threads and the
calls that you use to create the stack
and the actual thread itself take up a
little bit of overhead throughout the AP
is that Mac OS 10 provides for
multi-threading there are some common
concepts all these api's let you create
a thread and let the thread exit itself
there are synchronization primitives
that let you coordinate the events that
are occurring between multiple threads
and every API will have a set of threads
safe services they the documentation
describes things that you can and can't
do for multiple threads we're working
toward making it a lot easier so that
you don't have to worry about which AP
is our thread safe by making sure that
everything that you call will be thread
safe but that's not quite there yet in
Mac OS 10 threads are the scheduling
primitive it's the unit that the kernel
uses when giving up the work that needs
to be done at every time slice our
threads are fully pre-emptive so the
kernel will interrupt a thread that's
running to start the next thread there
are some exceptions to that where we
have some scheduling models where a real
time like API can be used to specify
somewhat of a deadline schedule where
you can say I want my thread to run this
long but in most cases the default
threads that get created are normally
preempted we use a priority based
scheduling model so by default all
threads get the same priority when you
create threads or after the thread has
been created you can change or modify
that priority so if you have a thread
that needs to be more important than
other threads either in your application
or system-wide you can change that you
can also depress the priority of a
thread if you want that thread to be in
the background more if it's just doing
some low-level work that doesn't need to
be in the user's face we use a one to
one threading model which means that as
the api's I described are calling into
the low-level kernel threads we use a
single kernel thread per high-level
thread concept so as I discuss these
api's keep that in mind
there are other implementations out
there where you have multiplexing of
threads in userspace per kernel thread
but the added complexity of that and
scalability on empty machines makes it a
little bit more difficult to justify on
OS 10 mock threads as I said are the the
basis of our threading model in general
you can inspect the mock thread by using
the mock API but you really want to use
the API that's appropriate for your
application if you're writing a
high-level carbon or cocoa application
you stay in those api's if you want to
inspect the thread state if you're
writing a performance tool or something
along those lines you can actually use
the the mock API directly but we
discourage it because if for instance
you change a threads priority through
the mock API and not through the API
you're using that API may not notice it
so later on your thread scheduling might
behave unexpectedly so this is a slide
we've shown before and what it's trying
to show is the an example of what
happens if you take an application and
run it on a multiprocessor system with
more than one thread and the numbers
along the edge of the bars there are the
multiplier factors for the improvement
in performance so you can see the first
third and fourth numbers are all under
two but that second number is above two
which is kind of interesting and it's an
exceptional case where you might wonder
how I could get more than 2x performance
improvement on a multi-threaded
application well if you have two
processors in the system you also happen
to have two caches so if your data set
fit in the primary cache you would
wouldn't see more than 2x performance
improvement but what happened in this
case was the data set was able to be
split up across two caches and you
actually got a little bit better than a
2x performance improvement so you may be
surprised in your application depending
on the size of the data that you're
manipulating how about how good your
performance can actually be in the mock
implementation it was designed from the
ground up to be full symmetric
multiprocessing so we don't have any
special case code
for a single processor dual processor
everything on the system is designed to
be run on a multiprocessor machine the
velocity context I mentioned earlier is
something that has to be saved and
restored across processors and that
context that gets saved is a little bit
expensive that's what I was mentioning
about the overhead you might need to
worry about on OS 10 we use the same
kernel binary for either a single
processor or a multiprocessor system we
don't have a special install for a u P
or an MP system this basically makes our
own development a little bit easier we
don't have to QA two different kernels
on the system and it's a little bit
easier for us to do the install as far
as making sure that customers all have
the same bits on their machines the mock
scheduler was inherited from the OS f
the open software foundation we use a
scheduling framework that they designed
but we've modified it heavily for our
own use it has a global run queue
meaning that all the tasks on the system
get switched through on every context
switch the tests that are runnable I
should say the system notices that if
you're on a multiprocessor system you
have an idle processor so it will go and
schedule a thread to be on the most idle
processor at the time so we don't really
have a notion of thread affinity it
might be a term you've heard of before
where you can have a thread running on a
single processor for a long time the
kernel will basically balance the
resources of the system as best it can
and as I've said before preemption is
key here every thread gets preempted as
it goes through the run queue the user
frameworks that you'll see when writing
a multi-threaded application are
probably just the same frameworks you're
using for your application there's
nothing really special most of the
frameworks that we have have an API for
threading in Carbon it's the MP or MP
task API that has been out for a few
years in cocoa there's n s threads which
are used both in the non GUI and GUI
frameworks and in Java we have Java
thread
which is just a special implementation
that is using the the underlying
primitives in Darwin all of those three
api is depend on the Darwin P threads or
POSIX threads api's and since I work in
the core s group that's actually the API
set that I'm most familiar with and I'll
talk about that in a second P threads as
I said is the basis for all threading
models every API that I described goes
through the P threads layer so when we
make changes in enhancements to the P
threads layer all of those API sets take
advantage of that I put in quotes there
it's a light implementation the the
history behind that is when we were
trying to decide on an API that we could
use to implement those higher-level
threading models we chose P threads and
the implementation decisions were driven
by those higher-level api's so if you
look in the header file and our
documentation you might see that there
are some API calls missing and in
general we're working toward flushing
out that API but the design goal was to
help ensure that the higher-level carbon
cocoa and Java API is could do their job
we use a one-to-one mock to P thread
implementation as I said that reduces
the complexity of our user level code
and helps the scaling on an MP system
better in P threads there's some common
API uses and misuses if you haven't done
threading before P threads is a fairly
well-defined standard you can go to your
local book store and get a book on it
I'll talk about some of the ways that
you'll need to be careful when using P
threads on our implementation for
instance one case we don't have any
system-wide type so in P threads there's
a specification that provides global
shared memory based mutexes and
condition variables for signaling those
can be implemented in your own
application but we don't provide those
api's right now one thing that you might
need to remember is synchronization is
not cheap in P threads the model that P
threads uses has a mutex lock associated
with a condition variable and for the
to be properly used in anatomic fashion
we have to use some kernel resources to
do the signaling when you're
synchronizing between threads the
default behavior for a pea thread as
specified by POSIX is that threads are
what's called joinable which means that
when you create a thread the operating
system will hang around and wait for
that thread to finish if you want your
thread to go away and do its job and you
don't want to worry about it anymore
there's an API to detach that thread
which just means let it do its job I
don't want to hear about it
let it finish on its own as I mentioned
earlier the stack space for a thread is
by default half a megabyte now it sounds
like a lot but it's all virtual memory
that is used on demand so if you look at
process listing you might see your
application using a lot of virtual
memory but unless it's actually been
touched the system hasn't allocated that
for your application yet so it won't
cost you as much as you might think but
even given that if you have a lot of
threads running in your application you
may want to create them with an
attribute saying I want my thread size
to thread stack size to be smaller and
if you do that then you can limit the
visible virtual memory used by your
application in the POSIX specification
for conditioned variables and signalling
there's the notion of a predicate which
is when you want to signal that
something has happened there's a mutex
and a condition variable associated with
that but there's also some external
condition that needs to be checked for
so you can have a global volatile
variable that says this thing happened
well if you just use the condition and
mutexes without having a global variable
the API won't work properly and this is
discussed in a lot of POSIX thread
specification texts you can just look
this up the the most common error that
people use is they try and do signalling
without a predicate our implementation
of P thread cancel which when you start
using threads or you if you've used
threads in other systems you might want
to try to cancel or kill a thread that's
currently running and this is dangerous
for a few
reasons one is if you're using
asynchronous cancellation where you're
basically telling the system I don't
care what the threads doing I just want
to go away that's dangerous in the sense
that there could be kernel resources
associated with that thread that may not
be properly cleaned up there may be some
other data associated with that thread
in some other task that is not getting
cleaned up like a file descriptor that's
open or a file that's taking up space on
the disk so we recommend using the P
thread canceled in its deferred or
synchronous model where you basically
make a request to the system that I'd
like this thread to quit and in our API
we have a P thread test cancel call
where if you're in a long-running
compute bound loop you can check to see
if a thread has a request to cancel and
if so that thread will exit at the P
thread test cancel point the POSIX
specification also provides for system
defined cancellation points like most
system calls and if you look in the
Darwin store space you'll see that we're
busily working on implementing those
because it's actually a better way of
doing the cancellation if I'm in an open
or read system call and I tell that
thread to cancel it should just break
out of that open or read system cause if
I had interrupted that system call the P
threads documentation right now is a
little sparse on our system I usually
point people to the open group site
because they happen to have a pretty
extensive documentation on both the UNIX
98 standard and P threads specifically
in general we use that as our model for
doing our implementation we will be
providing more pthreads documentation on
the system at some point in the future
so in the Carbon api's as I said the MP
task spec is what you'd probably look at
for your multi-threading needs MP tasks
just a quick overview in Mac OS 10
there's the notion of tasks and MP tasks
so tasks have classically been the
process notion where you have an
application it
address space all of its threads in MP
tasks those are threads within a carbon
application and as you know in Mac OS 10
all applications are in a separate
address space so some of the api's that
you may have used in classic Mac OS 9
are not going to work the same way you
can't do signalling between applications
right now using the MP tasks API the API
here is pretty rich there are a lot of
mechanisms to do synchronization between
MP tasks there's a semaphore model there
are message queues and event groups all
three of these can be used in different
ways depending on your application if
you have some client-server model if you
have a worker thread model you can
decide which one works best for you
the other API that's a little bit unique
here is the critical region API this
basically lets you do mutual exclusion
and it also allows for a recursive entry
to those regions there are atomic
operations that are present in this API
that are kind of handy for atomic
increment and decrement and test inset
type instructions these are all done
very efficiently and they're probably
very close to the same implementation as
on Mac OS 9 some of the api's that exist
on Mac OS 10 that use MP tasks under the
covers are the synchronous File Manager
api's and the open transport api's if
you'd like to see an example of some of
these api's and the tech note that we
usually refer to is 1104 the URLs kind
of hard to read there but in general
that will give you a background on what
we're doing with the MP task api's and
some examples of the thread-safe
services that you can use in carbene the
documentation specifically for the multi
processing services is on developer
apple comtex pub tech pubs MP services
and these are all these documents are
being
volved to reflect what the current
carbon api is the second framework I'll
talk about is cocoa it's the high level
GUI framework that Apple has presented
as an object oriented environment for
doing application development and as
threads API is very simple to use there
aren't very many entry points to it
basically you can create a thread you
can get the threads state at any time
the preemption pre-emptive nature of the
threat isn't unique all the threads in
the thread malls I've described or
pre-emptive there's an exit notification
for NS threads where even though the
thread is detached meaning that it can
go away and you can forget about it you
could also register for a notification
saying I'd like to know when this thread
goes away to clean up resources common
to most thread api's is the notion of a
per thread data and when you extend that
into an object-oriented environment the
per thread data becomes a per thread NS
dictionary so you can have keys and
values that are associated with your
thread using the nice high-level cocoa
api's in NS thread there's an app kit
extension so even though NS thread is
defined in the foundation classes if you
look in the app kit our cocoa framework
you'll notice that there's a method in
there that says detach
drawing thread and what that lets you do
is give a hint to the system that I'm
going to be creating a thread here that
might be doing interaction with the
window manager and the app kit will set
up special state to make sure that all
that's interactions with the window
manager are thread safe now if you're
writing a quartz pure quartz application
that interaction is already thread safe
in fact the way that you can write a
quartz application without using any of
the cocoa frameworks is to use one
connection to quartz per thread and that
provides all the the synchronization you
need you still have to protect your
global data if you have multiple threads
that are running that are all trying to
communicate with the same connection
you need to use the synchronization
mechanism that I've described to make
that work but in general the applicant
extension lets you do all you need to do
for our KOCO thread to let it know that
you're going to be doing drawing and
this threads are self aware meaning
there's no global notion of all the NS
threads on the system or you're not
really going to be handing NS threads
off to other objects in the system all
these api's I've described since they're
layered on top of POSIX threads can ask
for their POSIX thread and then once
they've done that they can perform any
of the POSIX thread api's like changing
their priority or finding out what the
stack size is for the thread but in
general NS threads kind of stay in their
own realm they have a separate run loop
so usually when you're creating an NS
thread since you're already in a GUI
application if you're using cocoa
there's a main run loop that's
associated with the first thread that's
been created on behalf of the system but
new threads that get created are going
to have their own run loop because those
those threads will probably have a
different signaling mechanism and
different events that are occurring that
need to signal back and forth between
other threads and for instance the other
cocoa api's that have to do with run
loops or timers and notifications and
you can send those between threads with
a little bit of synchronization there's
a concept of an auto release pool that
if you haven't done any cocoa
programming yet this is a wrapper for
objects which gets created and destroyed
kind of on the fly so you you call a
method it returns you an object and one
thing notion that cocoa tries to help
out with is the memory management so if
you don't actually explicitly create an
object it just comes back from a call it
gets what's called auto released and the
way the auto release pull works is on a
per thread basis so the the main run
loop has an auto release pool every time
through the event loop it releases all
these objects that may have been created
on behalf of another method call and in
a separate thread you need to make sure
that you're maintaining the out a
release pool as well because all the
messages that get
on that separate thread we'll need to be
Auto released if they're returning
objects eventually the documentation for
NS thread is also on developer.apple.com
in a very long URL actually the cocoa
documentation is very well done and
there's I believe in O'Reilly book out
that you can go get now for future
developments basically if you follow
Darwin since I'm involved in the crow us
group we basically get we have the
ability to put all of our work that
we're working on daily in the public CVS
repository so if you want to just go to
the Darwin web pages that will let you
know how to go ahead and check out any
of the CVS repositories for all the the
work that we're doing specifically the
Lib C project is where the pthreads code
lives and the xnu project is where the
mach kernel is and where the mock
threading model lives some of the things
we're working on and we're also getting
help actually the Darwin community is
very interested in our threading
implementation priority inheritance is
an issue where if you have multiple
threads and you're finding your lock
contention becomes a problem we're a
higher priority thread is blocked
waiting for a lower priority thread to
run there are some solutions that you
can use in in your application to work
around this problem but in general the
system should help out by temporarily
raising the priority of the thread that
needs to run for the higher priority
thread to continue so that concept
hasn't been implemented yet but we're
working on that the general API
expansion issues of the P thread spec
that we've provided we've gotten a lot
of requests for specific functionality
that's missing we know about that and
and we're working on it
the other thing that we've been focusing
on is performance like I said in the
first couple slides when you're deciding
whether you should use multiple threads
in your application or how you should
use them we don't want to be an
impediment
there we don't want the choice to use
multiple more than one thread in your
application to be have to be made
because there's a performance issue in
general you should use multiple threads
if your application has a data model
that works well with that if you have
lots of data that can be parallelized in
its functionality where you're splitting
up chunks of data in a graphical
application that's doing tiling or the
the best example we've used is photoshop
a lot for some of its filters those
things lend themselves very well to
multi-threading and we don't want you as
a developer to have to worry about
whether you're even on a multiprocessor
system in fact if your application is
written properly you should just
automatically take advantage of that
second processor and your customers will
be happy because they paid the money for
the multiprocessor box and they're
actually getting the performance that
that they would expect we're working on
providing more thread-safe services as
i've mentioned in the carbon api's and
even in the lower level darwin api's
we've been working pretty hard on making
sure that you can call the api's that
you want without having to worry about
creating your own locking mechanisms
around the parts of the api that are not
thread safe so right now we have a
couple demos first I'd like to bring up
Robert boated who's going to show an
example of some of the developer tools
that were working on thanks Matt
so what Matt has done is explained to us
what the api's are for using threads and
a little about the reasons about why we
might use them what I'd like to do is
give us some case studies and explain
how some of Apple's own tools use
threading now the interesting problem so
let's start this up is that this is
going to be a somewhat unauthorized talk
I've talked with the groups a bit but in
general what we're going to do is we're
going to reverse engineer on the fly
these apps and try to understand what's
going on the way I'm going to do it is
with a handy dandy little performance
tool this is a pet project it's not yet
on the developer CD that tries to
visualize how threading goes on now the
first step I'm going to look at is the
finder okay let's get some action here
and what the time what we're seeing here
is a timeline view in thread viewer so
each of the little blocks there
represents about a 50 millisecond
interval and each of the bars represents
each thread and so the idea here is that
you can see that there's three threads
currently in the finder click around
and the colors change according to
what's going on so for example the green
represents that there's currently
execution on that thread the yellow
represents that execution occurred but
is not currently occurring so there was
some execution during the last sample
the green as in here represents that the
program was waiting in the run loop the
red represents that the thread was
waiting on the lock now the first thing
I'll show you is that you can see that
there's basically one thread that does
most of the action that is the main
thread and that's how most applications
run so most of the drawing most the UI
logic is going on there the second
thread from the bottom the one that's
locked represents what the finder people
call a sync thread so the idea is that
every time that they cache a lot of the
information about what's going on in
each folder however when you enter a
folder that you've already seen you need
something that will go and make sure
that nothing has changed in that folder
and that's what the sync thread does so
the idea is it quickly goes and it looks
in that directory in a separate thread
notice that it's always existing it's
always locked so it can be started up
quickly and by having on a second
separate thread you not only have the
ability to basically have scalability
and do things in multiprocessing way so
that you get quick response but also
since you're accessing the disk you know
that if that blocks because let's say
it's an eye disk you're going to be able
to go and access that and wait for the
response without actually stopping the
UI thread and so that improves the user
experience is now is telling us let's
start finder up again
the other thing that you'll find as we
click around is that each time that we
enter a new folder we can see that new
threads get started so there was the
remnants of one here and then we have a
thread here and that thread only stays
around for a small instance and then
goes away again and what's happening
there is that once again the finder guys
don't want the UI to block the the
finder would look miserable if every
time that you went into a new folder and
it went out to touch the disk if the
entire finder locked up
it's a horrible user experience and so
to avoid that as many of you probably
will want to do in your own apps what
they do is they have the disk access is
going on in a separate thread when they
enter the new folder they go
the catalog it they do that on a
separate thread and that way they know
that the finder is not going to block
while they collect data a third example
is if we do a copy so let's go to the
home directory and let's duplicate a
folder or duplicate an application and
what we find is again up here we've
created a new thread the idea is that
the copy is something that's going to be
a long-running app or a long-running
thread it's something that's going to be
touching the disk and so it's going to
be blocking so you don't want it on the
normal thread and it's something that
should be running in the background
because it's probably something that the
user doesn't have a huge amount or
doesn't really care that it completes
immediately and wants to be able to do
other activities and so the idea of
being able to split off this background
task or background process is an
important idea so what you've seen here
is that the finder is using threading to
avoid blocking on IO in case they're
accessing disks that are remote for
example you've seen trying to improve
the user experience by making sure that
blocking stuff happens on separate
threads and you've seen the idea of
using the threads for background actions
ok the second example I'd like to show
is iTunes so let's go back to thread
viewer
and we'll see there's a few more threads
in this so let's start out by getting
some music playing okay so we know it's
actually playing you know that this
isn't canned and what you see here is
the activity going on in the threads the
thread at the bottom again is the main
thread so it's sitting there and it's
doing all the UI work and if we actually
had the visualization part of iTunes
going you'd see that thread basically
pegging out constantly running the next
thread up represents basically data Cola
data decompression which is actually
running as a deferred task and as a
carbon thread what you also will see is
occasionally on this third thread
there'll be some green blocks that go by
and what's happening there is that
there's an actually a separate thread
that's being used for accessing the disk
and so the idea is that this thread goes
off and everything now and then when it
needs data it grabs as much data as it
can stores it in a buffer then there's a
separate thread that actually does the
decompression and then the thread at the
very top where you see all the activity
is actually the thread that sends data
off to the audio device on the disk we
want to do large accesses and we want to
grab a huge amount of data and then do
the decompression with the audio device
we want to minimize latency and so the
idea is we want to throw a few little
bytes at a time out to that audio device
and so by having that on a separate
thread that means that we can easily
send the data that's needed and do it in
as timely a manner as possible so we
have no dropouts in actuality the three
threads that you see there the
decompression the disk reads and the
audio playback are actually all
controlled by the sound manager so
they're actually not threads that itunes
actually went to any trouble to actually
create but once again you're seeing
cases of iTunes using threading to avoid
disk block or a blocking on disk i/o you
see it trying to take the tasks that are
time critical and put them on separate
threads and you're seeing the idea of
trying to make sure that you can
parallel eyes the code by breaking the
major parts of sort of this pipe and
filter model into separate threads okay
these were just two examples about how
Apple is actually using threading
hopefully the people who are available
for Q&A can give you some more ideas
about when to use threading and when not
to you thank you thanks Robert
so the second demo we have is Yvonne
posta who works on the job of virtual
machine and as I said earlier there are
definitely cases where your application
is more inclined to be multi-threaded
especially if you have lots of data that
can be operated on in parallel so he's
going to give us an example of an
application where this is the case and
helps out a lot okay good morning
what I have is basically a digital
elevation model from Switzerland and I
wrote a swing app that basically render
scenes within Switzerland so I have a UI
element down here swing it says one so
I'll spawn this rendering in one thread
so it goes off it tiles the the image
into small pieces and does that on
thread you see in the task manager one
CPU is usually used and the other CPU is
Java UI making use of the spare
processing power to display so we saw
that it took fifteen point seven seconds
to display this image if I go to two or
even three threads on this machine when
I restart this image we see that the UI
updates much quicker
it's pegging both the CPUs calculating
so what else do I have I can do the same
thing with the satellite image just
taking the taking the same data model
and while it's calculating I can scroll
in the indie UI here and still use use
the UI why it's calculating the stuff so
Java itself has built-in support for
threading in language it's rather easy
to use threading rather easy
for us to update the UI at the same time
as you do calculation that's that's
about it
so how much what was the performance
benefit you saw with your multiplier in
example four for this calculation it was
about one point eight scale a scale
factor so that's pretty good if you
consider that part of the update is
happening while you're calculating it's
it's pretty using the processors that
machspeed so it's it's also a feature of
the swing implementation that the
developer doesn't have to worry about
the locking for drawing to the UI that
just happens for them that happened that
happens behind the scenes for the user
you just say repaint this area here's
your new image that's it great thanks
Yvonne so I'll bring up mark to finish
off the information about this session
and other sessions so what I wanted to
do is bring up a related sessions that
you might be interested in furthering
your knowledge about tuning and specific
areas of how to get Hardware
advancements here so session 121 with
carbon performance tuning which Robert
will be at advanced cocoa topics or
session 123 and the Darwin kernel and
session 140 I also want to add that
there will be a birds of the feathers a
session at the end of the evening today
at 6 p.m. here in Hall C I believe it is
with velocity engine so we'll we will
actually discuss with the updates on
velocity engine we wanted to kind of
separate both of these topics and
allocate as much time as we could to
threading you know one of the things
that last year I was up here on stage
promoting to you developers and at that
time we didn't have dual processor
systems I was promoting the fact that
you should thread your application kind
of not being able to tell you that hey
we're coming out with multiprocessor
systems but you know if you thread today
as OS 10 matures
and was actually going to be released
your application will run faster simply
because the threading model within OS 10
is a lot more efficient than what is in
oh s nine so today with multiprocessor
systems you can see now why there's even
more of a reason why you want to
optimize your applications so taking a
single threaded application bringing it
over to Mac OS 10 you the customer
experience is going to be well there may
be some performance enhancements but
really it's more perceptual because OS
10 is actually doing all the work for
you if you multi thread your application
you get additional benefits because I
was 10 now says okay great I can you
know move things around a lot quicker
and use the thread model within the mach
kernel now the next step is really
optimizing your application for MP
because not just providing threads is
not going to give you the the efficiency
of using that second processor that's
where SMP comes into play so actually
paralyzing your code and seeing where it
makes sense to actually have your your
thread go off to the second processor is
what factoring or paralyzing your code
involves and that's what we term as
optimization for MP hardware and that's
what you kind of saw in the example with
QuickTime itself actually balancing the
pegging of each processor so that SP
itself can take care of the housekeeping
there
you