713.srt

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

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

00:00:10.066 --> 00:00:10.866 A:middle
>> Good afternoon.

00:00:11.116 --> 00:00:13.026 A:middle
Welcome to the Accelerate
Framework Session.

00:00:13.726 --> 00:00:14.846 A:middle
My name's Jeff Belcher.

00:00:15.546 --> 00:00:17.536 A:middle
I'm an engineer in the
Vector and Numerics Group.

00:00:18.776 --> 00:00:21.076 A:middle
Today I want to start off
with a pretty common scenario.

00:00:22.036 --> 00:00:24.476 A:middle
Imagine you've got a great
idea for an application,

00:00:24.666 --> 00:00:26.936 A:middle
and that application
has a computationally

00:00:26.936 --> 00:00:27.956 A:middle
intensive component.

00:00:29.516 --> 00:00:31.506 A:middle
You look around and you
find an open source solution

00:00:31.506 --> 00:00:34.546 A:middle
to the problem, you bring
it into your application,

00:00:34.676 --> 00:00:37.916 A:middle
you test it, and you find
the graph's too slow,

00:00:39.076 --> 00:00:40.516 A:middle
or maybe it's a battery drain.

00:00:41.966 --> 00:00:44.526 A:middle
At this point you're forced to
spend the next several hours

00:00:44.526 --> 00:00:47.386 A:middle
or maybe days, profiling
and optimizing that code

00:00:48.446 --> 00:00:50.406 A:middle
to get the performance to
where you need it to be.

00:00:51.796 --> 00:00:53.496 A:middle
We don't think that's right.

00:00:54.026 --> 00:00:55.706 A:middle
The goal of the Accelerate
Framework is

00:00:55.736 --> 00:00:56.976 A:middle
to solve this problem.

00:00:58.496 --> 00:01:01.116 A:middle
The Accelerate Framework is
a collection of functions

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

00:00:58.496 --> 00:01:01.116 A:middle
The Accelerate Framework is
a collection of functions

00:01:01.116 --> 00:01:04.286 A:middle
of commonly used computationally
intensive operations.

00:01:04.836 --> 00:01:08.436 A:middle
The Accelerate Framework is
designed to be high performance

00:01:08.706 --> 00:01:12.366 A:middle
and deliver great
energy savings for all

00:01:12.366 --> 00:01:13.946 A:middle
of these APIs that
are available.

00:01:14.556 --> 00:01:17.236 A:middle
When you adopt the Accelerate
Framework you're going

00:01:17.236 --> 00:01:20.126 A:middle
to get great performance and
amazing energy characteristics

00:01:20.126 --> 00:01:22.576 A:middle
from the smallest
iPhone all the way

00:01:22.576 --> 00:01:24.216 A:middle
up through the biggest Mac Pro

00:01:24.276 --> 00:01:27.226 A:middle
without changing a single
line of code on your end.

00:01:28.286 --> 00:01:30.546 A:middle
Let's dive into the details
of the Accelerate Framework

00:01:30.546 --> 00:01:33.546 A:middle
and see how it can help you
make a really great app.

00:01:35.696 --> 00:01:37.576 A:middle
So what is the Accelerate
Framework?

00:01:39.156 --> 00:01:41.146 A:middle
When you think Accelerate
Framework there's a few things

00:01:41.146 --> 00:01:42.106 A:middle
that I want you to remember.

00:01:42.766 --> 00:01:45.226 A:middle
First, easy access to
a lot of functionality.

00:01:46.536 --> 00:01:48.636 A:middle
There's more than
2,000 APIs available

00:01:48.636 --> 00:01:49.716 A:middle
on the Accelerate Framework.

00:01:50.346 --> 00:01:52.856 A:middle
Throughout the rest of
the talk we'll break this

00:01:52.886 --> 00:01:54.876 A:middle
down into four easy-to-remember
categories

00:01:54.876 --> 00:01:56.956 A:middle
and show you what
exactly is available.

00:01:57.506 --> 00:01:58.486 A:middle
Think accurate.

00:01:58.606 --> 00:02:03.276 A:middle
We spent a lot of time testing
so that you don't have to.

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

00:01:58.606 --> 00:02:03.276 A:middle
We spent a lot of time testing
so that you don't have to.

00:02:04.196 --> 00:02:06.886 A:middle
The big one is fast
with low energy usage.

00:02:07.646 --> 00:02:09.026 A:middle
You guys really pushed
the limits

00:02:09.026 --> 00:02:12.116 A:middle
of the hardware available today
with your great applications.

00:02:12.726 --> 00:02:14.216 A:middle
When you use the Accelerate
Framework you're going

00:02:14.216 --> 00:02:16.366 A:middle
to get great performance,
and that's going to come

00:02:16.366 --> 00:02:18.506 A:middle
with amazing energy
characteristics.

00:02:19.056 --> 00:02:24.256 A:middle
The best part for you is it
works great on both OS X and iOS

00:02:24.876 --> 00:02:28.426 A:middle
and it's optimized for all
generations of hardware,

00:02:29.066 --> 00:02:30.896 A:middle
so when new hardware
comes out you're not going

00:02:30.896 --> 00:02:35.666 A:middle
to have to revisit your code.

00:02:35.866 --> 00:02:38.106 A:middle
So I mentioned that there's
a lot of functionality

00:02:38.266 --> 00:02:41.106 A:middle
and the Accelerate Framework
is geared toward commonly used

00:02:41.226 --> 00:02:42.856 A:middle
computationally intensive
operations,

00:02:43.166 --> 00:02:44.516 A:middle
but what exactly is available?

00:02:45.246 --> 00:02:47.516 A:middle
We break it down into
these four categories.

00:02:48.446 --> 00:02:52.106 A:middle
First we've got image
processing, with vImage,

00:02:53.536 --> 00:02:57.786 A:middle
we've got digital signal
processing and VVSP,

00:02:57.976 --> 00:03:01.556 A:middle
transcendental math functions
and vForce and vMathLive,

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

00:02:57.976 --> 00:03:01.556 A:middle
transcendental math functions
and vForce and vMathLive,

00:03:03.106 --> 00:03:06.876 A:middle
and finally, linear
algebra in LAPACK and BLAS.

00:03:07.456 --> 00:03:11.726 A:middle
At the end of this talk
there's a few points

00:03:11.726 --> 00:03:12.966 A:middle
that I want you to
come away with.

00:03:13.906 --> 00:03:16.266 A:middle
The first of these is how the
Accelerate Framework can help

00:03:16.266 --> 00:03:18.146 A:middle
you create a really
great application.

00:03:19.106 --> 00:03:20.706 A:middle
I'm going to show
you some examples

00:03:21.276 --> 00:03:23.336 A:middle
of real world performance
and energy savings

00:03:23.336 --> 00:03:25.026 A:middle
that you can expect
when you utilize the

00:03:25.026 --> 00:03:25.876 A:middle
Accelerate Framework.

00:03:26.446 --> 00:03:29.666 A:middle
I want you to have an
idea of areas of your code

00:03:29.666 --> 00:03:34.216 A:middle
that are likely to benefit
from the Accelerate Framework,

00:03:34.766 --> 00:03:37.736 A:middle
and finally, how to use
the Accelerate Framework.

00:03:37.986 --> 00:03:39.816 A:middle
So this is going to
range from linking

00:03:39.816 --> 00:03:43.066 A:middle
against the Accelerate Framework
up through some tips and tricks

00:03:43.066 --> 00:03:45.056 A:middle
that can really allow
you to get the most

00:03:45.056 --> 00:03:46.426 A:middle
out of the Accelerate Framework.

00:03:46.426 --> 00:03:51.736 A:middle
I want to move now to why the
Accelerate Framework is fast.

00:03:53.086 --> 00:03:55.546 A:middle
Understanding why the Accelerate
Framework is fast can help

00:03:55.546 --> 00:03:58.296 A:middle
in understanding when and why
to use the Accelerate Framework.

00:03:58.296 --> 00:04:03.366 A:middle
One of the big reasons the
Accelerate Framework is fast is

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

00:03:58.296 --> 00:04:03.366 A:middle
One of the big reasons the
Accelerate Framework is fast is

00:04:03.366 --> 00:04:05.166 A:middle
we utilize SIMD instructions.

00:04:06.576 --> 00:04:08.656 A:middle
This is Single Instruction
Multiple Data.

00:04:08.656 --> 00:04:12.496 A:middle
For those of you
unfamiliar, if we're trying

00:04:12.496 --> 00:04:15.856 A:middle
to for example add 2 arrays
together, there are instructions

00:04:15.856 --> 00:04:17.216 A:middle
on current hardware
that allow us

00:04:17.216 --> 00:04:19.255 A:middle
to add multiple elements
simultaneously.

00:04:19.886 --> 00:04:23.196 A:middle
For those of you more
familiar with SIMD operations,

00:04:23.736 --> 00:04:25.796 A:middle
on Intel this means
we're taking advantage

00:04:25.796 --> 00:04:28.736 A:middle
of SSE, AVX, and now AVX2.

00:04:30.186 --> 00:04:34.196 A:middle
On ARM we're taking
advantage of NEON.

00:04:34.366 --> 00:04:35.816 A:middle
Utilizing SIMD instructions

00:04:35.816 --> 00:04:38.166 A:middle
in certain situations can
have significant energy

00:04:38.166 --> 00:04:39.346 A:middle
and performance savings.

00:04:40.606 --> 00:04:45.496 A:middle
We also spend a lot of time
matching the microarchitecture

00:04:45.706 --> 00:04:47.486 A:middle
for the complete
Apple hardware lineup.

00:04:48.386 --> 00:04:51.246 A:middle
This includes optimizations
like instruction selection

00:04:51.246 --> 00:04:52.436 A:middle
and instruction scheduling,

00:04:52.486 --> 00:04:56.016 A:middle
as well as software
pipelining and loop unrolling.

00:04:57.516 --> 00:05:00.256 A:middle
So I bring these up because
it requires a certain amount

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

00:04:57.516 --> 00:05:00.256 A:middle
So I bring these up because
it requires a certain amount

00:05:00.256 --> 00:05:01.666 A:middle
of data before optimizations

00:05:01.666 --> 00:05:03.396 A:middle
like loop unrolling
become beneficial,

00:05:03.916 --> 00:05:05.116 A:middle
so it helps to understand

00:05:05.346 --> 00:05:07.546 A:middle
that this is sometimes
happening behind the scenes

00:05:07.546 --> 00:05:08.576 A:middle
in the Accelerated Framework.

00:05:09.316 --> 00:05:12.746 A:middle
The last reason the
Accelerated Framework is fast is

00:05:12.746 --> 00:05:15.316 A:middle
because it's multithreaded
using GCD.

00:05:16.326 --> 00:05:18.106 A:middle
When it's appropriate we're
going to take advantage

00:05:18.106 --> 00:05:19.416 A:middle
of all the cores available.

00:05:20.676 --> 00:05:25.806 A:middle
So I wanted to talk
about why it's fast

00:05:25.806 --> 00:05:28.466 A:middle
so that you have an
understanding of where some

00:05:28.466 --> 00:05:30.056 A:middle
of the tips for successful use

00:05:30.056 --> 00:05:31.576 A:middle
of the Accelerate
Framework come from.

00:05:32.116 --> 00:05:35.276 A:middle
The first tip is
preparation of your data.

00:05:35.276 --> 00:05:38.416 A:middle
When you prepare your
data there's a few things

00:05:38.416 --> 00:05:39.466 A:middle
that I want you to remember.

00:05:40.426 --> 00:05:42.756 A:middle
The first is if you can
make your data contiguous.

00:05:43.426 --> 00:05:45.466 A:middle
This means that if
you're creating an array,

00:05:45.766 --> 00:05:46.726 A:middle
you want to make that array

00:05:46.726 --> 00:05:48.566 A:middle
such that the elements
are contiguous.

00:05:49.116 --> 00:05:52.466 A:middle
If you're allocating or
have control over the layout

00:05:52.466 --> 00:05:55.126 A:middle
of that buffer and memory, if
you can align the beginning

