WWDC2013 Session 701

Transcript

X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
[ Silence ]
>> Well, good morning
and welcome.
[ Applause ]
>> I'm Bud Tribble, Vice
President of Software Technology
at Apple and I'm going to talk
about maximizing
battery life in OS X.
Now, you know, battery
life is just a key feature
for customers.
I know its key for me,
I know its key for you.
And as you can tell from
our key note sessions,
battery life is one of the
places where we put a lot
of focus in OS X Mavericks.
And the reason is simple,
mobility is a key feature
for our customers and battery
life is key for mobility.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, mobility has always
been an important feature.
However, the user experience
for mobility is not
always been great.
This is actually an Osborne
1, you probably don't--
most of you probably
don't remember
but the Osborne 1 was famous
for being the first computer
you could carry around with you.
However, even that in that
case because of the CRT
and other things, you had
to find a place to plug it
in as soon as you
wanted to use it.
Of course things have gotten
a lot better over the years
but nonetheless if you are
at 3 hours battery life
on your system, you're spending
most of your time just wondering
around looking for the next plug
and I'm sure you've all been
in the airport and that
sort of a situation.
Now, your battery life
will vary depending
on what you're doing of course.
But the goal that we set out for
was that for most of the people,
most of the users, most
of the time their battery would
last all day, they would plug it
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
in at night and that was it.
Now, we know that
that's a game changer
because of our experience
with products like iPad,
where that's the usual behavior
and once you get to that sort
of threshold, life gets a lot
better, there's a lot of bang
for the buck in getting
to that point.
Now, our latest products
which I'll go
into some more detail we
think we've gotten there
through a number of techniques.
It wasn't easy but
it was a lot of fun
over the development really with
a laser focus on battery life,
kind of a new perspective
in how you develop apps.
I hope to sort of translate
some of that to you or to--
I imbibe you with that because
in fact application developers
have a huge impact on the
user's battery life as well.
So, here we have a typical
customer out at the beach,
they've got the-- I don't
know if this is Mavericks,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
probably isn't Mavericks
but here's a surfer who is,
you know, in between
surfing is editing his movies
with Final Cut Pro.
Well, even in this case assuming
he spends a reasonably long time
surfing even with
a heavy duty app
like Final Cut Pro he may
experience all-day battery life.
Users do not use our computers--
do not use their
computers continuously
and you can give them that
experience of only plugging
in at night in just a wide
variety of situations.
Now, with the latest MacBook
Airs combination of the hardware
and the latest MacBook Airs
that has well ULT processors
which are very efficient,
and Mac OS X Mavericks we think
we have reached that threshold
where people can
start to not think
about their battery
during the day
and we think there's
incredible value to that.
Now, I'll go into some
detail on how we get there,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
it's actually there's a
lot of ingredients that go
into giving the customers
a great battery life.
Starting with chemistry, the
chemistry in the battery,
now we're used to Moore's law
with silicon wherever 18
months things get twice as--
you have twice as
much compute power,
that's not the case
with chemistry.
With batteries, batteries
have been slowly
but surely getting
better over the year
but the gains are measured in
single digit percentage points.
Nonetheless, Apple's been paying
a tremendous amount of attention
to battery life technology
and battery chemistry
and we have gotten
gradually better.
So, this is one of the
ingredients in getting there
in terms of all-day
battery life.
Second area though, the
hardware itself the silicon,
both at the atomic scale, the
nanoscale and the architecture
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of the chip itself, that's
extremely important at getting
to all-day battery life.
I'll go into that
in some detail.
Of course the system
software is responsible
for scheduling the CPU
and other resources
in the way that's most energy
efficient and we've done a lot,
this is where we've done a lot
of work in Mac OS X Mavericks
to make sure that things
are as efficiently scheduled
as possible that the energy
is being spent on work
that the user actually
wants done versus work
that maybe they don't
care about.
So, we'll go into a
lot more detail on that
and actually a lot
of sessions further
on during the week
we're going to focus
on that sort of thing as well.
And then finally, as I mentioned
you the application developer
are part of the equation here.
And it's important for you to
use the tools that are provided
in Mac OS X Mavericks to
take, take a microscope,
take a closer look at how your
application is using energy
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and try and maximize the
efficiency to give that customer
that all-day battery life
that they really want.
Now, Apple is, as a company,
uniquely positioned compared
to a lot of others being
at the intersection
of hardware and software.
We build hardware and we build
the software that goes with it.
The system software so we can
spend a lot of time making sure
that those two things
are optimized together
and play well together to give
maximum battery life possible.
And that's what I want to
spend some time talking about.
How the hardware plus the
software working together
maximizes battery life.
Now, silicon itself
has come along way
in the last thirty years.
So, this is actually
on your left.
The original 68K, the
68,000 processors that went
into the Mac 128K and
Mac 512 back in 1984.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, that chip had oddly enough,
around 68,000 transistors on it.
The Intel Core i7, the
fourth-generation Core i7
that we have in the
MacBook Air has
about 1.4 billion
transistors on it.
Now, you know, the transistors
in the original Mac we're
not all that efficient.
In fact, if they drew the
same, if the transistors
in the Core i7 were drawing
the same amount of power
as the transistors in the 68K,
then the amount of power needed
to run the Core i7 would be
equivalent to the power drawn
by about 10 US average
households about 20,000 kilowatt
or 20,000-- 20 kilowatts.
Obviously, you know, a lot
has gone into making sure
that that catastrophe doesn't
happen, one of the things is
of course the transistors
just got smaller but again,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
this chip is running
at a higher frequency
and thus using more power
just because of that.
So, a lot of work had
to go in to the physics
of the transistors in order
to make them more efficient.
I want to talk a little
bit about some of those.
So, Intel in starting
at the early 2000 began using
something called strained
silicon, not just normal
silicon but strained silicon.
Strained silicon actually
has germanium atoms inserted
in between the silicon atoms and
the net result of that is that--
is that they can run
at a lower voltage.
The voltage gap is
lower and running
at a lower voltage
has a big effect.
Energy draw tends to be
proportional to voltage squared
so anything you can do
to reduce the voltage
and still switch those
transistors has a big effect.
So, Intel put a lot of effort
into moving to strained silicon.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But that wasn't enough.
These things went forward.
Another problem arose which
was that between the gate
and the channel in
this transistors,
there's an insulator,
silicon dioxide.
Well that silicon dioxide as the
transistor shrunk was getting
to be just a few atoms thick.
And as a result electrons
actually tunnel through there,
they're leaking through there
and that leakage is
simply wasted energy.
There's R-squared energy leaked,
being wasted in that case.
So, what Intel did is they
looked around and they said,
"Is there any way we can make
those gates a little thicker
but still get the
same capacity."
And that's where they came
up with what's called
high-k metal gates.
And that those start
being used in 2007.
That was a big breakthrough
because you could get rid
of that leakage that would--
was really sitting there
continually drawing
down your battery and they
used a material called hafnium,
hafnium oxide which oxides
which have a very high
dielectric constant
so you can increase the
thickness of the gate.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
And then finally,
most recently in 2011,
they came up with something
that I guess they're marketing
guys called it Tri-gate
but it's really a
three-dimensional structure
for the gate so that
the gate can actually be
on all three sides of the
channel of the transistor rather
than just a plate on the
top of the transistor.
And these transistors are much
more efficient maybe 50 percent
more efficient.
So, there's going to be
more things in the future
but you can tell even--
even at the nanoscale,
a lot of stuff is being done to
make these chips more efficient.
Now, what's the result?
The result is that on the latest
chips, we're talking nanojoules
or tens of nanojouels
per instruction.
So, what's a nanojoule?
So, a nanojoules is a billionth
of a joule and a joule,
a billionth of a joule is a
very tiny amount of power.
I like to think sometimes in
terms of biology and in fact
when a neuron fires in your
brain its taking on the order
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of picojoules, about a
thousand times as much.
So, you can sort of think
of an instruction executing
in the Core i7 as being
same amount of power,
same amount of energy is
about several thousand neurons
in your brain firing, so your
brain executing one instruction.
So, we're really getting
down there to the level
where biological systems have
evolved over obviously billions
and billions of years.
Now, this is a micrograph of the
Haswell ULT chip from Intel and,
you know, it's a small chip
about the size of a fingernail
but on here are 1.4
billion transistors.
And that's divided up into
the functional units the--
in this chip there
are two cores.
There is a huge amount as
Phil said yesterday devoted
to the GPU to the
graphics processor.
There's the shared L2 cache,
the memory manager and some
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of the things for managing DMA.
Now, the interesting thing
about modern chips is
that during execution, you can
power down parts of those chips
that aren't being used.
If you're not using the GPU
right now, you can turn off
that part of the
chip, saving energy.
If you're not using both cores,
you can turn off
one of the cores.
You're not using both
cores, turn those off.
And that turns out to
be architecturally one
of the key ways to save power
in these portable systems
that we have today.
Now, it requires
close interaction
between a system software and
the silicon in order to make
that happen correctly
but as we'll get into,
if you do it right, you can
save a huge amount of power.
Now, this shows you what that
looks like and in reality,
this is actually,
it's not Haswell,
it's Ivy Bridge previous
generation
but it's what called an
infrared emission microscopy.
So, you're looking actually
at the heat waves coming off
the chip as its executing.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, the blue spots
are cooler, the orange
and the red spots are hotter
and in this case what you have
is one core is powered up,
this is a four core system, so
you see one core powered up,
the shared L3 cache
is powered up.
The GPU down at the
bottom is powered down.
And here's some other
examples of states
that that chip can be in.
The middle one shows all four
cores and some and the GPU going
at a fairly fast clip.
The last one shows
all four cores,
all the cores are powered
down, the GPU is powered down.
It turns out that
just a normal course
of using a computer
interactively, the chip,
the CPU chip spends most of its
time typically in that state.
That's because, the CPU is
often waiting for user input.
It's waiting for the
network I/O to interrupt.
It's waiting for
the GPU to be done.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
A lot of the time in modern chip
is spent with parts of that chip
or even most of that
chip turned off.
So, what do you get from that?
That you get a tremendous
dynamic range and how much power
that should CPU chip can draw.
When it's idle, when it's
not doing much and parts
of it are turned
off or powered down,
you can get down to 0.4 watts.
On the other hand if you're
doing a while one loop
and the thing is just
sitting there spinning
or a CPU limited operation
transcoding a movie or something
like that, that can boom up to
25 watts, 30 times more power.
And if the thermal conditions
are right, you can even kick
in to turbo and get up to
maybe 60 times more power
than an idle chip.
To let you know how
this compares
with total system power,
remember that was just the CPU,
well when you're idle, the
CPU is a very small part
of your system power
because a lot
of power is going
to the backlight.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
It maybe go into Wi-Fi,
radios and other things
and the power supply.
And so, the CPU at idle
when it's mostly turned
off is a very tiny part
of the total system power.
However, when you're doing
CPU limited operations,
you've got a tremendous amount--
the lion share the power going
to the CPU and that overshadows
things like the backlight.
That's important
thing to keep in mind.
That tremendous dynamic
range means that the software
and apps you write have
a tremendous impact--
tremendous leverage on how
much power is being drawn
and thus how much-- long the
battery is going to last.
Now, with interactive systems,
most of the time as I mentioned,
the CPU is actually
powered down or clock gated
or not drawing a lot of power.
It is a more or less idle state.
The reason is that user events
don't occur very frequently
compared to the time scales
of executing and instruction.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, even if you're
typing 50 words per minute
which probably most of you can
do-- that's one key every--
more quarter of a
second more or less.
That's a huge amount of
time in between responding
to those events that potentially
the CPU can be [inaudible]
assuming there's no network
activity, et cetera, et cetera.
So, that's a key strategy to
take advantage of the fact
that on interactive systems,
you're really spending a lot
of your time with the CPU idle.
And to show you what
that looks like,
this is actually a
trace of CPU activity.
So, system wide CPU activity
as someone is in Safari,
they're browsing to apple.com.
So, at the beginning here
you have their typing
and as I mentioned,
you've got less
than 10 percent of CPU activity.
That means the CPU is
essentially shut off 90 percent
of the time.
And then you go to where
you're fetching doing HTTP gets
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
from the network and the network
is not infinitely responsive,
so you even have time in
between those network,
in between those gets to put
the CPU to a low power state.
Then finally when you're
rendering, the CPU is waiting
on the GPU to render
those pages.
So, again, less than
5 percent activity.
So, if you were to-- if
you're able to look at CPU on,
CPU off over the course of time.
So, this is about five seconds.
You see that there are
many, many rapid transitions
from the CPU being
powered up fully running
to the CPU essentially going
to sleep in between events,
in between network packets,
in between GPU invocations.
So, the key here is to make
sure that the percentage
of time spent in those low power
states is the most that can be.
Now, if we zoom in here, this
is a 1 millisecond time scale.
We see that there
are pretty huge gaps
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
where you could literally
execute tens of thousands
or hundreds of thousands
of instructions
but instead you're-- the
system is putting the CPU
into a low power state.
Well, it would be nice if it was
just like turning a light switch
on or off to put it on
those states but it's not.
It's not that simple.
In order to get the CPU to
turn off or to turn back on,
it's actually a fairly
complex process.
So, in this case, it takes time.
This is not actually turning the
CPU or the core completely off.
This is an example of
what's called clock gating--
you stop all the clocks going
to that part of the chip.
And in this case, you
stop the phase-lock loop
that is supplying the clocks
for that part of the chip.
But, that means that when
you want to turn it back on,
you have to start up
that phase-lock loop.
You have to get it to sync
up with the rest of the chip
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and then finally,
you get to turn--
start doing useful processing
after 10 to 15 microseconds.
So, there's overhead associated
with turning the chip on or off.
It can be even more than that.
In this case, you're taking
the voltage to the core
and you're dropping
it all the way to zero
in which case you
lose all state.
That means that when
you turn it back on,
you're spending time
reloading state for that part
of the chip could be
hundreds of microseconds.
So, in these cases,
what's happening is
that you're applying full
power to the chip in order
to get it up, turn on again,
but you're not doing any
useful computing power.
That's wasted energy
for that time.
And, that adds up over time.
So, here's going back to
our diagram of CPU turns
on for a bit, turns
off for a bit.
But, those RAMs are intended
to show that during that time,
you're powering the chip,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
you're not doing any useful
work, that's wasted power.
So, the strategy here is
to minimize those times.
Now, how do you do that?
Well, that's where the
system scheduler comes in.
That's where how timers
are scheduled comes in.
And, that's what we'll spend
some time talking about.
But the basic idea is simple.
The basic idea is if you
can shift around that work
and batch it up into
a single packet
of CPU work then you can turn
on the chip once, do your work,
turn off the chip
and those red areas
which are essentially wasted
energy can be decreased
into just a couple of them.
So, this is what it looks
like when you do that.
So, scheduling that work in
bundles or in batching it
up together is one of the
key strategies that's used
by Mac OS X.
And we'll spend a little bit
of time talking about how
that interacts with App Nap,
how perhaps that interacts
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
with the application you're
writing, how you can do
that in a way that lets the
system coalesce these things
and decrease that red
rectangle the time it takes
to power the chip on
and power the chip off.
So, to review, in an
interactive system its idle most
of the time-- it's
idle much of the time.
And modern chips can
take advantage of that
by turning themselves off or
turning parts of themselves off
when they're not needed
and the key strategy is
to batch work together so that
you're not spending a lot your
time ramping up and
ramping down.
So, maximize idle time,
minimize transitions.
So, let's talk about how OS X
Mavericks addresses these sorts
of issues.
And I'm going to talk
about several things.
One is sort of on the tool side,
making energy impact visible.
And if you want to improve any
aspect of the system making it
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
so you can measure that is key
and we don't exactly have
ammeters that we can go in there
and put on apps or put on
processes but we have corallites
of energy use and we'll talk
about how we used those.
Second thing is system
strategies
and application strategies for
energy efficiency and that gets
to some of the things I
was just talking about.
How do you batch up work so that
you're minimizing the amount
of those wasting energy wasting
transitions that are going on.
And finally, what you
can you do as developers?
I mean there's a lot we can
do as a system developers
down at the low level
but actually,
this bubbles all the way to the
apps and how the apps behave
and how you can change your
apps to be more power efficient.
So, starting off in our-- in
OS X Mavericks, if you go up
and you look at the
battery status menu,
you'll see some new
things in it.
So, in this case, we are
actually showing applications
which are using significant
energy.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Now, in many cases, that will
be entirely expected and desired
if you're doing a
render in Final Cut Pro,
it's going to show up there.
If you're doing a
batch compile in Xcode,
it's going to show up there.
On the other hand, you may
have something show up there
that is unexpected and maybe
undesired and we're going
to make that visible in
the battery status menu.
If you double click on any
of those, it will take you
to activity monitor
and in activity monitor we
have a new tray or a new tab
which is the energy tab.
The energy tab shows
two new columns.
One is called energy impact.
I'll just take a moment
to say what that means.
So, energy impact is a
surrogate for trying to look
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
at the energy impact
that an application
or a process is having.
Now, as I mentioned, we
can't stick a power meter
on it directly but what we can
do is look at the CPU usage
by that app and look at
the interrupts or timers
that are caused by that app
and cause the CPU to wake up.
In other words, cause one
of those red rectangles
that I was looking at earlier.
And we track those using
counters and we apply
that to the energy impact
that that app is causing.
So, you get a number that
is a relative measure
of energy impact by an
app or by a process.
And further than that in
the next column over--
so that's the column
with the energy impact.
Next column over, we show
the average energy impact
over the previous eight hours.
So, actually the previous
eight hours or until, you know,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
back into the last time
you booted your system
if that was less
than eight hours.
But this is important
because, number one,
you might have something-- an
app that had come in there run
for five minutes and burned
a lot of your battery,
and now it's just quiescent
but you'd like to know
that that happened at some
point and that will show up in
that eight hour average.
Just as important,
you may have the apps
that are just using
battery energy at a low clip
but they're constant, they're
just going on all the time.
Again, the history, the
average makes that visible.
So, this is the first clue that
there might be something going
on you don't expect or that
the user doesn't expect.
Now, as a developer what
you're going to want
to do then is go into Xcode.
And in Xcode, we have
quite a few more tools
that let you take the next step
to investigate why this
app might be using energy.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, in the latest Xcode, we have
what's called the Energy Gauge,
Energy Impact Gauge.
Go to the-- if you
just run your app,
that'll show up on
the left there.
You can click on that
and it gives you much
more insight into,
is your app firing off timers?
Is your app using CPU?
Why might it be doing this?
Can I go look at the
event timeline and see--
you know, make sure you
understand why it's doing that.
As I mentioned before, it
maybe doing very useful work
but it maybe doing work that you
can do in a more efficient way.
Now, we have built
in to OS X Mavericks,
strategies that we
use across the board
to make things more efficient
from an energy standpoint
and I want to talk
about three of those.
First one is App Nap.
An App Nap was mentioned
yesterday.
I'll go into little
bit more detail
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
into what App Nap is actually
doing and there's going
to be further sessions coming up
that will go into great detail
and APIs around that that
I would suggest you go to.
Centralized Task
Scheduling is the next one.
Centralized task scheduling is a
much longer time scale but it's
about moving work around to
times they're more opportune,
either more opportune
from an energy standpoint,
you're back on AC power or more
opportune just from staying
out of the way of the user.
And then finally Power Saver,
and this all about Safari
and providing a web-browsing
experience
that is power efficient.
So, let's go through those.
First of all, App Nap.
So, a typical use, you
know, users interacting
with one application
on the screen
but of course they've
got, you know,
many other apps up
in the background.
Now, the app they're
interacting with is
where they're really
interested in results.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
But the apps that
are in the background
when you measure systems often
are sitting there drawing power.
They maybe drawing
low levels of power,
they maybe drawing
medium levels of power
but they're drawing power
and often times they're
not doing things
that the user is really--
all that interested
in at that moment.
So, what App Nap is all
about is quiescing those apps
that the user is
not interacting with
or that are not visibly
drawing on the screen
or they're not creating
an audio output stream
that they're going to hear.
So, we use heuristics to decide
when an app is a
candidate for App Nap.
Once we decide it's a candidate
for App Nap we start
doing a variety of things
to suppress the energy
use by that app.
And, you know, devote, thus
devoting most of the energy
to what the user
is interacting with
and what they're interested in.
So, what do we do?
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Well, we will adjust CPU
and I/O prioritization.
But beyond that, we will
also be more aggressive
about coalescing
timers in that app
or in processes associated
with that app.
So if there are timers that are
being set we will move those
timers around to align
them with other timers
so that you don't have
this overhead of power--
potential overhead
if the chip is coming
out of a low power
state and going back in.
You don't have that potential
overhead occurring over
and over, you coalesce
those into one.
Timer rate limiting which is a
little bit different which is
for repetitive timers, we
stretch those timers out.
And finally, there's some APIs.
We are able to tell an
app when it's visible
so it potentially take action
to decrease its energy usage.
And we let the app hint to
the system or pass information
to the system about how it
expects to use resources
so we can do the right
thing in App Nap.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, Timer Coalescing.
As I mentioned before, the
key is batching together work
so you don't have-- you're
not paying the overhead
of these transitions.
So, here in the red rectangle or
the overhead of the transitions
for the CPU coming to
a high-power state,
from a low-power state or vice
versa and what we're going
to do is-- if the app is being
App Nap, be more aggressive
about squishing two of these
events together we're going
to slide those timer
firings around so
that you only get a
single transition.
And overtime, these
add up it's--
we keep the timers in
exactly the same order
that they were set but
we change the exact time
in which they fire, we slide
them around to coalesce them.
Now, there's also an API for
NSTimer and DispatcherTimers
that lets you tell the
system how much leeway
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
or how much tolerance you can
accept, let's say 10 percent,
you'll accept the 10
percent sliding of that timer
and you've made the
judgment that's not going
to really affect
how things come up.
Now, there are timers
and apps where that has
to be as close as possible.
And that really gets into
the realm of real-time apps
which we're not really talking
about here and there are things
like audio playback where
you need exact timings
and will opt those
out of App Nap.
But, for timers associated
with perhaps network polling
or perhaps user interface
related interactions,
those kinds of timers
typically don't have
to be accurate to
the nanosecond.
And, if you tell us we can
slide those timers around.
If you give us tolerance then
the system will automatically
merge those to get rid of
the overhead between those.
So, here we have an example
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and what you've done is really
reclaim that wasted energy due
to those transitions
that were there earlier
and you've combined the
work into a single batch set
of work that gets done.
Now, this is happening
on the order of hundreds
of microseconds or
maybe milliseconds.
It's something that--
if everything is
operating correctly,
the user doesn't
even notice except
that their battery
life gets longer.
Timer rate limiting is
a little bit different.
If you have a repetitive timer
in one of those background apps,
one of those apps
that is not drawing,
that the user is not interacting
with, perhaps you've got--
you left the timer going at a
frame rate, 60 times a second.
To update some variable that you
want to keep up-to-date, well,
we will rate limit those timers
and essentially stretch
them out.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
So, we will let those timers
execute but let them execute
at a much lower duty cycle rate.
That means that whenever
processing is going on
and associated with that
timer is now occurring
at a much lower duty cycle and
the power associated with that
or the energy associated with
that is correspondingly lower.
So, those timers continue
to fire but they continue
to fire at a lower rate.
And again, this is happening
in apps that are not drawing
to the screen, they are
not outputting audio,
these things are not
noticeable to the user except
that they have less
draw on the battery,
they're using less energy.
Now, we also have
as I mentioned,
an API that lets an app find
out whether it is
visible on the screen.
And, here's an example of where
we use that to conserve energy.
This is Photo Booth, Photo Booth
is-- comes up in preview mode,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
it turns on the camera,
it's displaying the
preview on the screen there.
If Photo Booth gets
covered up by another app,
there's now an API to find
out, "Hey, I'm Photo Booth
but I'm not showing
on the screen."
And, Photo Booth will now use
that API to find that out,
turn off its camera
thus saving power.
In the case where you got
repetitive timers going on,
even though App Nap will
stretch those out for you will--
will rate limit those for you.
And even better situation in
that case is to use the API
to tell you, "Hey,
your screen is not--
your app is not visible
on the screen at all."
And if appropriate, turn
that timer off completely.
So, you know, the combination of
the system activities plus APIs
that you can use really
helps the system as a whole,
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
give the user the
maximum battery life.
You find out more about this
in a couple of sessions coming
up improving power efficiency
with App Nap which we'll go
into great detail about App Nap
and APIs associated with App Nap
and exactly how it figures
out when to nap something.
And Energy Best Practices
which is a lower level talk
that covers a lot of these
concepts but others as well.
Both those talks I think
are very worth going to--
the second one, will have a lot
of tools in it that you can use
and cover how you will-- how you
can maximize energy efficiency
for your costumers.
Now, Centralized
Task Scheduling.
Centralized Task
Scheduling as I mentioned is
on a much longer time scale
and it's a dual use technology.
It can be used to move tasks
to a time that is better
from a battery life
standpoint say back on AC power.
So, you might have a task
that's going to run--
use up some of your
battery, but it's a task
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that can wait hours
perhaps before it runs.
It's a housekeeping task and
we have a system-wide facility
for rescheduling
that to be executing
when you're back on AC power.
Also, tasks that are may be
going to use significant CPU
that you really only want to run
when the user hasn't interacted
with their system for awhile.
In other words, the users
probably gone to get a cup
of coffee, now is the time
for an intensive, you know,
background task to execute.
So, Centralized Task Scheduling
is a general mechanism
for doing that.
And you can tell the
system how you can--
first of all tell us
"Is this some work
that can be time shifted?
Can it be time shifted to either
back on AC or time shifted
to when the user is not
interacting and by how long?
What's the maximum
amount you're going
to let the system
time shift it by?"
Maybe it's a software update.
You don't want it to
go more than 24 hours.
Maybe it's a backup
you don't want it
to go more than a few hours.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
Whatever that is, you tell
the system through this API.
And there's a two
APIs for doing that,
one is if you're task
is a LaunchD Task.
You simply put that
in the launchd.plist.
There's a way to specify--
can this be time shifted
and by how long or directly
in your application.
There's an API, if you've got
let's say a block that you want
to execute on some schedule,
you can tell the system "Hey,
this block can be
delayed by up to 8 hours."
And that takes some
work on your part
but it provides a much better
experience for the user both
from a battery life standpoint
and not doing tasks that sort
of get in their way when
they're being very interactive.
So, Centralized Task Scheduling.
Couple of sessions
coming up on that.
This will be covered in
Energy Best Practices
which I mentioned before and
also Efficient Design with XPC.
So, XPC is one example where
you have a block of code.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
It's going to execute
but can just
as easily be put
off until later.
The system will make a decision
based on battery efficient
or battery life to move
out to back on AC power.
Finally, Power Saver.
So, Power Saver is all about
Safari and it's really some
of the same ideas, same
strategies we just talked
about with App Nap but applied
to the web browsing experience.
So, for example, in Safari,
as the user is browsing,
typically they've got tabs--
they've got a tab
they're looking at,
they've got other tabs
that are in the background
but if you look at what happens
on those web pages often
times those tabs are
executing JavaScript.
They're executing plug-ins.
They're burning power.
They're gradually
dragging your battery down.
So, what do we do?
Well, since in Safari, we now
have a separate process per tab.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
We can use those same techniques
we talked about in App Nap
to quiesce those tabs if the
user is not paying attention
to the ones that are
in the background.
That actually has a significant
effect given the web pages
that are out there today often--
they are just sitting there
in the background running their
plug-in, running JavaScript
and Safari will take care
of that with App Nap.
In addition, in web
pages today, often times,
power is being drawn
by plug-ins.
Plug-ins tend to be power hungry
and so these plug-ins are--
they're useful but
Safari is smart
about how it handles plug-ins
with respect to energy,
the latest Safari in Mavericks.
And what it does is for
plug-ins that are not the center
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
of your browsing
attention-- marginal plug-ins,
it will take a preview
snapshot of that plug-in,
display that until the
user interacts with it,
until the user clicks
on it and then
that plug-in will
start executing.
Great feature.
You end up with a web page
that has these previews in it
but they're not burning
any power.
They're not sitting
there executing
until the user goes
and clicks on one.
Now, if there is--
Safari uses heuristics,
if there is a plug-in
that's front and center then
that one will play
without interruptions.
But if there's marginal
plug-ins that are not the center
of the user's browsing activity,
those will still show up
but they will not play until
the user clicks on them.
To find out more about
this and more importantly,
if you're a web developer,
you should go to the session
on Power and Performance
in Optimizing Websites
because the Safari team is going
to talk about not just this
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
but also what you should do as
a web developer to make sure
that your web pages
that you're sending
out to users are not burning
through their battery.
That they're executing as
efficiently as possible
that the CSS is efficient,
that the users battery
experience is not impacted
by a bad web page.
So, we covered App Nap,
Centralized Task Scheduling,
Energy Saver, three great
features in OS X Mavericks
that are going to help the
users have a great battery
life experience.
So, what can you
do as developers?
Well, perhaps goes
without saying
but of course major effect
on battery life is
whether you're using
efficient algorithms.
And, so just make sure that,
you know, if you got tasks going
on that should be they're
nsquared algorithms
that you're using and they
really should be in login
or order in, make sure that
the algorithms were efficient.
That's going to help everything.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
That's going to help
responsiveness.
That's going to help
performance.
That's going to help-- help
you get the best battery life.
But beyond that, take a look,
use the tools in OS X Maverick
to take a closer look at energy
impact of your application.
Watch for your app in
energy in activity monitor.
Look at what it's doing,
understand what it's doing.
Like I say, it may be
perfectly expected behavior.
After all, the apps are supposed
to compute and so they're going
to use energy doing that.
But make sure that
it's as expected
and that it's not doing work
that either the user
didn't expect or worse
that the user really
didn't want.
Then the next step is measuring
your application with Xcode.
And as I mentioned, Xcode has a
lot of new tools in it to dive
down more deeply take a
look at things like time
or firings the frequency
of firings,
do I have high-frequency timers
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
that could have some
tolerance introduce
and let the system do a
better job coalescing those,
et cetera, et cetera.
And then finally, adopt
Centralized Task Scheduling.
Let the system move those
background task things like,
you know, downloading
updates from the web,
can be maybe pushed off
for hours or even days.
Let the system know about that
so the system can make the right
decision and put those events
so they occur when
you're on back on AC power
or when the users are not
interacting with their system.
So, additional related sessions
that I would really recommend,
Building Efficient OS X apps
and this is efficiency not just
from energy although energy
is the one focused on but also
from the standpoint of memory
use, from the standpoint
of just simply using
the resources
to their greatest effect.
Efficient Design with
XPC, I mentioned before
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
and that's an area where
you again can take advantage
of Centralized Task Scheduling.
Power and Performance:
Optimizing your Website
for Greatest Battery Life
in Response Scrolling.
That's going to be the longest
title of all the talks here.
But anyways, if you're a web
developer, absolutely go to that
so that you can produce
web pages that are more
in energy friendly
for your users.
Improving Power Efficiency with
App Nap, again a more deep dive
on the mechanisms in App
Nap and how those work
and how your app can
interact with those.
And then finally, Energy Best
Practices which is really
across the board kind
of more low level--
how OS X Mavericks
focuses on energy.
So, to leave you, you know,
it's really important I think
to understand that
battery life often
for users becomes almost the
most important feature to them.
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000
More and more you see
people out on the road.
They're using their
systems in a mobile fashion.
They're used to all-day
battery life from their iPads.
So, this is the new norm and
we need to get used to it
and we spent a lot of time
in Mavericks just squeezing
every last ounce out of
that battery and we hope
that you can use the tools
and the mechanisms in Mavericks,
do the same thing for your apps.
Thank you very much.
[Applause]
[ Silence ]