701.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:00.506 --> 00:00:15.486 A:middle
[ Silence ]

00:00:15.986 --> 00:00:24.516 A:middle
>> Well, good morning
and welcome.

00:00:24.516 --> 00:00:25.276 A:middle
[ Applause ]

00:00:25.276 --> 00:00:28.246 A:middle
>> I'm Bud Tribble, Vice
President of Software Technology

00:00:28.246 --> 00:00:29.456 A:middle
at Apple and I'm going to talk

00:00:29.456 --> 00:00:32.566 A:middle
about maximizing
battery life in OS X.

00:00:34.556 --> 00:00:41.206 A:middle
Now, you know, battery
life is just a key feature

00:00:41.206 --> 00:00:42.016 A:middle
for customers.

00:00:42.016 --> 00:00:45.146 A:middle
I know its key for me,
I know its key for you.

00:00:45.146 --> 00:00:48.506 A:middle
And as you can tell from
our key note sessions,

00:00:48.956 --> 00:00:51.596 A:middle
battery life is one of the
places where we put a lot

00:00:51.596 --> 00:00:53.636 A:middle
of focus in OS X Mavericks.

00:00:54.136 --> 00:00:58.546 A:middle
And the reason is simple,
mobility is a key feature

00:00:58.546 --> 00:01:02.156 A:middle
for our customers and battery
life is key for mobility.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:58.546 --> 00:01:02.156 A:middle
for our customers and battery
life is key for mobility.

00:01:02.816 --> 00:01:08.686 A:middle
Now, mobility has always
been an important feature.

00:01:09.726 --> 00:01:11.666 A:middle
However, the user experience

00:01:11.666 --> 00:01:13.596 A:middle
for mobility is not
always been great.

00:01:13.596 --> 00:01:16.896 A:middle
This is actually an Osborne
1, you probably don't--

00:01:16.896 --> 00:01:19.026 A:middle
most of you probably
don't remember

00:01:19.026 --> 00:01:20.386 A:middle
but the Osborne 1 was famous

00:01:20.386 --> 00:01:22.896 A:middle
for being the first computer
you could carry around with you.

00:01:23.306 --> 00:01:25.916 A:middle
However, even that in that
case because of the CRT

00:01:25.916 --> 00:01:28.526 A:middle
and other things, you had
to find a place to plug it

00:01:28.526 --> 00:01:30.836 A:middle
in as soon as you
wanted to use it.

00:01:31.406 --> 00:01:34.896 A:middle
Of course things have gotten
a lot better over the years

00:01:35.216 --> 00:01:40.956 A:middle
but nonetheless if you are
at 3 hours battery life

00:01:40.956 --> 00:01:44.446 A:middle
on your system, you're spending
most of your time just wondering

00:01:44.446 --> 00:01:46.736 A:middle
around looking for the next plug
and I'm sure you've all been

00:01:46.736 --> 00:01:48.886 A:middle
in the airport and that
sort of a situation.

00:01:49.536 --> 00:01:51.866 A:middle
Now, your battery life
will vary depending

00:01:51.866 --> 00:01:53.406 A:middle
on what you're doing of course.

00:01:53.766 --> 00:01:57.716 A:middle
But the goal that we set out for
was that for most of the people,

00:01:58.006 --> 00:01:59.506 A:middle
most of the users, most

00:01:59.506 --> 00:02:03.396 A:middle
of the time their battery would
last all day, they would plug it

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:59.506 --> 00:02:03.396 A:middle
of the time their battery would
last all day, they would plug it

00:02:03.396 --> 00:02:04.856 A:middle
in at night and that was it.

00:02:05.726 --> 00:02:08.376 A:middle
Now, we know that
that's a game changer

00:02:08.556 --> 00:02:11.806 A:middle
because of our experience
with products like iPad,

00:02:11.806 --> 00:02:16.886 A:middle
where that's the usual behavior
and once you get to that sort

00:02:16.886 --> 00:02:20.676 A:middle
of threshold, life gets a lot
better, there's a lot of bang

00:02:20.676 --> 00:02:23.336 A:middle
for the buck in getting
to that point.

00:02:27.766 --> 00:02:30.086 A:middle
Now, our latest products
which I'll go

00:02:30.086 --> 00:02:32.406 A:middle
into some more detail we
think we've gotten there

00:02:32.406 --> 00:02:33.876 A:middle
through a number of techniques.

00:02:33.876 --> 00:02:36.456 A:middle
It wasn't easy but
it was a lot of fun

00:02:36.456 --> 00:02:40.526 A:middle
over the development really with
a laser focus on battery life,

00:02:40.526 --> 00:02:43.766 A:middle
kind of a new perspective
in how you develop apps.

00:02:43.766 --> 00:02:47.196 A:middle
I hope to sort of translate
some of that to you or to--

00:02:47.456 --> 00:02:50.886 A:middle
I imbibe you with that because
in fact application developers

00:02:50.886 --> 00:02:54.536 A:middle
have a huge impact on the
user's battery life as well.

00:02:55.326 --> 00:02:59.176 A:middle
So, here we have a typical
customer out at the beach,

00:02:59.246 --> 00:03:03.986 A:middle
they've got the-- I don't
know if this is Mavericks,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:59.246 --> 00:03:03.986 A:middle
they've got the-- I don't
know if this is Mavericks,

00:03:04.056 --> 00:03:07.236 A:middle
probably isn't Mavericks
but here's a surfer who is,

00:03:07.236 --> 00:03:11.066 A:middle
you know, in between
surfing is editing his movies

00:03:11.066 --> 00:03:12.076 A:middle
with Final Cut Pro.

00:03:12.566 --> 00:03:18.096 A:middle
Well, even in this case assuming
he spends a reasonably long time

00:03:18.096 --> 00:03:20.496 A:middle
surfing even with
a heavy duty app

00:03:20.496 --> 00:03:24.196 A:middle
like Final Cut Pro he may
experience all-day battery life.

00:03:24.636 --> 00:03:26.896 A:middle
Users do not use our computers--

00:03:26.996 --> 00:03:29.146 A:middle
do not use their
computers continuously

00:03:29.456 --> 00:03:31.856 A:middle
and you can give them that
experience of only plugging

00:03:31.856 --> 00:03:35.196 A:middle
in at night in just a wide
variety of situations.

00:03:36.216 --> 00:03:40.506 A:middle
Now, with the latest MacBook
Airs combination of the hardware

00:03:40.506 --> 00:03:45.116 A:middle
and the latest MacBook Airs
that has well ULT processors

00:03:45.346 --> 00:03:46.376 A:middle
which are very efficient,

00:03:46.936 --> 00:03:52.616 A:middle
and Mac OS X Mavericks we think
we have reached that threshold

00:03:52.906 --> 00:03:54.736 A:middle
where people can
start to not think

00:03:54.736 --> 00:03:56.446 A:middle
about their battery
during the day

00:03:56.446 --> 00:03:59.176 A:middle
and we think there's
incredible value to that.

00:03:59.386 --> 00:04:02.246 A:middle
Now, I'll go into some
detail on how we get there,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:03:59.386 --> 00:04:02.246 A:middle
Now, I'll go into some
detail on how we get there,

00:04:02.656 --> 00:04:06.496 A:middle
it's actually there's a
lot of ingredients that go

00:04:06.496 --> 00:04:08.876 A:middle
into giving the customers
a great battery life.

00:04:09.156 --> 00:04:14.446 A:middle
Starting with chemistry, the
chemistry in the battery,

00:04:14.976 --> 00:04:18.125 A:middle
now we're used to Moore's law

00:04:18.125 --> 00:04:21.536 A:middle
with silicon wherever 18
months things get twice as--

00:04:21.956 --> 00:04:23.636 A:middle
you have twice as
much compute power,

00:04:24.016 --> 00:04:25.786 A:middle
that's not the case
with chemistry.

00:04:26.276 --> 00:04:28.996 A:middle
With batteries, batteries
have been slowly

00:04:28.996 --> 00:04:30.606 A:middle
but surely getting
better over the year

00:04:30.606 --> 00:04:33.976 A:middle
but the gains are measured in
single digit percentage points.

00:04:34.536 --> 00:04:40.686 A:middle
Nonetheless, Apple's been paying
a tremendous amount of attention

00:04:41.096 --> 00:04:44.056 A:middle
to battery life technology
and battery chemistry

00:04:44.216 --> 00:04:46.116 A:middle
and we have gotten
gradually better.

00:04:46.116 --> 00:04:48.796 A:middle
So, this is one of the
ingredients in getting there

00:04:49.036 --> 00:04:50.706 A:middle
in terms of all-day
battery life.

00:04:52.296 --> 00:04:55.906 A:middle
Second area though, the
hardware itself the silicon,

00:04:56.416 --> 00:05:01.336 A:middle
both at the atomic scale, the
nanoscale and the architecture

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:04:56.416 --> 00:05:01.336 A:middle
both at the atomic scale, the
nanoscale and the architecture

00:05:01.336 --> 00:05:05.506 A:middle
of the chip itself, that's
extremely important at getting

00:05:05.506 --> 00:05:06.506 A:middle
to all-day battery life.

00:05:06.506 --> 00:05:08.816 A:middle
I'll go into that
in some detail.

00:05:09.446 --> 00:05:12.146 A:middle
Of course the system
software is responsible

00:05:12.146 --> 00:05:15.976 A:middle
for scheduling the CPU
and other resources

00:05:16.226 --> 00:05:20.776 A:middle
in the way that's most energy
efficient and we've done a lot,

00:05:20.776 --> 00:05:24.106 A:middle
this is where we've done a lot
of work in Mac OS X Mavericks

00:05:24.256 --> 00:05:26.976 A:middle
to make sure that things
are as efficiently scheduled

00:05:26.976 --> 00:05:31.216 A:middle
as possible that the energy
is being spent on work

00:05:31.216 --> 00:05:34.496 A:middle
that the user actually
wants done versus work

00:05:34.686 --> 00:05:37.286 A:middle
that maybe they don't
care about.

00:05:37.286 --> 00:05:39.446 A:middle
So, we'll go into a
lot more detail on that

00:05:39.446 --> 00:05:41.096 A:middle
and actually a lot
of sessions further

00:05:41.096 --> 00:05:42.936 A:middle
on during the week
we're going to focus

00:05:42.936 --> 00:05:44.296 A:middle
on that sort of thing as well.

00:05:44.296 --> 00:05:47.926 A:middle
And then finally, as I mentioned
you the application developer

00:05:47.926 --> 00:05:49.376 A:middle
are part of the equation here.

00:05:49.746 --> 00:05:54.176 A:middle
And it's important for you to
use the tools that are provided

00:05:54.176 --> 00:05:57.116 A:middle
in Mac OS X Mavericks to
take, take a microscope,