00:05:55.126 --> 00:05:57.076 A:middle
of that buffer to
16-byte boundary,

00:05:57.076 --> 00:05:58.196 A:middle
that's going to be ideal.

00:05:58.786 --> 00:06:01.916 A:middle
With the Accelerate
Framework we always strive

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

00:05:58.786 --> 00:06:01.916 A:middle
With the Accelerate
Framework we always strive

00:06:01.916 --> 00:06:03.396 A:middle
to deliver the greatest
performance,

00:06:03.426 --> 00:06:05.606 A:middle
but if you can meet
these recommendations,

00:06:06.236 --> 00:06:09.066 A:middle
in certain situations we
can algorithmically exploit

00:06:09.066 --> 00:06:11.216 A:middle
that to give you
slightly more performance.

00:06:11.606 --> 00:06:16.556 A:middle
The next tip is to
understand the problem size.

00:06:18.756 --> 00:06:21.476 A:middle
Any function call has a
cost associated with it.

00:06:22.436 --> 00:06:24.846 A:middle
The Accelerate Framework
is not immune to this.

00:06:26.216 --> 00:06:27.836 A:middle
On the previous slide
we also saw

00:06:27.836 --> 00:06:29.686 A:middle
that in certain situations
optimizations

00:06:29.686 --> 00:06:31.456 A:middle
like loop unrolling are used.

00:06:31.966 --> 00:06:34.596 A:middle
What this means for you is

00:06:34.596 --> 00:06:37.456 A:middle
that when you're
using really small --

00:06:37.456 --> 00:06:38.916 A:middle
when you're using the
Accelerate Framework

00:06:38.916 --> 00:06:40.306 A:middle
with really small datasets,

00:06:40.806 --> 00:06:43.246 A:middle
it may not deliver
the best performance.

00:06:44.606 --> 00:06:45.716 A:middle
There's not a problem size

00:06:45.716 --> 00:06:47.766 A:middle
that I can say don't use
the Accelerate Framework

00:06:47.766 --> 00:06:49.966 A:middle
for something that's
small; it's going to depend

00:06:49.966 --> 00:06:51.406 A:middle
on the operation
you're performing.

00:06:52.186 --> 00:06:54.916 A:middle
For example, if you're scaling a
vector it might be on the order

00:06:54.916 --> 00:06:56.916 A:middle
of 100 elements; whereas

00:06:56.916 --> 00:06:59.286 A:middle
if you have a more complicated
operation for example,

00:06:59.286 --> 00:07:02.826 A:middle
Matrix Multiply, it could
be as small as 8 elements.

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

00:06:59.286 --> 00:07:02.826 A:middle
Matrix Multiply, it could
be as small as 8 elements.

00:07:04.086 --> 00:07:06.196 A:middle
The best thing you can
do here is to experiment.

00:07:07.116 --> 00:07:08.676 A:middle
The Accelerate Framework
is always going

00:07:08.676 --> 00:07:10.196 A:middle
to deliver the great
functionality,

00:07:10.626 --> 00:07:13.066 A:middle
just for these smaller
problem sizes it may not be the

00:07:13.066 --> 00:07:13.986 A:middle
best performance.

00:07:13.986 --> 00:07:20.596 A:middle
The last tip for successful
use is to do setup once

00:07:20.596 --> 00:07:21.956 A:middle
and destroy once at the end.

00:07:23.066 --> 00:07:25.376 A:middle
There's a handful of operations
in the Accelerate Framework

00:07:25.376 --> 00:07:26.896 A:middle
that require a setup structure.

00:07:28.116 --> 00:07:30.096 A:middle
Creating this setup
structure can be costly

00:07:30.096 --> 00:07:30.986 A:middle
and time-consuming.

00:07:31.496 --> 00:07:34.476 A:middle
These setup structures
are designed

00:07:34.476 --> 00:07:38.836 A:middle
to be used multiple times, so if
you find yourself in a situation

00:07:38.836 --> 00:07:42.576 A:middle
where you need to do these
setups, create the setup,

00:07:42.746 --> 00:07:45.246 A:middle
do all of the computation that
you want to do with that setup,

00:07:45.316 --> 00:07:48.696 A:middle
and then destroy
once at the end.

00:07:48.696 --> 00:07:51.116 A:middle
Throughout the rest of the talk
we'll see some examples of this

00:07:51.116 --> 00:07:52.406 A:middle
and it will become more clear.

00:07:53.066 --> 00:07:57.726 A:middle
Now I want to move on to using
the Accelerate Framework.

00:07:58.376 --> 00:08:00.786 A:middle
For those of you brand new
to the Accelerate Framework,

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

00:07:58.376 --> 00:08:00.786 A:middle
For those of you brand new
to the Accelerate Framework,

00:08:01.046 --> 00:08:03.896 A:middle
including it is just like
including any other framework.

00:08:04.586 --> 00:08:08.946 A:middle
Here we have a typical Xcode
project, and we're just going

00:08:08.946 --> 00:08:10.706 A:middle
to navigate to the build phases.

00:08:11.876 --> 00:08:13.976 A:middle
In the build phases we're
going to find the link

00:08:13.976 --> 00:08:16.056 A:middle
with the library
section and we're going

00:08:16.056 --> 00:08:17.106 A:middle
to find the Plus button.

00:08:18.276 --> 00:08:20.816 A:middle
This brings up the list
of available frameworks.

00:08:21.396 --> 00:08:24.996 A:middle
The Accelerate Framework's
right at the top,

00:08:24.996 --> 00:08:26.406 A:middle
we'll just select
it and click Add.

00:08:27.276 --> 00:08:32.336 A:middle
And then we can be sure that the
Accelerate Framework is included

00:08:32.336 --> 00:08:33.926 A:middle
in our project because
it's going to show

00:08:33.926 --> 00:08:35.566 A:middle
up in this link the
Library section.

00:08:35.976 --> 00:08:40.385 A:middle
The only other step to using
the Accelerate Framework is

00:08:40.416 --> 00:08:41.446 A:middle
to include the headers.

00:08:41.936 --> 00:08:48.826 A:middle
This is accelerate/accelerate.h.
That's all it takes

00:08:48.826 --> 00:08:50.346 A:middle
to use the Accelerate Framework.

00:08:50.966 --> 00:08:53.276 A:middle
Linking from the Command
line is just as easy.

00:08:53.736 --> 00:08:57.396 A:middle
In your link step simply
include -framework accelerate.

00:08:57.396 --> 00:09:03.256 A:middle
So now I want to dive into the
details of what's available

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

00:08:57.396 --> 00:09:03.256 A:middle
So now I want to dive into the
details of what's available

00:09:03.256 --> 00:09:04.316 A:middle
in the Accelerate Framework.

00:09:05.176 --> 00:09:06.986 A:middle
I mentioned there's
over 2,000 APIs

00:09:06.986 --> 00:09:10.056 A:middle
and we've got these four
categories so we'll start

00:09:10.056 --> 00:09:11.356 A:middle
to step through these now.

00:09:12.346 --> 00:09:14.076 A:middle
And we'll begin with
image processing.

00:09:16.346 --> 00:09:18.416 A:middle
For image processing
we have vImage,

00:09:18.746 --> 00:09:20.946 A:middle
our vectorized image
processing library.

00:09:21.436 --> 00:09:25.866 A:middle
There's a lot of
functionality in vImage,

00:09:26.066 --> 00:09:28.686 A:middle
and rather than just list it
I put together a short video

00:09:28.686 --> 00:09:30.656 A:middle
to show you some of the
features that are available.

00:09:31.246 --> 00:09:33.916 A:middle
We've got alpha blending

00:09:33.916 --> 00:09:37.976 A:middle
and alpha compositing,
dilation, erosion.

00:09:38.816 --> 00:09:41.706 A:middle
You can create Sobel filters
for form edge detection,

00:09:42.826 --> 00:09:46.916 A:middle
various types of CONVLs
to perform blur, deblur,

00:09:47.446 --> 00:09:52.896 A:middle
or multi-kernel CONVLs,
MaxFilters, MinFilters,

00:09:54.416 --> 00:09:59.646 A:middle
color transformations,
warps and Shears.

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

00:10:00.406 --> 00:10:04.536 A:middle
So this is just some of
what you'll find in vImage.

00:10:05.046 --> 00:10:09.346 A:middle
We also have some great
additions and improvements

00:10:09.766 --> 00:10:13.116 A:middle
in both iOS 7 and OS X.

00:10:13.976 --> 00:10:16.196 A:middle
First we have improved
conversion support.

00:10:17.406 --> 00:10:20.476 A:middle
Conversions are operations
like converting between planar

00:10:20.476 --> 00:10:24.656 A:middle
and chunky data or changing
between a pixel component type,

00:10:24.656 --> 00:10:28.226 A:middle
so an 8-bit image format
to a 16-bit image format

00:10:28.226 --> 00:10:33.556 A:middle
or a floating point image
format, just to name a few.

00:10:33.776 --> 00:10:36.716 A:middle
We also introduced vImage
buffer creation utilities,

00:10:37.826 --> 00:10:39.966 A:middle
so in the tips I talked
about how important it is

00:10:39.966 --> 00:10:43.306 A:middle
to create a buffer,
getting the alignment right

00:10:43.306 --> 00:10:46.246 A:middle
and getting everything
contiguous, so to take some

00:10:46.246 --> 00:10:48.256 A:middle
of the guesswork out
of that for vImage,

00:10:49.056 --> 00:10:50.356 A:middle
we introduced the utilities

00:10:50.356 --> 00:10:53.166 A:middle
where you can just specify
the size of the image,

00:10:53.696 --> 00:10:58.436 A:middle
and this function will create
the appropriately sized buffer

00:10:58.636 --> 00:11:00.556 A:middle
to deliver the maximum
performance.

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

00:10:58.636 --> 00:11:00.556 A:middle
to deliver the maximum
performance.

00:11:03.696 --> 00:11:07.046 A:middle
We also introduced
resampling of 16-bit images,

00:11:08.246 --> 00:11:11.346 A:middle
so all the operations like Warp
and Shear that were available

00:11:11.346 --> 00:11:14.486 A:middle
for 8-bit and floating point
image formats are now available

00:11:14.486 --> 00:11:16.386 A:middle
for 16-bit image
formats as well.

00:11:16.996 --> 00:11:23.216 A:middle
The last addition is streamlined
core graphics interoperability.

00:11:23.506 --> 00:11:26.476 A:middle
This is a big one, and I
want to dive into the details

00:11:26.476 --> 00:11:27.806 A:middle
of this with an example.

00:11:28.466 --> 00:11:31.616 A:middle
So we got the question a lot.

00:11:31.616 --> 00:11:34.826 A:middle
How do I use vImage
with my CGImage ref?

00:11:35.756 --> 00:11:38.276 A:middle
To solve this problem
we introduced two new

00:11:38.276 --> 00:11:39.536 A:middle
utility functions.

00:11:40.096 --> 00:11:43.656 A:middle
To go from CGImage
ref to vImage buffer,

00:11:43.656 --> 00:11:47.416 A:middle
we introduced a utility function
vImage buffer and with CGImage

00:11:48.466 --> 00:11:50.166 A:middle
and for the reverse direction,

00:11:50.166 --> 00:11:53.206 A:middle
we introduced vImage
create CGImage from buffer.

00:11:53.846 --> 00:11:56.746 A:middle
Let's take a look at
an example of this,

00:11:56.856 --> 00:11:58.856 A:middle
and see just how
easy it is to use.

00:11:59.746 --> 00:12:03.646 A:middle
So here we're going
to look at how to go

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

00:11:59.746 --> 00:12:03.646 A:middle
So here we're going
to look at how to go

00:12:03.646 --> 00:12:06.646 A:middle
from a CGImage ref
to a vImage buffer.

00:12:07.816 --> 00:12:09.636 A:middle
As always, we're going to begin

00:12:09.636 --> 00:12:11.576 A:middle
by including the
Accelerate Framework header

00:12:12.136 --> 00:12:16.116 A:middle
and then we're going to
create an openImage ref.

