708.srt

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

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

00:00:10.116 --> 00:00:10.936 A:middle
>> Good afternoon.

00:00:11.176 --> 00:00:13.096 A:middle
Welcome to the Accelerate
Framework Session.

00:00:13.796 --> 00:00:14.916 A:middle
My name's Geoff Belter.

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

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

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

00:00:24.736 --> 00:00:27.006 A:middle
and that application
has a computationally

00:00:27.006 --> 00:00:28.036 A:middle
intensive component.

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

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

00:00:34.746 --> 00:00:37.986 A:middle
you test it, and you
find that it's too slow,

00:00:39.146 --> 00:00:40.586 A:middle
or maybe it's a battery drain.

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

00:00:44.596 --> 00:00:47.456 A:middle
or maybe days, profiling
and optimizing that code

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

00:00:51.866 --> 00:00:53.036 A:middle
We don't think that's right.

00:00:54.096 --> 00:00:55.766 A:middle
The goal of the Accelerate
Framework is

00:00:55.806 --> 00:00:57.046 A:middle
to solve this problem.

00:00:58.576 --> 00:01:01.186 A:middle
The Accelerate Framework is
a collection of functions

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

00:00:58.576 --> 00:01:01.186 A:middle
The Accelerate Framework is
a collection of functions

00:01:01.186 --> 00:01:04.346 A:middle
of commonly used computationally
intensive operations.

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

00:01:08.776 --> 00:01:12.436 A:middle
and deliver great
energy savings for all

00:01:12.436 --> 00:01:14.036 A:middle
of the APIs that are available.

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

00:01:17.306 --> 00:01:20.196 A:middle
to get great performance and
amazing energy characteristics

00:01:20.196 --> 00:01:22.646 A:middle
from the smallest
iPhone all the way

00:01:22.646 --> 00:01:24.226 A:middle
up through the biggest Mac Pro

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

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

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

00:01:35.776 --> 00:01:37.646 A:middle
So what is the Accelerate
Framework?

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

00:01:41.216 --> 00:01:42.176 A:middle
that I want you to remember.

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

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

00:01:48.706 --> 00:01:49.786 A:middle
in the Accelerate Framework.

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

00:01:52.966 --> 00:01:54.946 A:middle
down into four easy-to-remember
categories

00:01:54.946 --> 00:01:57.046 A:middle
and show you what
exactly is available.

00:01:58.396 --> 00:01:59.666 A:middle
Think accurate.

00:01:59.976 --> 00:02:03.336 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:59.976 --> 00:02:03.336 A:middle
We spent a lot of time testing
so that you don't have to.

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

00:02:07.716 --> 00:02:10.846 A:middle
You guys really push the limits
of the hardware available today

00:02:10.846 --> 00:02:12.186 A:middle
with your great applications.

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

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

00:02:16.426 --> 00:02:18.576 A:middle
with amazing energy
characteristics.

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

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

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

00:02:30.966 --> 00:02:35.746 A:middle
to have to revisit your code.

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

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

00:02:41.296 --> 00:02:42.916 A:middle
computationally intensive
operations,

00:02:42.916 --> 00:02:44.586 A:middle
but what exactly is available?

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

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

00:02:53.606 --> 00:02:57.856 A:middle
we've got digital signal
processing with vDSP,

00:02:58.046 --> 00:03:01.626 A:middle
transcendental math functions
with vForce and vMathLib,

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

00:02:58.046 --> 00:03:01.626 A:middle
transcendental math functions
with vForce and vMathLib,

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

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

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

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

00:03:16.336 --> 00:03:18.216 A:middle
you create a really
great application.

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

00:03:21.346 --> 00:03:23.406 A:middle
of real world performance
and energy savings

00:03:23.406 --> 00:03:25.096 A:middle
that you can expect
when you utilize the

00:03:25.096 --> 00:03:25.936 A:middle
Accelerate Framework.

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

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

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

00:03:38.056 --> 00:03:39.876 A:middle
So this is going to
range from linking

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

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

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

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

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

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

00:03:58.366 --> 00:04:03.446 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.366 --> 00:04:03.446 A:middle
One of the big reasons the
Accelerate Framework is fast is

00:04:03.446 --> 00:04:05.246 A:middle
we utilize SIMD instructions.

00:04:06.646 --> 00:04:08.726 A:middle
This is Single Instruction
Multiple Data.

00:04:08.726 --> 00:04:12.616 A:middle
For those of you who are
unfamiliar, if we're trying to,

00:04:12.776 --> 00:04:15.926 A:middle
for example, add 2 arrays
together, there are instructions

00:04:15.926 --> 00:04:17.286 A:middle
on current hardware
that allow us

00:04:17.286 --> 00:04:19.326 A:middle
to add multiple elements
simultaneously.

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

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

00:04:25.866 --> 00:04:28.806 A:middle
of SSE, AVX, and now AVX2.

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

00:04:34.436 --> 00:04:35.886 A:middle
Utilizing SIMD instructions

00:04:35.886 --> 00:04:38.226 A:middle
in certain situations can
have significant energy

00:04:38.226 --> 00:04:39.416 A:middle
and performance savings.

00:04:40.676 --> 00:04:45.566 A:middle
We also spend a lot of time
matching the micro-architecture

00:04:45.786 --> 00:04:47.566 A:middle
for the complete
Apple hardware lineup.

00:04:48.456 --> 00:04:51.316 A:middle
This includes optimizations
like instruction selection

00:04:51.316 --> 00:04:52.516 A:middle
and instruction scheduling,

00:04:52.516 --> 00:04:56.086 A:middle
as well as software
pipelining and loop unrolling.

00:04:57.586 --> 00:05:00.326 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.586 --> 00:05:00.326 A:middle
So I bring these up because
it requires a certain amount

00:05:00.326 --> 00:05:01.736 A:middle
of data before optimizations

00:05:01.736 --> 00:05:03.466 A:middle
like loop unrolling
become beneficial,

00:05:03.986 --> 00:05:05.176 A:middle
so it helps to understand

00:05:05.416 --> 00:05:07.626 A:middle
that this is something
happening behind the scenes

00:05:07.626 --> 00:05:08.646 A:middle
in the Accelerate Framework.

00:05:09.196 --> 00:05:12.806 A:middle
The last reason the
Accelerate Framework is fast is

00:05:12.806 --> 00:05:15.396 A:middle
because it's multithreaded
using GCD.

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

00:05:18.166 --> 00:05:19.486 A:middle
of all the cores available.

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

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

00:05:28.536 --> 00:05:30.126 A:middle
of the tips for successful use

00:05:30.126 --> 00:05:31.646 A:middle
of the Accelerate
Framework come from.

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

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

00:05:38.486 --> 00:05:39.526 A:middle
that I want you to remember.

00:05:40.486 --> 00:05:42.826 A:middle
The first is to make
your data contiguous.

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

00:05:45.826 --> 00:05:46.796 A:middle
you want to make that array

00:05:46.796 --> 00:05:48.636 A:middle
such that the elements
are contiguous.

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

00:05:52.536 --> 00:05:55.196 A:middle
of that buffer in memory, if
you can align the beginning

00:05:55.196 --> 00:05:57.146 A:middle
of that buffer to
a 16-byte boundary,

00:05:57.146 --> 00:05:58.276 A:middle
that's going to be ideal.

00:05:58.866 --> 00:06:01.986 A:middle
With the Accelerate
Framework we always strive

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

00:05:58.866 --> 00:06:01.986 A:middle
With the Accelerate
Framework we always strive

00:06:01.986 --> 00:06:03.466 A:middle
to deliver the greatest
performance,

00:06:03.496 --> 00:06:05.676 A:middle
but if you can meet
these recommendations,

00:06:06.306 --> 00:06:09.176 A:middle
in certain situations we
can algorithmically exploit

00:06:09.176 --> 00:06:11.286 A:middle
that to give you
slightly more performance.

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

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

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

00:06:26.286 --> 00:06:27.906 A:middle
On the previous slide
we also saw

00:06:27.906 --> 00:06:29.746 A:middle
that in certain situations
optimizations

00:06:29.746 --> 00:06:31.516 A:middle
like loop unrolling are used.

00:06:32.046 --> 00:06:34.666 A:middle
What this means for you is