00:05:57.116 --> 00:06:00.346 A:middle
take a closer look at how your
application is using energy

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:57.116 --> 00:06:00.346 A:middle
take a closer look at how your
application is using energy

00:06:00.796 --> 00:06:06.196 A:middle
and try and maximize the
efficiency to give that customer

00:06:06.336 --> 00:06:08.886 A:middle
that all-day battery life
that they really want.

00:06:09.716 --> 00:06:15.436 A:middle
Now, Apple is, as a company,
uniquely positioned compared

00:06:15.436 --> 00:06:17.916 A:middle
to a lot of others being
at the intersection

00:06:17.916 --> 00:06:19.246 A:middle
of hardware and software.

00:06:19.516 --> 00:06:23.176 A:middle
We build hardware and we build
the software that goes with it.

00:06:23.376 --> 00:06:26.756 A:middle
The system software so we can
spend a lot of time making sure

00:06:26.756 --> 00:06:29.646 A:middle
that those two things
are optimized together

00:06:29.646 --> 00:06:33.516 A:middle
and play well together to give
maximum battery life possible.

00:06:34.176 --> 00:06:36.826 A:middle
And that's what I want to
spend some time talking about.

00:06:37.186 --> 00:06:40.856 A:middle
How the hardware plus the
software working together

00:06:41.396 --> 00:06:42.906 A:middle
maximizes battery life.

00:06:43.556 --> 00:06:47.496 A:middle
Now, silicon itself
has come along way

00:06:47.496 --> 00:06:48.666 A:middle
in the last thirty years.

00:06:48.896 --> 00:06:52.706 A:middle
So, this is actually
on your left.

00:06:52.706 --> 00:06:57.076 A:middle
The original 68K, the
68,000 processors that went

00:06:57.076 --> 00:07:01.396 A:middle
into the Mac 128K and
Mac 512 back in 1984.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:06:57.076 --> 00:07:01.396 A:middle
into the Mac 128K and
Mac 512 back in 1984.

00:07:01.896 --> 00:07:08.506 A:middle
Now, that chip had oddly enough,
around 68,000 transistors on it.

00:07:09.326 --> 00:07:13.266 A:middle
The Intel Core i7, the
fourth-generation Core i7

00:07:13.266 --> 00:07:15.896 A:middle
that we have in the
MacBook Air has

00:07:15.896 --> 00:07:19.546 A:middle
about 1.4 billion
transistors on it.

00:07:19.976 --> 00:07:23.366 A:middle
Now, you know, the transistors

00:07:23.366 --> 00:07:26.656 A:middle
in the original Mac we're
not all that efficient.

00:07:26.656 --> 00:07:30.496 A:middle
In fact, if they drew the
same, if the transistors

00:07:30.496 --> 00:07:33.136 A:middle
in the Core i7 were drawing
the same amount of power

00:07:33.136 --> 00:07:37.486 A:middle
as the transistors in the 68K,
then the amount of power needed

00:07:37.486 --> 00:07:41.596 A:middle
to run the Core i7 would be
equivalent to the power drawn

00:07:41.596 --> 00:07:46.746 A:middle
by about 10 US average
households about 20,000 kilowatt

00:07:47.706 --> 00:07:49.846 A:middle
or 20,000-- 20 kilowatts.

00:07:50.246 --> 00:07:53.706 A:middle
Obviously, you know, a lot
has gone into making sure

00:07:53.706 --> 00:07:57.426 A:middle
that that catastrophe doesn't
happen, one of the things is

00:07:57.426 --> 00:08:02.426 A:middle
of course the transistors
just got smaller but again,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:57.426 --> 00:08:02.426 A:middle
of course the transistors
just got smaller but again,

00:08:02.426 --> 00:08:04.526 A:middle
this chip is running
at a higher frequency

00:08:04.856 --> 00:08:08.616 A:middle
and thus using more power
just because of that.

00:08:08.616 --> 00:08:11.986 A:middle
So, a lot of work had
to go in to the physics

00:08:11.986 --> 00:08:14.566 A:middle
of the transistors in order
to make them more efficient.

00:08:14.766 --> 00:08:19.366 A:middle
I want to talk a little
bit about some of those.

00:08:19.696 --> 00:08:22.536 A:middle
So, Intel in starting

00:08:22.536 --> 00:08:26.056 A:middle
at the early 2000 began using
something called strained

00:08:26.056 --> 00:08:29.116 A:middle
silicon, not just normal
silicon but strained silicon.

00:08:29.116 --> 00:08:33.696 A:middle
Strained silicon actually
has germanium atoms inserted

00:08:33.996 --> 00:08:38.525 A:middle
in between the silicon atoms and
the net result of that is that--

00:08:38.525 --> 00:08:41.905 A:middle
is that they can run
at a lower voltage.

00:08:41.905 --> 00:08:44.396 A:middle
The voltage gap is
lower and running

00:08:44.396 --> 00:08:46.196 A:middle
at a lower voltage
has a big effect.

00:08:46.466 --> 00:08:49.426 A:middle
Energy draw tends to be
proportional to voltage squared

00:08:49.426 --> 00:08:51.946 A:middle
so anything you can do
to reduce the voltage

00:08:52.306 --> 00:08:55.866 A:middle
and still switch those
transistors has a big effect.

00:08:55.866 --> 00:08:59.666 A:middle
So, Intel put a lot of effort
into moving to strained silicon.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:09:00.386 --> 00:09:01.706 A:middle
But that wasn't enough.

00:09:01.706 --> 00:09:02.886 A:middle
These things went forward.

00:09:02.886 --> 00:09:07.476 A:middle
Another problem arose which
was that between the gate

00:09:07.476 --> 00:09:09.736 A:middle
and the channel in
this transistors,

00:09:10.006 --> 00:09:12.076 A:middle
there's an insulator,
silicon dioxide.

00:09:12.556 --> 00:09:15.596 A:middle
Well that silicon dioxide as the
transistor shrunk was getting

00:09:15.596 --> 00:09:17.406 A:middle
to be just a few atoms thick.

00:09:17.966 --> 00:09:20.896 A:middle
And as a result electrons
actually tunnel through there,

00:09:21.176 --> 00:09:22.466 A:middle
they're leaking through there

00:09:22.586 --> 00:09:25.196 A:middle
and that leakage is
simply wasted energy.

00:09:25.526 --> 00:09:29.296 A:middle
There's R-squared energy leaked,
being wasted in that case.

00:09:29.296 --> 00:09:31.426 A:middle
So, what Intel did is they
looked around and they said,

00:09:31.626 --> 00:09:33.876 A:middle
"Is there any way we can make
those gates a little thicker

00:09:33.876 --> 00:09:35.526 A:middle
but still get the
same capacity."

00:09:35.526 --> 00:09:36.406 A:middle
And that's where they came

00:09:36.406 --> 00:09:39.306 A:middle
up with what's called
high-k metal gates.

00:09:39.766 --> 00:09:42.216 A:middle
And that those start
being used in 2007.

00:09:42.216 --> 00:09:45.076 A:middle
That was a big breakthrough
because you could get rid

00:09:45.076 --> 00:09:46.726 A:middle
of that leakage that would--

00:09:46.726 --> 00:09:49.616 A:middle
was really sitting there
continually drawing

00:09:49.616 --> 00:09:53.686 A:middle
down your battery and they
used a material called hafnium,

00:09:53.686 --> 00:09:56.156 A:middle
hafnium oxide which oxides

00:09:56.156 --> 00:09:58.386 A:middle
which have a very high
dielectric constant

00:09:58.386 --> 00:10:00.226 A:middle
so you can increase the
thickness of the gate.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:09:58.386 --> 00:10:00.226 A:middle
so you can increase the
thickness of the gate.

00:10:00.876 --> 00:10:03.806 A:middle
And then finally,
most recently in 2011,

00:10:03.806 --> 00:10:04.866 A:middle
they came up with something

00:10:05.186 --> 00:10:07.346 A:middle
that I guess they're marketing
guys called it Tri-gate

00:10:07.346 --> 00:10:09.476 A:middle
but it's really a
three-dimensional structure

00:10:09.476 --> 00:10:12.816 A:middle
for the gate so that
the gate can actually be

00:10:12.816 --> 00:10:16.406 A:middle
on all three sides of the
channel of the transistor rather

00:10:16.406 --> 00:10:18.546 A:middle
than just a plate on the
top of the transistor.

00:10:18.826 --> 00:10:21.666 A:middle
And these transistors are much
more efficient maybe 50 percent

00:10:21.666 --> 00:10:22.246 A:middle
more efficient.

00:10:22.706 --> 00:10:24.966 A:middle
So, there's going to be
more things in the future

00:10:24.966 --> 00:10:27.736 A:middle
but you can tell even--
even at the nanoscale,

00:10:27.946 --> 00:10:31.136 A:middle
a lot of stuff is being done to
make these chips more efficient.

00:10:31.976 --> 00:10:34.346 A:middle
Now, what's the result?

00:10:34.346 --> 00:10:40.246 A:middle
The result is that on the latest
chips, we're talking nanojoules

00:10:40.246 --> 00:10:42.476 A:middle
or tens of nanojouels
per instruction.

00:10:42.836 --> 00:10:43.786 A:middle
So, what's a nanojoule?

00:10:43.786 --> 00:10:47.686 A:middle
So, a nanojoules is a billionth
of a joule and a joule,

00:10:47.686 --> 00:10:51.726 A:middle
a billionth of a joule is a
very tiny amount of power.

00:10:52.026 --> 00:10:56.776 A:middle
I like to think sometimes in
terms of biology and in fact

00:10:57.046 --> 00:11:00.806 A:middle
when a neuron fires in your
brain its taking on the order

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:57.046 --> 00:11:00.806 A:middle
when a neuron fires in your
brain its taking on the order

00:11:00.806 --> 00:11:03.516 A:middle
of picojoules, about a
thousand times as much.

00:11:03.516 --> 00:11:07.156 A:middle
So, you can sort of think
of an instruction executing

00:11:07.156 --> 00:11:11.206 A:middle
in the Core i7 as being
same amount of power,

00:11:11.206 --> 00:11:15.906 A:middle
same amount of energy is
about several thousand neurons

00:11:16.246 --> 00:11:19.166 A:middle
in your brain firing, so your
brain executing one instruction.

00:11:19.566 --> 00:11:22.136 A:middle
So, we're really getting
down there to the level

00:11:22.136 --> 00:11:25.796 A:middle
where biological systems have
evolved over obviously billions

00:11:25.796 --> 00:11:26.826 A:middle
and billions of years.

00:11:27.896 --> 00:11:35.286 A:middle
Now, this is a micrograph of the
Haswell ULT chip from Intel and,