00:12:16.966 --> 00:12:19.136 A:middle
I'm not going to go through
the details of this here.

00:12:19.136 --> 00:12:21.496 A:middle
There's a lot of documentation
and examples of this,

00:12:22.136 --> 00:12:26.196 A:middle
but assume after this line that
we have our CGImage ref open.

00:12:26.196 --> 00:12:28.636 A:middle
The first step that we're going

00:12:28.636 --> 00:12:31.046 A:middle
to do then is specify
the image format.

00:12:31.606 --> 00:12:35.986 A:middle
This image format describes
the format of the vImage buffer

00:12:35.986 --> 00:12:37.646 A:middle
that we want to create.

00:12:38.536 --> 00:12:42.156 A:middle
We've introduced the
vImage/CGImage format structure.

00:12:43.526 --> 00:12:45.926 A:middle
You'll find several elements
in here; for example,

00:12:45.926 --> 00:12:49.256 A:middle
bits per component,
bits per pixel,

00:12:49.506 --> 00:12:56.586 A:middle
information about the color
and bitmap info to name a few.

00:12:56.796 --> 00:13:00.576 A:middle
This descriptor is
describing an ARGB 8-bit image.

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

00:12:56.796 --> 00:13:00.576 A:middle
This descriptor is
describing an ARGB 8-bit image.

00:13:01.876 --> 00:13:03.816 A:middle
We see that the first entry

00:13:03.886 --> 00:13:07.346 A:middle
in this structure is
bits per component of 8,

00:13:07.686 --> 00:13:10.176 A:middle
so each component in the
picture is going to be 8 bits.

00:13:10.976 --> 00:13:12.726 A:middle
The bits per pixel is 32,

00:13:12.726 --> 00:13:14.406 A:middle
so there's going
to be 4 components.

00:13:16.516 --> 00:13:18.306 A:middle
Color space, we pass null.

00:13:18.766 --> 00:13:20.506 A:middle
When we pass null this
means that we're going

00:13:20.506 --> 00:13:22.676 A:middle
to get a default
RBG color space,

00:13:22.826 --> 00:13:24.766 A:middle
so we have 3 color components.

00:13:25.686 --> 00:13:29.926 A:middle
And then in the bitmap info,
we have kCGImage alpha first.

00:13:30.366 --> 00:13:32.396 A:middle
This means we have a
single alpha component

00:13:32.706 --> 00:13:33.886 A:middle
and it's the first component.

00:13:34.406 --> 00:13:37.356 A:middle
So this describes our
8-bit ARGB image format.

00:13:37.926 --> 00:13:43.836 A:middle
With this format we're going to
call vImage buffer with CGImage.

00:13:45.546 --> 00:13:48.306 A:middle
The first argument is the
input buffer that we want

00:13:48.306 --> 00:13:50.626 A:middle
to create from our CGImage ref.

00:13:51.886 --> 00:13:53.546 A:middle
The second argument
is the reference

00:13:53.546 --> 00:13:55.736 A:middle
to that format description
that we just created.

00:13:56.336 --> 00:13:59.636 A:middle
The third argument is
unused in this case.

00:13:59.636 --> 00:14:01.706 A:middle
This is information
about background color.

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

00:13:59.636 --> 00:14:01.706 A:middle
This is information
about background color.

00:14:02.706 --> 00:14:05.916 A:middle
In certain conversions when
alpha channels are involved,

00:14:05.916 --> 00:14:07.966 A:middle
it may be necessary
to provide information

00:14:07.966 --> 00:14:08.976 A:middle
about a background color.

00:14:09.576 --> 00:14:14.416 A:middle
The next argument is NImage --

00:14:14.416 --> 00:14:16.566 A:middle
this is our CGImage ref
that we want to convert

00:14:16.566 --> 00:14:20.196 A:middle
to the vImage buffer, and
finally any additional flags.

00:14:20.346 --> 00:14:24.226 A:middle
In this case we don't have any
so we pass kV image no flags.

00:14:26.966 --> 00:14:30.046 A:middle
Upon successful return
of this function,

00:14:30.046 --> 00:14:32.406 A:middle
we've allocated a
new vImage buffer.

00:14:32.656 --> 00:14:37.026 A:middle
It contains the image format,
the image and the format

00:14:37.026 --> 00:14:39.706 A:middle
that we've described,
and we're free

00:14:39.706 --> 00:14:42.626 A:middle
to at this point
release the CGImage ref.

00:14:44.736 --> 00:14:46.666 A:middle
The reverse is just as easy,

00:14:46.666 --> 00:14:49.866 A:middle
going from a vImage
buffer to a CGImage ref.

00:14:50.876 --> 00:14:52.706 A:middle
So we've done our
image processing,

00:14:53.606 --> 00:14:56.046 A:middle
and we have our vImage
buffer out buffer.

00:14:56.796 --> 00:14:58.506 A:middle
We haven't changed the
format so we're going

00:14:58.506 --> 00:15:01.676 A:middle
to use our same format specifier
that we created before.

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

00:14:58.506 --> 00:15:01.676 A:middle
to use our same format specifier
that we created before.

00:15:02.386 --> 00:15:05.536 A:middle
To create the CGImage
refer we're going

00:15:05.536 --> 00:15:09.456 A:middle
to call vImageCreate
CGImage ref from buffer.

00:15:09.926 --> 00:15:16.006 A:middle
The first argument is going
to be the output vImage buffer

00:15:16.006 --> 00:15:17.666 A:middle
that we just finished
processing,

00:15:18.976 --> 00:15:21.936 A:middle
that same format type, because
we haven't changed the format.

00:15:23.156 --> 00:15:27.136 A:middle
The next two arguments are user
callback and user functions,

00:15:27.966 --> 00:15:30.036 A:middle
user callback functions
and user data.

00:15:30.926 --> 00:15:33.166 A:middle
For this particular
conversion we don't need

00:15:33.166 --> 00:15:34.976 A:middle
that so we're just
going to pass null.

00:15:35.496 --> 00:15:38.706 A:middle
And then we pass flag,
any additional flags.

00:15:38.706 --> 00:15:40.616 A:middle
Again, in this case
there are none,

00:15:40.676 --> 00:15:43.456 A:middle
so we pass k at vImage,
no flags.

00:15:44.616 --> 00:15:47.056 A:middle
And then finally a
reference to a vImage error

00:15:47.436 --> 00:15:50.616 A:middle
to capture the error state.

00:15:50.796 --> 00:15:52.876 A:middle
Upon successful return
of this function,

00:15:53.176 --> 00:15:56.066 A:middle
we're going to return
the CGImage ref,

00:15:56.066 --> 00:15:57.646 A:middle
out image in this case.

00:15:58.536 --> 00:16:03.336 A:middle
This is going to be a freshly
allocated CGImage ref containing

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

00:15:58.536 --> 00:16:03.336 A:middle
This is going to be a freshly
allocated CGImage ref containing

00:16:03.486 --> 00:16:07.246 A:middle
the image information,
and we are free

00:16:07.246 --> 00:16:08.796 A:middle
to release the vImagem buffer.

00:16:09.496 --> 00:16:15.136 A:middle
All of this is built
around a really powerful API

00:16:15.136 --> 00:16:20.206 A:middle
that we're introducing now
called vImage Convert Any

00:16:20.916 --> 00:16:22.926 A:middle
to Any.

00:16:23.116 --> 00:16:25.456 A:middle
What vImage Convert Any
to Any does it it converts

00:16:25.456 --> 00:16:28.756 A:middle
between the image format
specifiers that we just saw,

00:16:29.246 --> 00:16:34.506 A:middle
so you'll create two of these
format types, one for the source

00:16:34.506 --> 00:16:35.926 A:middle
and one for the destination
type,

00:16:35.986 --> 00:16:37.836 A:middle
and you'll create a converter.

00:16:39.036 --> 00:16:41.446 A:middle
Once you've created this
converter, you can then convert

00:16:41.446 --> 00:16:44.266 A:middle
as many images as you
want from that source type

00:16:44.266 --> 00:16:46.186 A:middle
to that destination type.

00:16:46.736 --> 00:16:49.546 A:middle
So this is one of those cases
where you want to create

00:16:49.546 --> 00:16:52.976 A:middle
that converter once and use
it as many times as you can.

00:16:53.576 --> 00:16:58.556 A:middle
The vImage Convert Any
to Any is really fast,

00:16:59.336 --> 00:17:01.216 A:middle
and I want to show
you an example of hits

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

00:16:59.336 --> 00:17:01.216 A:middle
and I want to show
you an example of hits

00:17:01.216 --> 00:17:02.576 A:middle
with a real world application.

00:17:02.706 --> 00:17:08.715 A:middle
I want to show you that with
software jpeg encode performance

00:17:09.106 --> 00:17:10.406 A:middle
running on the iPhone 5.

00:17:10.986 --> 00:17:13.646 A:middle
What I have here is a graph.

00:17:14.266 --> 00:17:16.726 A:middle
On the y-axis I've got
megapixels per second,

00:17:16.826 --> 00:17:18.876 A:middle
so this is the rate at
which we can perform

00:17:18.876 --> 00:17:20.296 A:middle
that software jpeg encode.

00:17:21.296 --> 00:17:24.386 A:middle
On the x-axis I have
various image format types.

00:17:24.596 --> 00:17:26.236 A:middle
For the sake of this example,

00:17:26.236 --> 00:17:28.406 A:middle
think of this software
jpeg encode

00:17:28.496 --> 00:17:30.036 A:middle
as happening in two steps.

00:17:31.086 --> 00:17:33.866 A:middle
Step one is to convert from
our input image format type,

00:17:33.996 --> 00:17:35.856 A:middle
so those that we
see on the x-axis;

00:17:36.656 --> 00:17:40.976 A:middle
two the image format type
that the encode step consumes,

00:17:41.786 --> 00:17:44.386 A:middle
and the second step is to
perform the actual encode.

00:17:45.046 --> 00:17:49.086 A:middle
What we're interested here
is step one, so converting

00:17:49.086 --> 00:17:50.606 A:middle
from the input image format type

00:17:51.036 --> 00:17:53.426 A:middle
to the format type
consumed by the encode.

00:17:54.476 --> 00:17:56.826 A:middle
Let's take a look at the
performance the original way.

00:17:57.536 --> 00:18:01.786 A:middle
We see a few things here.

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

00:17:57.536 --> 00:18:01.786 A:middle
We see a few things here.

00:18:02.266 --> 00:18:03.976 A:middle
First we see a lot
of variability.

00:18:05.146 --> 00:18:09.116 A:middle
For example, if you start
from an 8-bit RGBA image,

00:18:09.606 --> 00:18:12.616 A:middle
your encode performance is
going to be almost twice as fast

00:18:12.616 --> 00:18:15.516 A:middle
as if you start from a
floating point RGBA image.

00:18:16.056 --> 00:18:19.156 A:middle
The reason that this
is happening is

00:18:19.196 --> 00:18:21.276 A:middle
because step one is so variable.

00:18:22.676 --> 00:18:25.346 A:middle
So what we wanted to do
is change just step one.

00:18:25.536 --> 00:18:28.436 A:middle
We replace step one now with
vImage Convert Any to Any,

00:18:29.856 --> 00:18:31.196 A:middle
and let's look at
the performance.

00:18:35.356 --> 00:18:37.526 A:middle
We see everything
gets a lot faster now.

00:18:38.926 --> 00:18:43.266 A:middle
We also see that the
performance is quite consistent.

00:18:46.286 --> 00:18:50.306 A:middle
So our 8-bit RGBA image is
now only a few percent faster

00:18:50.306 --> 00:18:52.306 A:middle
than our floating
point RGBA image.

00:18:52.856 --> 00:18:56.746 A:middle
The reason that this happens is
because we reduced the amount

00:18:56.746 --> 00:18:58.416 A:middle
of time that we spent
in step one,

00:18:58.416 --> 00:19:01.116 A:middle
converting from the input image
format to the other format,

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

00:18:58.416 --> 00:19:01.116 A:middle
converting from the input image
format to the other format,

00:19:01.706 --> 00:19:04.266 A:middle
to a very small percent
of the overall operation.