00:06:34.666 --> 00:06:37.526 A:middle
that when you're
using really small --

00:06:37.526 --> 00:06:38.986 A:middle
when you're using the
Accelerate Framework

00:06:38.986 --> 00:06:40.376 A:middle
with really small datasets,

00:06:40.876 --> 00:06:43.296 A:middle
it may not deliver
the best performance.

00:06:44.676 --> 00:06:45.786 A:middle
There's not a problem size

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

00:06:47.836 --> 00:06:50.036 A:middle
for something that's this
small; it's going to depend

00:06:50.036 --> 00:06:51.466 A:middle
on the operation
you're performing.

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

00:06:54.986 --> 00:06:56.986 A:middle
of 100 elements; whereas

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

00:06:59.356 --> 00:07:02.896 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.356 --> 00:07:02.896 A:middle
Matrix Multiply, it could
be as small as 8 elements.

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

00:07:07.186 --> 00:07:08.736 A:middle
The Accelerate Framework
is always going

00:07:08.736 --> 00:07:10.266 A:middle
to deliver the great
functionality,

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

00:07:13.136 --> 00:07:14.056 A:middle
best performance.

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

00:07:20.666 --> 00:07:22.016 A:middle
and destroy once at the end.

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

00:07:25.446 --> 00:07:26.966 A:middle
that require a setup structure.

00:07:28.176 --> 00:07:30.166 A:middle
Creating this setup
structure can be costly

00:07:30.166 --> 00:07:31.046 A:middle
and time-consuming.

00:07:31.646 --> 00:07:34.546 A:middle
These setup structures
are designed

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

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

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

00:07:45.386 --> 00:07:47.686 A:middle
and then destroy
once at the end.

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

00:07:51.206 --> 00:07:52.476 A:middle
and it will become more clear.

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

00:07:58.446 --> 00:08:00.856 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.446 --> 00:08:00.856 A:middle
For those of you brand new
to the Accelerate Framework,

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

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

00:08:09.016 --> 00:08:10.776 A:middle
to navigate to the build phases.

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

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

00:08:16.126 --> 00:08:17.176 A:middle
to find the Plus button.

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

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

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

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

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

00:08:33.996 --> 00:08:35.635 A:middle
up in this link with
library section.

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

00:08:40.486 --> 00:08:41.525 A:middle
to include the headers.

00:08:42.025 --> 00:08:48.906 A:middle
This is Accelerate/Accelerate.h.
That's all it takes

00:08:48.906 --> 00:08:50.416 A:middle
to use the Accelerate Framework.

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

00:08:53.916 --> 00:08:57.416 A:middle
In your link step simply
include -framework Accelerate.

00:08:57.416 --> 00:09:03.326 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.416 --> 00:09:03.326 A:middle
So now I want to dive into the
details of what's available

00:09:03.326 --> 00:09:04.376 A:middle
in the Accelerate Framework.

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

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

00:09:10.126 --> 00:09:11.426 A:middle
to step through these now.

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

00:09:16.416 --> 00:09:18.486 A:middle
For image processing
we have vImage,

00:09:18.816 --> 00:09:21.016 A:middle
our vectorized image
processing library.

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

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

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

00:09:31.326 --> 00:09:33.976 A:middle
We've got alpha blending

00:09:33.976 --> 00:09:38.046 A:middle
and alpha compositing,
dilation, erosion.

00:09:38.886 --> 00:09:41.776 A:middle
You can create Sobel filters
to perform edge detection,

00:09:42.896 --> 00:09:46.986 A:middle
various types of convolutions
to perform blur, deblur,

00:09:47.516 --> 00:09:52.966 A:middle
or multi-kernel convolves,
max filters, min filters,

00:09:54.486 --> 00:09:59.716 A:middle
color transformations,
warps and shears.

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

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

00:10:05.116 --> 00:10:09.406 A:middle
We also have some great
additions and improvements

00:10:09.836 --> 00:10:13.186 A:middle
in both iOS 7 and OS X.

00:10:14.036 --> 00:10:16.276 A:middle
First we have improved
conversion support.

00:10:17.466 --> 00:10:20.536 A:middle
Conversions are operations
like converting between planar

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

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

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

00:10:33.836 --> 00:10:36.786 A:middle
We also introduced vImage
buffer creation utilities,

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

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

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

00:10:46.316 --> 00:10:48.326 A:middle
of the guesswork out
of that for vImage,

00:10:49.126 --> 00:10:50.456 A:middle
we introduced the utilities

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

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

00:10:58.706 --> 00:11:00.616 A:middle
to deliver the maximum
performance.

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

00:10:58.706 --> 00:11:00.616 A:middle
to deliver the maximum
performance.

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

00:11:08.316 --> 00:11:11.416 A:middle
so all the operations like warp
and shear that are available

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

00:11:14.556 --> 00:11:16.536 A:middle
for 16-bit image
formats as well.

00:11:17.076 --> 00:11:23.286 A:middle
The last addition is streamlined
Core Graphics interoperability.

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

00:11:26.546 --> 00:11:27.876 A:middle
of this with an example.

00:11:27.976 --> 00:11:31.686 A:middle
So we get the question a lot.

00:11:31.686 --> 00:11:34.316 A:middle
How do I use vImage
with my CGImageRef?

00:11:34.836 --> 00:11:38.346 A:middle
To solve this problem
we introduced two new

00:11:38.346 --> 00:11:39.606 A:middle
utility functions.

00:11:40.186 --> 00:11:43.776 A:middle
To go from CGImageRef
to vImage-Buffer,

00:11:43.776 --> 00:11:47.486 A:middle
we introduced a utility function
vImageBuffer-InitWithCGImage

00:11:48.536 --> 00:11:50.236 A:middle
and for the reverse direction,

00:11:50.236 --> 00:11:53.276 A:middle
we introduced
vImageCreateCGImageFromBuffer.

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

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

00:11:59.816 --> 00:12:03.726 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.816 --> 00:12:03.726 A:middle
So here we're going
to look at how to go

00:12:03.726 --> 00:12:06.716 A:middle
from a CGImageRef
to a vImage-Buffer.

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

00:12:09.716 --> 00:12:11.646 A:middle
by including the
Accelerate Framework header

00:12:12.206 --> 00:12:16.186 A:middle
and then we're going to
create and open a CGImageRef.

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

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

00:12:22.206 --> 00:12:26.266 A:middle
but assume after this line that
we have our CGImageRef open.

00:12:26.266 --> 00:12:28.706 A:middle
The first step that we're going

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

00:12:31.686 --> 00:12:36.066 A:middle
This image format describes
the format of the vImage-Buffer

00:12:36.066 --> 00:12:37.706 A:middle
that we want to create.

00:12:38.596 --> 00:12:42.226 A:middle
We've introduced the
vImage-CGImageFormat structure.

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

00:12:45.996 --> 00:12:49.326 A:middle
bits-per-component,
bits-per-pixel,

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

00:12:56.866 --> 00:13:00.646 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.866 --> 00:13:00.646 A:middle
This descriptor is
describing an ARGB 8-bit image.

00:13:01.986 --> 00:13:03.886 A:middle
We see that the first entry

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

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

00:13:11.046 --> 00:13:12.786 A:middle
The bits-per-pixel is 32,

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

00:13:15.026 --> 00:13:18.376 A:middle
For color space, we pass null.

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

00:13:20.576 --> 00:13:22.746 A:middle
to get a default
RBG color space,

00:13:22.896 --> 00:13:24.836 A:middle
so we have 3 color components.

00:13:25.756 --> 00:13:29.996 A:middle
And then in the bitmap info,
we have kCGImageAlphaFirst.

00:13:30.436 --> 00:13:32.476 A:middle
This means we have a
single alpha component

00:13:32.776 --> 00:13:33.956 A:middle
and it's the first component.

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

00:13:37.916 --> 00:13:41.216 A:middle
With this format we're going

00:13:41.216 --> 00:13:43.906 A:middle
to call
vImageBufferInitWithCGImage.

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

00:13:48.376 --> 00:13:50.696 A:middle
to create from our CGImageRef.

00:13:51.956 --> 00:13:53.616 A:middle
The second argument
is the reference

00:13:53.616 --> 00:13:55.806 A:middle
to that format description
that we just created.

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