00:11:35.546 --> 00:11:39.596 A:middle
you know, it's a small chip
about the size of a fingernail

00:11:39.986 --> 00:11:42.936 A:middle
but on here are 1.4
billion transistors.

00:11:42.936 --> 00:11:46.076 A:middle
And that's divided up into
the functional units the--

00:11:46.426 --> 00:11:48.406 A:middle
in this chip there
are two cores.

00:11:49.316 --> 00:11:52.606 A:middle
There is a huge amount as
Phil said yesterday devoted

00:11:52.606 --> 00:11:55.826 A:middle
to the GPU to the
graphics processor.

00:11:56.456 --> 00:12:00.576 A:middle
There's the shared L2 cache,
the memory manager and some

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:11:56.456 --> 00:12:00.576 A:middle
There's the shared L2 cache,
the memory manager and some

00:12:00.576 --> 00:12:02.556 A:middle
of the things for managing DMA.

00:12:02.926 --> 00:12:06.676 A:middle
Now, the interesting thing
about modern chips is

00:12:06.676 --> 00:12:11.766 A:middle
that during execution, you can
power down parts of those chips

00:12:11.766 --> 00:12:12.826 A:middle
that aren't being used.

00:12:13.016 --> 00:12:15.356 A:middle
If you're not using the GPU
right now, you can turn off

00:12:15.356 --> 00:12:17.246 A:middle
that part of the
chip, saving energy.

00:12:17.826 --> 00:12:19.366 A:middle
If you're not using both cores,

00:12:19.366 --> 00:12:20.716 A:middle
you can turn off
one of the cores.

00:12:20.816 --> 00:12:22.796 A:middle
You're not using both
cores, turn those off.

00:12:23.296 --> 00:12:26.486 A:middle
And that turns out to
be architecturally one

00:12:26.486 --> 00:12:28.576 A:middle
of the key ways to save power

00:12:28.576 --> 00:12:31.286 A:middle
in these portable systems
that we have today.

00:12:31.756 --> 00:12:34.116 A:middle
Now, it requires
close interaction

00:12:34.116 --> 00:12:37.116 A:middle
between a system software and
the silicon in order to make

00:12:37.116 --> 00:12:41.236 A:middle
that happen correctly
but as we'll get into,

00:12:41.236 --> 00:12:43.746 A:middle
if you do it right, you can
save a huge amount of power.

00:12:44.316 --> 00:12:48.486 A:middle
Now, this shows you what that
looks like and in reality,

00:12:48.486 --> 00:12:51.056 A:middle
this is actually,
it's not Haswell,

00:12:51.056 --> 00:12:52.866 A:middle
it's Ivy Bridge previous
generation

00:12:53.226 --> 00:12:57.416 A:middle
but it's what called an
infrared emission microscopy.

00:12:57.786 --> 00:12:59.336 A:middle
So, you're looking actually

00:12:59.336 --> 00:13:02.886 A:middle
at the heat waves coming off
the chip as its executing.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:59.336 --> 00:13:02.886 A:middle
at the heat waves coming off
the chip as its executing.

00:13:03.466 --> 00:13:06.696 A:middle
So, the blue spots
are cooler, the orange

00:13:06.696 --> 00:13:08.136 A:middle
and the red spots are hotter

00:13:08.336 --> 00:13:12.516 A:middle
and in this case what you have
is one core is powered up,

00:13:12.516 --> 00:13:15.656 A:middle
this is a four core system, so
you see one core powered up,

00:13:15.886 --> 00:13:17.836 A:middle
the shared L3 cache
is powered up.

00:13:18.206 --> 00:13:20.416 A:middle
The GPU down at the
bottom is powered down.

00:13:21.166 --> 00:13:24.416 A:middle
And here's some other
examples of states

00:13:24.416 --> 00:13:25.656 A:middle
that that chip can be in.

00:13:25.656 --> 00:13:29.596 A:middle
The middle one shows all four
cores and some and the GPU going

00:13:29.636 --> 00:13:31.636 A:middle
at a fairly fast clip.

00:13:31.996 --> 00:13:34.326 A:middle
The last one shows
all four cores,

00:13:34.326 --> 00:13:38.226 A:middle
all the cores are powered
down, the GPU is powered down.

00:13:38.616 --> 00:13:42.456 A:middle
It turns out that
just a normal course

00:13:42.456 --> 00:13:46.226 A:middle
of using a computer
interactively, the chip,

00:13:46.336 --> 00:13:51.076 A:middle
the CPU chip spends most of its
time typically in that state.

00:13:51.436 --> 00:13:55.716 A:middle
That's because, the CPU is
often waiting for user input.

00:13:55.766 --> 00:13:58.816 A:middle
It's waiting for the
network I/O to interrupt.

00:13:58.816 --> 00:14:00.526 A:middle
It's waiting for
the GPU to be done.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:58.816 --> 00:14:00.526 A:middle
It's waiting for
the GPU to be done.

00:14:00.766 --> 00:14:04.616 A:middle
A lot of the time in modern chip
is spent with parts of that chip

00:14:04.956 --> 00:14:06.866 A:middle
or even most of that
chip turned off.

00:14:07.636 --> 00:14:09.016 A:middle
So, what do you get from that?

00:14:09.016 --> 00:14:12.776 A:middle
That you get a tremendous
dynamic range and how much power

00:14:12.776 --> 00:14:14.796 A:middle
that should CPU chip can draw.

00:14:15.216 --> 00:14:18.136 A:middle
When it's idle, when it's
not doing much and parts

00:14:18.136 --> 00:14:20.856 A:middle
of it are turned
off or powered down,

00:14:20.856 --> 00:14:24.156 A:middle
you can get down to 0.4 watts.

00:14:24.686 --> 00:14:28.396 A:middle
On the other hand if you're
doing a while one loop

00:14:28.606 --> 00:14:30.286 A:middle
and the thing is just
sitting there spinning

00:14:30.286 --> 00:14:34.356 A:middle
or a CPU limited operation
transcoding a movie or something

00:14:34.356 --> 00:14:39.386 A:middle
like that, that can boom up to
25 watts, 30 times more power.

00:14:39.816 --> 00:14:42.706 A:middle
And if the thermal conditions
are right, you can even kick

00:14:42.706 --> 00:14:46.116 A:middle
in to turbo and get up to
maybe 60 times more power

00:14:46.466 --> 00:14:47.366 A:middle
than an idle chip.

00:14:47.736 --> 00:14:50.026 A:middle
To let you know how
this compares

00:14:50.026 --> 00:14:53.396 A:middle
with total system power,
remember that was just the CPU,

00:14:53.986 --> 00:14:56.866 A:middle
well when you're idle, the
CPU is a very small part

00:14:56.866 --> 00:14:58.486 A:middle
of your system power
because a lot

00:14:58.486 --> 00:15:00.016 A:middle
of power is going
to the backlight.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:58.486 --> 00:15:00.016 A:middle
of power is going
to the backlight.

00:15:00.016 --> 00:15:01.586 A:middle
It maybe go into Wi-Fi,

00:15:01.986 --> 00:15:05.036 A:middle
radios and other things
and the power supply.

00:15:05.346 --> 00:15:07.506 A:middle
And so, the CPU at idle

00:15:07.506 --> 00:15:09.666 A:middle
when it's mostly turned
off is a very tiny part

00:15:09.666 --> 00:15:11.136 A:middle
of the total system power.

00:15:11.476 --> 00:15:15.416 A:middle
However, when you're doing
CPU limited operations,

00:15:15.976 --> 00:15:21.026 A:middle
you've got a tremendous amount--
the lion share the power going

00:15:21.026 --> 00:15:24.406 A:middle
to the CPU and that overshadows
things like the backlight.

00:15:25.056 --> 00:15:26.646 A:middle
That's important
thing to keep in mind.

00:15:26.646 --> 00:15:30.456 A:middle
That tremendous dynamic
range means that the software

00:15:30.456 --> 00:15:33.276 A:middle
and apps you write have
a tremendous impact--

00:15:33.646 --> 00:15:36.236 A:middle
tremendous leverage on how
much power is being drawn

00:15:36.236 --> 00:15:40.066 A:middle
and thus how much-- long the
battery is going to last.

00:15:41.056 --> 00:15:44.846 A:middle
Now, with interactive systems,
most of the time as I mentioned,

00:15:45.076 --> 00:15:48.666 A:middle
the CPU is actually
powered down or clock gated

00:15:48.666 --> 00:15:50.326 A:middle
or not drawing a lot of power.

00:15:50.326 --> 00:15:51.806 A:middle
It is a more or less idle state.

00:15:52.116 --> 00:15:56.336 A:middle
The reason is that user events
don't occur very frequently

00:15:56.336 --> 00:15:59.376 A:middle
compared to the time scales
of executing and instruction.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:16:00.026 --> 00:16:02.256 A:middle
So, even if you're
typing 50 words per minute

00:16:02.256 --> 00:16:05.706 A:middle
which probably most of you can
do-- that's one key every--

00:16:05.706 --> 00:16:07.796 A:middle
more quarter of a
second more or less.

00:16:08.126 --> 00:16:11.446 A:middle
That's a huge amount of
time in between responding

00:16:11.446 --> 00:16:15.446 A:middle
to those events that potentially
the CPU can be [inaudible]

00:16:15.446 --> 00:16:20.636 A:middle
assuming there's no network
activity, et cetera, et cetera.

00:16:21.136 --> 00:16:24.396 A:middle
So, that's a key strategy to
take advantage of the fact

00:16:24.396 --> 00:16:27.226 A:middle
that on interactive systems,
you're really spending a lot

00:16:27.226 --> 00:16:28.916 A:middle
of your time with the CPU idle.

00:16:29.396 --> 00:16:30.706 A:middle
And to show you what
that looks like,

00:16:31.396 --> 00:16:35.776 A:middle
this is actually a
trace of CPU activity.

00:16:35.776 --> 00:16:40.216 A:middle
So, system wide CPU activity
as someone is in Safari,

00:16:40.496 --> 00:16:42.336 A:middle
they're browsing to apple.com.

00:16:43.066 --> 00:16:46.116 A:middle
So, at the beginning here
you have their typing

00:16:46.516 --> 00:16:49.066 A:middle
and as I mentioned,
you've got less

00:16:49.066 --> 00:16:52.036 A:middle
than 10 percent of CPU activity.

00:16:52.036 --> 00:16:55.236 A:middle
That means the CPU is
essentially shut off 90 percent

00:16:55.236 --> 00:16:55.776 A:middle
of the time.

00:16:56.316 --> 00:16:59.916 A:middle
And then you go to where
you're fetching doing HTTP gets

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:00.186 --> 00:17:04.336 A:middle
from the network and the network
is not infinitely responsive,