00:19:04.786 --> 00:19:09.836 A:middle
This type of result is what you
can expect in your applications.

00:19:09.836 --> 00:19:11.536 A:middle
This is a real world
application.

00:19:12.596 --> 00:19:14.736 A:middle
vImage is delivering
great performance

00:19:14.866 --> 00:19:16.236 A:middle
and consistent results.

00:19:16.236 --> 00:19:20.876 A:middle
I want to stay on the
topic of conversion

00:19:20.876 --> 00:19:21.886 A:middle
for a little bit longer.

00:19:22.676 --> 00:19:25.336 A:middle
I want to talk about an example

00:19:25.336 --> 00:19:27.936 A:middle
of scaling a premultiplied
image.

00:19:28.506 --> 00:19:33.456 A:middle
A lot of people will have an
image format and they'll have it

00:19:33.456 --> 00:19:36.136 A:middle
in a vImage buffer and
they'll want to scale it.

00:19:36.526 --> 00:19:37.816 A:middle
They'll look through
vImagem and see

00:19:37.816 --> 00:19:43.126 A:middle
that the only way you can scale
an image is a non-premultiplied

00:19:43.126 --> 00:19:43.826 A:middle
image format.

00:19:44.926 --> 00:19:48.366 A:middle
So the way that you need to do
this is three steps in vImage.

00:19:49.456 --> 00:19:51.806 A:middle
I'm not going to go into the
details of each of these steps,

00:19:52.146 --> 00:19:59.386 A:middle
but in step one, we're going
to unpremultiply the data.

00:19:59.566 --> 00:20:02.656 A:middle
In step two, we're going
to perform the scale.

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

00:19:59.566 --> 00:20:02.656 A:middle
In step two, we're going
to perform the scale.

00:20:03.926 --> 00:20:05.706 A:middle
And then in step
three we're going

00:20:05.706 --> 00:20:08.176 A:middle
to premultiply the
results of that output.

00:20:08.726 --> 00:20:12.906 A:middle
A lot of people see this as
three times the amount of work,

00:20:14.006 --> 00:20:15.906 A:middle
and they get afraid
and they go off

00:20:15.906 --> 00:20:17.336 A:middle
and they implement
their own scale.

00:20:17.336 --> 00:20:21.496 A:middle
I want to show you how much time
we spent in each of these steps.

00:20:22.026 --> 00:20:26.456 A:middle
What I have here is the
percentage of time in each

00:20:26.456 --> 00:20:28.396 A:middle
of those three same
steps as we saw them.

00:20:28.976 --> 00:20:32.746 A:middle
At the top we see
unpremultiply, a little over 1%,

00:20:32.746 --> 00:20:37.756 A:middle
at the bottom we see the
premultiply, a little of 1/2%.

00:20:39.116 --> 00:20:42.016 A:middle
The vast majority of time is
spent in the actual operation.

00:20:42.566 --> 00:20:44.596 A:middle
What I want you to take away

00:20:44.596 --> 00:20:47.816 A:middle
from this is don't take away
the conversions, they're fast.

00:20:48.436 --> 00:20:51.446 A:middle
If your image isn't in the right
format, use the conversions.

00:20:51.446 --> 00:20:53.996 A:middle
It's going to be worthwhile
getting into the image.

00:20:53.996 --> 00:21:00.986 A:middle
Now I want to talk about
some performance of vImage

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

00:20:53.996 --> 00:21:00.986 A:middle
Now I want to talk about
some performance of vImage

00:21:00.986 --> 00:21:04.736 A:middle
as compared to some of the
other options, and I want to do

00:21:04.736 --> 00:21:07.156 A:middle
that by comparing to OpenCV.

00:21:08.076 --> 00:21:11.946 A:middle
OpenCV is a third party open
source computer vision library.

00:21:13.216 --> 00:21:14.996 A:middle
It has an image processing
module.

00:21:15.766 --> 00:21:17.546 A:middle
That image processing
module has a lot

00:21:17.546 --> 00:21:19.516 A:middle
of the same functionality
that vImage has.

00:21:19.996 --> 00:21:23.426 A:middle
There's a couple points
that I want to compare.

00:21:24.076 --> 00:21:25.826 A:middle
The first is execution time.

00:21:27.196 --> 00:21:29.436 A:middle
Everybody wants their
applications to run fast.

00:21:30.356 --> 00:21:31.906 A:middle
The second is energy consumed.

00:21:32.616 --> 00:21:35.546 A:middle
We're increasingly reliant on
our batteries so it's important

00:21:35.546 --> 00:21:37.976 A:middle
that we get that
performance while being aware

00:21:37.976 --> 00:21:39.226 A:middle
of the energy consumption.

00:21:39.796 --> 00:21:43.856 A:middle
To begin we'll look at the
execution time and we'll do

00:21:43.856 --> 00:21:47.456 A:middle
that by looking at the
speedup of vImage over OpenCV.

00:21:48.726 --> 00:21:52.646 A:middle
So on this graph I've
got numbers where numbers

00:21:52.646 --> 00:21:56.296 A:middle
above 1 means vImage is going
to be that many times faster

00:21:56.296 --> 00:22:00.256 A:middle
than OpenCV, and for numbers
below 1 it means OpenCV is going

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

00:21:56.296 --> 00:22:00.256 A:middle
than OpenCV, and for numbers
below 1 it means OpenCV is going

00:22:00.256 --> 00:22:00.846 A:middle
to be faster.

00:22:01.986 --> 00:22:05.236 A:middle
I've got a handful of operations
here, and we see that vImage is

00:22:05.236 --> 00:22:10.006 A:middle
between 1.6 and over 20
times faster than OpenCV,

00:22:10.956 --> 00:22:13.506 A:middle
so these are some really
great performance results.

00:22:13.926 --> 00:22:16.386 A:middle
But as I mentioned, it's not
just all about performance.

00:22:17.676 --> 00:22:20.736 A:middle
We're concerned also with energy
consumption and battery life.

00:22:20.736 --> 00:22:25.706 A:middle
I want to explain this
relationship between performance

00:22:25.706 --> 00:22:29.606 A:middle
and energy consumption and
battery life a little bit,

00:22:29.606 --> 00:22:30.666 A:middle
and there's a few points.

00:22:30.936 --> 00:22:34.666 A:middle
First, fast code tends to
decrease energy consumption,

00:22:35.736 --> 00:22:38.466 A:middle
therefore, fast code tends
to increase battery life.

00:22:39.616 --> 00:22:41.626 A:middle
Let's look at why
this tends to happen.

00:22:42.896 --> 00:22:46.216 A:middle
What I have here is a typical
energy consumption profile.

00:22:46.636 --> 00:22:48.896 A:middle
So we're measuring the
instantaneous power.

00:22:50.336 --> 00:22:52.636 A:middle
Energy is the area
underneath that power curve.

00:22:53.206 --> 00:22:56.156 A:middle
So on the x-axis I've got time.

00:22:57.616 --> 00:23:01.186 A:middle
In the beginning, on the y-axis
I've got our instantaneous

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

00:22:57.616 --> 00:23:01.186 A:middle
In the beginning, on the y-axis
I've got our instantaneous

00:23:01.186 --> 00:23:01.896 A:middle
power measurement.

00:23:03.156 --> 00:23:05.096 A:middle
In the beginning we're
running at some idle state

00:23:05.096 --> 00:23:08.116 A:middle
and using a very
small amount of power.

00:23:08.116 --> 00:23:10.276 A:middle
At time t0 our application
begins

00:23:10.686 --> 00:23:13.676 A:middle
and we increase the amount of
power that we're consuming.

00:23:14.246 --> 00:23:16.106 A:middle
The application runs
through time t1

00:23:16.106 --> 00:23:18.796 A:middle
and we return back
to some idle state.

00:23:19.456 --> 00:23:23.366 A:middle
The amount of battery that we're
using, the energy consumption,

00:23:23.366 --> 00:23:25.076 A:middle
is the area underneath
this curve.

00:23:25.786 --> 00:23:27.986 A:middle
Let's look at how an
optimized routine compares

00:23:27.986 --> 00:23:29.336 A:middle
to an unoptimized routine.

00:23:29.926 --> 00:23:34.256 A:middle
So here in blue I've got
an optimized routine --

00:23:34.846 --> 00:23:35.806 A:middle
much faster.

00:23:36.476 --> 00:23:41.156 A:middle
In certain situations it's
going to take more power to make

00:23:41.156 --> 00:23:45.216 A:middle
that routine run faster, but
the important part here is

00:23:45.436 --> 00:23:47.936 A:middle
that the energy consumption
is the area underneath,

00:23:48.056 --> 00:23:50.626 A:middle
and we can seek that the
optimized routine is using

00:23:50.626 --> 00:23:52.126 A:middle
significantly less energy.

00:23:52.766 --> 00:23:58.176 A:middle
So now let's look at that
same vImage OpenCV comparison

00:23:58.876 --> 00:24:00.416 A:middle
for the energy numbers.

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

00:23:58.876 --> 00:24:00.416 A:middle
for the energy numbers.

00:24:01.856 --> 00:24:05.216 A:middle
So I've got the vImage energy
savings over OpenCV here.

00:24:06.596 --> 00:24:10.656 A:middle
So again, numbers above
1 means vImage is using

00:24:10.656 --> 00:24:12.686 A:middle
that much times less
energy than OpenCV,

00:24:12.686 --> 00:24:17.156 A:middle
and for numbers below 1 it means
OpenCV is using less energy.

00:24:18.916 --> 00:24:24.036 A:middle
This ranges from .75 up through
almost 7 times less energy.

00:24:25.246 --> 00:24:27.226 A:middle
So we're delivering
really great performance,

00:24:27.226 --> 00:24:30.496 A:middle
and we're also delivering
really great energy savings.

00:24:31.456 --> 00:24:33.716 A:middle
This is what you can
expect in your applications.

00:24:33.716 --> 00:24:40.436 A:middle
We love to get feedback about
use of the Accelerate Framework

00:24:40.436 --> 00:24:44.066 A:middle
and we found this tweet I wanted
to share with you: "Using vImage

00:24:44.096 --> 00:24:45.556 A:middle
from the Accelerate Framework

00:24:45.556 --> 00:24:47.496 A:middle
to dynamically prerender
my spreads,

00:24:48.776 --> 00:24:54.216 A:middle
it's the only way
to make it fast."

00:24:54.976 --> 00:24:57.326 A:middle
Now I want to move on
to the next big category

00:24:57.426 --> 00:24:59.596 A:middle
of operations available on
the Accelerate Framework

00:24:59.596 --> 00:25:02.346 A:middle
and that is digital
signal processing.

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

00:24:59.596 --> 00:25:02.346 A:middle
and that is digital
signal processing.

00:25:02.906 --> 00:25:06.606 A:middle
You'll find digital
signal processing in vDSP.

00:25:06.646 --> 00:25:10.136 A:middle
This is our Vectorized Digital
Signal Processing library.

00:25:10.756 --> 00:25:17.166 A:middle
In vDSP you'll find basic
operation on arrays, additions,

00:25:17.166 --> 00:25:22.206 A:middle
subtractions, multiplies,
conversions, accumulations.

00:25:23.496 --> 00:25:26.326 A:middle
You'll also find discrete
Fourier transforms,

00:25:26.326 --> 00:25:28.086 A:middle
discrete cosine transforms,

00:25:28.556 --> 00:25:31.036 A:middle
as well as convolutions
and correlations.

00:25:31.596 --> 00:25:36.656 A:middle
In both iOS 7 and OS 10.9,

00:25:36.656 --> 00:25:39.056 A:middle
we've introduced some great
new features and functionality.

00:25:39.716 --> 00:25:43.936 A:middle
The first of these is a
multi-channel IIR filter.

00:25:44.076 --> 00:25:46.406 A:middle
This is an infinite
impulse response filter.

00:25:46.976 --> 00:25:51.016 A:middle
So whereas before if you
needed to perform an IIR filter

00:25:51.016 --> 00:25:54.336 A:middle
on multiple channels, maybe you
have a surround sound system