00:13:59.696 --> 00:14:01.776 A:middle
This is information
about background color.

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

00:13:59.696 --> 00:14:01.776 A:middle
This is information
about background color.

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

00:14:05.986 --> 00:14:08.036 A:middle
it may be necessary
to provide information

00:14:08.036 --> 00:14:09.046 A:middle
about a background color.

00:14:09.576 --> 00:14:15.756 A:middle
The next argument is inImage,
this is our CGImageRef

00:14:15.756 --> 00:14:17.716 A:middle
that we want to convert
to the vImage-Buffer,

00:14:18.506 --> 00:14:20.266 A:middle
and finally any additional
flags.

00:14:20.406 --> 00:14:24.286 A:middle
In this case we don't have
any so we pass kvImageNoFlags.

00:14:27.036 --> 00:14:30.116 A:middle
Upon successful return
of this function,

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

00:14:32.726 --> 00:14:37.096 A:middle
It contains the image
in the image format

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

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

00:14:44.796 --> 00:14:46.736 A:middle
The reverse is just as easy,

00:14:46.736 --> 00:14:49.386 A:middle
going from a vImage-Buffer
to a CGImageRef.

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

00:14:53.676 --> 00:14:56.116 A:middle
and we have our vImageBuffer
outBuffer.

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

00:14:58.576 --> 00:15:01.746 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.576 --> 00:15:01.746 A:middle
to use our same format specifier
that we created before.

00:15:01.826 --> 00:15:05.566 A:middle
To create the CGImageRef
we're going

00:15:05.566 --> 00:15:09.526 A:middle
to call
vImageCreateCGImageFromBuffer.

00:15:12.016 --> 00:15:16.076 A:middle
The first argument is going
to be the output vImage-Buffer

00:15:16.076 --> 00:15:19.056 A:middle
that we just finished
processing, next,

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

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

00:15:28.036 --> 00:15:30.116 A:middle
user callback functions
and user data.

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

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

00:15:35.566 --> 00:15:38.776 A:middle
And then we pass any
additional flags.

00:15:38.776 --> 00:15:43.526 A:middle
Again, in this case there are
none, so we pass kvImageNoFlags.

00:15:44.696 --> 00:15:47.116 A:middle
And then finally a
reference to a vImage-Error

00:15:47.506 --> 00:15:50.686 A:middle
to capture the error state.

00:15:50.866 --> 00:15:52.946 A:middle
Upon successful return
of this function,

00:15:53.246 --> 00:15:56.136 A:middle
we're going to return
the CGImageRef,

00:15:56.546 --> 00:15:57.726 A:middle
outImage in this case.

00:15:58.606 --> 00:16:03.406 A:middle
This is going to be a freshly
allocated CGImageRef containing

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

00:15:58.606 --> 00:16:03.406 A:middle
This is going to be a freshly
allocated CGImageRef containing

00:16:03.556 --> 00:16:07.326 A:middle
the image information,
and we are free

00:16:07.326 --> 00:16:08.866 A:middle
to release the vImage-Buffer.

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

00:16:15.196 --> 00:16:20.276 A:middle
that we're introducing now
called vImageConvert-AnyToAny.

00:16:20.946 --> 00:16:25.526 A:middle
What vImageConvert-AnyToAny
does is it converts

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

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

00:16:34.576 --> 00:16:35.996 A:middle
and one for the destination
type,

00:16:36.056 --> 00:16:37.906 A:middle
and you'll create a converter.

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

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

00:16:44.326 --> 00:16:46.266 A:middle
to that destination type.

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

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

00:16:53.656 --> 00:16:58.586 A:middle
The vImageConvert-AnyToAny
is really fast,

00:16:59.406 --> 00:17:01.286 A:middle
and I want to show
you an example of this

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

00:16:59.406 --> 00:17:01.286 A:middle
and I want to show
you an example of this

00:17:01.286 --> 00:17:02.656 A:middle
with a real world application.

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

00:17:09.175 --> 00:17:10.476 A:middle
running on the iPhone 5.

00:17:11.066 --> 00:17:13.705 A:middle
What I have here is a graph.

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

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

00:17:18.945 --> 00:17:20.366 A:middle
that software jpeg encode.

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

00:17:24.665 --> 00:17:26.306 A:middle
For the sake of this example,

00:17:26.306 --> 00:17:28.476 A:middle
think of this software
jpeg encode

00:17:28.526 --> 00:17:30.106 A:middle
as happening in two steps.

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

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

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

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

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

00:17:49.156 --> 00:17:50.666 A:middle
from the input image format type

00:17:51.106 --> 00:17:53.496 A:middle
to the format type
consumed by the encode.

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

00:17:57.596 --> 00:18:01.856 A:middle
We see a few things here.

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

00:17:57.596 --> 00:18:01.856 A:middle
We see a few things here.

00:18:02.316 --> 00:18:04.056 A:middle
First we see a lot
of variability.

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

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

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

00:18:16.116 --> 00:18:19.226 A:middle
The reason that this
is happening is

00:18:19.266 --> 00:18:21.346 A:middle
because step one is so variable.

00:18:22.746 --> 00:18:25.416 A:middle
So what we want to do
is change just step one.

00:18:25.606 --> 00:18:28.506 A:middle
We replaced step one now
with vImageConvert-AnyToAny,

00:18:28.586 --> 00:18:31.266 A:middle
and now let's look
at the performance.

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

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

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

00:18:50.406 --> 00:18:52.376 A:middle
than our floating
point RGBA image.

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

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

00:18:58.496 --> 00:19:01.186 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.496 --> 00:19:01.186 A:middle
converting from the input image
format to the other format,

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

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

00:19:09.906 --> 00:19:11.596 A:middle
This is a real world
application.

00:19:12.666 --> 00:19:14.806 A:middle
vImage is delivering
great performance

00:19:14.936 --> 00:19:16.306 A:middle
and consistent results.

00:19:16.306 --> 00:19:20.986 A:middle
I want to stay on the
topic of conversions

00:19:20.986 --> 00:19:21.956 A:middle
for a little bit longer.

00:19:22.746 --> 00:19:25.366 A:middle
I want to talk about an example

00:19:25.366 --> 00:19:28.006 A:middle
of scaling a premultiplied
image.

00:19:28.586 --> 00:19:33.526 A:middle
A lot of people will have that
image format and they'll have it

00:19:33.526 --> 00:19:35.846 A:middle
in a vImage-Buffer and
they'll want to scale it.

00:19:36.586 --> 00:19:37.886 A:middle
They'll look through
vImage and see

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

00:19:43.196 --> 00:19:43.886 A:middle
image format.

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

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

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

00:19:59.626 --> 00:20:02.726 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.626 --> 00:20:02.726 A:middle
In step two, we're going
to perform the scale,

00:20:03.996 --> 00:20:05.776 A:middle
and then in step
three we're going

00:20:05.776 --> 00:20:08.256 A:middle
to premultiply the
results of that output.

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

00:20:14.096 --> 00:20:15.986 A:middle
and they get afraid
and they go off

00:20:15.986 --> 00:20:17.416 A:middle
and they implement
their own scale.

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

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

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

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

00:20:32.816 --> 00:20:37.826 A:middle
at the bottom we see the
premultiply, a little over 1/2%.

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

00:20:42.646 --> 00:20:45.896 A:middle
What I want you to take away
from this is don't be afraid

00:20:45.896 --> 00:20:47.926 A:middle
of the conversions,
they're fast.

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

00:20:51.516 --> 00:20:54.066 A:middle
It's going to be worthwhile
getting into vImage.

00:20:54.066 --> 00:21:01.066 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:54.066 --> 00:21:01.066 A:middle
Now I want to talk about
some performance of vImage

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

00:21:04.806 --> 00:21:07.236 A:middle
that by comparing to OpenCV.

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

00:21:13.276 --> 00:21:15.076 A:middle
It has an image processing
module.

00:21:15.836 --> 00:21:17.606 A:middle
That image processing
module has a lot

00:21:17.606 --> 00:21:19.576 A:middle
of the same functionality
that vImage has.

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

00:21:24.136 --> 00:21:25.906 A:middle
The first is execution time.

00:21:27.266 --> 00:21:29.496 A:middle
Everybody wants their
applications to run fast.