00:17:04.336 --> 00:17:06.606 A:middle
so you even have time in
between those network,

00:17:06.606 --> 00:17:10.356 A:middle
in between those gets to put
the CPU to a low power state.

00:17:10.766 --> 00:17:13.876 A:middle
Then finally when you're
rendering, the CPU is waiting

00:17:13.876 --> 00:17:15.806 A:middle
on the GPU to render
those pages.

00:17:15.806 --> 00:17:18.636 A:middle
So, again, less than
5 percent activity.

00:17:18.846 --> 00:17:24.685 A:middle
So, if you were to-- if
you're able to look at CPU on,

00:17:24.685 --> 00:17:26.906 A:middle
CPU off over the course of time.

00:17:26.906 --> 00:17:28.286 A:middle
So, this is about five seconds.

00:17:28.616 --> 00:17:31.276 A:middle
You see that there are
many, many rapid transitions

00:17:31.546 --> 00:17:34.846 A:middle
from the CPU being
powered up fully running

00:17:35.096 --> 00:17:38.996 A:middle
to the CPU essentially going
to sleep in between events,

00:17:38.996 --> 00:17:43.156 A:middle
in between network packets,
in between GPU invocations.

00:17:43.506 --> 00:17:48.396 A:middle
So, the key here is to make
sure that the percentage

00:17:48.396 --> 00:17:52.686 A:middle
of time spent in those low power
states is the most that can be.

00:17:52.956 --> 00:17:58.286 A:middle
Now, if we zoom in here, this
is a 1 millisecond time scale.

00:17:58.796 --> 00:18:02.036 A:middle
We see that there
are pretty huge gaps

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:58.796 --> 00:18:02.036 A:middle
We see that there
are pretty huge gaps

00:18:02.036 --> 00:18:04.996 A:middle
where you could literally
execute tens of thousands

00:18:04.996 --> 00:18:06.816 A:middle
or hundreds of thousands
of instructions

00:18:07.166 --> 00:18:09.966 A:middle
but instead you're-- the
system is putting the CPU

00:18:09.966 --> 00:18:11.496 A:middle
into a low power state.

00:18:12.356 --> 00:18:16.336 A:middle
Well, it would be nice if it was
just like turning a light switch

00:18:16.336 --> 00:18:19.066 A:middle
on or off to put it on
those states but it's not.

00:18:19.416 --> 00:18:20.506 A:middle
It's not that simple.

00:18:21.796 --> 00:18:28.186 A:middle
In order to get the CPU to
turn off or to turn back on,

00:18:28.456 --> 00:18:31.916 A:middle
it's actually a fairly
complex process.

00:18:32.276 --> 00:18:37.436 A:middle
So, in this case, it takes time.

00:18:37.756 --> 00:18:41.926 A:middle
This is not actually turning the
CPU or the core completely off.

00:18:41.926 --> 00:18:44.836 A:middle
This is an example of
what's called clock gating--

00:18:44.836 --> 00:18:47.796 A:middle
you stop all the clocks going
to that part of the chip.

00:18:47.796 --> 00:18:50.936 A:middle
And in this case, you
stop the phase-lock loop

00:18:51.296 --> 00:18:54.196 A:middle
that is supplying the clocks
for that part of the chip.

00:18:54.896 --> 00:18:57.416 A:middle
But, that means that when
you want to turn it back on,

00:18:57.936 --> 00:18:59.976 A:middle
you have to start up
that phase-lock loop.

00:18:59.976 --> 00:19:02.136 A:middle
You have to get it to sync
up with the rest of the chip

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:18:59.976 --> 00:19:02.136 A:middle
You have to get it to sync
up with the rest of the chip

00:19:02.136 --> 00:19:04.746 A:middle
and then finally,
you get to turn--

00:19:04.746 --> 00:19:08.816 A:middle
start doing useful processing
after 10 to 15 microseconds.

00:19:09.156 --> 00:19:13.806 A:middle
So, there's overhead associated
with turning the chip on or off.

00:19:14.086 --> 00:19:15.706 A:middle
It can be even more than that.

00:19:16.046 --> 00:19:19.286 A:middle
In this case, you're taking
the voltage to the core

00:19:19.286 --> 00:19:21.256 A:middle
and you're dropping
it all the way to zero

00:19:21.546 --> 00:19:23.096 A:middle
in which case you
lose all state.

00:19:23.896 --> 00:19:26.236 A:middle
That means that when
you turn it back on,

00:19:26.406 --> 00:19:29.216 A:middle
you're spending time
reloading state for that part

00:19:29.216 --> 00:19:31.736 A:middle
of the chip could be
hundreds of microseconds.

00:19:32.336 --> 00:19:36.596 A:middle
So, in these cases,
what's happening is

00:19:36.596 --> 00:19:39.436 A:middle
that you're applying full
power to the chip in order

00:19:39.436 --> 00:19:41.396 A:middle
to get it up, turn on again,

00:19:41.856 --> 00:19:43.976 A:middle
but you're not doing any
useful computing power.

00:19:44.076 --> 00:19:46.126 A:middle
That's wasted energy
for that time.

00:19:46.826 --> 00:19:48.756 A:middle
And, that adds up over time.

00:19:49.186 --> 00:19:53.426 A:middle
So, here's going back to
our diagram of CPU turns

00:19:53.426 --> 00:19:55.036 A:middle
on for a bit, turns
off for a bit.

00:19:55.446 --> 00:19:59.456 A:middle
But, those RAMs are intended
to show that during that time,

00:19:59.746 --> 00:20:00.736 A:middle
you're powering the chip,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:59.746 --> 00:20:00.736 A:middle
you're powering the chip,

00:20:00.786 --> 00:20:03.466 A:middle
you're not doing any useful
work, that's wasted power.

00:20:03.876 --> 00:20:07.496 A:middle
So, the strategy here is
to minimize those times.

00:20:08.686 --> 00:20:10.316 A:middle
Now, how do you do that?

00:20:10.966 --> 00:20:14.236 A:middle
Well, that's where the
system scheduler comes in.

00:20:14.236 --> 00:20:18.066 A:middle
That's where how timers
are scheduled comes in.

00:20:18.366 --> 00:20:20.456 A:middle
And, that's what we'll spend
some time talking about.

00:20:21.006 --> 00:20:22.736 A:middle
But the basic idea is simple.

00:20:22.736 --> 00:20:25.826 A:middle
The basic idea is if you
can shift around that work

00:20:25.826 --> 00:20:27.926 A:middle
and batch it up into
a single packet

00:20:27.926 --> 00:20:33.686 A:middle
of CPU work then you can turn
on the chip once, do your work,

00:20:33.906 --> 00:20:36.196 A:middle
turn off the chip
and those red areas

00:20:36.526 --> 00:20:41.246 A:middle
which are essentially wasted
energy can be decreased

00:20:41.246 --> 00:20:42.416 A:middle
into just a couple of them.

00:20:42.416 --> 00:20:45.176 A:middle
So, this is what it looks
like when you do that.

00:20:45.856 --> 00:20:50.446 A:middle
So, scheduling that work in
bundles or in batching it

00:20:50.446 --> 00:20:54.206 A:middle
up together is one of the
key strategies that's used

00:20:54.206 --> 00:20:55.416 A:middle
by Mac OS X.

00:20:55.826 --> 00:20:58.096 A:middle
And we'll spend a little bit
of time talking about how

00:20:58.096 --> 00:21:01.666 A:middle
that interacts with App Nap,
how perhaps that interacts

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:58.096 --> 00:21:01.666 A:middle
that interacts with App Nap,
how perhaps that interacts

00:21:01.666 --> 00:21:04.066 A:middle
with the application you're
writing, how you can do

00:21:04.066 --> 00:21:07.766 A:middle
that in a way that lets the
system coalesce these things

00:21:08.026 --> 00:21:11.866 A:middle
and decrease that red
rectangle the time it takes

00:21:11.866 --> 00:21:14.206 A:middle
to power the chip on
and power the chip off.

00:21:14.666 --> 00:21:21.526 A:middle
So, to review, in an
interactive system its idle most

00:21:21.526 --> 00:21:23.776 A:middle
of the time-- it's
idle much of the time.

00:21:24.196 --> 00:21:26.406 A:middle
And modern chips can
take advantage of that

00:21:26.406 --> 00:21:30.086 A:middle
by turning themselves off or
turning parts of themselves off

00:21:30.086 --> 00:21:32.746 A:middle
when they're not needed
and the key strategy is

00:21:32.746 --> 00:21:35.596 A:middle
to batch work together so that
you're not spending a lot your

00:21:35.596 --> 00:21:37.406 A:middle
time ramping up and
ramping down.

00:21:38.126 --> 00:21:41.176 A:middle
So, maximize idle time,
minimize transitions.

00:21:42.756 --> 00:21:47.786 A:middle
So, let's talk about how OS X
Mavericks addresses these sorts

00:21:47.786 --> 00:21:48.426 A:middle
of issues.

00:21:49.176 --> 00:21:52.346 A:middle
And I'm going to talk
about several things.

00:21:52.346 --> 00:21:57.236 A:middle
One is sort of on the tool side,
making energy impact visible.

00:21:57.236 --> 00:22:00.616 A:middle
And if you want to improve any
aspect of the system making it

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:57.236 --> 00:22:00.616 A:middle
And if you want to improve any
aspect of the system making it

00:22:00.616 --> 00:22:02.436 A:middle
so you can measure that is key

00:22:02.806 --> 00:22:05.586 A:middle
and we don't exactly have
ammeters that we can go in there

00:22:05.586 --> 00:22:09.446 A:middle
and put on apps or put on
processes but we have corallites

00:22:09.446 --> 00:22:12.046 A:middle
of energy use and we'll talk
about how we used those.

00:22:12.826 --> 00:22:16.436 A:middle
Second thing is system
strategies

00:22:16.436 --> 00:22:19.476 A:middle
and application strategies for
energy efficiency and that gets

00:22:19.476 --> 00:22:21.266 A:middle
to some of the things I
was just talking about.

00:22:21.636 --> 00:22:25.006 A:middle
How do you batch up work so that
you're minimizing the amount

00:22:25.006 --> 00:22:28.756 A:middle
of those wasting energy wasting
transitions that are going on.

00:22:29.216 --> 00:22:31.026 A:middle
And finally, what you
can you do as developers?

00:22:31.026 --> 00:22:35.356 A:middle
I mean there's a lot we can
do as a system developers

00:22:35.546 --> 00:22:37.416 A:middle
down at the low level
but actually,

00:22:37.416 --> 00:22:40.226 A:middle
this bubbles all the way to the
apps and how the apps behave

00:22:40.226 --> 00:22:43.546 A:middle
and how you can change your
apps to be more power efficient.