00:25:54.336 --> 00:25:56.246 A:middle
that you want to
filter, you'd have to do

00:25:56.246 --> 00:26:00.296 A:middle
that with individual
calls into an IIR filter.

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

00:25:56.246 --> 00:26:00.296 A:middle
that with individual
calls into an IIR filter.

00:26:00.456 --> 00:26:02.136 A:middle
Now with this new
multi-channel you can do

00:26:02.136 --> 00:26:05.426 A:middle
that with a single function
call, and we've been able

00:26:05.426 --> 00:26:08.656 A:middle
to give you some great
performance and energy savings

00:26:08.686 --> 00:26:11.256 A:middle
by doing that operation
in a single function.

00:26:15.216 --> 00:26:17.286 A:middle
We've also improved
power of 2 support

00:26:17.286 --> 00:26:19.636 A:middle
for the discrete
Fourier transform

00:26:19.636 --> 00:26:21.556 A:middle
and the discrete
cosine transform.

00:26:21.896 --> 00:26:24.706 A:middle
I want to talk about
this with an example.

00:26:25.326 --> 00:26:32.026 A:middle
So before we essentially
had two entry points

00:26:32.376 --> 00:26:35.146 A:middle
for the same operation based
on the number of points

00:26:35.146 --> 00:26:36.316 A:middle
that you wanted to evaluate.

00:26:38.116 --> 00:26:40.696 A:middle
So if you had a power of 2,
you would call into the FFT.

00:26:40.696 --> 00:26:45.856 A:middle
If you had a non-power of 2
you would call into the DFT.

00:26:45.976 --> 00:26:48.876 A:middle
Starting in iOS 10.9 and iOS 7,

00:26:48.876 --> 00:26:53.456 A:middle
the DFT supports
certain powers of 2.

00:26:53.696 --> 00:26:56.006 A:middle
When the DFT supports the
number of points that you want

00:26:56.006 --> 00:27:00.666 A:middle
to compute, we recommend
that you use the DFT.

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

00:26:56.006 --> 00:27:00.666 A:middle
to compute, we recommend
that you use the DFT.

00:27:00.876 --> 00:27:03.306 A:middle
So this brings up another
question: How can I be sure

00:27:03.306 --> 00:27:04.896 A:middle
that my number of
points is supported?

00:27:05.736 --> 00:27:08.226 A:middle
If you can't find it in the
documentation for some reason,

00:27:08.566 --> 00:27:10.156 A:middle
you can always programmatically
check.

00:27:11.146 --> 00:27:14.506 A:middle
The DFT is one of the routines
that requires a setup structure,

00:27:15.146 --> 00:27:18.136 A:middle
and that setup structure
is designed to return 0

00:27:18.136 --> 00:27:19.816 A:middle
if the number of
points isn't supported.

00:27:20.276 --> 00:27:21.536 A:middle
You can always be sure

00:27:21.766 --> 00:27:24.276 A:middle
that you're using
the correct routine.

00:27:24.276 --> 00:27:29.666 A:middle
Let's look at an
example of the DFT.

00:27:31.156 --> 00:27:33.436 A:middle
Again, we'll start by including
the Accelerate Framework,

00:27:34.756 --> 00:27:36.776 A:middle
then we're going to create
and prepare our data.

00:27:36.776 --> 00:27:40.446 A:middle
In this case we've got 4
buffers, 2 input buffers,

00:27:41.126 --> 00:27:46.406 A:middle
one for the real numbers and
one for the imaginary numbers,

00:27:46.696 --> 00:27:48.836 A:middle
2 output buffers --
again, one for the real

00:27:48.836 --> 00:27:49.916 A:middle
and one for the imaginary.

00:27:50.916 --> 00:27:52.576 A:middle
We want to align
these if possible.

00:27:53.126 --> 00:27:58.526 A:middle
Then we're going to perform a
DFT setup, and we're going to do

00:27:58.526 --> 00:28:00.616 A:middle
that with vDSP zop create setup.

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

00:27:58.526 --> 00:28:00.616 A:middle
that with vDSP zop create setup.

00:28:01.896 --> 00:28:03.076 A:middle
Takes a few arguments.

00:28:03.796 --> 00:28:05.926 A:middle
The first argument
is information

00:28:05.926 --> 00:28:08.076 A:middle
about any pervious setups
that may have occurred.

00:28:08.256 --> 00:28:11.736 A:middle
We don't have one in this case
so we'll pass zero or null.

00:28:12.536 --> 00:28:15.596 A:middle
The next is the number of points
that we want to compute, 1024,

00:28:15.596 --> 00:28:19.976 A:middle
and then information that
describes the DFT that we want

00:28:20.306 --> 00:28:23.566 A:middle
to perform, in this
case the forward DFT.

00:28:24.726 --> 00:28:29.326 A:middle
Once we've created a setup,
we're going to execute our DFT.

00:28:30.396 --> 00:28:33.836 A:middle
We do that with vDSP
DFT execute,

00:28:33.836 --> 00:28:35.696 A:middle
takes that setup structure
that we just created

00:28:35.696 --> 00:28:39.996 A:middle
and the 4 buffers that
we had set up before.

00:28:39.996 --> 00:28:44.066 A:middle
Again, we want to do this
as many times as we can

00:28:44.066 --> 00:28:45.826 A:middle
with that same setup structure.

00:28:45.906 --> 00:28:47.436 A:middle
We can use it over
and over again.

00:28:48.546 --> 00:28:51.276 A:middle
Once we've done all the
computation one time at the end,

00:28:51.276 --> 00:28:55.306 A:middle
then we want to clean up our
setup with vDSP DFT Destroy.

00:28:56.046 --> 00:29:02.596 A:middle
So I want to do another
comparison now vDSP versus FFTW.

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

00:28:56.046 --> 00:29:02.596 A:middle
So I want to do another
comparison now vDSP versus FFTW.

00:29:04.126 --> 00:29:07.886 A:middle
FFTW is called Fastest
Fourier Transform in the West.

00:29:09.016 --> 00:29:13.086 A:middle
This is another third party
freely available library,

00:29:13.826 --> 00:29:14.536 A:middle
supports one

00:29:14.536 --> 00:29:16.446 A:middle
and multidimensional
transformations,

00:29:17.356 --> 00:29:19.116 A:middle
both real and complex data.

00:29:19.836 --> 00:29:20.606 A:middle
It's parallel.

00:29:21.176 --> 00:29:24.936 A:middle
It's a good freely
available library.

00:29:24.936 --> 00:29:26.126 A:middle
It's a fair comparison.

00:29:30.286 --> 00:29:33.126 A:middle
I'm going to show
again the vDSP speedup

00:29:33.126 --> 00:29:35.746 A:middle
over FFTW on the iPhone 5.

00:29:37.206 --> 00:29:40.396 A:middle
So again, numbers above 1
means vDSP is going to be

00:29:40.396 --> 00:29:43.366 A:middle
that many times faster than FFTW

00:29:43.976 --> 00:29:46.056 A:middle
and numbers below
1 FFTW is going

00:29:46.056 --> 00:29:47.816 A:middle
to be faster than the vDSP.

00:29:48.616 --> 00:29:54.766 A:middle
Across the x-axis I have
several number of points

00:29:54.766 --> 00:29:55.866 A:middle
that we're going to execute.

00:29:56.676 --> 00:29:58.536 A:middle
Let's take a look at the
performance that we get.

00:29:58.536 --> 00:30:06.836 A:middle
We see that vDSP is between
1.8 and about 2.5 times faster

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

00:29:58.536 --> 00:30:06.836 A:middle
We see that vDSP is between
1.8 and about 2.5 times faster

00:30:06.886 --> 00:30:09.606 A:middle
than FFTW for all of these
number of points that we looked

00:30:09.606 --> 00:30:12.336 A:middle
at -- some really great
performance results.

00:30:12.876 --> 00:30:16.376 A:middle
It's one thing to look
at benchmarks, though.

00:30:17.476 --> 00:30:19.986 A:middle
It's another thing to
look at the performance

00:30:19.986 --> 00:30:22.586 A:middle
that you can expect
from a real application.

00:30:23.166 --> 00:30:28.536 A:middle
So imagine you need to code an
audio signal using AAC enhanced

00:30:28.656 --> 00:30:29.156 A:middle
low delay.

00:30:30.656 --> 00:30:34.066 A:middle
This is a process
that's done in face time.

00:30:34.846 --> 00:30:38.336 A:middle
The DFT is one of many of
the DFT routines in use,

00:30:38.386 --> 00:30:40.026 A:middle
but it's the only one that
we're looking at here.

00:30:40.026 --> 00:30:43.346 A:middle
And we're going to look at this
by looking at the percentage

00:30:43.346 --> 00:30:49.696 A:middle
of time that we spend
in the DFT.

00:30:49.906 --> 00:30:52.636 A:middle
So what I've got here is the
percentage of time for the DFT

00:30:52.636 --> 00:30:58.706 A:middle
at 54% and at 47% is everything
else in the operation.

00:30:59.196 --> 00:31:02.816 A:middle
This is when we're
linking against FFTW.

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

00:30:59.196 --> 00:31:02.816 A:middle
This is when we're
linking against FFTW.

00:31:02.816 --> 00:31:07.156 A:middle
The only thing we change
is we link against vDSP

00:31:07.156 --> 00:31:10.236 A:middle
so that we get the
DFT out of vDSP.

00:31:10.236 --> 00:31:13.086 A:middle
And let's look at
how this changes.

00:31:17.116 --> 00:31:20.036 A:middle
When the DFT is replaced
with the DFT out of VDSP,

00:31:20.036 --> 00:31:22.676 A:middle
the time spent goes to 30%.

00:31:23.446 --> 00:31:26.576 A:middle
This translates to significant
performance and energy savings.

00:31:27.966 --> 00:31:30.346 A:middle
This is what you can
expect in your applications.

00:31:30.886 --> 00:31:37.766 A:middle
A little bit more details
about what VDSP supports.

00:31:38.296 --> 00:31:42.386 A:middle
It supports single and
double precision, both real

00:31:42.386 --> 00:31:45.956 A:middle
and complex values,
as well as strided

00:31:45.956 --> 00:31:47.596 A:middle
and non-strided data accesses.

00:31:48.166 --> 00:31:52.386 A:middle
So again, we love
to get feedback.

00:31:52.386 --> 00:31:55.276 A:middle
Another tweet about using vDSP.

00:31:55.566 --> 00:31:57.166 A:middle
Want to do FFT on iOS?

00:31:57.416 --> 00:31:58.776 A:middle
Use the Accelerate Framework.

00:31:59.226 --> 00:32:00.296 A:middle
Highly recommended.

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

00:31:59.226 --> 00:32:00.296 A:middle
Highly recommended.

00:32:01.516 --> 00:32:02.006 A:middle
Thank you.

00:32:02.586 --> 00:32:06.686 A:middle
So now I want to move on to
transcendental math functions.

00:32:06.926 --> 00:32:08.706 A:middle
And for that, I'm going
to turn it over to Luke.

00:32:10.146 --> 00:32:10.786 A:middle
>> Luke: Hello, everyone.

00:32:10.786 --> 00:32:12.376 A:middle
My name's Luke Chang.

00:32:12.896 --> 00:32:14.826 A:middle
I'm here to talk
about math functions.

00:32:15.676 --> 00:32:19.936 A:middle
In our group, we support
math for every data level.

00:32:20.966 --> 00:32:26.116 A:middle
For scaled data, we have
libem, takes a scalar input,

00:32:26.226 --> 00:32:28.286 A:middle
returns a scalar output.

00:32:29.256 --> 00:32:33.566 A:middle
If you're writing vector
code, we have the method.

00:32:34.786 --> 00:32:36.656 A:middle
It takes a SIMD vector S input

00:32:36.656 --> 00:32:39.236 A:middle
and then return a
SIMD vector S output.

00:32:39.736 --> 00:32:44.656 A:middle
And you want to handle a lot
of data, will have vForce.

00:32:45.786 --> 00:32:48.766 A:middle
It takes Arias input and
then returns Arias output.