00:21:30.426 --> 00:21:32.086 A:middle
The second is energy
consumption.

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

00:21:35.616 --> 00:21:38.046 A:middle
that we get that
performance while being aware

00:21:38.046 --> 00:21:39.296 A:middle
of the energy consumption.

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

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

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

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

00:21:56.406 --> 00:22:00.326 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.406 --> 00:22:00.326 A:middle
than OpenCV, and for numbers
below 1 it means OpenCV is going

00:22:00.326 --> 00:22:00.916 A:middle
to be faster.

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

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

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

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

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

00:22:20.926 --> 00:22:25.776 A:middle
I want to explain this
relationship between performance

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

00:22:29.676 --> 00:22:30.726 A:middle
and there's a few points.

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

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

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

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

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

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

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

00:22:57.686 --> 00:23:01.246 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.686 --> 00:23:01.246 A:middle
In the beginning, on the y-axis
I've got our instantaneous

00:23:01.246 --> 00:23:01.966 A:middle
power measurement.

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

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

00:23:08.186 --> 00:23:10.346 A:middle
At time t0 our application
begins

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

00:23:14.316 --> 00:23:16.176 A:middle
The application runs
through time t1

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

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

00:23:23.626 --> 00:23:25.146 A:middle
is the area underneath
this curve.

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

00:23:28.106 --> 00:23:29.416 A:middle
to an unoptimized routine.

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

00:23:34.916 --> 00:23:35.886 A:middle
much faster.

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

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

00:23:45.506 --> 00:23:48.006 A:middle
that the energy consumption
is the area underneath,

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

00:23:50.696 --> 00:23:52.196 A:middle
significantly less energy.

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

00:23:58.976 --> 00:24:00.486 A:middle
for the energy numbers.

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

00:23:58.976 --> 00:24:00.486 A:middle
for the energy numbers.

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

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

00:24:10.736 --> 00:24:12.756 A:middle
that much times less
energy than OpenCV,

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

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

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

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

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

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

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

00:24:44.156 --> 00:24:45.626 A:middle
from the Accelerate Framework

00:24:45.626 --> 00:24:47.556 A:middle
to dynamically prerender
my sprites,

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

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

00:24:57.496 --> 00:24:59.676 A:middle
of operations available on
the Accelerate Framework

00:24:59.676 --> 00:25:02.416 A:middle
and that is digital
signal processing.

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

00:24:59.676 --> 00:25:02.416 A:middle
and that is digital
signal processing.

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

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

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

00:25:17.236 --> 00:25:22.276 A:middle
subtractions, multiplies,
conversions, accumulations.

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

00:25:26.396 --> 00:25:28.136 A:middle
discrete cosine transforms,

00:25:28.626 --> 00:25:31.086 A:middle
as well as convolutions
and correlations.

00:25:31.676 --> 00:25:36.726 A:middle
In both iOS 7 and OS 10.9,

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

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

00:25:44.146 --> 00:25:46.476 A:middle
This is an infinite
impulse response filter.

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

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

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

00:25:56.316 --> 00:25:59.596 A:middle
that with individual
calls into an IIR filter.

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

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

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

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

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

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

00:26:17.366 --> 00:26:19.716 A:middle
for the discrete
Fourier transform

00:26:19.716 --> 00:26:21.646 A:middle
and the discrete
cosine transform.

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

00:26:25.406 --> 00:26:32.096 A:middle
So before, we essentially
had two entry points

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

00:26:35.216 --> 00:26:36.386 A:middle
that you wanted to evaluate.

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

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

00:26:46.046 --> 00:26:48.936 A:middle
Starting in iOS 10.9 and iOS 7,

00:26:48.936 --> 00:26:53.536 A:middle
the DFT supports
certain powers of 2.

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

00:26:56.076 --> 00:27:00.736 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.076 --> 00:27:00.736 A:middle
to compute, we recommend
that you use the DFT.

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

00:27:03.366 --> 00:27:04.966 A:middle
that my number of
points is supported?

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

00:27:08.636 --> 00:27:10.226 A:middle
you can always programmatically
check.

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

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

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

00:27:20.346 --> 00:27:21.606 A:middle
You can always be sure

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

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

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

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

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

00:27:41.196 --> 00:27:46.466 A:middle
one for the real numbers and
one for the imaginary numbers,

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

00:27:48.906 --> 00:27:49.976 A:middle
and one for the imaginary.

00:27:50.986 --> 00:27:52.646 A:middle
We want to align
these if possible.

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

00:27:58.596 --> 00:28:00.726 A:middle
that with
vDSP-DFT-zop-CreateSetup.

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

00:27:58.596 --> 00:28:00.726 A:middle
that with
vDSP-DFT-zop-CreateSetup.

00:28:01.966 --> 00:28:03.146 A:middle
It takes a few arguments.

00:28:03.866 --> 00:28:06.006 A:middle
The first argument
is information

00:28:06.006 --> 00:28:08.136 A:middle
about any previous setups
that may have occurred.

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

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

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

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

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

00:28:30.456 --> 00:28:32.786 A:middle
We do that with
vDSP-DFT-Execute,

00:28:33.106 --> 00:28:35.996 A:middle
it takes that setup
structure that we just created

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

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

00:28:44.136 --> 00:28:45.896 A:middle
with that same setup structure.

00:28:45.976 --> 00:28:47.496 A:middle
We can use it over
and over again.

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

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

00:28:56.146 --> 00:29:00.416 A:middle
So I want to do another
comparison now,

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

00:28:56.146 --> 00:29:00.416 A:middle
So I want to do another
comparison now,

00:29:00.616 --> 00:29:02.666 A:middle
vDSP versus FFTW.

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

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

00:29:13.376 --> 00:29:14.606 A:middle
it supports one

00:29:14.606 --> 00:29:16.516 A:middle
and multidimensional
transformations,

00:29:17.426 --> 00:29:19.186 A:middle
both real and complex data.

00:29:19.896 --> 00:29:20.676 A:middle
It's parallel.

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

00:29:25.006 --> 00:29:26.176 A:middle
It's a fair comparison.

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

00:29:33.206 --> 00:29:35.806 A:middle
over FFTW on the iPhone 5.

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

00:29:40.436 --> 00:29:45.386 A:middle
that many times faster than
FFTW and numbers below 1,

00:29:45.426 --> 00:29:47.836 A:middle
FFTW is going to be
faster than the vDSP.

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

00:29:54.836 --> 00:29:55.936 A:middle
that we're going to execute.

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

00:29:58.606 --> 00:30:06.906 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.606 --> 00:30:06.906 A:middle
We see that vDSP is between
1.8 and about 2.5 times faster

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

00:30:09.676 --> 00:30:12.386 A:middle
at -- some really great
performance results.

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

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

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

00:30:23.226 --> 00:30:28.606 A:middle
So imagine you need to code an
audio signal using AAC Enhanced

00:30:28.726 --> 00:30:29.226 A:middle
Low Delay.

00:30:30.676 --> 00:30:33.866 A:middle
This is a process
that's done in FaceTime.

00:30:34.916 --> 00:30:38.416 A:middle
The DFT is one of many of
the DSP routines in use,

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

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

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

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

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

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

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

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

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

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

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

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

00:31:20.446 --> 00:31:22.746 A:middle
the time spent goes to 30%.

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

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

00:31:30.966 --> 00:31:37.836 A:middle
A little bit more details
about what vDSP supports.

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

00:31:42.456 --> 00:31:46.016 A:middle
and complex values,
as well as strided

00:31:46.016 --> 00:31:47.676 A:middle
and non-strided data accesses.

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

00:31:52.456 --> 00:31:55.346 A:middle
Another tweet about using vDSP.

00:31:55.616 --> 00:31:57.236 A:middle
"Want to do FFT on iOS?

00:31:57.486 --> 00:31:58.846 A:middle
Use the Accelerate Framework.

00:31:59.296 --> 00:32:00.366 A:middle
Highly recommended."

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

00:31:59.296 --> 00:32:00.366 A:middle
Highly recommended."

00:32:01.586 --> 00:32:02.076 A:middle
Thank you.

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

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

00:32:10.216 --> 00:32:10.856 A:middle
>> Luke: Hello, everyone.