00:22:44.426 --> 00:22:50.126 A:middle
So, starting off in our-- in
OS X Mavericks, if you go up

00:22:50.126 --> 00:22:52.066 A:middle
and you look at the
battery status menu,

00:22:52.836 --> 00:22:54.156 A:middle
you'll see some new
things in it.

00:22:54.536 --> 00:22:59.056 A:middle
So, in this case, we are
actually showing applications

00:22:59.476 --> 00:23:01.656 A:middle
which are using significant
energy.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:22:59.476 --> 00:23:01.656 A:middle
which are using significant
energy.

00:23:02.466 --> 00:23:08.776 A:middle
Now, in many cases, that will
be entirely expected and desired

00:23:09.436 --> 00:23:13.256 A:middle
if you're doing a
render in Final Cut Pro,

00:23:13.256 --> 00:23:14.676 A:middle
it's going to show up there.

00:23:14.676 --> 00:23:18.336 A:middle
If you're doing a
batch compile in Xcode,

00:23:18.336 --> 00:23:19.436 A:middle
it's going to show up there.

00:23:19.836 --> 00:23:23.176 A:middle
On the other hand, you may
have something show up there

00:23:23.176 --> 00:23:29.716 A:middle
that is unexpected and maybe
undesired and we're going

00:23:29.716 --> 00:23:33.516 A:middle
to make that visible in
the battery status menu.

00:23:33.796 --> 00:23:38.416 A:middle
If you double click on any
of those, it will take you

00:23:38.416 --> 00:23:39.886 A:middle
to activity monitor

00:23:40.356 --> 00:23:44.196 A:middle
and in activity monitor we
have a new tray or a new tab

00:23:44.936 --> 00:23:46.986 A:middle
which is the energy tab.

00:23:47.546 --> 00:23:52.056 A:middle
The energy tab shows
two new columns.

00:23:52.206 --> 00:23:53.996 A:middle
One is called energy impact.

00:23:54.226 --> 00:23:57.946 A:middle
I'll just take a moment
to say what that means.

00:23:58.206 --> 00:24:02.966 A:middle
So, energy impact is a
surrogate for trying to look

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:58.206 --> 00:24:02.966 A:middle
So, energy impact is a
surrogate for trying to look

00:24:02.966 --> 00:24:05.536 A:middle
at the energy impact
that an application

00:24:05.536 --> 00:24:06.736 A:middle
or a process is having.

00:24:07.006 --> 00:24:09.936 A:middle
Now, as I mentioned, we
can't stick a power meter

00:24:09.936 --> 00:24:14.746 A:middle
on it directly but what we can
do is look at the CPU usage

00:24:15.126 --> 00:24:18.646 A:middle
by that app and look at
the interrupts or timers

00:24:18.646 --> 00:24:23.466 A:middle
that are caused by that app
and cause the CPU to wake up.

00:24:23.466 --> 00:24:25.746 A:middle
In other words, cause one
of those red rectangles

00:24:26.006 --> 00:24:27.236 A:middle
that I was looking at earlier.

00:24:27.236 --> 00:24:33.026 A:middle
And we track those using
counters and we apply

00:24:33.026 --> 00:24:35.756 A:middle
that to the energy impact
that that app is causing.

00:24:36.106 --> 00:24:39.516 A:middle
So, you get a number that
is a relative measure

00:24:39.516 --> 00:24:42.826 A:middle
of energy impact by an
app or by a process.

00:24:43.476 --> 00:24:45.776 A:middle
And further than that in
the next column over--

00:24:45.776 --> 00:24:49.146 A:middle
so that's the column
with the energy impact.

00:24:49.456 --> 00:24:54.126 A:middle
Next column over, we show
the average energy impact

00:24:54.126 --> 00:24:55.926 A:middle
over the previous eight hours.

00:24:56.216 --> 00:24:59.996 A:middle
So, actually the previous
eight hours or until, you know,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:00.216 --> 00:25:02.526 A:middle
back into the last time
you booted your system

00:25:02.826 --> 00:25:04.336 A:middle
if that was less
than eight hours.

00:25:04.446 --> 00:25:07.336 A:middle
But this is important
because, number one,

00:25:07.336 --> 00:25:12.336 A:middle
you might have something-- an
app that had come in there run

00:25:12.586 --> 00:25:15.386 A:middle
for five minutes and burned
a lot of your battery,

00:25:15.616 --> 00:25:18.676 A:middle
and now it's just quiescent
but you'd like to know

00:25:18.676 --> 00:25:21.016 A:middle
that that happened at some
point and that will show up in

00:25:21.016 --> 00:25:22.166 A:middle
that eight hour average.

00:25:22.466 --> 00:25:25.186 A:middle
Just as important,
you may have the apps

00:25:25.186 --> 00:25:30.266 A:middle
that are just using
battery energy at a low clip

00:25:30.476 --> 00:25:33.206 A:middle
but they're constant, they're
just going on all the time.

00:25:33.536 --> 00:25:37.406 A:middle
Again, the history, the
average makes that visible.

00:25:37.886 --> 00:25:41.686 A:middle
So, this is the first clue that
there might be something going

00:25:41.686 --> 00:25:44.366 A:middle
on you don't expect or that
the user doesn't expect.

00:25:44.786 --> 00:25:49.106 A:middle
Now, as a developer what
you're going to want

00:25:49.106 --> 00:25:51.046 A:middle
to do then is go into Xcode.

00:25:51.046 --> 00:25:55.326 A:middle
And in Xcode, we have
quite a few more tools

00:25:55.326 --> 00:25:57.466 A:middle
that let you take the next step

00:25:57.546 --> 00:26:00.956 A:middle
to investigate why this
app might be using energy.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:57.546 --> 00:26:00.956 A:middle
to investigate why this
app might be using energy.

00:26:01.356 --> 00:26:07.226 A:middle
So, in the latest Xcode, we have
what's called the Energy Gauge,

00:26:07.226 --> 00:26:08.456 A:middle
Energy Impact Gauge.

00:26:08.776 --> 00:26:10.656 A:middle
Go to the-- if you
just run your app,

00:26:11.326 --> 00:26:14.266 A:middle
that'll show up on
the left there.

00:26:14.296 --> 00:26:15.446 A:middle
You can click on that

00:26:15.446 --> 00:26:17.646 A:middle
and it gives you much
more insight into,

00:26:17.916 --> 00:26:20.106 A:middle
is your app firing off timers?

00:26:20.736 --> 00:26:22.966 A:middle
Is your app using CPU?

00:26:23.146 --> 00:26:25.526 A:middle
Why might it be doing this?

00:26:25.526 --> 00:26:28.306 A:middle
Can I go look at the
event timeline and see--

00:26:28.306 --> 00:26:32.286 A:middle
you know, make sure you
understand why it's doing that.

00:26:32.536 --> 00:26:35.456 A:middle
As I mentioned before, it
maybe doing very useful work

00:26:35.906 --> 00:26:38.876 A:middle
but it maybe doing work that you
can do in a more efficient way.

00:26:40.346 --> 00:26:44.246 A:middle
Now, we have built
in to OS X Mavericks,

00:26:44.786 --> 00:26:48.076 A:middle
strategies that we
use across the board

00:26:48.416 --> 00:26:51.076 A:middle
to make things more efficient
from an energy standpoint

00:26:51.076 --> 00:26:52.696 A:middle
and I want to talk
about three of those.

00:26:53.586 --> 00:26:56.446 A:middle
First one is App Nap.

00:26:56.446 --> 00:26:58.816 A:middle
An App Nap was mentioned
yesterday.

00:26:59.056 --> 00:27:00.616 A:middle
I'll go into little
bit more detail

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:59.056 --> 00:27:00.616 A:middle
I'll go into little
bit more detail

00:27:00.616 --> 00:27:03.396 A:middle
into what App Nap is actually
doing and there's going

00:27:03.396 --> 00:27:07.316 A:middle
to be further sessions coming up
that will go into great detail

00:27:07.316 --> 00:27:11.976 A:middle
and APIs around that that
I would suggest you go to.

00:27:12.176 --> 00:27:14.326 A:middle
Centralized Task
Scheduling is the next one.

00:27:14.506 --> 00:27:17.726 A:middle
Centralized task scheduling is a
much longer time scale but it's

00:27:17.726 --> 00:27:21.386 A:middle
about moving work around to
times they're more opportune,

00:27:21.696 --> 00:27:24.006 A:middle
either more opportune
from an energy standpoint,

00:27:24.246 --> 00:27:27.356 A:middle
you're back on AC power or more
opportune just from staying

00:27:27.356 --> 00:27:28.526 A:middle
out of the way of the user.

00:27:28.636 --> 00:27:33.026 A:middle
And then finally Power Saver,
and this all about Safari

00:27:33.196 --> 00:27:36.366 A:middle
and providing a web-browsing
experience

00:27:36.366 --> 00:27:37.426 A:middle
that is power efficient.

00:27:37.756 --> 00:27:40.316 A:middle
So, let's go through those.

00:27:40.316 --> 00:27:41.666 A:middle
First of all, App Nap.

00:27:41.926 --> 00:27:46.366 A:middle
So, a typical use, you
know, users interacting

00:27:46.366 --> 00:27:48.006 A:middle
with one application
on the screen

00:27:48.226 --> 00:27:51.506 A:middle
but of course they've
got, you know,

00:27:51.506 --> 00:27:53.386 A:middle
many other apps up
in the background.

00:27:54.546 --> 00:27:57.786 A:middle
Now, the app they're
interacting with is

00:27:57.786 --> 00:28:00.116 A:middle
where they're really
interested in results.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:57.786 --> 00:28:00.116 A:middle
where they're really
interested in results.

00:28:00.516 --> 00:28:03.176 A:middle
But the apps that
are in the background

00:28:03.716 --> 00:28:07.646 A:middle
when you measure systems often
are sitting there drawing power.

00:28:07.646 --> 00:28:09.406 A:middle
They maybe drawing
low levels of power,

00:28:09.406 --> 00:28:10.976 A:middle
they maybe drawing
medium levels of power

00:28:10.976 --> 00:28:12.596 A:middle
but they're drawing power

00:28:12.926 --> 00:28:15.826 A:middle
and often times they're
not doing things

00:28:15.826 --> 00:28:18.256 A:middle
that the user is really--

00:28:18.606 --> 00:28:20.576 A:middle
all that interested
in at that moment.

00:28:21.296 --> 00:28:25.626 A:middle
So, what App Nap is all
about is quiescing those apps

00:28:25.836 --> 00:28:27.606 A:middle
that the user is
not interacting with

00:28:28.216 --> 00:28:31.566 A:middle
or that are not visibly
drawing on the screen

00:28:31.936 --> 00:28:35.346 A:middle
or they're not creating
an audio output stream