00:32:48.766 --> 00:32:51.956 A:middle
We're going to talk
about them one by one.

00:32:52.756 --> 00:32:54.556 A:middle
First, libem.

00:32:54.936 --> 00:33:00.766 A:middle
It's a standard C math
library, it has a collection

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

00:32:54.936 --> 00:33:00.766 A:middle
It's a standard C math
library, it has a collection

00:33:00.766 --> 00:33:05.426 A:middle
of [inaudible] like
exponents, logarithm,

00:33:06.286 --> 00:33:08.056 A:middle
trigonometry, power functions.

00:33:09.036 --> 00:33:12.206 A:middle
You're probably very familiar
with it, so I'm going to talk

00:33:12.206 --> 00:33:14.806 A:middle
about what we added
this year for libem.

00:33:15.366 --> 00:33:20.476 A:middle
What we added is an
extension to the C11 standard,

00:33:20.476 --> 00:33:23.766 A:middle
so we prefixed the function
name with double underscores.

00:33:25.046 --> 00:33:30.056 A:middle
They are available on both
iOS 7 and Mac OS 10.9.

00:33:30.856 --> 00:33:35.696 A:middle
They are power of 10 function,
trigonometry in terms of pi,

00:33:36.746 --> 00:33:38.206 A:middle
and sine and cosine pairs.

00:33:38.676 --> 00:33:44.386 A:middle
First, power of 10, why
do we add power of 10?

00:33:45.486 --> 00:33:48.226 A:middle
It's a very common operation
in decimal calculation,

00:33:48.976 --> 00:33:52.586 A:middle
so if you're writing audio apps,
you need quite a lot of it.

00:33:53.586 --> 00:33:57.946 A:middle
Without a specific power of 10
function you have 2 options --

00:33:59.026 --> 00:34:03.166 A:middle
one, to use Pow and use
constant 10 as base.

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

00:33:59.026 --> 00:34:03.166 A:middle
one, to use Pow and use
constant 10 as base.

00:34:04.046 --> 00:34:08.295 A:middle
However, this is inefficient,
because Pow is designed

00:34:08.295 --> 00:34:09.716 A:middle
to handle generic inputs.

00:34:10.766 --> 00:34:13.786 A:middle
if you know your base is a
constant, there are a lot

00:34:13.786 --> 00:34:18.116 A:middle
of optimization that we can
do to make it go faster.

00:34:18.896 --> 00:34:21.235 A:middle
The other way is to use X.

00:34:22.326 --> 00:34:27.136 A:middle
You can prescale your input
by log(10) to do power of 10.

00:34:28.456 --> 00:34:30.746 A:middle
But it has its own problem.

00:34:31.146 --> 00:34:31.976 A:middle
It's not accurate.

00:34:32.436 --> 00:34:34.876 A:middle
There's routing error
in the multiplication.

00:34:35.766 --> 00:34:39.815 A:middle
For example, if you
want to calculate 10(5),

00:34:40.406 --> 00:34:44.726 A:middle
using this method, you will
not exactly get 100,000.

00:34:45.356 --> 00:34:46.966 A:middle
There's a small error
at the end.

00:34:48.456 --> 00:34:52.406 A:middle
That's why we added
X(10) so you can do power

00:34:52.406 --> 00:34:56.085 A:middle
of 10 faster and more accurate.

00:34:57.266 --> 00:35:00.486 A:middle
Next is trigonometry
function in terms of pi.

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

00:34:57.266 --> 00:35:00.486 A:middle
Next is trigonometry
function in terms of pi.

00:35:01.836 --> 00:35:04.926 A:middle
Basically it's the same
regular trigonometry function

00:35:04.926 --> 00:35:06.856 A:middle
with your input scale by pi.

00:35:07.546 --> 00:35:12.076 A:middle
It is faster because we can do
automatic reductions faster.

00:35:12.566 --> 00:35:16.246 A:middle
It's much easier to reduce
the argument by multiple of 2

00:35:16.786 --> 00:35:20.576 A:middle
than multiple of 2 pi.

00:35:20.576 --> 00:35:23.946 A:middle
It's also more accurate when
you're dealing with degrees.

00:35:25.256 --> 00:35:29.576 A:middle
For example, if you want to
calculate cosine of 90 degrees,

00:35:30.716 --> 00:35:32.726 A:middle
90 degrees [inaudible]
into 1/2 pi.

00:35:33.696 --> 00:35:36.076 A:middle
With the regular trigonometry
function you will have

00:35:36.076 --> 00:35:42.576 A:middle
to say cos pi x 0.5, and
you will not get 0 back;

00:35:42.576 --> 00:35:44.056 A:middle
you will get a very
small number,

00:35:44.646 --> 00:35:48.026 A:middle
because pi is not so accurate.

00:35:49.386 --> 00:35:56.016 A:middle
So if you use cos pi 0.5,
you will get exactly 0 back.

00:35:56.556 --> 00:36:01.936 A:middle
There's no error
sine/cosine pairs.

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

00:35:56.556 --> 00:36:01.936 A:middle
There's no error
sine/cosine pairs.

00:36:03.276 --> 00:36:05.096 A:middle
A lot of times when
you can't really sine,

00:36:05.096 --> 00:36:07.656 A:middle
you'll need cosine
for the same value.

00:36:08.086 --> 00:36:11.826 A:middle
For example, if you want to do
a polar 2 [inaudible] conversion

00:36:11.826 --> 00:36:17.726 A:middle
you will need cosine for the
x-axis and sine for the y-axis.

00:36:19.956 --> 00:36:22.276 A:middle
Because we do it simultaneously,

00:36:22.506 --> 00:36:24.296 A:middle
there is only one
argument reduction.

00:36:24.856 --> 00:36:28.196 A:middle
You will have to do the argument
reduction twice to save time.

00:36:28.196 --> 00:36:31.366 A:middle
And what's even better is

00:36:31.366 --> 00:36:34.026 A:middle
that compiler recognize
we have sine cos,

00:36:34.546 --> 00:36:39.316 A:middle
so you will optimize your
code into calling sine cos,

00:36:39.776 --> 00:36:40.866 A:middle
without even knowing it.

00:36:41.716 --> 00:36:46.646 A:middle
Of course, if you want to call
sine cos yourself, you can.

00:36:47.356 --> 00:36:52.966 A:middle
We also added C11
support for CMPLX.

00:36:54.846 --> 00:36:57.576 A:middle
This macro is used to
define a complex number.

00:36:58.916 --> 00:37:01.176 A:middle
Without this, you're more likely

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

00:36:58.916 --> 00:37:01.176 A:middle
Without this, you're more likely

00:37:01.176 --> 00:37:05.716 A:middle
to do the real part
+ imaginary part x I.

00:37:06.696 --> 00:37:10.836 A:middle
But in that expression, there's
addition and a multiplication

00:37:10.836 --> 00:37:15.376 A:middle
in it, so sometimes you will
not get what you expect --

00:37:15.376 --> 00:37:19.116 A:middle
like this example:
0.0 + infinity x I.

00:37:20.876 --> 00:37:24.866 A:middle
Using CMPLX allows you
to specify the real part

00:37:24.866 --> 00:37:27.976 A:middle
and the imaginary part of
the complex number directly,

00:37:28.516 --> 00:37:30.466 A:middle
so you don't have to worry
about multiplication.

00:37:31.016 --> 00:37:37.786 A:middle
We also have CMPLXF and CMPLXL
for float and load level.

00:37:39.196 --> 00:37:41.766 A:middle
So that's the new
addition to libem.

00:37:42.896 --> 00:37:46.566 A:middle
Vmathlib is a SIMD
vector math library.

00:37:47.416 --> 00:37:51.406 A:middle
It is designed to take
a SIMD vector as input

00:37:51.486 --> 00:37:53.236 A:middle
and then return a SIMD vector.

00:37:54.926 --> 00:37:57.196 A:middle
Similar to libem,
it has a collection

00:37:57.196 --> 00:37:57.796 A:middle
of [inaudible] functions.

00:37:58.516 --> 00:38:04.436 A:middle
We prefix the function then
with a single V, so we have VX,

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

00:37:58.516 --> 00:38:04.436 A:middle
We prefix the function then
with a single V, so we have VX,

00:38:04.436 --> 00:38:06.986 A:middle
Vlog, Vsine, et cetera.

00:38:07.426 --> 00:38:11.146 A:middle
You want to use V method

00:38:11.146 --> 00:38:12.846 A:middle
when you're writing
your own vector code.

00:38:14.136 --> 00:38:18.626 A:middle
Accelerate Framework provide a
wide range of functionalities,

00:38:19.236 --> 00:38:21.766 A:middle
but sometimes you have
your own special algorithm

00:38:21.766 --> 00:38:24.176 A:middle
that you write, and
you want to be fast,

00:38:24.606 --> 00:38:25.746 A:middle
so you write in vector code.

00:38:26.176 --> 00:38:28.926 A:middle
What if you need
the, for example?

00:38:31.126 --> 00:38:35.436 A:middle
You could use libem and then
use a for loop to iterate

00:38:35.436 --> 00:38:39.116 A:middle
through each of your
element in the SIMD vector.

00:38:39.896 --> 00:38:43.566 A:middle
But obviously you're not
going to take full advantage

00:38:43.566 --> 00:38:49.346 A:middle
of the vector unit, so we
can replace it with Vmathlib.

00:38:51.796 --> 00:38:55.846 A:middle
Instead of including Math.H,
you include accelerator header,

00:38:55.846 --> 00:38:58.486 A:middle
accelerator.h. Instead of the

00:38:58.546 --> 00:39:02.326 A:middle
for loop you make one
function call to VsineF.

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

00:38:58.546 --> 00:39:02.326 A:middle
for loop you make one
function call to VsineF.

00:39:02.716 --> 00:39:04.156 A:middle
You will take your SIMD vector

00:39:04.156 --> 00:39:07.256 A:middle
and then return the
result SIMD vector.

00:39:07.846 --> 00:39:09.566 A:middle
But you can go on
with your vector code.

00:39:10.996 --> 00:39:14.506 A:middle
The code looks simpler,
cleaner, and it's also faster.

00:39:14.506 --> 00:39:16.656 A:middle
So it's VMathlib.

00:39:16.656 --> 00:39:20.986 A:middle
You use it when you write
your own vector code.

00:39:21.896 --> 00:39:23.656 A:middle
Next, vForce.

00:39:24.676 --> 00:39:27.116 A:middle
vForce is designed to
handle a lot of data,

00:39:27.816 --> 00:39:29.896 A:middle
called the vectorized
math library.

00:39:30.506 --> 00:39:34.076 A:middle
It works on arrays, so it
prefix the function then

00:39:34.076 --> 00:39:39.246 A:middle
with double Vs, VVX,
VVlog, VVSine, et cetera.

00:39:39.246 --> 00:39:44.486 A:middle
Let's say you want to write
a signal generator app

00:39:44.486 --> 00:39:47.166 A:middle
and you want to generate
a sine wave, for example.

00:39:47.736 --> 00:39:52.366 A:middle
You can do it with Libem,
again, write a for loop,

00:39:52.366 --> 00:39:54.336 A:middle
go through each element
in your buffer --

00:39:54.906 --> 00:39:58.636 A:middle
you could do better
by using vForce.

00:39:59.536 --> 00:40:00.036 A:middle
Here's how.

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

00:39:59.536 --> 00:40:00.036 A:middle
Here's how.

00:40:02.296 --> 00:40:04.036 A:middle
Instead of using a for loop,

00:40:04.706 --> 00:40:07.056 A:middle
you make one function
call to VV Sine F.

00:40:08.136 --> 00:40:10.996 A:middle
You're passing the upper
buffer, inner buffer,

00:40:10.996 --> 00:40:12.956 A:middle
and the pointer to the length.

00:40:14.476 --> 00:40:17.466 A:middle
The generator sine will be
ready in the upper buffer right

00:40:17.466 --> 00:40:18.636 A:middle
after this function call.

00:40:19.086 --> 00:40:22.666 A:middle
Again, the code looks
simpler, cleaner,