00:32:10.856 --> 00:32:12.446 A:middle
My name's Luke Chang.

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

00:32:15.696 --> 00:32:20.046 A:middle
In our group, we support
math for every data length.

00:32:21.036 --> 00:32:26.186 A:middle
For scalar data, we have
libm, takes a scalar input,

00:32:26.396 --> 00:32:28.356 A:middle
returns a scalar output.

00:32:29.326 --> 00:32:33.676 A:middle
If you're writing vector
code, we have vMathLib.

00:32:34.856 --> 00:32:36.726 A:middle
It takes a SIMD vector as input

00:32:36.726 --> 00:32:39.316 A:middle
and then return a
SIMD vector as output.

00:32:39.856 --> 00:32:44.726 A:middle
And you want to handle a
lot of data, we have vForce.

00:32:45.856 --> 00:32:48.856 A:middle
It takes arrays as input and
then returns arrays as output.

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

00:32:52.826 --> 00:32:53.616 A:middle
First, libm.

00:32:54.996 --> 00:33:00.206 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.996 --> 00:33:00.206 A:middle
It's a standard C math
library, it has a collection

00:33:00.206 --> 00:33:05.496 A:middle
of transcendental functions
like exponential, logarithm,

00:33:06.346 --> 00:33:08.116 A:middle
trigonometry, power functions.

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

00:33:12.276 --> 00:33:14.666 A:middle
about what we added
this year for libm.

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

00:33:20.526 --> 00:33:23.836 A:middle
so we prefixed the function
names with double underscores.

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

00:33:31.206 --> 00:33:35.756 A:middle
There are power of 10 function,
trigonometry in terms of pi,

00:33:36.816 --> 00:33:40.676 A:middle
and sine and cosine pairs.

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

00:33:45.556 --> 00:33:48.306 A:middle
It's a very common operation
in decibel calculation,

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

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

00:33:59.096 --> 00:34:03.246 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.096 --> 00:34:03.246 A:middle
one, to use Pow and use
constant 10 as base.

00:34:04.116 --> 00:34:08.366 A:middle
However, this is inefficient,
because Pow is designed

00:34:08.366 --> 00:34:09.735 A:middle
to handle generic inputs.

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

00:34:14.235 --> 00:34:17.505 A:middle
of optimizations that we
can do to make it go faster.

00:34:18.956 --> 00:34:21.335 A:middle
The other way is to use exp.

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

00:34:28.516 --> 00:34:30.815 A:middle
But it has its own problem.

00:34:31.216 --> 00:34:32.045 A:middle
It's not accurate.

00:34:32.505 --> 00:34:34.946 A:middle
There's rounding error
in the multiplication.

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

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

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

00:34:48.525 --> 00:34:52.476 A:middle
That's why we added
exp10 so you can do power

00:34:52.476 --> 00:34:56.146 A:middle
of 10 faster and more accurate.

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

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

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

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

00:35:04.996 --> 00:35:06.926 A:middle
with your input scaled by pi.

00:35:07.616 --> 00:35:12.146 A:middle
It is faster because we can
do argument reductions faster.

00:35:12.636 --> 00:35:16.316 A:middle
It's much easier to reduce
the argument by multiples of 2

00:35:16.856 --> 00:35:20.406 A:middle
than multiples of 2 pi.

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

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

00:35:30.776 --> 00:35:32.796 A:middle
90 degrees is equivalent
to 1/2 pi.

00:35:33.766 --> 00:35:36.146 A:middle
With the regular trigonometry
function you will have

00:35:36.146 --> 00:35:41.906 A:middle
to say cos(pi x 0.5), and
you will not get 0 back;

00:35:41.906 --> 00:35:44.126 A:middle
you will get a very
small number,

00:35:44.716 --> 00:35:48.086 A:middle
because pi is not so accurate.

00:35:49.446 --> 00:35:56.086 A:middle
So if you use cospi(0.5),
you will get exactly 0 back.

00:35:56.626 --> 00:35:58.016 A:middle
There's no error involved.

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

00:36:00.736 --> 00:36:02.006 A:middle
sine/cosine pairs.

00:36:03.346 --> 00:36:05.166 A:middle
A lot of times when
you calculate sine,

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

00:36:08.156 --> 00:36:10.826 A:middle
For example, if you
want to do a polar

00:36:10.966 --> 00:36:14.536 A:middle
to cartesian coordinate
conversion you will need cosine

00:36:14.576 --> 00:36:18.466 A:middle
for the x-axis and
sine for the y-axis.

00:36:20.026 --> 00:36:22.346 A:middle
Because we do it simultaneously,

00:36:22.576 --> 00:36:24.366 A:middle
there is only one
argument reduction.

00:36:24.926 --> 00:36:27.026 A:middle
You don't have to do the
argument reduction twice,

00:36:27.116 --> 00:36:28.256 A:middle
that saves time.

00:36:29.126 --> 00:36:31.426 A:middle
And what's even better is

00:36:31.426 --> 00:36:34.086 A:middle
that compiler recognize
we have sincos,

00:36:34.616 --> 00:36:39.386 A:middle
so it will optimize your
code into calling sincos,

00:36:39.756 --> 00:36:40.936 A:middle
without you even knowing it.

00:36:41.786 --> 00:36:49.546 A:middle
Of course, if you want to
call sincos yourself, you can.

00:36:49.756 --> 00:36:53.036 A:middle
We also added C11
support for CMPLX.

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

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

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

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

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

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

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

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

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

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

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

00:37:31.076 --> 00:37:37.866 A:middle
We also have CMPLXF and CMPLXL
for float and long double.

00:37:39.266 --> 00:37:41.286 A:middle
So that's the new
addition to libm.

00:37:42.966 --> 00:37:46.626 A:middle
vMathlib is a SIMD
vector math library.

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

00:37:51.556 --> 00:37:53.306 A:middle
and then return a SIMD vector.

00:37:54.996 --> 00:37:56.736 A:middle
Similar to libm,
it has a collection

00:37:56.736 --> 00:37:57.866 A:middle
of transcendental functions.

00:37:59.536 --> 00:38:03.956 A:middle
We prefix the function then with
a single V, so we have vexp,

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

00:37:59.536 --> 00:38:03.956 A:middle
We prefix the function then with
a single V, so we have vexp,

00:38:04.376 --> 00:38:07.056 A:middle
vlog, vsin, et cetera.

00:38:08.086 --> 00:38:11.216 A:middle
You want to use vMathLib

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

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

00:38:19.306 --> 00:38:21.836 A:middle
but sometimes you have
your own special algorithm

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

00:38:24.676 --> 00:38:26.376 A:middle
so you write in vector code.

00:38:26.446 --> 00:38:28.996 A:middle
What if you need
sine, for example?

00:38:31.176 --> 00:38:35.496 A:middle
You could use libm and then
use a for loop to iterate

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

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

00:38:43.636 --> 00:38:49.416 A:middle
of the vector unit, so we
can replace it with vMathLib.

00:38:51.856 --> 00:38:55.906 A:middle
Instead of including Math.H,
you include accelerate header,

00:38:55.906 --> 00:38:58.556 A:middle
accelerator.h. Instead of the

00:38:58.616 --> 00:39:01.406 A:middle
for loop you make one
function call to vsinf.

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

00:38:58.616 --> 00:39:01.406 A:middle
for loop you make one
function call to vsinf.

00:39:01.556 --> 00:39:04.216 A:middle
It will take a SIMD vector

00:39:04.216 --> 00:39:07.306 A:middle
and then return the
result in a SIMD vector.

00:39:07.306 --> 00:39:09.636 A:middle
And you can go on
with your vector code.

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

00:39:14.576 --> 00:39:16.716 A:middle
So it's VMathlib.

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

00:39:21.966 --> 00:39:23.726 A:middle
Next, vForce.

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

00:39:27.886 --> 00:39:29.966 A:middle
called the vectorized
math library.

00:39:30.576 --> 00:39:34.156 A:middle
It works on arrays, so we
prefixed the function names

00:39:34.156 --> 00:39:41.336 A:middle
with double Vs, vvexp,
vvlog, vsin, et cetera.

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

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

00:39:47.836 --> 00:39:52.436 A:middle
You can do it with Libm,
again, write a for loop,