00:28:35.346 --> 00:28:36.136 A:middle
that they're going to hear.

00:28:36.256 --> 00:28:38.606 A:middle
So, we use heuristics to decide

00:28:38.606 --> 00:28:41.376 A:middle
when an app is a
candidate for App Nap.

00:28:42.076 --> 00:28:43.446 A:middle
Once we decide it's a candidate

00:28:43.446 --> 00:28:47.426 A:middle
for App Nap we start
doing a variety of things

00:28:47.646 --> 00:28:50.686 A:middle
to suppress the energy
use by that app.

00:28:51.226 --> 00:28:55.126 A:middle
And, you know, devote, thus
devoting most of the energy

00:28:55.326 --> 00:28:57.216 A:middle
to what the user
is interacting with

00:28:57.216 --> 00:28:58.586 A:middle
and what they're interested in.

00:28:59.356 --> 00:29:00.196 A:middle
So, what do we do?

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:59.356 --> 00:29:00.196 A:middle
So, what do we do?

00:29:00.256 --> 00:29:04.636 A:middle
Well, we will adjust CPU
and I/O prioritization.

00:29:04.966 --> 00:29:07.556 A:middle
But beyond that, we will
also be more aggressive

00:29:07.556 --> 00:29:10.586 A:middle
about coalescing
timers in that app

00:29:10.676 --> 00:29:12.826 A:middle
or in processes associated
with that app.

00:29:13.176 --> 00:29:18.416 A:middle
So if there are timers that are
being set we will move those

00:29:18.416 --> 00:29:21.396 A:middle
timers around to align
them with other timers

00:29:21.606 --> 00:29:24.626 A:middle
so that you don't have
this overhead of power--

00:29:24.766 --> 00:29:26.836 A:middle
potential overhead
if the chip is coming

00:29:26.836 --> 00:29:30.176 A:middle
out of a low power
state and going back in.

00:29:30.366 --> 00:29:32.596 A:middle
You don't have that potential
overhead occurring over

00:29:32.596 --> 00:29:34.806 A:middle
and over, you coalesce
those into one.

00:29:35.306 --> 00:29:38.286 A:middle
Timer rate limiting which is a
little bit different which is

00:29:38.286 --> 00:29:41.166 A:middle
for repetitive timers, we
stretch those timers out.

00:29:41.626 --> 00:29:43.876 A:middle
And finally, there's some APIs.

00:29:44.156 --> 00:29:46.746 A:middle
We are able to tell an
app when it's visible

00:29:46.746 --> 00:29:49.946 A:middle
so it potentially take action
to decrease its energy usage.

00:29:50.566 --> 00:29:54.916 A:middle
And we let the app hint to
the system or pass information

00:29:54.916 --> 00:29:58.476 A:middle
to the system about how it
expects to use resources

00:29:58.476 --> 00:30:01.346 A:middle
so we can do the right
thing in App Nap.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:58.476 --> 00:30:01.346 A:middle
so we can do the right
thing in App Nap.

00:30:03.036 --> 00:30:05.206 A:middle
So, Timer Coalescing.

00:30:06.086 --> 00:30:10.266 A:middle
As I mentioned before, the
key is batching together work

00:30:10.266 --> 00:30:12.256 A:middle
so you don't have-- you're
not paying the overhead

00:30:12.256 --> 00:30:13.486 A:middle
of these transitions.

00:30:13.656 --> 00:30:16.916 A:middle
So, here in the red rectangle or
the overhead of the transitions

00:30:16.916 --> 00:30:20.166 A:middle
for the CPU coming to
a high-power state,

00:30:20.166 --> 00:30:23.886 A:middle
from a low-power state or vice
versa and what we're going

00:30:23.886 --> 00:30:28.546 A:middle
to do is-- if the app is being
App Nap, be more aggressive

00:30:28.596 --> 00:30:33.226 A:middle
about squishing two of these
events together we're going

00:30:33.226 --> 00:30:35.866 A:middle
to slide those timer
firings around so

00:30:35.866 --> 00:30:38.076 A:middle
that you only get a
single transition.

00:30:38.736 --> 00:30:41.856 A:middle
And overtime, these
add up it's--

00:30:42.036 --> 00:30:44.656 A:middle
we keep the timers in
exactly the same order

00:30:44.656 --> 00:30:47.986 A:middle
that they were set but
we change the exact time

00:30:47.986 --> 00:30:50.696 A:middle
in which they fire, we slide
them around to coalesce them.

00:30:51.236 --> 00:30:56.236 A:middle
Now, there's also an API for
NSTimer and DispatcherTimers

00:30:56.526 --> 00:31:00.516 A:middle
that lets you tell the
system how much leeway

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:56.526 --> 00:31:00.516 A:middle
that lets you tell the
system how much leeway

00:31:00.516 --> 00:31:05.586 A:middle
or how much tolerance you can
accept, let's say 10 percent,

00:31:05.866 --> 00:31:10.316 A:middle
you'll accept the 10
percent sliding of that timer

00:31:10.536 --> 00:31:12.806 A:middle
and you've made the
judgment that's not going

00:31:12.806 --> 00:31:14.846 A:middle
to really affect
how things come up.

00:31:15.126 --> 00:31:18.406 A:middle
Now, there are timers
and apps where that has

00:31:18.406 --> 00:31:20.806 A:middle
to be as close as possible.

00:31:21.016 --> 00:31:23.536 A:middle
And that really gets into
the realm of real-time apps

00:31:23.576 --> 00:31:27.606 A:middle
which we're not really talking
about here and there are things

00:31:27.606 --> 00:31:30.786 A:middle
like audio playback where
you need exact timings

00:31:30.786 --> 00:31:32.616 A:middle
and will opt those
out of App Nap.

00:31:32.976 --> 00:31:38.446 A:middle
But, for timers associated
with perhaps network polling

00:31:38.446 --> 00:31:42.756 A:middle
or perhaps user interface
related interactions,

00:31:43.166 --> 00:31:45.106 A:middle
those kinds of timers
typically don't have

00:31:45.146 --> 00:31:46.706 A:middle
to be accurate to
the nanosecond.

00:31:47.306 --> 00:31:51.306 A:middle
And, if you tell us we can
slide those timers around.

00:31:51.306 --> 00:31:54.366 A:middle
If you give us tolerance then
the system will automatically

00:31:54.736 --> 00:31:58.226 A:middle
merge those to get rid of
the overhead between those.

00:31:59.376 --> 00:32:02.186 A:middle
So, here we have an example

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:31:59.376 --> 00:32:02.186 A:middle
So, here we have an example

00:32:02.506 --> 00:32:08.016 A:middle
and what you've done is really
reclaim that wasted energy due

00:32:08.016 --> 00:32:10.266 A:middle
to those transitions
that were there earlier

00:32:10.666 --> 00:32:13.916 A:middle
and you've combined the
work into a single batch set

00:32:13.916 --> 00:32:15.316 A:middle
of work that gets done.

00:32:15.726 --> 00:32:18.626 A:middle
Now, this is happening
on the order of hundreds

00:32:18.626 --> 00:32:21.806 A:middle
of microseconds or
maybe milliseconds.

00:32:22.126 --> 00:32:24.656 A:middle
It's something that--

00:32:24.656 --> 00:32:26.386 A:middle
if everything is
operating correctly,

00:32:26.386 --> 00:32:28.536 A:middle
the user doesn't
even notice except

00:32:28.536 --> 00:32:30.126 A:middle
that their battery
life gets longer.

00:32:31.346 --> 00:32:34.716 A:middle
Timer rate limiting is
a little bit different.

00:32:35.106 --> 00:32:39.206 A:middle
If you have a repetitive timer
in one of those background apps,

00:32:39.206 --> 00:32:41.136 A:middle
one of those apps
that is not drawing,

00:32:41.136 --> 00:32:43.886 A:middle
that the user is not interacting
with, perhaps you've got--

00:32:43.886 --> 00:32:48.746 A:middle
you left the timer going at a
frame rate, 60 times a second.

00:32:48.746 --> 00:32:54.686 A:middle
To update some variable that you
want to keep up-to-date, well,

00:32:55.246 --> 00:32:58.326 A:middle
we will rate limit those timers

00:32:58.846 --> 00:33:01.266 A:middle
and essentially stretch
them out.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:58.846 --> 00:33:01.266 A:middle
and essentially stretch
them out.

00:33:01.986 --> 00:33:07.216 A:middle
So, we will let those timers
execute but let them execute

00:33:07.216 --> 00:33:09.406 A:middle
at a much lower duty cycle rate.

00:33:09.736 --> 00:33:12.916 A:middle
That means that whenever
processing is going on

00:33:12.916 --> 00:33:15.426 A:middle
and associated with that
timer is now occurring

00:33:15.426 --> 00:33:19.426 A:middle
at a much lower duty cycle and
the power associated with that

00:33:19.426 --> 00:33:22.676 A:middle
or the energy associated with
that is correspondingly lower.

00:33:23.236 --> 00:33:26.666 A:middle
So, those timers continue
to fire but they continue

00:33:26.666 --> 00:33:27.996 A:middle
to fire at a lower rate.

00:33:28.706 --> 00:33:33.216 A:middle
And again, this is happening
in apps that are not drawing

00:33:33.216 --> 00:33:36.216 A:middle
to the screen, they are
not outputting audio,

00:33:36.216 --> 00:33:40.136 A:middle
these things are not
noticeable to the user except

00:33:40.136 --> 00:33:42.526 A:middle
that they have less
draw on the battery,

00:33:42.526 --> 00:33:43.796 A:middle
they're using less energy.

00:33:44.716 --> 00:33:47.936 A:middle
Now, we also have
as I mentioned,

00:33:48.016 --> 00:33:50.716 A:middle
an API that lets an app find

00:33:50.716 --> 00:33:52.846 A:middle
out whether it is
visible on the screen.

00:33:53.536 --> 00:33:57.596 A:middle
And, here's an example of where
we use that to conserve energy.

00:33:57.956 --> 00:34:03.806 A:middle
This is Photo Booth, Photo Booth
is-- comes up in preview mode,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:33:57.956 --> 00:34:03.806 A:middle
This is Photo Booth, Photo Booth
is-- comes up in preview mode,

00:34:03.806 --> 00:34:05.206 A:middle
it turns on the camera,

00:34:05.256 --> 00:34:08.366 A:middle
it's displaying the
preview on the screen there.

00:34:08.366 --> 00:34:13.626 A:middle
If Photo Booth gets
covered up by another app,

00:34:13.976 --> 00:34:17.036 A:middle
there's now an API to find
out, "Hey, I'm Photo Booth

00:34:17.036 --> 00:34:18.606 A:middle
but I'm not showing
on the screen."

00:34:19.136 --> 00:34:24.686 A:middle
And, Photo Booth will now use
that API to find that out,