00:40:22.666 --> 00:40:26.196 A:middle
and most importantly, is faster.

00:40:27.376 --> 00:40:30.616 A:middle
Let's look at the performance
measured on the iPhone 5.

00:40:30.796 --> 00:40:36.406 A:middle
As you can see, vForce
is more than twice faster

00:40:36.626 --> 00:40:37.666 A:middle
than using a for loop.

00:40:38.546 --> 00:40:41.016 A:middle
Within the same amount of
time it can generate more

00:40:41.016 --> 00:40:44.126 A:middle
than twice the restful
than the for loop.

00:40:45.176 --> 00:40:46.196 A:middle
This is not it.

00:40:47.056 --> 00:40:49.726 A:middle
It also has great
energy performance.

00:40:50.616 --> 00:40:53.116 A:middle
It use lot less energy
than using a for loop.

00:40:53.696 --> 00:40:58.736 A:middle
It use about only
60% of the energy

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

00:41:00.016 --> 00:41:04.116 A:middle
when you use vForce
compared to a for loop.

00:41:05.576 --> 00:41:10.396 A:middle
So your app will last longer,
you will not drain the battery,

00:41:10.506 --> 00:41:15.116 A:middle
and we did not cherry
pick just VVSineF

00:41:15.116 --> 00:41:16.246 A:middle
to show you the performance.

00:41:16.686 --> 00:41:18.926 A:middle
There is performance
improvement across the board.

00:41:19.726 --> 00:41:21.756 A:middle
The graph doesn't even
fit into the screen.

00:41:22.146 --> 00:41:25.876 A:middle
For the Trunk F, vForce is
more than 5 times faster

00:41:25.876 --> 00:41:27.106 A:middle
than using a for loop.

00:41:27.546 --> 00:41:30.846 A:middle
For all other functions they
are at least twice faster

00:41:30.846 --> 00:41:32.446 A:middle
than using a for loop.

00:41:34.856 --> 00:41:36.916 A:middle
A few words about vForce.

00:41:36.916 --> 00:41:38.646 A:middle
vForce supports single

00:41:38.646 --> 00:41:40.436 A:middle
and double precision
floating point numbers.

00:41:40.436 --> 00:41:44.926 A:middle
It handle Edge cases currently,
so if you have infinities

00:41:44.926 --> 00:41:47.856 A:middle
or nins in your input, you
don't have to worry about them.

00:41:48.656 --> 00:41:51.156 A:middle
vForce will handle the
Edge cases correctly.

00:41:51.606 --> 00:41:55.476 A:middle
vForce require minimal
data alignment.

00:41:56.226 --> 00:41:58.156 A:middle
We only require native
data alignment

00:41:58.226 --> 00:42:01.646 A:middle
for a single precision floating
number that's 4 bytes aligned,

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

00:41:58.226 --> 00:42:01.646 A:middle
for a single precision floating
number that's 4 bytes aligned,

00:42:02.106 --> 00:42:04.656 A:middle
double precision floating point
number is 8 bytes aligned.

00:42:05.676 --> 00:42:08.506 A:middle
Supports in place
operation, so you don't have

00:42:08.506 --> 00:42:09.986 A:middle
to create a temporary buffer.

00:42:09.986 --> 00:42:11.796 A:middle
That minimize the
memory movement.

00:42:12.216 --> 00:42:16.146 A:middle
We get this question a lot.

00:42:16.406 --> 00:42:20.876 A:middle
Like Jeff mentioned before,
how much data is enough,

00:42:21.206 --> 00:42:25.826 A:middle
so using vForce or any other
server function is beneficial?

00:42:27.686 --> 00:42:32.056 A:middle
Well, for vForce, I can give
a rule of thumb; that is,

00:42:32.056 --> 00:42:36.306 A:middle
if you have more than 16
elements in your array,

00:42:36.306 --> 00:42:37.486 A:middle
consider using vForce.

00:42:38.126 --> 00:42:42.446 A:middle
Of course, the actual crossover
point may vary for each function

00:42:42.446 --> 00:42:46.046 A:middle
in vForce, but if you
have more than 16,

00:42:46.046 --> 00:42:49.006 A:middle
you're probably good to go.

00:42:49.006 --> 00:42:49.996 A:middle
So that's vForce.

00:42:49.996 --> 00:42:52.856 A:middle
I'm going to hand the
presentation back to Jeff.

00:42:52.856 --> 00:42:54.316 A:middle
He'll talk about linear algebra,

00:42:54.316 --> 00:42:56.186 A:middle
my favorite section
of the presentation.

00:42:57.516 --> 00:43:00.816 A:middle
[Applause]

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

00:42:57.516 --> 00:43:00.816 A:middle
[Applause]

00:43:01.316 --> 00:43:01.826 A:middle
>> Jeff: Thanks, Luke.

00:43:03.216 --> 00:43:06.546 A:middle
So for linear algebra we've got
the industry standard LAPACK

00:43:06.716 --> 00:43:08.126 A:middle
and BLAS libraries.

00:43:08.766 --> 00:43:10.846 A:middle
LAPACK is linear
algebra package,

00:43:11.636 --> 00:43:14.356 A:middle
and BLAS is basic linear
algebra subprograms.

00:43:15.266 --> 00:43:17.046 A:middle
Let's begin with LAPACK.

00:43:17.876 --> 00:43:21.066 A:middle
In LAPACK you'll find high level
linear algebra functionality.

00:43:22.206 --> 00:43:24.366 A:middle
This includes things
like solving systems

00:43:24.366 --> 00:43:28.086 A:middle
of linear equations, performing
matrix factorizations,

00:43:29.226 --> 00:43:31.946 A:middle
as well as computing eigen
values and eigen vectors.

00:43:32.426 --> 00:43:37.346 A:middle
One of the great ways to tell
how you're doing with LAPACK

00:43:37.346 --> 00:43:39.466 A:middle
and BLAS is to look at
the LINPACK benchmark.

00:43:40.486 --> 00:43:42.176 A:middle
So as I mentioned these
are industry standard.

00:43:42.176 --> 00:43:44.476 A:middle
They've been around a
long time, and people came

00:43:44.476 --> 00:43:46.556 A:middle
up with LINPACK benchmark
to see how they're doing.

00:43:48.586 --> 00:43:51.676 A:middle
LINPACK benchmark is essentially
answering the question,

00:43:51.676 --> 00:43:54.356 A:middle
how fast can you solve a
system of linear equations?

00:43:55.786 --> 00:43:57.956 A:middle
There's a couple variations
of the LINPACK benchmark.

00:43:58.736 --> 00:44:01.436 A:middle
The one that we're going to
look at here is using a matrix

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

00:43:58.736 --> 00:44:01.436 A:middle
The one that we're going to
look at here is using a matrix

00:44:01.436 --> 00:44:03.466 A:middle
of 1,000 x 1,000 elements.

00:44:03.846 --> 00:44:06.846 A:middle
Let's look at the performance.

00:44:07.386 --> 00:44:13.106 A:middle
So this is the LINPACK
performance of Brand A.

00:44:13.486 --> 00:44:15.646 A:middle
Two years ago we
did this comparison

00:44:15.726 --> 00:44:17.206 A:middle
and we compared Brand A.

00:44:17.846 --> 00:44:20.416 A:middle
We looked around at all
the published benchmarks

00:44:20.416 --> 00:44:23.216 A:middle
that we could find, and
they were at 40 megaflops.

00:44:23.736 --> 00:44:27.466 A:middle
In 2 years, there's
been a lot of time,

00:44:27.536 --> 00:44:31.176 A:middle
improvements have been
made, and that performance

00:44:31.176 --> 00:44:35.316 A:middle
for Brand A has come
up to 788 megaflops,

00:44:35.796 --> 00:44:39.236 A:middle
just under a gigaflop
-- pretty good.

00:44:39.236 --> 00:44:42.006 A:middle
Let's look at the performance

00:44:42.006 --> 00:44:44.606 A:middle
of the LINPACK benchmark using
the Accelerate Framework.

00:44:49.036 --> 00:44:52.856 A:middle
1200 megaflops --
this is 1.2 gigaflops.

00:44:53.516 --> 00:44:54.266 A:middle
This is pretty good.

00:44:55.506 --> 00:44:56.486 A:middle
There's just one thing.

00:44:57.926 --> 00:44:59.066 A:middle
We've had 2 years, too.

00:44:59.686 --> 00:45:04.376 A:middle
This is the performance
running on the iPhone 4S.

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

00:44:59.686 --> 00:45:04.376 A:middle
This is the performance
running on the iPhone 4S.

00:45:04.376 --> 00:45:07.216 A:middle
Let's look at the performance

00:45:07.216 --> 00:45:19.096 A:middle
of the Accelerate Framework
running on the iPhone 5.

00:45:19.096 --> 00:45:20.386 A:middle
It's quite a bit better.

00:45:21.756 --> 00:45:22.156 A:middle
Thank you.

00:45:25.076 --> 00:45:27.736 A:middle
Well, LINPACK benchmark using
the Accelerate Framework

00:45:27.736 --> 00:45:31.326 A:middle
on the iPhone 5 is
at 3,400 megaflops.

00:45:31.846 --> 00:45:33.896 A:middle
That's 3.4 gigaflops.

00:45:34.516 --> 00:45:36.736 A:middle
This is a phone that
fits in your pocket

00:45:36.776 --> 00:45:37.906 A:middle
and runs on a battery.

00:45:38.416 --> 00:45:39.626 A:middle
This is really impressive.

00:45:40.126 --> 00:45:44.306 A:middle
As I said, the LINPACK
benchmark's been

00:45:44.306 --> 00:45:47.436 A:middle
around for awhile, and so
we wanted to do a comparison

00:45:47.436 --> 00:45:48.766 A:middle
to an older machine for fun.

00:45:49.636 --> 00:45:51.396 A:middle
And so we're going
to compare the iPad

00:45:51.426 --> 00:45:54.156 A:middle
with the Retina display
to a Power Mac G5.

00:45:54.156 --> 00:45:58.856 A:middle
For those of you that have
been around for awhile,

00:45:58.856 --> 00:46:01.726 A:middle
you might remember some of the
bake-offs with the Power Mac G5,

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

00:45:58.856 --> 00:46:01.726 A:middle
you might remember some of the
bake-offs with the Power Mac G5,

00:46:02.326 --> 00:46:04.916 A:middle
so we're having a
triumphant return.

00:46:05.926 --> 00:46:07.426 A:middle
This is a 10-year old machine,

00:46:08.336 --> 00:46:10.666 A:middle
and if any of you remember
this machine, it's returning

00:46:10.666 --> 00:46:11.996 A:middle
with all fans blazing.

00:46:12.636 --> 00:46:15.176 A:middle
I think there's 7 case
fans, when you turn it

00:46:15.176 --> 00:46:17.156 A:middle
on you know it's in the room.

00:46:17.626 --> 00:46:20.166 A:middle
When you run LINPACK benchmark,
sounds like you're driving

00:46:20.166 --> 00:46:21.826 A:middle
down the highway with
your head out the window.

00:46:22.026 --> 00:46:25.046 A:middle
Let's look at the performance.

00:46:27.166 --> 00:46:33.116 A:middle
LINPACK benchmark on Power
Mac G5 is 3,643 megaflops.

00:46:34.406 --> 00:46:36.106 A:middle
Let's see how the iPad compares.

00:46:38.606 --> 00:46:42.806 A:middle
Just edges it out at
3,686 megaflops --

00:46:43.316 --> 00:46:45.446 A:middle
pretty impressive
for a little tablet.

00:46:48.116 --> 00:46:48.816 A:middle
Thank you.

00:46:53.306 --> 00:46:56.156 A:middle
Let's look at an example
of how to use a LAPACK.

00:46:56.656 --> 00:46:58.236 A:middle
As always, we'll begin

00:46:58.236 --> 00:47:00.466 A:middle
by including the
Accelerate Framework header,

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

00:46:58.236 --> 00:47:00.466 A:middle
by including the
Accelerate Framework header,

00:47:00.466 --> 00:47:03.886 A:middle
and then we're going to
create and prepare our data,