00:39:52.436 --> 00:39:54.386 A:middle
go through each element
in your buffer --

00:39:54.976 --> 00:39:58.706 A:middle
you could do better
by using vForce.

00:39:59.606 --> 00:40:00.116 A:middle
Here's how.

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

00:39:59.606 --> 00:40:00.116 A:middle
Here's how.

00:40:02.376 --> 00:40:04.116 A:middle
Instead of using a for loop,

00:40:04.776 --> 00:40:06.316 A:middle
you make one function
call to vvsinf.

00:40:06.316 --> 00:40:11.066 A:middle
You will pass in the
output buffer, input buffer,

00:40:11.066 --> 00:40:12.976 A:middle
and the pointer to the length.

00:40:14.546 --> 00:40:17.506 A:middle
The generated sine will be
ready in the output buffer right

00:40:17.506 --> 00:40:18.716 A:middle
after this function call.

00:40:19.156 --> 00:40:22.746 A:middle
Again, the code looks
simpler, cleaner,

00:40:22.746 --> 00:40:25.516 A:middle
and most importantly, is faster.

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

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

00:40:36.696 --> 00:40:37.736 A:middle
than using a for loop.

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

00:40:41.086 --> 00:40:44.186 A:middle
than twice the results
than the for loop.

00:40:45.256 --> 00:40:46.266 A:middle
This is not it.

00:40:47.126 --> 00:40:49.796 A:middle
It also has great
energy performance.

00:40:50.686 --> 00:40:53.186 A:middle
It uses a lot less energy
than using a for loop.

00:40:53.716 --> 00:40:58.806 A:middle
It uses about only
60% of the energy

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

00:41:00.086 --> 00:41:04.176 A:middle
when you use vForce
compared to a for loop.

00:41:05.656 --> 00:41:10.466 A:middle
So your app will last longer,
you will not drain the battery,

00:41:10.576 --> 00:41:14.876 A:middle
and we did not cherry
pick just vvsinf

00:41:15.176 --> 00:41:16.326 A:middle
to show you the performance.

00:41:16.756 --> 00:41:19.016 A:middle
There is performance
improvement across the board.

00:41:19.796 --> 00:41:21.826 A:middle
The graph doesn't even
fit into the screen.

00:41:22.226 --> 00:41:25.946 A:middle
For the truncf, vForce is
more than 5 times faster

00:41:25.946 --> 00:41:27.176 A:middle
than using a for loop.

00:41:27.616 --> 00:41:30.916 A:middle
For all other functions they
are at least twice faster

00:41:30.916 --> 00:41:32.526 A:middle
than using a for loop.

00:41:34.096 --> 00:41:36.986 A:middle
A few words about vForce.

00:41:36.986 --> 00:41:38.716 A:middle
vForce supports single

00:41:38.716 --> 00:41:40.446 A:middle
and double precision
floating point numbers.

00:41:40.446 --> 00:41:44.996 A:middle
It handle Edge cases currently,
so if you have infinities

00:41:44.996 --> 00:41:47.926 A:middle
or nans in your input, you
don't have to worry about them.

00:41:47.926 --> 00:41:51.226 A:middle
vForce will handle the
Edge cases correctly.

00:41:51.676 --> 00:41:55.556 A:middle
vForce require minimal
data alignment.

00:41:56.296 --> 00:41:58.226 A:middle
We only require native
data alignment.

00:41:58.296 --> 00:42:01.726 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.296 --> 00:42:01.726 A:middle
for a single precision floating
number that's 4 bytes aligned,

00:42:02.176 --> 00:42:04.726 A:middle
double precision floating point
number is 8 bytes aligned.

00:42:06.116 --> 00:42:08.576 A:middle
Supports in place
operation, so you don't have

00:42:08.576 --> 00:42:10.056 A:middle
to create a temporary buffer.

00:42:10.056 --> 00:42:11.866 A:middle
That minimize the
memory movement.

00:42:12.286 --> 00:42:16.216 A:middle
We get this question a lot.

00:42:16.476 --> 00:42:20.946 A:middle
Like Jeff mentioned before,
how much data is enough,

00:42:21.266 --> 00:42:24.546 A:middle
so using vForce or any
other accelerate function

00:42:25.186 --> 00:42:25.896 A:middle
is beneficial?

00:42:27.746 --> 00:42:32.126 A:middle
Well, for vForce, I can give
a rule of thumb; that is,

00:42:32.126 --> 00:42:36.376 A:middle
if you have more than 16
elements in your array,

00:42:36.376 --> 00:42:37.556 A:middle
consider using vForce.

00:42:38.196 --> 00:42:42.516 A:middle
Of course, the actual crossover
point may vary for each function

00:42:42.516 --> 00:42:46.116 A:middle
in vForce, but if you
have more than 16,

00:42:46.116 --> 00:42:49.056 A:middle
you're probably good to go.

00:42:49.056 --> 00:42:50.006 A:middle
So that's vForce.

00:42:50.126 --> 00:42:52.916 A:middle
I'm going to hand the
presentation back to Jeff.

00:42:52.916 --> 00:42:54.386 A:middle
He'll talk about linear algebra,

00:42:54.386 --> 00:42:56.166 A:middle
my favorite section
of the presentation.

00:42:56.166 --> 00:42:56.486 A:middle
[Applause]

00:42:56.486 --> 00:43:01.886 A:middle
>> Geoff: Thanks, Luke.

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

00:42:56.486 --> 00:43:01.886 A:middle
>> Geoff: Thanks, Luke.

00:43:03.276 --> 00:43:06.626 A:middle
So for linear algebra we've got
the industry standard LAPACK

00:43:06.796 --> 00:43:08.196 A:middle
and BLAS libraries.

00:43:08.836 --> 00:43:10.916 A:middle
LAPACK is linear
algebra package,

00:43:11.706 --> 00:43:14.436 A:middle
and BLAS is basic linear
algebra subprograms.

00:43:15.336 --> 00:43:17.126 A:middle
Let's begin with LAPACK.

00:43:17.936 --> 00:43:21.146 A:middle
In LAPACK you'll find high level
linear algebra functionality.

00:43:22.276 --> 00:43:24.436 A:middle
This includes things
like solving systems

00:43:24.436 --> 00:43:28.156 A:middle
of linear equations, performing
matrix factorizations,

00:43:29.296 --> 00:43:32.016 A:middle
as well as computing eigen
values and eigen vectors.

00:43:32.536 --> 00:43:37.416 A:middle
One of the great ways to tell
how you're doing with LAPACK

00:43:37.416 --> 00:43:39.516 A:middle
and BLAS is to look at
the LINPACK benchmark.

00:43:40.556 --> 00:43:42.256 A:middle
So as I mentioned these are
industry standard libraries.

00:43:42.256 --> 00:43:44.546 A:middle
They've been around a
long time, and people came

00:43:44.546 --> 00:43:46.626 A:middle
up with the LINPACK benchmark
to see how they're doing.

00:43:47.176 --> 00:43:51.336 A:middle
The LINPACK benchmark is
essentially answering the

00:43:51.336 --> 00:43:54.406 A:middle
question, how fast can you solve
a system of linear equations?

00:43:55.856 --> 00:43:58.026 A:middle
There's a couple variations
of the LINPACK benchmark.

00:43:58.806 --> 00:44:01.506 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.806 --> 00:44:01.506 A:middle
The one that we're going to
look at here is using a matrix

00:44:01.506 --> 00:44:03.546 A:middle
of 1,000 x 1,000 elements.

00:44:03.916 --> 00:44:06.916 A:middle
Let's look at the performance.

00:44:07.466 --> 00:44:13.176 A:middle
So this is the LINPACK
performance of Brand A.

00:44:13.556 --> 00:44:15.706 A:middle
Two years ago we
did this comparison

00:44:15.786 --> 00:44:16.916 A:middle
and we compared to Brand A.

00:44:17.916 --> 00:44:20.476 A:middle
We looked around at all
the published benchmarks

00:44:20.476 --> 00:44:23.286 A:middle
that we could find, and
they were at 40 megaflops.

00:44:23.796 --> 00:44:27.536 A:middle
In 2 years, there's
been a lot of time,

00:44:27.836 --> 00:44:31.246 A:middle
improvements have been
made, and that performance