00:34:24.906 --> 00:34:27.226 A:middle
turn off its camera
thus saving power.

00:34:28.335 --> 00:34:32.045 A:middle
In the case where you got
repetitive timers going on,

00:34:32.116 --> 00:34:35.166 A:middle
even though App Nap will
stretch those out for you will--

00:34:35.266 --> 00:34:36.896 A:middle
will rate limit those for you.

00:34:37.275 --> 00:34:41.956 A:middle
And even better situation in
that case is to use the API

00:34:42.016 --> 00:34:43.585 A:middle
to tell you, "Hey,
your screen is not--

00:34:43.585 --> 00:34:46.186 A:middle
your app is not visible
on the screen at all."

00:34:46.186 --> 00:34:49.936 A:middle
And if appropriate, turn
that timer off completely.

00:34:50.846 --> 00:34:55.406 A:middle
So, you know, the combination of
the system activities plus APIs

00:34:55.406 --> 00:35:01.066 A:middle
that you can use really
helps the system as a whole,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:55.406 --> 00:35:01.066 A:middle
that you can use really
helps the system as a whole,

00:35:01.456 --> 00:35:03.126 A:middle
give the user the
maximum battery life.

00:35:03.476 --> 00:35:06.646 A:middle
You find out more about this
in a couple of sessions coming

00:35:06.646 --> 00:35:10.056 A:middle
up improving power efficiency
with App Nap which we'll go

00:35:10.056 --> 00:35:13.736 A:middle
into great detail about App Nap
and APIs associated with App Nap

00:35:13.736 --> 00:35:16.806 A:middle
and exactly how it figures
out when to nap something.

00:35:17.286 --> 00:35:20.526 A:middle
And Energy Best Practices
which is a lower level talk

00:35:20.976 --> 00:35:24.066 A:middle
that covers a lot of these
concepts but others as well.

00:35:24.336 --> 00:35:26.796 A:middle
Both those talks I think
are very worth going to--

00:35:27.066 --> 00:35:29.766 A:middle
the second one, will have a lot
of tools in it that you can use

00:35:29.766 --> 00:35:35.756 A:middle
and cover how you will-- how you
can maximize energy efficiency

00:35:35.756 --> 00:35:36.836 A:middle
for your costumers.

00:35:37.466 --> 00:35:39.816 A:middle
Now, Centralized
Task Scheduling.

00:35:40.556 --> 00:35:42.546 A:middle
Centralized Task
Scheduling as I mentioned is

00:35:42.546 --> 00:35:46.366 A:middle
on a much longer time scale
and it's a dual use technology.

00:35:46.366 --> 00:35:51.826 A:middle
It can be used to move tasks
to a time that is better

00:35:51.826 --> 00:35:55.456 A:middle
from a battery life
standpoint say back on AC power.

00:35:55.786 --> 00:35:59.086 A:middle
So, you might have a task
that's going to run--

00:35:59.086 --> 00:36:01.206 A:middle
use up some of your
battery, but it's a task

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:59.086 --> 00:36:01.206 A:middle
use up some of your
battery, but it's a task

00:36:01.206 --> 00:36:04.016 A:middle
that can wait hours
perhaps before it runs.

00:36:04.016 --> 00:36:08.096 A:middle
It's a housekeeping task and
we have a system-wide facility

00:36:08.096 --> 00:36:10.456 A:middle
for rescheduling
that to be executing

00:36:10.456 --> 00:36:11.786 A:middle
when you're back on AC power.

00:36:12.246 --> 00:36:18.316 A:middle
Also, tasks that are may be
going to use significant CPU

00:36:18.316 --> 00:36:21.306 A:middle
that you really only want to run
when the user hasn't interacted

00:36:21.306 --> 00:36:22.406 A:middle
with their system for awhile.

00:36:22.406 --> 00:36:24.666 A:middle
In other words, the users
probably gone to get a cup

00:36:24.666 --> 00:36:27.636 A:middle
of coffee, now is the time
for an intensive, you know,

00:36:27.636 --> 00:36:29.166 A:middle
background task to execute.

00:36:29.716 --> 00:36:33.166 A:middle
So, Centralized Task Scheduling
is a general mechanism

00:36:33.166 --> 00:36:33.826 A:middle
for doing that.

00:36:34.136 --> 00:36:38.046 A:middle
And you can tell the
system how you can--

00:36:38.046 --> 00:36:39.716 A:middle
first of all tell us
"Is this some work

00:36:39.716 --> 00:36:40.896 A:middle
that can be time shifted?

00:36:41.176 --> 00:36:44.606 A:middle
Can it be time shifted to either
back on AC or time shifted

00:36:44.606 --> 00:36:47.966 A:middle
to when the user is not
interacting and by how long?

00:36:47.966 --> 00:36:49.286 A:middle
What's the maximum
amount you're going

00:36:49.286 --> 00:36:51.676 A:middle
to let the system
time shift it by?"

00:36:52.506 --> 00:36:53.846 A:middle
Maybe it's a software update.

00:36:53.846 --> 00:36:56.106 A:middle
You don't want it to
go more than 24 hours.

00:36:56.656 --> 00:36:59.196 A:middle
Maybe it's a backup
you don't want it

00:36:59.196 --> 00:37:00.486 A:middle
to go more than a few hours.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:36:59.196 --> 00:37:00.486 A:middle
to go more than a few hours.

00:37:00.696 --> 00:37:03.286 A:middle
Whatever that is, you tell
the system through this API.

00:37:03.286 --> 00:37:07.456 A:middle
And there's a two
APIs for doing that,

00:37:07.456 --> 00:37:10.436 A:middle
one is if you're task
is a LaunchD Task.

00:37:10.726 --> 00:37:13.456 A:middle
You simply put that
in the launchd.plist.

00:37:13.656 --> 00:37:17.036 A:middle
There's a way to specify--
can this be time shifted

00:37:17.036 --> 00:37:21.066 A:middle
and by how long or directly
in your application.

00:37:21.066 --> 00:37:24.976 A:middle
There's an API, if you've got
let's say a block that you want

00:37:24.976 --> 00:37:30.106 A:middle
to execute on some schedule,
you can tell the system "Hey,

00:37:30.106 --> 00:37:33.416 A:middle
this block can be
delayed by up to 8 hours."

00:37:34.176 --> 00:37:37.576 A:middle
And that takes some
work on your part

00:37:37.576 --> 00:37:40.696 A:middle
but it provides a much better
experience for the user both

00:37:40.696 --> 00:37:44.326 A:middle
from a battery life standpoint
and not doing tasks that sort

00:37:44.326 --> 00:37:46.616 A:middle
of get in their way when
they're being very interactive.

00:37:48.116 --> 00:37:50.156 A:middle
So, Centralized Task Scheduling.

00:37:50.576 --> 00:37:52.806 A:middle
Couple of sessions
coming up on that.

00:37:52.806 --> 00:37:54.946 A:middle
This will be covered in
Energy Best Practices

00:37:54.946 --> 00:37:58.696 A:middle
which I mentioned before and
also Efficient Design with XPC.

00:37:58.966 --> 00:38:02.306 A:middle
So, XPC is one example where
you have a block of code.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:58.966 --> 00:38:02.306 A:middle
So, XPC is one example where
you have a block of code.

00:38:02.306 --> 00:38:05.276 A:middle
It's going to execute
but can just

00:38:05.276 --> 00:38:06.866 A:middle
as easily be put
off until later.

00:38:07.116 --> 00:38:10.406 A:middle
The system will make a decision
based on battery efficient

00:38:10.406 --> 00:38:13.976 A:middle
or battery life to move
out to back on AC power.

00:38:14.506 --> 00:38:16.446 A:middle
Finally, Power Saver.

00:38:16.446 --> 00:38:20.146 A:middle
So, Power Saver is all about
Safari and it's really some

00:38:20.146 --> 00:38:23.316 A:middle
of the same ideas, same
strategies we just talked

00:38:23.316 --> 00:38:27.646 A:middle
about with App Nap but applied
to the web browsing experience.

00:38:27.946 --> 00:38:35.246 A:middle
So, for example, in Safari,
as the user is browsing,

00:38:35.426 --> 00:38:37.176 A:middle
typically they've got tabs--

00:38:37.246 --> 00:38:38.366 A:middle
they've got a tab
they're looking at,

00:38:38.366 --> 00:38:40.116 A:middle
they've got other tabs
that are in the background

00:38:40.506 --> 00:38:42.606 A:middle
but if you look at what happens

00:38:42.606 --> 00:38:45.326 A:middle
on those web pages often
times those tabs are

00:38:45.326 --> 00:38:46.526 A:middle
executing JavaScript.

00:38:46.856 --> 00:38:48.116 A:middle
They're executing plug-ins.

00:38:48.296 --> 00:38:50.576 A:middle
They're burning power.

00:38:50.656 --> 00:38:52.926 A:middle
They're gradually
dragging your battery down.

00:38:53.386 --> 00:38:54.986 A:middle
So, what do we do?

00:38:55.276 --> 00:39:01.026 A:middle
Well, since in Safari, we now
have a separate process per tab.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:55.276 --> 00:39:01.026 A:middle
Well, since in Safari, we now
have a separate process per tab.

00:39:01.436 --> 00:39:04.696 A:middle
We can use those same techniques
we talked about in App Nap

00:39:05.086 --> 00:39:08.526 A:middle
to quiesce those tabs if the
user is not paying attention

00:39:08.526 --> 00:39:10.056 A:middle
to the ones that are
in the background.

00:39:10.356 --> 00:39:13.296 A:middle
That actually has a significant
effect given the web pages

00:39:13.296 --> 00:39:15.726 A:middle
that are out there today often--

00:39:15.796 --> 00:39:16.876 A:middle
they are just sitting there

00:39:16.876 --> 00:39:22.146 A:middle
in the background running their
plug-in, running JavaScript

00:39:22.716 --> 00:39:27.466 A:middle
and Safari will take care
of that with App Nap.

00:39:29.326 --> 00:39:33.856 A:middle
In addition, in web
pages today, often times,

00:39:33.856 --> 00:39:35.646 A:middle
power is being drawn
by plug-ins.

00:39:36.036 --> 00:39:43.756 A:middle
Plug-ins tend to be power hungry
and so these plug-ins are--

00:39:43.926 --> 00:39:48.086 A:middle
they're useful but
Safari is smart

00:39:48.456 --> 00:39:52.216 A:middle
about how it handles plug-ins
with respect to energy,

00:39:52.426 --> 00:39:55.176 A:middle
the latest Safari in Mavericks.

00:39:55.266 --> 00:40:00.276 A:middle
And what it does is for
plug-ins that are not the center

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:39:55.266 --> 00:40:00.276 A:middle
And what it does is for
plug-ins that are not the center