00:47:04.426 --> 00:47:07.676 A:middle
so we'll create 2 major Cs, A
and B, which describe our system

00:47:07.676 --> 00:47:08.446 A:middle
that we want to solve.

00:47:09.886 --> 00:47:13.216 A:middle
In this case, we're going to
use a system solve that's going

00:47:13.216 --> 00:47:16.446 A:middle
to perform pivoting, so we need
a vector to contain information

00:47:16.446 --> 00:47:17.956 A:middle
about the pivots that
we're going to perform,

00:47:18.856 --> 00:47:22.286 A:middle
and then we're going to
perform this all with DGESV.

00:47:23.536 --> 00:47:25.146 A:middle
There's a couple things
I want to point out.

00:47:25.956 --> 00:47:28.556 A:middle
So as I mentioned, the
LAPAC is industry standard,

00:47:28.556 --> 00:47:30.736 A:middle
it's been around for awhile.

00:47:30.996 --> 00:47:33.056 A:middle
It's originally written
in FORTRAN and maintained

00:47:33.056 --> 00:47:35.546 A:middle
in FORTRAN, so the entry
points look like this.

00:47:35.546 --> 00:47:38.496 A:middle
It's going to be DGSB
followed by an underbar.

00:47:39.506 --> 00:47:41.636 A:middle
It also means that all the
values are going to be passed

00:47:41.636 --> 00:47:44.156 A:middle
by reference, must
something to be aware of.

00:47:44.156 --> 00:47:47.086 A:middle
It's pretty easy to get
tripped up with this.

00:47:47.296 --> 00:47:50.916 A:middle
But to perform the system solve,
we simply pass in the size

00:47:50.916 --> 00:47:53.976 A:middle
of the matrix in N, the
number of right-hand sides

00:47:53.976 --> 00:47:55.906 A:middle
which is the number of systems
that we're going to solve,

00:47:57.156 --> 00:47:59.446 A:middle
the matrix, the leading
dimension of the matrix,

00:47:59.946 --> 00:48:03.046 A:middle
and then the pivot
vector that we created,

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

00:47:59.946 --> 00:48:03.046 A:middle
and then the pivot
vector that we created,

00:48:03.956 --> 00:48:05.446 A:middle
and that right-hand sides B.

00:48:06.616 --> 00:48:10.206 A:middle
Info will capture any errors
that happen in this operation.

00:48:10.746 --> 00:48:12.346 A:middle
It's pretty easy
to solve a system

00:48:12.346 --> 00:48:16.816 A:middle
with linear equations
with a LAPACK.

00:48:17.036 --> 00:48:18.066 A:middle
Next is BLAS.

00:48:18.376 --> 00:48:23.186 A:middle
So a LAPACK is the higher level
linear algebra operations.

00:48:23.266 --> 00:48:24.986 A:middle
It's built heavily on BLAS,

00:48:25.016 --> 00:48:27.046 A:middle
the lower level linear
algebra operations.

00:48:27.806 --> 00:48:30.186 A:middle
All of BLAS is available through
the Accelerate Framework.

00:48:31.216 --> 00:48:34.216 A:middle
It's typically broken down
into three categories:

00:48:34.666 --> 00:48:38.396 A:middle
vector operations -- this is
DOT product, scalar product,

00:48:38.396 --> 00:48:41.796 A:middle
vector sums, matrix
vector operations,

00:48:41.996 --> 00:48:44.986 A:middle
matrix vector product,
outer product,

00:48:45.516 --> 00:48:49.236 A:middle
and matrix/matrix operations,
like matrix multiply.

00:48:49.906 --> 00:48:53.766 A:middle
Let's look at an example
of how to use BLAS

00:48:53.766 --> 00:48:54.826 A:middle
in the Accelerate Framework.

00:48:55.336 --> 00:48:59.016 A:middle
We'll begin by including the
Accelerate Framework header.

00:48:59.876 --> 00:49:02.296 A:middle
As always we'll create
and prepare our data,

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

00:48:59.876 --> 00:49:02.296 A:middle
As always we'll create
and prepare our data,

00:49:02.336 --> 00:49:04.766 A:middle
so we'll align these
buffers if we can.

00:49:05.296 --> 00:49:09.786 A:middle
In this case we have 2
operands matrices A and B,

00:49:09.786 --> 00:49:11.376 A:middle
and the result matrix C.

00:49:15.516 --> 00:49:20.636 A:middle
And then we're going to
call into C BLAS DGEM.

00:49:20.636 --> 00:49:22.846 A:middle
BLAS supports both
row and call major,

00:49:22.846 --> 00:49:24.906 A:middle
so the first argument is
going to be to specify

00:49:24.906 --> 00:49:26.206 A:middle
if we're a row or call major.

00:49:27.236 --> 00:49:30.756 A:middle
The next 2 arguments specify if
we want to perform a transpose

00:49:30.756 --> 00:49:32.216 A:middle
on the 2 operand matrices.

00:49:32.736 --> 00:49:36.166 A:middle
It's important with BLAS
and a LAPACK to understand

00:49:36.166 --> 00:49:38.676 A:middle
that these transposes
don't actually happen;

00:49:39.046 --> 00:49:40.686 A:middle
the operation is
organized as such

00:49:40.716 --> 00:49:43.836 A:middle
that they are implied
as transposes.

00:49:45.016 --> 00:49:48.376 A:middle
And then the last
several parameters

00:49:48.376 --> 00:49:50.376 A:middle
for this argument are
information about the size

00:49:50.376 --> 00:49:52.306 A:middle
of the matrix, the
matrices themselves,

00:49:52.306 --> 00:49:56.216 A:middle
their leading dimensions,
and any scalar values

00:49:56.216 --> 00:49:58.666 A:middle
which will scale the
operands or a result matrix.

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

00:50:02.876 --> 00:50:06.006 A:middle
Just to cover some of the data
types and details supported

00:50:06.006 --> 00:50:08.756 A:middle
by both BLAS and LAPACK,
they both support single

00:50:08.756 --> 00:50:13.226 A:middle
and double precision values,
both real and complex,

00:50:13.766 --> 00:50:18.016 A:middle
and multiple data
formats for your matrices,

00:50:18.016 --> 00:50:21.726 A:middle
so dense matrices, band in
matrices, triangular matrices.

00:50:21.726 --> 00:50:26.226 A:middle
As we saw before, transposes as
well as conjugate transposes --

00:50:26.446 --> 00:50:30.526 A:middle
and again, these
disappear in the operation.

00:50:30.526 --> 00:50:32.126 A:middle
They aren't explicit transposes.

00:50:33.086 --> 00:50:35.216 A:middle
And then finally,
BLAS supports both row

00:50:35.216 --> 00:50:38.766 A:middle
and column major while LAPACK
only supports column major.

00:50:41.596 --> 00:50:43.286 A:middle
Another tweet I wanted
to share with you,

00:50:43.286 --> 00:50:46.006 A:middle
playing with the Accelerate
Framework today, having BLAST.

00:50:48.736 --> 00:50:52.666 A:middle
So in summary, there's
a lot of functionality

00:50:52.666 --> 00:50:53.716 A:middle
in the Accelerate Framework.

00:50:54.476 --> 00:50:56.596 A:middle
You'll find image
processing in vImage,

00:50:57.796 --> 00:51:01.526 A:middle
digital signal processing
in vDSP,

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

00:50:57.796 --> 00:51:01.526 A:middle
digital signal processing
in vDSP,

00:51:01.526 --> 00:51:04.876 A:middle
transcendental math functions
in vForce and vMathLib

00:51:05.886 --> 00:51:08.626 A:middle
and linear algebra,
LAPACK and BLAS.

00:51:09.126 --> 00:51:13.066 A:middle
When you think Accelerate
Framework, think easy access

00:51:13.066 --> 00:51:16.016 A:middle
to all this functionality,
over 2,000 APIs.

00:51:16.806 --> 00:51:19.556 A:middle
Accurate, we tested so
that you don't have to.

00:51:19.556 --> 00:51:22.686 A:middle
You're going to get
great performance

00:51:22.966 --> 00:51:24.166 A:middle
with low energy usage.

00:51:24.166 --> 00:51:30.146 A:middle
It's going to work great on OS X
and iOS, and it's going to work

00:51:30.146 --> 00:51:32.076 A:middle
on the complete Apple
hardware lineup,

00:51:32.726 --> 00:51:35.486 A:middle
everything that's available now
and everything that's to come.

00:51:36.016 --> 00:51:40.616 A:middle
Just a recap of the
tips to be successful

00:51:40.616 --> 00:51:41.746 A:middle
with the Accelerate Framework.

00:51:42.516 --> 00:51:43.756 A:middle
When you're preparing your data,

00:51:43.876 --> 00:51:45.926 A:middle
if you can make the
buffers contiguous

00:51:46.186 --> 00:51:48.006 A:middle
and you can align the
beginning of those buffers

00:51:48.006 --> 00:51:50.116 A:middle
to a 16-byte boundary, we can

00:51:50.116 --> 00:51:52.466 A:middle
in some cases get you
slightly more performance.

00:51:53.136 --> 00:51:55.306 A:middle
Again, Accelerate
Framework is always going

00:51:55.306 --> 00:51:57.136 A:middle
to give you the best
performance possible

00:51:57.136 --> 00:51:58.806 A:middle
when you can't meet
these recommendations.

00:51:59.706 --> 00:52:01.246 A:middle
Understand the problem size.

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

00:51:59.706 --> 00:52:01.246 A:middle
Understand the problem size.

00:52:01.846 --> 00:52:04.436 A:middle
For small problem sets,

00:52:04.436 --> 00:52:06.146 A:middle
the Accelerate Framework
might not be able

00:52:06.146 --> 00:52:07.756 A:middle
to deliver the best performance.

00:52:08.086 --> 00:52:11.106 A:middle
It's always going to deliver
the functionality, though.

00:52:11.966 --> 00:52:13.866 A:middle
Finally, do set up
and destroy once.

00:52:14.016 --> 00:52:17.436 A:middle
If you find yourself
creating a setup structure,

00:52:17.466 --> 00:52:19.836 A:middle
use that setup structure
as many times as possible.

00:52:20.476 --> 00:52:25.536 A:middle
The Accelerate Framework is
for you guys, and so I want

00:52:25.536 --> 00:52:26.186 A:middle
to leave you with this.

00:52:26.186 --> 00:52:28.776 A:middle
If you need a feature,
please request it.

00:52:29.236 --> 00:52:33.196 A:middle
The best way to do that
is by filing a bug.

00:52:33.416 --> 00:52:34.626 A:middle
And one more tweet:

00:52:34.936 --> 00:52:37.656 A:middle
"The discrete cosine transform
was my feature request

00:52:37.656 --> 00:52:39.226 A:middle
that made it into the
Accelerate Framework.

00:52:39.276 --> 00:52:40.276 A:middle
I feel so special."

00:52:41.006 --> 00:52:42.236 A:middle
So we do listen.

00:52:43.016 --> 00:52:43.686 A:middle
Please request.

00:52:44.256 --> 00:52:46.176 A:middle
And then lastly, thanks, Apple,

00:52:46.176 --> 00:52:47.586 A:middle
for making the Accelerate
Framework.

00:52:48.096 --> 00:52:49.866 A:middle
Thank you, guys, for
making it a success.

00:52:50.516 --> 00:52:54.996 A:middle
[Applause]

00:52:55.496 --> 00:52:58.146 A:middle
Just a little more information
here, if you guys need to get

00:52:58.146 --> 00:53:00.736 A:middle
in touch with us,
contact Paul or George.

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

00:52:58.146 --> 00:53:00.736 A:middle
in touch with us,
contact Paul or George.

00:53:01.116 --> 00:53:04.446 A:middle
There's some documentation
available online, and as always,

00:53:04.476 --> 00:53:06.186 A:middle
check the Apple developer
forums.

00:53:06.806 --> 00:53:08.756 A:middle
That's all we got,
thank you, guys.

00:53:10.516 --> 00:53:18.270 A:middle
[Silence]