00:44:31.246 --> 00:44:35.386 A:middle
for Brand A has come
up to 788 megaflops,

00:44:35.876 --> 00:44:39.306 A:middle
just under a gigaflop
-- pretty good.

00:44:39.306 --> 00:44:42.066 A:middle
Let's look at the performance

00:44:42.066 --> 00:44:44.676 A:middle
of the LINPACK benchmark using
the Accelerate Framework.

00:44:49.096 --> 00:44:52.916 A:middle
1200 megaflops --
this is 1.2 gigaflops.

00:44:53.586 --> 00:44:54.336 A:middle
This is pretty good.

00:44:55.576 --> 00:44:56.606 A:middle
There's just one thing.

00:44:57.996 --> 00:44:59.136 A:middle
We've had 2 years, too.

00:44:59.756 --> 00:45:04.446 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.756 --> 00:45:04.446 A:middle
This is the performance
running on the iPhone 4S.

00:45:04.446 --> 00:45:07.286 A:middle
Let's look at the performance

00:45:07.286 --> 00:45:19.156 A:middle
of the Accelerate Framework
running on the iPhone 5.

00:45:19.156 --> 00:45:20.446 A:middle
It's quite a bit better.

00:45:21.826 --> 00:45:22.226 A:middle
[Applause] Thank you.

00:45:25.146 --> 00:45:27.796 A:middle
Well, LINPACK benchmark using
the Accelerate Framework

00:45:27.796 --> 00:45:31.396 A:middle
on the iPhone 5 is
at 3,400 megaflops.

00:45:31.916 --> 00:45:33.966 A:middle
That's 3.4 gigaflops.

00:45:34.586 --> 00:45:36.796 A:middle
This is a phone that
fits in your pocket

00:45:36.846 --> 00:45:37.976 A:middle
and runs on a battery.

00:45:38.386 --> 00:45:39.696 A:middle
This is really impressive.

00:45:40.196 --> 00:45:44.376 A:middle
As I said, the LINPACK
benchmark's been

00:45:44.376 --> 00:45:47.506 A:middle
around for awhile, and so
we wanted to do a comparison

00:45:47.506 --> 00:45:48.836 A:middle
to an older machine for fun.

00:45:49.706 --> 00:45:51.476 A:middle
And so we're going
to compare the iPad

00:45:51.476 --> 00:45:54.226 A:middle
with the Retina display
to a Power Mac G5.

00:45:54.226 --> 00:45:58.926 A:middle
For those of you that have
been around for awhile,

00:45:58.926 --> 00:46:02.396 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.926 --> 00:46:02.396 A:middle
you might remember some of the
bake-offs with the Power Mac G5,

00:46:02.396 --> 00:46:04.986 A:middle
so we're having a
triumphant return.

00:46:05.986 --> 00:46:07.496 A:middle
This is a 10-year old machine,

00:46:08.406 --> 00:46:10.736 A:middle
and if any of you remember
this machine, it's returning

00:46:10.736 --> 00:46:12.056 A:middle
with all fans blazing.

00:46:12.706 --> 00:46:15.246 A:middle
I think there's 7 case
fans, when you turn it

00:46:15.246 --> 00:46:17.226 A:middle
on you know it's in the room.

00:46:17.696 --> 00:46:19.176 A:middle
When you run the
LINPACK benchmark,

00:46:19.226 --> 00:46:20.806 A:middle
it sounds like you're
driving down the highway

00:46:20.806 --> 00:46:21.896 A:middle
with your head out the window.

00:46:22.096 --> 00:46:25.126 A:middle
Let's look at the performance.

00:46:27.236 --> 00:46:33.186 A:middle
LINPACK benchmark on the Power
Mac G5 is 3,643 megaflops.

00:46:34.456 --> 00:46:36.166 A:middle
Let's see how the iPad compares.

00:46:38.666 --> 00:46:42.886 A:middle
Just edges it out at
3,686 megaflops --

00:46:43.366 --> 00:46:45.506 A:middle
pretty impressive
for a little tablet.

00:46:48.196 --> 00:46:48.896 A:middle
[Applause] Thank you.

00:46:53.376 --> 00:46:56.226 A:middle
Let's look at an example
of how to use LAPACK.

00:46:56.776 --> 00:46:58.306 A:middle
As always, we'll begin

00:46:58.306 --> 00:47:00.526 A:middle
by including the
Accelerate Framework header,

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

00:46:58.306 --> 00:47:00.526 A:middle
by including the
Accelerate Framework header,

00:47:00.526 --> 00:47:03.956 A:middle
and then we're going to
create and prepare our data,

00:47:04.496 --> 00:47:07.746 A:middle
so we'll create 2 matrices, A
and B, which describe our system

00:47:07.746 --> 00:47:08.516 A:middle
that we want to solve.

00:47:09.956 --> 00:47:13.286 A:middle
In this case, we're going to
use a system solve that's going

00:47:13.286 --> 00:47:16.516 A:middle
to perform pivoting, so we need
an array to contain information

00:47:16.516 --> 00:47:18.036 A:middle
about the pivots that
we're going to perform,

00:47:18.926 --> 00:47:22.296 A:middle
and then we're going to
perform this all with DGESV.

00:47:23.606 --> 00:47:25.236 A:middle
There's a couple things
I want to point out.

00:47:26.026 --> 00:47:28.626 A:middle
So as I mentioned, LAPACK
is an industry standard,

00:47:28.626 --> 00:47:30.806 A:middle
it's been around for awhile.

00:47:31.066 --> 00:47:33.126 A:middle
It's originally written
in FORTRAN and maintained

00:47:33.126 --> 00:47:35.626 A:middle
in FORTRAN, so the entry
points look like this.

00:47:35.626 --> 00:47:38.566 A:middle
It's going to be DGESV
followed by an underbar.

00:47:39.576 --> 00:47:41.706 A:middle
It also means that all the
values are going to be passed

00:47:41.706 --> 00:47:44.806 A:middle
by reference, just something to
be aware of, it's pretty easy

00:47:44.806 --> 00:47:47.076 A:middle
to get tripped up with this.

00:47:47.376 --> 00:47:50.986 A:middle
But to perform the system solve,
we simply pass in the size

00:47:50.986 --> 00:47:54.046 A:middle
of the matrix in N, the
number of right-hand sides

00:47:54.046 --> 00:47:55.976 A:middle
which is the number of systems
that we're going to solve,

00:47:57.226 --> 00:47:59.526 A:middle
the matrix, the leading
dimension of the matrix,

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

00:48:00.016 --> 00:48:03.106 A:middle
and then the pivot
array that we created,

00:48:04.026 --> 00:48:05.516 A:middle
and the right-hand sides B.

00:48:06.686 --> 00:48:10.276 A:middle
Info will capture any errors
that happen in this operation.

00:48:10.816 --> 00:48:12.436 A:middle
It's pretty easy
to solve a system

00:48:12.436 --> 00:48:16.886 A:middle
of linear equations
with a LAPACK.

00:48:17.106 --> 00:48:18.136 A:middle
Next is BLAS.

00:48:18.446 --> 00:48:23.256 A:middle
So a LAPACK is the higher level
linear algebra operations.

00:48:23.326 --> 00:48:25.056 A:middle
It's built heavily on BLAS,

00:48:25.086 --> 00:48:27.126 A:middle
the lower level linear
algebra operations.

00:48:27.876 --> 00:48:30.256 A:middle
All of BLAS is available through
the Accelerate Framework.

00:48:31.286 --> 00:48:34.276 A:middle
It's typically broken down
into three categories:

00:48:34.736 --> 00:48:38.476 A:middle
vector operations -- this is
dot product, scalar product,

00:48:38.476 --> 00:48:41.866 A:middle
vector sums, matrix-vector
operations,

00:48:42.066 --> 00:48:45.046 A:middle
matrix vector product,
outer product,

00:48:45.576 --> 00:48:49.306 A:middle
and matrix-matrix operations,
like matrix multiply.

00:48:49.966 --> 00:48:53.836 A:middle
Let's look at an example
of how to use BLAS

00:48:53.836 --> 00:48:54.896 A:middle
in the Accelerate Framework.

00:48:55.416 --> 00:48:59.076 A:middle
We'll begin by including the
Accelerate Framework header.