00:40:00.276 --> 00:40:04.926 A:middle
of your browsing
attention-- marginal plug-ins,

00:40:05.306 --> 00:40:09.876 A:middle
it will take a preview
snapshot of that plug-in,

00:40:10.176 --> 00:40:13.596 A:middle
display that until the
user interacts with it,

00:40:13.596 --> 00:40:15.416 A:middle
until the user clicks
on it and then

00:40:15.416 --> 00:40:17.806 A:middle
that plug-in will
start executing.

00:40:17.996 --> 00:40:18.816 A:middle
Great feature.

00:40:19.166 --> 00:40:22.546 A:middle
You end up with a web page
that has these previews in it

00:40:22.836 --> 00:40:24.276 A:middle
but they're not burning
any power.

00:40:24.446 --> 00:40:25.926 A:middle
They're not sitting
there executing

00:40:26.156 --> 00:40:27.786 A:middle
until the user goes
and clicks on one.

00:40:27.786 --> 00:40:31.326 A:middle
Now, if there is--
Safari uses heuristics,

00:40:31.556 --> 00:40:34.736 A:middle
if there is a plug-in
that's front and center then

00:40:34.736 --> 00:40:36.586 A:middle
that one will play
without interruptions.

00:40:37.036 --> 00:40:41.336 A:middle
But if there's marginal
plug-ins that are not the center

00:40:41.336 --> 00:40:45.396 A:middle
of the user's browsing activity,
those will still show up

00:40:45.396 --> 00:40:48.396 A:middle
but they will not play until
the user clicks on them.

00:40:49.056 --> 00:40:51.626 A:middle
To find out more about
this and more importantly,

00:40:51.626 --> 00:40:54.526 A:middle
if you're a web developer,
you should go to the session

00:40:54.526 --> 00:40:57.266 A:middle
on Power and Performance
in Optimizing Websites

00:40:57.266 --> 00:41:00.876 A:middle
because the Safari team is going
to talk about not just this

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:57.266 --> 00:41:00.876 A:middle
because the Safari team is going
to talk about not just this

00:41:00.876 --> 00:41:04.226 A:middle
but also what you should do as
a web developer to make sure

00:41:04.226 --> 00:41:06.186 A:middle
that your web pages
that you're sending

00:41:06.186 --> 00:41:08.696 A:middle
out to users are not burning
through their battery.

00:41:08.696 --> 00:41:12.166 A:middle
That they're executing as
efficiently as possible

00:41:12.466 --> 00:41:13.996 A:middle
that the CSS is efficient,

00:41:13.996 --> 00:41:16.876 A:middle
that the users battery
experience is not impacted

00:41:16.926 --> 00:41:18.206 A:middle
by a bad web page.

00:41:20.956 --> 00:41:24.696 A:middle
So, we covered App Nap,
Centralized Task Scheduling,

00:41:24.696 --> 00:41:27.896 A:middle
Energy Saver, three great
features in OS X Mavericks

00:41:28.276 --> 00:41:30.676 A:middle
that are going to help the
users have a great battery

00:41:30.676 --> 00:41:31.626 A:middle
life experience.

00:41:32.096 --> 00:41:33.916 A:middle
So, what can you
do as developers?

00:41:34.266 --> 00:41:36.986 A:middle
Well, perhaps goes
without saying

00:41:37.296 --> 00:41:40.196 A:middle
but of course major effect

00:41:40.196 --> 00:41:42.556 A:middle
on battery life is
whether you're using

00:41:42.586 --> 00:41:43.776 A:middle
efficient algorithms.

00:41:44.206 --> 00:41:48.996 A:middle
And, so just make sure that,
you know, if you got tasks going

00:41:48.996 --> 00:41:52.976 A:middle
on that should be they're
nsquared algorithms

00:41:52.976 --> 00:41:55.456 A:middle
that you're using and they
really should be in login

00:41:55.756 --> 00:41:59.706 A:middle
or order in, make sure that
the algorithms were efficient.

00:41:59.706 --> 00:42:00.856 A:middle
That's going to help everything.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:41:59.706 --> 00:42:00.856 A:middle
That's going to help everything.

00:42:00.856 --> 00:42:02.426 A:middle
That's going to help
responsiveness.

00:42:02.426 --> 00:42:04.496 A:middle
That's going to help
performance.

00:42:04.496 --> 00:42:08.806 A:middle
That's going to help-- help
you get the best battery life.

00:42:09.226 --> 00:42:13.976 A:middle
But beyond that, take a look,
use the tools in OS X Maverick

00:42:13.976 --> 00:42:17.496 A:middle
to take a closer look at energy
impact of your application.

00:42:18.646 --> 00:42:21.876 A:middle
Watch for your app in
energy in activity monitor.

00:42:22.326 --> 00:42:25.016 A:middle
Look at what it's doing,
understand what it's doing.

00:42:25.356 --> 00:42:28.516 A:middle
Like I say, it may be
perfectly expected behavior.

00:42:28.626 --> 00:42:32.126 A:middle
After all, the apps are supposed
to compute and so they're going

00:42:32.126 --> 00:42:33.256 A:middle
to use energy doing that.

00:42:33.606 --> 00:42:35.656 A:middle
But make sure that
it's as expected

00:42:35.716 --> 00:42:37.786 A:middle
and that it's not doing work

00:42:38.136 --> 00:42:40.986 A:middle
that either the user
didn't expect or worse

00:42:40.986 --> 00:42:44.216 A:middle
that the user really
didn't want.

00:42:44.566 --> 00:42:47.496 A:middle
Then the next step is measuring
your application with Xcode.

00:42:48.026 --> 00:42:52.396 A:middle
And as I mentioned, Xcode has a
lot of new tools in it to dive

00:42:52.396 --> 00:42:56.196 A:middle
down more deeply take a
look at things like time

00:42:56.196 --> 00:42:58.646 A:middle
or firings the frequency
of firings,

00:42:58.646 --> 00:43:00.246 A:middle
do I have high-frequency timers

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:58.646 --> 00:43:00.246 A:middle
do I have high-frequency timers

00:43:00.816 --> 00:43:03.426 A:middle
that could have some
tolerance introduce

00:43:03.656 --> 00:43:06.086 A:middle
and let the system do a
better job coalescing those,

00:43:06.146 --> 00:43:07.046 A:middle
et cetera, et cetera.

00:43:07.746 --> 00:43:11.116 A:middle
And then finally, adopt
Centralized Task Scheduling.

00:43:11.446 --> 00:43:15.206 A:middle
Let the system move those
background task things like,

00:43:15.206 --> 00:43:20.416 A:middle
you know, downloading
updates from the web,

00:43:20.836 --> 00:43:26.076 A:middle
can be maybe pushed off
for hours or even days.

00:43:26.676 --> 00:43:28.206 A:middle
Let the system know about that

00:43:28.206 --> 00:43:32.206 A:middle
so the system can make the right
decision and put those events

00:43:32.336 --> 00:43:35.266 A:middle
so they occur when
you're on back on AC power

00:43:35.526 --> 00:43:38.466 A:middle
or when the users are not
interacting with their system.

00:43:39.456 --> 00:43:44.166 A:middle
So, additional related sessions
that I would really recommend,

00:43:44.696 --> 00:43:49.116 A:middle
Building Efficient OS X apps
and this is efficiency not just

00:43:49.116 --> 00:43:52.546 A:middle
from energy although energy
is the one focused on but also

00:43:52.546 --> 00:43:55.696 A:middle
from the standpoint of memory
use, from the standpoint

00:43:55.776 --> 00:43:57.546 A:middle
of just simply using
the resources

00:43:57.546 --> 00:43:58.536 A:middle
to their greatest effect.

00:43:59.086 --> 00:44:02.416 A:middle
Efficient Design with
XPC, I mentioned before

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:59.086 --> 00:44:02.416 A:middle
Efficient Design with
XPC, I mentioned before

00:44:03.356 --> 00:44:06.726 A:middle
and that's an area where
you again can take advantage

00:44:06.726 --> 00:44:08.236 A:middle
of Centralized Task Scheduling.

00:44:08.546 --> 00:44:10.776 A:middle
Power and Performance:
Optimizing your Website

00:44:10.776 --> 00:44:12.966 A:middle
for Greatest Battery Life
in Response Scrolling.

00:44:13.166 --> 00:44:16.396 A:middle
That's going to be the longest
title of all the talks here.

00:44:16.896 --> 00:44:20.206 A:middle
But anyways, if you're a web
developer, absolutely go to that

00:44:20.206 --> 00:44:22.996 A:middle
so that you can produce
web pages that are more

00:44:22.996 --> 00:44:25.206 A:middle
in energy friendly
for your users.

00:44:25.806 --> 00:44:30.276 A:middle
Improving Power Efficiency with
App Nap, again a more deep dive

00:44:30.276 --> 00:44:33.336 A:middle
on the mechanisms in App
Nap and how those work

00:44:33.336 --> 00:44:36.136 A:middle
and how your app can
interact with those.

00:44:36.596 --> 00:44:41.026 A:middle
And then finally, Energy Best
Practices which is really

00:44:41.026 --> 00:44:45.816 A:middle
across the board kind
of more low level--

00:44:45.816 --> 00:44:50.036 A:middle
how OS X Mavericks
focuses on energy.

00:44:50.266 --> 00:44:56.546 A:middle
So, to leave you, you know,
it's really important I think

00:44:56.546 --> 00:44:59.566 A:middle
to understand that
battery life often

00:44:59.566 --> 00:45:03.556 A:middle
for users becomes almost the
most important feature to them.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:59.566 --> 00:45:03.556 A:middle
for users becomes almost the
most important feature to them.

00:45:03.906 --> 00:45:06.246 A:middle
More and more you see
people out on the road.

00:45:06.246 --> 00:45:08.736 A:middle
They're using their
systems in a mobile fashion.

00:45:09.056 --> 00:45:12.106 A:middle
They're used to all-day
battery life from their iPads.

00:45:12.496 --> 00:45:16.876 A:middle
So, this is the new norm and
we need to get used to it

00:45:16.876 --> 00:45:18.436 A:middle
and we spent a lot of time

00:45:18.436 --> 00:45:21.486 A:middle
in Mavericks just squeezing
every last ounce out of

00:45:21.486 --> 00:45:24.516 A:middle
that battery and we hope
that you can use the tools

00:45:24.516 --> 00:45:27.786 A:middle
and the mechanisms in Mavericks,
do the same thing for your apps.

00:45:28.156 --> 00:45:28.976 A:middle
Thank you very much.

00:45:29.476 --> 00:45:34.723 A:middle
[Applause]

00:45:35.223 --> 00:45:40.470 A:middle
[ Silence ]