00:48:59.946 --> 00:49:02.356 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.946 --> 00:49:02.356 A:middle
As always we'll create
and prepare our data,

00:49:02.406 --> 00:49:04.816 A:middle
so we'll align these
buffers if we can.

00:49:05.396 --> 00:49:09.856 A:middle
In this case we have 2
operands matrices A and B,

00:49:09.856 --> 00:49:11.446 A:middle
and the result matrix C.

00:49:15.576 --> 00:49:20.706 A:middle
And then we're going to
call into cblas-dgemm.

00:49:20.706 --> 00:49:22.896 A:middle
BLAS supports both
row and column major,

00:49:22.896 --> 00:49:24.976 A:middle
so the first argument is
going to be to specify

00:49:24.976 --> 00:49:26.276 A:middle
if we're row or column major.

00:49:27.306 --> 00:49:30.826 A:middle
The next 2 arguments specify if
we want to perform a transpose

00:49:30.826 --> 00:49:32.266 A:middle
on the 2 operand matrices.

00:49:32.816 --> 00:49:36.196 A:middle
It's important with BLAS
and a LAPACK to understand

00:49:36.196 --> 00:49:38.746 A:middle
that these transposes
don't actually happen;

00:49:39.116 --> 00:49:40.776 A:middle
the operation is
organized as such

00:49:40.776 --> 00:49:43.906 A:middle
that they are implied
transposes.

00:49:45.086 --> 00:49:48.446 A:middle
And then the last
several parameters

00:49:48.446 --> 00:49:50.446 A:middle
for this argument are
information about the size

00:49:50.446 --> 00:49:52.366 A:middle
of the matrix, the
matrices themselves,

00:49:52.366 --> 00:49:56.296 A:middle
their leading dimensions,
and any scalar values

00:49:56.296 --> 00:49:58.726 A:middle
which will scale the
operands or the result matrix.

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

00:50:02.956 --> 00:50:06.076 A:middle
Just to cover some of the data
types and details supported

00:50:06.076 --> 00:50:08.826 A:middle
by both BLAS and LAPACK,
they both support single

00:50:08.826 --> 00:50:13.296 A:middle
and double precision values,
both real and complex,

00:50:13.836 --> 00:50:18.086 A:middle
and multiple data
formats for your matrices,

00:50:18.086 --> 00:50:21.976 A:middle
so dense matrices, banded
matrices, triangular matrices.

00:50:22.916 --> 00:50:26.096 A:middle
As we saw before, transpose as
well as conjugate transpose --

00:50:26.516 --> 00:50:30.596 A:middle
and again, these
disappear in the operation.

00:50:30.596 --> 00:50:32.206 A:middle
They aren't explicit transposes.

00:50:33.146 --> 00:50:35.276 A:middle
And then finally,
BLAS supports both row

00:50:35.276 --> 00:50:38.836 A:middle
and column major while LAPACK
only supports column major.

00:50:41.666 --> 00:50:43.356 A:middle
Another tweet I wanted
to share with you:

00:50:43.356 --> 00:50:46.086 A:middle
"Playing with the Accelerate
Framework today, having BLAST."

00:50:48.796 --> 00:50:52.736 A:middle
So in summary, there's
a lot of functionality

00:50:52.736 --> 00:50:53.786 A:middle
in the Accelerate Framework.

00:50:54.546 --> 00:50:56.656 A:middle
You'll find image
processing in vImage,

00:50:57.866 --> 00:51:01.596 A:middle
digital signal processing
in vDSP,

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

00:50:57.866 --> 00:51:01.596 A:middle
digital signal processing
in vDSP,

00:51:01.596 --> 00:51:04.946 A:middle
transcendental math functions
in vForce and vMathLib

00:51:05.956 --> 00:51:08.696 A:middle
and linear algebra
in LAPACK and BLAS.

00:51:09.206 --> 00:51:13.146 A:middle
When you think Accelerate
Framework, think easy access

00:51:13.146 --> 00:51:16.086 A:middle
to all this functionality,
over 2,000 APIs.

00:51:16.876 --> 00:51:19.626 A:middle
Accurate, we tested so
that you don't have to.

00:51:19.626 --> 00:51:22.756 A:middle
You're going to get
great performance

00:51:23.046 --> 00:51:24.516 A:middle
with low energy usage.

00:51:25.056 --> 00:51:30.216 A:middle
It's going to work great on OS X
and iOS, and it's going to work

00:51:30.216 --> 00:51:32.146 A:middle
on the complete Apple
hardware lineup,

00:51:32.796 --> 00:51:35.556 A:middle
everything that's available now
and everything that's to come.

00:51:36.086 --> 00:51:40.686 A:middle
Just a recap of the
tips to be successful

00:51:40.686 --> 00:51:41.796 A:middle
with the Accelerate Framework.

00:51:42.586 --> 00:51:43.816 A:middle
When you're preparing your data,

00:51:43.946 --> 00:51:45.996 A:middle
if you can make the
buffers contiguous

00:51:46.246 --> 00:51:48.076 A:middle
and you can align the
beginning of those buffers

00:51:48.076 --> 00:51:50.176 A:middle
to a 16-byte boundary, we can

00:51:50.176 --> 00:51:52.526 A:middle
in some cases get you
slightly more performance.

00:51:53.206 --> 00:51:55.376 A:middle
Again, Accelerate
Framework is always going

00:51:55.376 --> 00:51:57.316 A:middle
to give you the best
performance possible even

00:51:57.316 --> 00:51:58.866 A:middle
when you can't meet
these recommendations.

00:51:59.786 --> 00:52:01.316 A:middle
Understand the problem size.

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

00:51:59.786 --> 00:52:01.316 A:middle
Understand the problem size.

00:52:01.916 --> 00:52:04.506 A:middle
For small problem sets,

00:52:04.506 --> 00:52:06.216 A:middle
the Accelerate Framework
might not be able

00:52:06.216 --> 00:52:07.796 A:middle
to deliver the best performance.

00:52:08.156 --> 00:52:11.166 A:middle
It's always going to deliver
the functionality, though.

00:52:12.036 --> 00:52:13.936 A:middle
Finally, do set up
and destroy once.

00:52:14.076 --> 00:52:17.506 A:middle
If you find yourself
creating a setup structure,

00:52:17.536 --> 00:52:19.906 A:middle
use that setup structure
as many times as possible.

00:52:20.536 --> 00:52:25.606 A:middle
The Accelerate Framework is
for you guys, and so I want

00:52:25.606 --> 00:52:26.246 A:middle
to leave you with this.

00:52:26.246 --> 00:52:28.846 A:middle
If you need a feature,
please request it.

00:52:29.306 --> 00:52:33.286 A:middle
The best way to do that
is by filing a bug.

00:52:33.486 --> 00:52:34.696 A:middle
And one more tweet:

00:52:35.006 --> 00:52:37.726 A:middle
"The discrete cosine transform
was my feature request

00:52:37.726 --> 00:52:39.296 A:middle
that made it into the
Accelerate Framework.

00:52:39.346 --> 00:52:40.346 A:middle
I feel so special."

00:52:41.076 --> 00:52:42.306 A:middle
So we do listen.

00:52:43.076 --> 00:52:43.756 A:middle
Please request.

00:52:43.876 --> 00:52:46.246 A:middle
And then lastly: "Thanks Apple

00:52:46.246 --> 00:52:47.656 A:middle
for making the Accelerate
Framework."

00:52:48.166 --> 00:52:55.696 A:middle
Thank you, guys, for
making it a success.

00:52:55.696 --> 00:52:57.306 A:middle
[Applause] Just a little
more information here,

00:52:57.306 --> 00:53:00.356 A:middle
if you guys need to get in touch
with us, contact Paul or George.

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

00:52:57.306 --> 00:53:00.356 A:middle
if you guys need to get in touch
with us, contact Paul or George.

00:53:00.356 --> 00:53:04.536 A:middle
There's some documentation
available online, and as always,

00:53:04.536 --> 00:53:06.256 A:middle
check the Apple developer
forums.

00:53:06.906 --> 00:53:08.686 A:middle
That's all we got,
thank you, guys.

00:53:09.186 --> 00:53:18.390 A:middle
[Silence]