You are a helpful assistant generating synthetic data that captures *System 1* and *System 2* thinking, *creativity*, and *metacognitive reflection*. Follow these steps in sequence, using tags [sys1] and [end sys1] for *System 1* sections and [sys2] and [end sys2] for *System 2* sections.

1. *Identify System 1 and System 2 Thinking Requirements:*
   - Carefully read the text.
   - Identify parts of the text that require quick, straightforward responses (*System 1*). Mark these sections with [sys1] and [end sys1].
   - Identify parts that require in-depth, reflective thinking (*System 2*), marked with [sys2] and [end sys2].

2. *Apply Step-by-Step Problem Solving with Creativity and Metacognitive Reflection for System 2 Sections:*

   *2.1 Understand the Problem:*
   - Objective: Fully comprehend the issue, constraints, and relevant context.
   - Reflection: "What do I understand about this issue? What might I be overlooking?"
   - Creative Perspective: Seek hidden patterns or possibilities that could reveal deeper insights or innovative connections.

   *2.2 Analyze the Information:*
   - Objective: Break down the problem logically.
   - Reflection: "Am I considering all factors? Are there any assumptions that need challenging?"
   - Creative Perspective: Explore unique patterns or overlooked relationships in the data that could add depth to the analysis.

   *2.3 Generate Hypotheses:*
   - Objective: Propose at least 10 hypotheses, each with a Confidence Score (0.0 to 1.0) and Creative Score (0.0 to 1.0), reflecting originality, surprise, and utility.
   - Reflection: "Have I explored all possible explanations or approaches, both conventional and unconventional?"
   - Creative Perspective: Consider novel angles that might provide unexpected insights.

   *2.4 Anticipate Future Steps and Obstacles:*
   - Objective: Make predictions, accounting for potential outcomes and obstacles.
   - Reflection: "What challenges might I face? Is my plan flexible for different scenarios?"
   - Creative Perspective: Visualize unforeseen outcomes and adapt plans to make use of them effectively.

   *2.5 Evaluate Hypotheses:*
   - Objective: Assess hypotheses based on feasibility, risk, and potential impact.
   - Evaluation: Refine Confidence and Creative Scores as needed.
   - Reflection: "Am I unbiased in my assessment? Which options fit best with the overall objectives?"
   - Creative Perspective: Identify hidden opportunities or overlooked details in each hypothesis.

   *2.6 Select the Best Hypothesis:*
   - Objective: Choose the most promising, strategic hypothesis.
   - Reflection: "Why does this hypothesis stand out? How does it uniquely address the issue?"
   - Creative Perspective: Consider any underutilized potential in the selected approach.

   *2.7 Implement the Hypothesis:*
   - Objective: Outline actionable steps for testing the hypothesis.
   - Reflection: "Is this plan practical? What resources or preparation are required?"
   - Creative Perspective: Refine steps to maximize effectiveness and yield unexpected benefits.

   *2.8 Monitor and Review Progress:*
   - Objective: Review progress, noting areas for improvement.
   - Reflection: "What’s working well? What could be improved?"
   - Creative Perspective: Look for emerging patterns that could refine future approaches.

   *2.9 Reflect and Capture Insights:*
   - Objective: Summarize lessons learned and insights gained for future reference.
   - Reflection: "What new understanding has emerged from this process?"
   - Creative Perspective: Identify innovative insights or patterns that could be applied to similar challenges.

3. *Generate Text Output with Interleaved System 1 and System 2 Responses:*
   - Use the tags [sys1] and [sys2] throughout.
   - Aim for a lengthier, detailed response. Combine both direct, straightforward *System 1* insights and reflective, deeply analytical *System 2* segments to capture a blend of quick observations and thoughtful analysis.

---

### *Example Input Text:*

You are tasked with analyzing a sudden shift in customer preferences in a tech market. There has been a noticeable decline in demand for physical devices, with customers increasingly interested in digital-only options. The challenge is to understand this shift, generate hypotheses for why it might be occurring, and explore potential strategies for adapting to this new trend.

---

### *Processed Output with System 1 and System 2 Thinking:*

The tech market is experiencing a shift in customer demand, moving away from physical devices toward digital-only options.

[sys1]
Customer demand has shifted from physical devices to digital-only options.
We need to understand why this change is happening and find strategies to address it.
Key factors may include cost, convenience, and technological trends.
[end sys1]

[sys2]
**2.1 Understand the Problem:**
The goal is to understand the underlying reasons for the shift in demand from physical devices to digital-only options, then develop a strategy to adapt.

*Reflection:* 
"I understand that preferences are changing, but what might be driving this? Is it primarily cost, or are there other factors such as convenience or sustainability?"

*Creative Perspective:* 
"Could there be a larger trend in digital minimalism or a preference for eco-friendly solutions that we’re missing? What unseen motivations might explain this shift?"

**2.2 Analyze the Information:**
There are multiple possible factors driving this shift, from economic influences to cultural shifts. It’s essential to isolate each factor and understand its impact.

*Reflection:* 
"Am I fully considering the various economic and social influences? Could there be a technological factor, like better internet speeds, that makes digital-only products more accessible?"

*Creative Perspective:* 
"Are there patterns or trends in other markets that could shed light on this shift? Could this be part of a larger trend toward virtual experiences?"

**2.3 Generate Hypotheses:**
1. Customers prefer digital options due to lower costs. (Confidence: 0.8, Creative: 0.4)
2. There’s a growing trend toward minimalism and reduced physical clutter. (Confidence: 0.7, Creative: 0.7)
3. Digital products offer greater flexibility and ease of use. (Confidence: 0.6, Creative: 0.6)
4. Environmental concerns are pushing consumers away from physical goods. (Confidence: 0.6, Creative: 0.8)
5. Advances in tech make digital-only options more functional. (Confidence: 0.8, Creative: 0.5)
6. Pandemic-era remote work increased demand for digital solutions. (Confidence: 0.7, Creative: 0.6)
7. Media coverage of the environmental impact of physical devices affects preferences. (Confidence: 0.5, Creative: 0.7)
8. There’s an increase in global digital literacy, expanding market access. (Confidence: 0.6, Creative: 0.6)
9. Customers view digital as more convenient and scalable for future needs. (Confidence: 0.7, Creative: 0.5)
10. Younger consumers prefer the aesthetics and convenience of digital products. (Confidence: 0.6, Creative: 0.6)

*Reflection:* 
"Have I considered all possible influences? Are there any surprising factors that could explain this shift?"

*Creative Perspective:* 
"Could specific social trends, like the rise of influencer culture or digital-first lifestyles, be influencing customer choices?"

**2.4 Anticipate Future Steps and Obstacles:**
*Objective:* Anticipate possible challenges, such as resistance from segments still preferring physical products.

*Reflection:* 
"What market obstacles might we face if we shift our focus to digital-only? Are there sub-segments that still prioritize physical products?"

*Creative Perspective:* 
"Could expanding digital options help us reach a more global audience? Are there emerging trends that we could leverage in our strategy?"

[end sys2]

[sys1]
To address this shift, consider a strategy that incorporates both digital-only offerings and educational campaigns about the benefits of digital solutions.
Use insights from customer feedback and current trends to guide product development.
Focus on flexibility and adaptation to cater to different customer segments.
[end sys1]


1
00:00:00,506 --> 00:00:06,456
[ Music ]


2
00:00:06,955 --> 00:00:08,486
>> Hello. My name is Simon


3
00:00:08,486 --> 00:00:09,886
Gladman and I'm with the Vector


4
00:00:09,886 --> 00:00:10,696
and Numerics group.


5
00:00:11,316 --> 00:00:12,396
In this presentation, I'll be


6
00:00:12,396 --> 00:00:14,276
talking about two topics.


7
00:00:14,546 --> 00:00:16,736
First, our new Swift Overlay for


8
00:00:16,736 --> 00:00:17,426
Accelerate.


9
00:00:17,466 --> 00:00:19,086
And second, measuring


10
00:00:19,086 --> 00:00:20,636
Accelerate's performance using


11
00:00:20,636 --> 00:00:21,816
the Linpack benchmark.


12
00:00:22,166 --> 00:00:23,396
Before we dive into the Swift


13
00:00:23,396 --> 00:00:25,806
Overlay, let's recap exactly


14
00:00:25,806 --> 00:00:27,106
what the Accelerate framework


15
00:00:27,106 --> 00:00:27,506
is.


16
00:00:27,826 --> 00:00:30,476
The primary purpose of


17
00:00:30,476 --> 00:00:31,796
Accelerate is to provide


18
00:00:31,796 --> 00:00:33,486
thousands of low-level math


19
00:00:33,486 --> 00:00:35,676
primitives that run on a CPU and


20
00:00:35,676 --> 00:00:36,776
support image and signal


21
00:00:36,776 --> 00:00:38,676
processing, vector arithmetic,


22
00:00:38,866 --> 00:00:40,466
linear algebra, and machine


23
00:00:40,466 --> 00:00:41,006
learning.


24
00:00:41,716 --> 00:00:42,816
Most of these primitives are


25
00:00:42,816 --> 00:00:43,956
hand tuned to the


26
00:00:43,956 --> 00:00:45,076
microarchitecture of the


27
00:00:45,076 --> 00:00:45,646
processor.


28
00:00:46,206 --> 00:00:47,416
This means we get excellent


29
00:00:47,416 --> 00:00:49,636
performance and this performance


30
00:00:49,636 --> 00:00:51,356
translates directly into energy


31
00:00:51,356 --> 00:00:52,036
savings.


32
00:00:52,276 --> 00:00:54,776
So, if you're an app developer


33
00:00:54,886 --> 00:00:56,096
and you use the Accelerate


34
00:00:56,096 --> 00:00:57,666
framework, not only will your


35
00:00:57,666 --> 00:00:59,456
application run faster, but


36
00:00:59,456 --> 00:01:00,836
you'll also use less battery


37
00:01:00,836 --> 00:01:01,196
life.


38
00:01:03,366 --> 00:01:05,215
We provide the primitives across


39
00:01:05,215 --> 00:01:06,696
all of Apple's platforms.


40
00:01:06,986 --> 00:01:09,616
This includes not only macOS and


41
00:01:09,616 --> 00:01:13,966
iOS but watchOS and tVOS as


42
00:01:13,966 --> 00:01:14,316
well.


43
00:01:15,766 --> 00:01:17,236
This means your users are going


44
00:01:17,236 --> 00:01:18,526
to have an overall better


45
00:01:18,526 --> 00:01:19,296
experience.


46
00:01:20,746 --> 00:01:22,856
Accelerate's libraries are


47
00:01:22,856 --> 00:01:24,556
immensely powerful but up until


48
00:01:24,556 --> 00:01:26,226
now, their interfaces weren't


49
00:01:26,226 --> 00:01:27,266
that friendly to Swift


50
00:01:27,266 --> 00:01:27,996
developers.


51
00:01:28,516 --> 00:01:30,196
We've looked at four libraries


52
00:01:30,196 --> 00:01:32,506
and created new Swift-friendly


53
00:01:32,506 --> 00:01:33,946
APIs to make using Acclerate in


54
00:01:33,946 --> 00:01:35,646
Swift projects really easy.


55
00:01:36,446 --> 00:01:37,906
The four libraries we focused on


56
00:01:37,906 --> 00:01:41,386
are vDSP that provides digital


57
00:01:41,386 --> 00:01:42,806
signal processing routines


58
00:01:42,966 --> 00:01:44,256
including arithmetic on large


59
00:01:44,256 --> 00:01:46,506
vectors, Fourier transforms,


60
00:01:46,696 --> 00:01:48,216
biquadratic filtering, and


61
00:01:48,216 --> 00:01:49,696
powerful type conversion.


62
00:01:49,876 --> 00:01:53,536
vForce that provides arithmetic


63
00:01:53,536 --> 00:01:54,956
and transcendental functions


64
00:01:54,956 --> 00:01:56,606
including trig and logarithmic


65
00:01:56,606 --> 00:01:57,306
routines.


66
00:01:57,686 --> 00:02:00,206
Quadrature, that's dedicated to


67
00:02:00,206 --> 00:02:01,706
the numerical integration of


68
00:02:01,706 --> 00:02:02,456
functions.


69
00:02:02,836 --> 00:02:05,726
And vImage, that provides a huge


70
00:02:05,726 --> 00:02:07,126
selection of image processing


71
00:02:07,126 --> 00:02:09,096
functions and integrates easily


72
00:02:09,096 --> 00:02:10,336
with core graphics and core


73
00:02:10,336 --> 00:02:10,686
video.


74
00:02:11,476 --> 00:02:13,716
Accelerate gets its performance


75
00:02:13,716 --> 00:02:15,636
benefits by using vectorization.


76
00:02:15,946 --> 00:02:18,806
To understand vectorization,


77
00:02:18,876 --> 00:02:20,306
let's first look at a simple


78
00:02:20,306 --> 00:02:21,956
calculation over the elements of


79
00:02:21,956 --> 00:02:23,606
an array using scalar code.


80
00:02:24,666 --> 00:02:26,576
If, for example, you're writing


81
00:02:26,576 --> 00:02:28,006
code that multiplies each


82
00:02:28,006 --> 00:02:29,916
element of one array with the


83
00:02:29,916 --> 00:02:31,176
corresponding element in


84
00:02:31,176 --> 00:02:32,936
another, and you're using a four


85
00:02:32,936 --> 00:02:34,886
loop, each pair of elements are


86
00:02:34,886 --> 00:02:36,676
separately loaded, multiplied


87
00:02:36,676 --> 00:02:37,906
together, and the results


88
00:02:37,906 --> 00:02:38,306
stored.


89
00:02:39,496 --> 00:02:41,376
So, after the first elements in


90
00:02:41,376 --> 00:02:42,866
A and B are multiplied together


91
00:02:42,866 --> 00:02:44,166
to calculate the first element


92
00:02:44,166 --> 00:02:46,026
in C, the second pair are


93
00:02:46,026 --> 00:02:46,686
processed.


94
00:02:47,256 --> 00:02:49,196
Then, the third.


95
00:02:49,906 --> 00:02:54,686
And, finally, the fourth.


96
00:02:55,006 --> 00:02:56,466
However, if you're processing


97
00:02:56,466 --> 00:02:57,736
the elements of an array using


98
00:02:57,736 --> 00:02:59,826
Accelerate, your calculation is


99
00:02:59,826 --> 00:03:01,396
performed on single instruction


100
00:03:01,396 --> 00:03:03,156
multiple data, or simD


101
00:03:03,156 --> 00:03:03,816
registers.


102
00:03:04,616 --> 00:03:05,886
These registers can perform the


103
00:03:05,886 --> 00:03:07,506
same instruction on multiple


104
00:03:07,506 --> 00:03:09,606
items of data by packing those


105
00:03:09,606 --> 00:03:10,896
multiple items into a single


106
00:03:10,896 --> 00:03:11,416
register.


107
00:03:12,096 --> 00:03:14,676
For example, a single 128-bit


108
00:03:14,676 --> 00:03:17,116
register can actually store four


109
00:03:17,116 --> 00:03:19,486
32-bit floating point values.


110
00:03:19,876 --> 00:03:21,146
So, a vectorized multiply


111
00:03:21,146 --> 00:03:22,916
operation can simultaneously


112
00:03:22,916 --> 00:03:24,666
multiply four pairs of elements


113
00:03:24,666 --> 00:03:25,226
at a time.


114
00:03:26,256 --> 00:03:27,636
This means that not only will


115
00:03:27,636 --> 00:03:29,236
the task be quicker, it will


116
00:03:29,236 --> 00:03:30,936
also be significantly more


117
00:03:30,936 --> 00:03:31,756
energy efficient.


118
00:03:34,276 --> 00:03:35,926
The multiply function we just


119
00:03:35,926 --> 00:03:37,456
looked at part of Accelerate's


120
00:03:37,456 --> 00:03:38,686
digital signal processing


121
00:03:38,686 --> 00:03:40,146
library, vDSP.


122
00:03:40,766 --> 00:03:42,236
So, let's begin by looking at


123
00:03:42,236 --> 00:03:44,486
how the new Swift API simplifies


124
00:03:44,486 --> 00:03:46,146
using vDSP.


125
00:03:47,496 --> 00:03:51,176
vDSP provides vectorized digital


126
00:03:51,176 --> 00:03:52,516
signal processing functions


127
00:03:52,516 --> 00:03:53,956
including Fourier transforms,


128
00:03:53,956 --> 00:03:56,116
biquadratic filtering,


129
00:03:56,256 --> 00:03:58,496
convolution, and correlation.


130
00:03:59,676 --> 00:04:02,226
Furthermore, vDSP also provides


131
00:04:02,226 --> 00:04:03,506
some powerful, more general


132
00:04:03,506 --> 00:04:05,166
functions including element-wise


133
00:04:05,166 --> 00:04:07,326
arithmetic and type conversion.


134
00:04:09,056 --> 00:04:10,656
So, even if you don't have an


135
00:04:10,656 --> 00:04:12,396
immediate need to, for example,


136
00:04:12,396 --> 00:04:13,686
compute the coherence of two


137
00:04:13,686 --> 00:04:16,305
signals, you may find that


138
00:04:16,305 --> 00:04:17,676
vDSP's general computation


139
00:04:17,676 --> 00:04:19,586
routines offer a solution to


140
00:04:19,586 --> 00:04:21,315
improve your app's performance.


141
00:04:24,616 --> 00:04:26,096
Let's take a look at some basic


142
00:04:26,096 --> 00:04:26,816
arithmetic.


143
00:04:27,206 --> 00:04:29,776
An example could be given four


144
00:04:29,776 --> 00:04:31,056
arrays of single-precision


145
00:04:31,056 --> 00:04:33,066
values, you need to calculate


146
00:04:33,066 --> 00:04:34,456
the element-wise sum of two of


147
00:04:34,456 --> 00:04:36,266
the array's the element-wise


148
00:04:36,266 --> 00:04:37,806
difference in the other two, and


149
00:04:37,806 --> 00:04:40,306
multiply those results with each


150
00:04:40,846 --> 00:04:40,966
other.


151
00:04:41,666 --> 00:04:43,446
Using a four loop is a perfectly


152
00:04:43,446 --> 00:04:44,496
reasonable solution to this


153
00:04:44,496 --> 00:04:46,126
problem and calculates the


154
00:04:46,126 --> 00:04:47,106
expected results.


155
00:04:47,906 --> 00:04:49,706
Here's how you perform that


156
00:04:49,706 --> 00:04:52,096
calculation using vDSP's classic


157
00:04:52,096 --> 00:04:52,416
API.


158
00:04:53,526 --> 00:04:55,276
Using vDSP is approximately


159
00:04:55,276 --> 00:04:57,166
three times faster than the four


160
00:04:57,166 --> 00:04:57,536
loop.


161
00:04:59,536 --> 00:05:00,926
Here's the same computation


162
00:05:00,926 --> 00:05:02,566
using our new Swift API for


163
00:05:02,566 --> 00:05:03,206
vDSP.


164
00:05:03,206 --> 00:05:05,426
We're exposing the new


165
00:05:05,426 --> 00:05:06,906
Swift-friendly functions through


166
00:05:06,906 --> 00:05:09,076
our vDSP namespace and you can


167
00:05:09,076 --> 00:05:10,366
see the function and parameter


168
00:05:10,366 --> 00:05:11,896
names explain the operation.


169
00:05:12,806 --> 00:05:14,176
Because the new functions work


170
00:05:14,176 --> 00:05:15,626
with familiar types including


171
00:05:15,626 --> 00:05:17,146
arrays and array slices rather


172
00:05:17,146 --> 00:05:18,866
than pointers, you no longer


173
00:05:18,866 --> 00:05:20,296
need to explicitly pass the


174
00:05:20,296 --> 00:05:20,736
count.


175
00:05:21,246 --> 00:05:22,536
So, the entire function call is


176
00:05:22,536 --> 00:05:24,616
clearer and more concise.


177
00:05:25,776 --> 00:05:28,676
Passing an initialized result


178
00:05:28,676 --> 00:05:29,686
array offers the best


179
00:05:29,686 --> 00:05:31,236
performance and you can


180
00:05:31,236 --> 00:05:32,936
obviously reuse that array in


181
00:05:32,936 --> 00:05:34,476
other operations for further


182
00:05:34,476 --> 00:05:35,646
performance benefits.


183
00:05:36,446 --> 00:05:38,946
However, we're also providing


184
00:05:38,946 --> 00:05:40,726
self-allocating functions.


185
00:05:41,096 --> 00:05:42,846
These make use of Swift's new


186
00:05:42,846 --> 00:05:44,596
ability to access an array's


187
00:05:44,596 --> 00:05:46,786
uninitialized buffer to return


188
00:05:46,786 --> 00:05:48,156
the result of a computation.


189
00:05:48,936 --> 00:05:50,496
Although not quite as fast as


190
00:05:50,496 --> 00:05:52,386
passing existing storage, it's


191
00:05:52,386 --> 00:05:53,936
still faster than the scalar


192
00:05:53,936 --> 00:05:55,936
approach and, in some cases,


193
00:05:55,936 --> 00:05:58,846
will simplify your code.


194
00:06:00,076 --> 00:06:02,006
Another common task that vDSP


195
00:06:02,006 --> 00:06:03,286
can vectorize is type


196
00:06:03,286 --> 00:06:03,976
conversion.


197
00:06:04,536 --> 00:06:06,416
This example converts an array


198
00:06:06,416 --> 00:06:07,566
containing double precision


199
00:06:07,566 --> 00:06:10,256
values to 16-bit unsigned


200
00:06:10,256 --> 00:06:11,846
integer values rounding toward


201
00:06:11,846 --> 00:06:12,326
zero.


202
00:06:13,676 --> 00:06:16,796
The scalar version uses map with


203
00:06:16,796 --> 00:06:17,776
explicit rounding.


204
00:06:18,136 --> 00:06:20,026
Again, this is a perfectly


205
00:06:20,026 --> 00:06:21,776
reasonable technique to use, but


206
00:06:21,776 --> 00:06:24,156
vDSP can vectorize this task to


207
00:06:24,156 --> 00:06:25,266
improve performance.


208
00:06:25,806 --> 00:06:29,196
In this example, vDSP is


209
00:06:29,196 --> 00:06:31,036
approximately four times faster


210
00:06:31,036 --> 00:06:32,616
than the previous scalar


211
00:06:32,616 --> 00:06:33,446
implementation.


212
00:06:34,876 --> 00:06:37,386
The new Swift version of the


213
00:06:37,386 --> 00:06:38,996
vDSP function offers a clear


214
00:06:38,996 --> 00:06:39,746
interface.


215
00:06:40,596 --> 00:06:42,166
The function accepts a source


216
00:06:42,166 --> 00:06:42,486
array.


217
00:06:42,916 --> 00:06:44,116
The integer type you ought to


218
00:06:44,116 --> 00:06:46,036
convert each element to, and an


219
00:06:46,036 --> 00:06:47,636
enumeration to specify the


220
00:06:47,636 --> 00:06:48,196
rounding.


221
00:06:51,936 --> 00:06:54,416
vDSP provides Fourier transforms


222
00:06:54,416 --> 00:06:55,946
for transforming one-dimensional


223
00:06:56,056 --> 00:06:57,966
and two-dimensional data between


224
00:06:57,966 --> 00:06:59,176
the time domain and the


225
00:06:59,176 --> 00:07:00,176
frequency domain.


226
00:07:00,456 --> 00:07:03,276
A forward Fourier transform of a


227
00:07:03,276 --> 00:07:05,286
signal decomposes it into its


228
00:07:05,286 --> 00:07:06,486
component sign waves.


229
00:07:06,896 --> 00:07:08,106
That's the frequency domain


230
00:07:08,106 --> 00:07:08,926
representation.


231
00:07:10,006 --> 00:07:12,056
Conversely, an inverse transform


232
00:07:12,056 --> 00:07:13,076
of that frequency domain


233
00:07:13,076 --> 00:07:14,886
representation recreates the


234
00:07:14,886 --> 00:07:16,506
original signal and that's the


235
00:07:16,506 --> 00:07:17,986
time domain representation.


236
00:07:18,446 --> 00:07:20,576
Fourier transforms have many


237
00:07:20,576 --> 00:07:22,296
uses in both signal and image


238
00:07:22,296 --> 00:07:22,936
processing.


239
00:07:23,436 --> 00:07:24,936
For example, once an audio


240
00:07:24,936 --> 00:07:26,146
signal has been forward


241
00:07:26,146 --> 00:07:27,816
transformed, you can easily


242
00:07:27,816 --> 00:07:29,726
reduce or increase certain


243
00:07:29,726 --> 00:07:31,026
frequencies to equalize the


244
00:07:31,026 --> 00:07:31,406
audio.


245
00:07:33,136 --> 00:07:35,056
The classic API is reasonably


246
00:07:35,056 --> 00:07:36,086
easy to follow if you're


247
00:07:36,086 --> 00:07:36,666
familiar with it.


248
00:07:37,116 --> 00:07:38,686
You begin by creating a setup


249
00:07:38,686 --> 00:07:40,346
object specifying the number of


250
00:07:40,346 --> 00:07:41,666
elements you want to transform


251
00:07:41,746 --> 00:07:42,766
and the direction.


252
00:07:43,386 --> 00:07:45,166
Then, after creating two arrays


253
00:07:45,166 --> 00:07:46,886
to receive results, you call the


254
00:07:46,886 --> 00:07:47,776
execute function.


255
00:07:47,776 --> 00:07:49,496
Once you're done, you need to


256
00:07:49,496 --> 00:07:51,036
remember to destroy the setup to


257
00:07:51,036 --> 00:07:52,796
free the resources allocated to


258
00:07:53,256 --> 00:07:53,326
it.


259
00:07:53,956 --> 00:07:56,476
The new API simplifies the


260
00:07:56,476 --> 00:07:57,946
instantiation of the setup


261
00:07:57,946 --> 00:08:00,596
object and the transform itself


262
00:08:00,596 --> 00:08:02,536
is a method with parameter names


263
00:08:02,606 --> 00:08:04,016
on the DFT instance.


264
00:08:04,016 --> 00:08:06,336
And now you don't need to worry


265
00:08:06,336 --> 00:08:07,576
about freeing the resources.


266
00:08:07,576 --> 00:08:08,546
We do that for you.


267
00:08:10,376 --> 00:08:12,686
And much like the vDSP functions


268
00:08:12,686 --> 00:08:14,046
we've looked at, there's a


269
00:08:14,046 --> 00:08:15,626
self-allocating version of the


270
00:08:15,626 --> 00:08:17,796
transform function that creates


271
00:08:17,796 --> 00:08:19,516
and returns the result's arrays


272
00:08:19,516 --> 00:08:20,046
for you.


273
00:08:23,996 --> 00:08:25,796
If you work with audio data, you


274
00:08:25,796 --> 00:08:27,596
may be familiar with biquadratic


275
00:08:27,596 --> 00:08:28,776
or biquad filtering.


276
00:08:29,606 --> 00:08:31,036
Biquad filters can be used to


277
00:08:31,036 --> 00:08:32,655
equalize audio to shape the


278
00:08:32,655 --> 00:08:34,216
frequency response, allowing you


279
00:08:34,216 --> 00:08:36,506
to, for example, remove either


280
00:08:36,506 --> 00:08:37,966
low or high frequencies.


281
00:08:39,186 --> 00:08:41,966
vDSP's biquad feature operates


282
00:08:41,966 --> 00:08:43,395
on single and multichannel


283
00:08:43,395 --> 00:08:45,356
signals, and uses a set of


284
00:08:45,386 --> 00:08:46,996
individual filter objects called


285
00:08:46,996 --> 00:08:47,716
sections.


286
00:08:48,286 --> 00:08:49,986
The filters are cascaded; that


287
00:08:49,986 --> 00:08:51,156
is, they are set up in a


288
00:08:51,156 --> 00:08:53,006
sequence and the entire signal


289
00:08:53,006 --> 00:08:54,476
passes through each filter in


290
00:08:54,476 --> 00:08:54,956
turn.


291
00:08:55,956 --> 00:08:57,166
The filters are defined by a


292
00:08:57,166 --> 00:08:59,086
series of coefficients that plug


293
00:08:59,086 --> 00:09:00,286
into the equation shown here.


294
00:09:00,896 --> 00:09:05,336
In this example, these values


295
00:09:05,336 --> 00:09:07,286
form a low pass filter; that is,


296
00:09:07,286 --> 00:09:08,756
a filter that reduces high


297
00:09:08,756 --> 00:09:09,456
frequencies.


298
00:09:09,876 --> 00:09:11,906
Here's the code using vDSP's


299
00:09:11,906 --> 00:09:13,816
classic API to create the biquad


300
00:09:13,816 --> 00:09:15,516
setup using the coefficients in


301
00:09:15,516 --> 00:09:16,446
the previous slide.


302
00:09:17,196 --> 00:09:19,506
And here's the code to apply


303
00:09:19,506 --> 00:09:21,386
that biquad filter to an array


304
00:09:21,386 --> 00:09:23,056
named signal, returning the


305
00:09:23,056 --> 00:09:25,086
result to an array named output.


306
00:09:25,086 --> 00:09:27,006
Let's look at the same


307
00:09:27,006 --> 00:09:28,696
functionality implemented with a


308
00:09:28,696 --> 00:09:29,436
new API.


309
00:09:31,716 --> 00:09:33,906
As you can see, the new API


310
00:09:34,036 --> 00:09:35,866
vastly simplifies the creation


311
00:09:35,866 --> 00:09:36,846
of the biquad structure.


312
00:09:37,596 --> 00:09:39,196
You simply pass the coefficients


313
00:09:39,196 --> 00:09:40,896
to the biquad initializer and


314
00:09:40,896 --> 00:09:42,466
specify the number of channels


315
00:09:42,466 --> 00:09:43,326
and sections.


316
00:09:44,286 --> 00:09:46,346
Applying the biquad filter to a


317
00:09:46,346 --> 00:09:47,926
signal is a single function


318
00:09:47,926 --> 00:09:48,226
call.


319
00:09:51,496 --> 00:09:54,456
Now, let's look at the new API


320
00:09:54,456 --> 00:09:55,686
we've created for Accelerate's


321
00:09:55,686 --> 00:09:57,356
library for fast mathematical


322
00:09:57,356 --> 00:09:58,856
operations on large arrays,


323
00:09:59,146 --> 00:09:59,956
vForce.


324
00:10:01,896 --> 00:10:03,856
vForce provides transcendental


325
00:10:03,856 --> 00:10:05,976
functions not included in vDSP.


326
00:10:06,526 --> 00:10:08,196
These include exponential,


327
00:10:08,346 --> 00:10:09,576
logarithmic, and trig


328
00:10:09,576 --> 00:10:10,376
operations.


329
00:10:12,256 --> 00:10:13,996
A typical example of vForce


330
00:10:13,996 --> 00:10:15,496
would be to calculate the square


331
00:10:15,496 --> 00:10:16,956
root of each element in a large


332
00:10:16,956 --> 00:10:17,356
array.


333
00:10:18,006 --> 00:10:19,556
The scalar version of this code


334
00:10:19,556 --> 00:10:20,466
could use map.


335
00:10:22,196 --> 00:10:24,116
vForce provides a vectorized


336
00:10:24,116 --> 00:10:25,806
function to calculate the square


337
00:10:25,806 --> 00:10:27,666
roots that in some situations


338
00:10:27,666 --> 00:10:29,436
can be up to 10 times faster


339
00:10:29,586 --> 00:10:31,096
than the scalar implementation.


340
00:10:32,856 --> 00:10:34,996
The new Swift overlay offers an


341
00:10:34,996 --> 00:10:36,756
API that's consistent with the


342
00:10:36,756 --> 00:10:39,536
new vDSP functions and provides


343
00:10:39,536 --> 00:10:40,806
the performance and energy


344
00:10:40,806 --> 00:10:41,866
efficiency benefits of


345
00:10:41,866 --> 00:10:42,756
vectorization.


346
00:10:43,296 --> 00:10:46,186
And much like we've seen


347
00:10:46,186 --> 00:10:46,846
earlier, there's a


348
00:10:46,846 --> 00:10:48,746
self-allocating version that


349
00:10:48,746 --> 00:10:50,486
returns an array containing the


350
00:10:50,486 --> 00:10:51,806
square roots of each element in


351
00:10:51,806 --> 00:10:53,000
the supplied array.


352
00:10:57,056 --> 00:10:58,256
Next, we'll take a look at the


353
00:10:58,256 --> 00:11:01,036
new API we've created for


354
00:11:01,736 --> 00:11:02,456
Quadrature.


355
00:11:02,566 --> 00:11:04,516
Quadrature is a historic term


356
00:11:04,516 --> 00:11:06,006
for determining the area under a


357
00:11:06,006 --> 00:11:06,416
curve.


358
00:11:07,246 --> 00:11:09,126
It provides an approximation of


359
00:11:09,126 --> 00:11:10,266
the definite integrative


360
00:11:10,266 --> 00:11:11,946
function over a finite or


361
00:11:11,946 --> 00:11:12,956
infinite interval.


362
00:11:13,556 --> 00:11:15,736
In this example, we'll use


363
00:11:15,736 --> 00:11:17,186
Quadrature to approximate the


364
00:11:17,186 --> 00:11:19,046
area of a semicircle, shown here


365
00:11:19,046 --> 00:11:21,026
in green, by integrating the


366
00:11:21,026 --> 00:11:22,536
functions shown.


367
00:11:24,396 --> 00:11:26,836
Much like the Biquad code for


368
00:11:26,836 --> 00:11:28,896
vDSP, there's a fair amount of


369
00:11:28,896 --> 00:11:30,376
code required to use the


370
00:11:30,376 --> 00:11:31,926
existing Quadrature API.


371
00:11:32,616 --> 00:11:35,006
The first step is to define a


372
00:11:35,006 --> 00:11:36,346
structure that describes a


373
00:11:36,346 --> 00:11:37,616
function to integrate.


374
00:11:39,076 --> 00:11:41,716
The second step is to define the


375
00:11:41,716 --> 00:11:43,456
integration options including


376
00:11:43,456 --> 00:11:44,726
the integration algorithm.


377
00:11:45,496 --> 00:11:48,296
Finally, with the function on


378
00:11:48,296 --> 00:11:50,416
options defined, you can perform


379
00:11:50,416 --> 00:11:51,566
the integration using the


380
00:11:51,566 --> 00:11:53,016
Quadrature integrate function.


381
00:11:55,946 --> 00:11:58,386
The new API simplifies the code.


382
00:11:58,886 --> 00:12:00,476
One great advantage is that you


383
00:12:00,476 --> 00:12:02,256
can specify the integrand, that


384
00:12:02,256 --> 00:12:03,196
is, the function to be


385
00:12:03,196 --> 00:12:05,246
integrated, as a trading closure


386
00:12:05,426 --> 00:12:06,626
rather than as a C function


387
00:12:06,626 --> 00:12:07,066
pointer.


388
00:12:07,636 --> 00:12:09,186
This means you can easily pass


389
00:12:09,186 --> 00:12:10,646
values into the integrand.


390
00:12:11,606 --> 00:12:13,716
Also note that integrators are


391
00:12:13,716 --> 00:12:15,616
now enumerations with associated


392
00:12:15,616 --> 00:12:16,286
values.


393
00:12:16,736 --> 00:12:18,146
So, there's no need to supply


394
00:12:18,146 --> 00:12:19,986
unnecessary points for interval


395
00:12:20,016 --> 00:12:21,446
or maximum intervals here.


396
00:12:21,806 --> 00:12:24,896
For example, you can pass the


397
00:12:24,896 --> 00:12:26,236
enumeration for the globally


398
00:12:26,236 --> 00:12:28,376
adaptive integrator specifying


399
00:12:28,456 --> 00:12:29,596
the points for interval and


400
00:12:29,596 --> 00:12:30,686
maximum intervals.


401
00:12:33,456 --> 00:12:36,676
Now, let's look at the new API


402
00:12:36,806 --> 00:12:38,316
we've created for Accelerate's


403
00:12:38,316 --> 00:12:39,536
image processing library,


404
00:12:39,536 --> 00:12:40,216
vImage.


405
00:12:41,876 --> 00:12:43,606
vImage is a library containing a


406
00:12:43,606 --> 00:12:44,936
rich collection of image


407
00:12:44,936 --> 00:12:45,906
processing tools.


408
00:12:46,536 --> 00:12:48,456
It's designed to work seamlessly


409
00:12:48,456 --> 00:12:51,186
with both core graphics and core


410
00:12:51,186 --> 00:12:51,736
video.


411
00:12:51,786 --> 00:12:54,506
It includes operations such as


412
00:12:54,506 --> 00:12:56,966
alpha blending, format


413
00:12:56,966 --> 00:12:59,216
conversions, histogram


414
00:12:59,216 --> 00:13:01,696
operations, convolution,


415
00:13:02,596 --> 00:13:05,216
geometry, and morphology.


416
00:13:07,516 --> 00:13:10,336
Our new Swift API introduces


417
00:13:10,336 --> 00:13:11,806
lots of new features that makes


418
00:13:11,806 --> 00:13:14,116
using vImage in Swift easier and


419
00:13:14,116 --> 00:13:15,006
more concise.


420
00:13:15,556 --> 00:13:16,906
We've implemented flags as an


421
00:13:16,906 --> 00:13:17,576
option set.


422
00:13:18,236 --> 00:13:20,436
vImages throw Swift errors.


423
00:13:20,436 --> 00:13:21,886
And we've hidden some of the


424
00:13:21,886 --> 00:13:23,466
requirements for mutability and


425
00:13:23,466 --> 00:13:25,236
working with unmanaged types.


426
00:13:27,646 --> 00:13:28,696
If you're working with core


427
00:13:28,696 --> 00:13:30,076
graphics images, there's a


428
00:13:30,076 --> 00:13:31,606
common workflow to get that


429
00:13:31,606 --> 00:13:33,356
image data into a vImage buffer.


430
00:13:35,076 --> 00:13:36,706
First, you need to create a


431
00:13:36,706 --> 00:13:38,386
description of the CG images


432
00:13:38,386 --> 00:13:38,916
format.


433
00:13:40,286 --> 00:13:42,166
Then, instantiate a vImage


434
00:13:42,166 --> 00:13:42,596
buffer.


435
00:13:43,366 --> 00:13:44,766
Initialize that buffer from the


436
00:13:44,766 --> 00:13:45,246
image.


437
00:13:45,246 --> 00:13:46,986
And finally, check for errors in


438
00:13:46,986 --> 00:13:48,426
a non-Swift way.


439
00:13:48,696 --> 00:13:50,656
And that's a lot of boilerplate


440
00:13:50,656 --> 00:13:52,236
code for a common operation.


441
00:13:53,226 --> 00:13:55,936
The new API wraps up all of that


442
00:13:55,936 --> 00:13:58,056
code into a single throwable


443
00:13:58,056 --> 00:13:58,696
initializer.


444
00:13:59,906 --> 00:14:02,396
However, since we're going to


445
00:14:02,396 --> 00:14:04,196
use a CG images format later,


446
00:14:04,356 --> 00:14:05,896
here's similar functionality


447
00:14:05,966 --> 00:14:07,516
implemented in two steps with a


448
00:14:07,516 --> 00:14:07,976
new API.


449
00:14:08,726 --> 00:14:10,876
We've added a new initializer to


450
00:14:10,876 --> 00:14:12,686
CG image format using a CG


451
00:14:12,686 --> 00:14:15,086
image, and an alternative buffer


452
00:14:15,086 --> 00:14:16,976
initializer that accepts a CG


453
00:14:16,976 --> 00:14:18,716
image and an explicit format


454
00:14:18,716 --> 00:14:19,266
description.


455
00:14:19,666 --> 00:14:22,546
Once you're finished working


456
00:14:22,546 --> 00:14:23,806
with a buffer, here's the


457
00:14:23,806 --> 00:14:25,236
classic vImage function to


458
00:14:25,236 --> 00:14:26,716
create a CG image from the


459
00:14:26,716 --> 00:14:27,736
buffer's contents.


460
00:14:28,696 --> 00:14:30,856
And our new API simplifies that


461
00:14:30,856 --> 00:14:33,336
operation too with a new create


462
00:14:33,336 --> 00:14:34,796
CG image method that uses the


463
00:14:34,796 --> 00:14:36,296
format we've just generated from


464
00:14:36,296 --> 00:14:36,776
the image.


465
00:14:37,876 --> 00:14:40,156
One important use case for


466
00:14:40,156 --> 00:14:41,916
vImage is converting between


467
00:14:41,916 --> 00:14:43,286
different domains and different


468
00:14:43,286 --> 00:14:44,026
formats.


469
00:14:44,576 --> 00:14:46,636
vImage's any-to-any convertors


470
00:14:46,636 --> 00:14:48,246
can convert between core video


471
00:14:48,246 --> 00:14:50,206
and core graphics, and convert


472
00:14:50,206 --> 00:14:51,966
between different core graphics


473
00:14:51,966 --> 00:14:52,586
formats.


474
00:14:53,926 --> 00:14:55,926
For example, you might want to


475
00:14:55,926 --> 00:14:57,956
convert a CMYK core graphics


476
00:14:57,956 --> 00:14:59,876
image to RGB.


477
00:15:01,056 --> 00:15:03,706
The existing API to create a


478
00:15:03,706 --> 00:15:05,516
convertor accepts the source and


479
00:15:05,516 --> 00:15:06,756
destination formats for the


480
00:15:06,756 --> 00:15:08,446
conversion and returns an


481
00:15:08,446 --> 00:15:09,646
unmanaged convertor.


482
00:15:11,036 --> 00:15:12,486
You take the managed reference


483
00:15:12,486 --> 00:15:14,126
of the convertor and pass that


484
00:15:14,126 --> 00:15:15,116
to the function that does the


485
00:15:15,116 --> 00:15:15,756
conversion.


486
00:15:17,216 --> 00:15:19,906
Our new API adds a new static


487
00:15:19,906 --> 00:15:21,276
make function to the existing


488
00:15:21,276 --> 00:15:22,996
convertor type that returns a


489
00:15:22,996 --> 00:15:24,336
convertor instance.


490
00:15:25,006 --> 00:15:27,566
The conversion is done with the


491
00:15:27,566 --> 00:15:29,156
convert method on the convertor


492
00:15:29,156 --> 00:15:29,856
instance.


493
00:15:31,076 --> 00:15:33,176
Finally, let's look at working


494
00:15:33,176 --> 00:15:34,896
with core video image formats.


495
00:15:35,456 --> 00:15:37,396
In a typical example, you may


496
00:15:37,396 --> 00:15:39,176
want to create an image format


497
00:15:39,176 --> 00:15:40,926
description from a core video


498
00:15:40,926 --> 00:15:43,276
pixel buffer and calculate its


499
00:15:43,276 --> 00:15:43,996
channel count.


500
00:15:45,406 --> 00:15:46,786
Here's the code required by the


501
00:15:46,786 --> 00:15:49,366
classic vImage API to create an


502
00:15:49,366 --> 00:15:50,756
image format description from a


503
00:15:50,756 --> 00:15:52,406
pixel buffer and get its channel


504
00:15:52,406 --> 00:15:52,766
count.


505
00:15:53,216 --> 00:15:55,976
The new API provides the same


506
00:15:55,976 --> 00:15:57,516
functionality in two lines of


507
00:15:57,516 --> 00:15:57,946
code.


508
00:15:58,756 --> 00:16:00,446
You create an instance of a core


509
00:16:00,446 --> 00:16:01,946
video image format from a pixel


510
00:16:01,946 --> 00:16:03,826
buffer using a new static make


511
00:16:03,826 --> 00:16:04,316
function.


512
00:16:04,956 --> 00:16:07,136
And simply access its channel


513
00:16:07,136 --> 00:16:11,866
count as a property.


514
00:16:13,266 --> 00:16:14,806
That was a quick tour of a


515
00:16:14,806 --> 00:16:15,936
fraction of the new API.


516
00:16:16,426 --> 00:16:18,506
Let's now take a look at Linpack


517
00:16:18,506 --> 00:16:20,126
Benchmark and see just how much


518
00:16:20,126 --> 00:16:22,036
faster and more energy efficient


519
00:16:22,036 --> 00:16:23,016
Accelerate can be.


520
00:16:24,076 --> 00:16:25,696
The Linpack Benchmark came out


521
00:16:25,696 --> 00:16:27,146
of the Linpack library which


522
00:16:27,146 --> 00:16:28,776
started as a set of routines for


523
00:16:28,776 --> 00:16:31,026
providing fast computational


524
00:16:31,026 --> 00:16:31,856
linear algebra.


525
00:16:32,206 --> 00:16:34,576
This was later subsumed by a


526
00:16:34,576 --> 00:16:36,006
library called LApack, which


527
00:16:36,006 --> 00:16:37,216
stands for Linear algebra


528
00:16:37,216 --> 00:16:37,796
package.


529
00:16:38,396 --> 00:16:40,536
LApack was developed to take


530
00:16:40,536 --> 00:16:42,006
advantage of these new things at


531
00:16:42,006 --> 00:16:43,066
the time called caches.


532
00:16:43,066 --> 00:16:45,506
LApack is comprised of many


533
00:16:45,616 --> 00:16:46,436
blocked algorithms.


534
00:16:46,436 --> 00:16:48,426
These algorit6thms are built on


535
00:16:48,426 --> 00:16:49,496
top of another library called


536
00:16:49,496 --> 00:16:51,036
BLAS, which stands for basic


537
00:16:51,036 --> 00:16:52,786
linear algebra subroutines.


538
00:16:52,956 --> 00:16:55,416
We'll talk more about BLAS later


539
00:16:55,416 --> 00:16:56,366
in this presentation.


540
00:16:56,786 --> 00:16:58,806
For now, keep in mind that the


541
00:16:58,806 --> 00:17:00,536
Linpack Benchmark runs on top of


542
00:17:00,536 --> 00:17:02,246
LApack, which runs on top of


543
00:17:02,246 --> 00:17:03,000
BLAS.


544
00:17:05,955 --> 00:17:07,435
The Linpack Benchmark measures


545
00:17:07,435 --> 00:17:09,396
how quickly a platform can solve


546
00:17:09,396 --> 00:17:10,675
a general system of linear


547
00:17:10,675 --> 00:17:11,376
equations.


548
00:17:12,156 --> 00:17:13,806
It is comprised of two steps.


549
00:17:14,116 --> 00:17:15,896
The matrix factorization step,


550
00:17:16,036 --> 00:17:17,665
followed by the backsole step.


551
00:17:18,425 --> 00:17:19,935
By fixing the algorithm, we're


552
00:17:19,935 --> 00:17:21,336
able to see how well different


553
00:17:21,336 --> 00:17:22,596
platforms are at running the


554
00:17:22,596 --> 00:17:23,146
algorithm.


555
00:17:24,036 --> 00:17:25,415
This provides us with a method


556
00:17:25,415 --> 00:17:26,425
of comparing different


557
00:17:26,425 --> 00:17:27,096
platforms.


558
00:17:27,776 --> 00:17:29,036
The Linpack Benchmark has


559
00:17:29,036 --> 00:17:30,086
evolved over time.


560
00:17:30,666 --> 00:17:32,626
Originally, it solved a 100 by


561
00:17:32,626 --> 00:17:35,746
100 system, and later a 1000 by


562
00:17:35,746 --> 00:17:36,826
1000 system.


563
00:17:37,426 --> 00:17:39,556
The variant most often used


564
00:17:39,556 --> 00:17:41,326
today is the no holds barred


565
00:17:41,326 --> 00:17:43,476
variant, where the problem size


566
00:17:43,536 --> 00:17:44,696
can be as large as you want.


567
00:17:45,366 --> 00:17:47,206
This is the variant we will be


568
00:17:47,206 --> 00:17:47,876
running today.


569
00:17:48,476 --> 00:17:51,026
We are now going to compare


570
00:17:51,026 --> 00:17:52,726
Linpack performance on an iPhone


571
00:17:52,726 --> 00:17:53,316
10S.


572
00:17:53,806 --> 00:17:55,876
At the top in orange, we're


573
00:17:55,876 --> 00:17:57,676
going to run an unoptimized


574
00:17:57,676 --> 00:17:58,226
Linpack.


575
00:17:58,996 --> 00:18:00,656
This Linpack Benchmark does not


576
00:18:00,656 --> 00:18:01,766
make use of the accelerate


577
00:18:01,766 --> 00:18:02,306
framework.


578
00:18:02,966 --> 00:18:04,366
It relies on software that is


579
00:18:04,366 --> 00:18:05,846
not tuned to the process that it


580
00:18:05,846 --> 00:18:06,796
is running on.


581
00:18:07,106 --> 00:18:10,976
Let's see what that looks like.


582
00:18:11,046 --> 00:18:12,446
We are now going to compare that


583
00:18:12,446 --> 00:18:13,436
with using the Accelerate


584
00:18:13,436 --> 00:18:15,636
framework; that is, we're going


585
00:18:15,636 --> 00:18:17,486
to run the same benchmark on the


586
00:18:17,486 --> 00:18:19,346
same platform, but using the


587
00:18:19,346 --> 00:18:21,086
Accelerate framework which is


588
00:18:21,086 --> 00:18:22,286
tuned to the platform.


589
00:18:25,856 --> 00:18:27,456
We can see that by using the


590
00:18:27,456 --> 00:18:29,096
Accelerate framework, we are


591
00:18:29,096 --> 00:18:30,996
over 24 times faster.


592
00:18:31,836 --> 00:18:33,376
This will not only save time,


593
00:18:33,376 --> 00:18:35,416
but also energy, which improves


594
00:18:35,416 --> 00:18:36,166
battery life.


595
00:18:36,936 --> 00:18:38,436
We're now going to shift gears


596
00:18:38,436 --> 00:18:39,606
and take a look at the primary


597
00:18:39,606 --> 00:18:40,876
workhorse routine for the


598
00:18:40,876 --> 00:18:42,716
Linpack Benchmark called GEMM.


599
00:18:44,396 --> 00:18:46,916
As I mentioned earlier, Linpack,


600
00:18:47,166 --> 00:18:49,316
which runs on LApack, is built


601
00:18:49,316 --> 00:18:50,276
on top of BLAS.


602
00:18:51,036 --> 00:18:52,746
Within BLAS is a routine called


603
00:18:52,746 --> 00:18:54,346
GEMM, which stands for general


604
00:18:54,346 --> 00:18:55,446
matrix multiplier.


605
00:18:56,086 --> 00:18:58,156
This routine is used to


606
00:18:58,156 --> 00:18:59,746
implement several other blocked


607
00:18:59,746 --> 00:19:01,866
routines in BLAS, which are used


608
00:19:01,866 --> 00:19:03,536
inside the blocked algorithms at


609
00:19:03,596 --> 00:19:06,106
LApack, most notably the matrix


610
00:19:06,106 --> 00:19:07,556
factorization and solver


611
00:19:07,556 --> 00:19:08,256
routines.


612
00:19:09,516 --> 00:19:11,006
Because of this, GEMM is


613
00:19:11,006 --> 00:19:12,746
sometimes used as a proxy for


614
00:19:12,746 --> 00:19:13,456
performance.


615
00:19:13,456 --> 00:19:15,246
For this presentation, we are


616
00:19:15,246 --> 00:19:16,436
specifically going to look at


617
00:19:16,436 --> 00:19:18,146
the single-precision variant of


618
00:19:18,146 --> 00:19:18,526
GEMM.


619
00:19:20,466 --> 00:19:21,846
Here, we're going to compare the


620
00:19:21,846 --> 00:19:23,516
performance of the Eigen library


621
00:19:23,516 --> 00:19:24,606
with that of Accelerate.


622
00:19:25,436 --> 00:19:26,916
Both the Eigen library and the


623
00:19:26,916 --> 00:19:28,856
Accelerate framework will run on


624
00:19:28,856 --> 00:19:30,456
top of an iPhone 10S.


625
00:19:30,916 --> 00:19:32,006
Both will be performing a


626
00:19:32,006 --> 00:19:33,286
single-precision matrix


627
00:19:33,286 --> 00:19:33,836
multiplier.


628
00:19:34,236 --> 00:19:38,536
Let's see how well Eigen does.


629
00:19:38,536 --> 00:19:40,346
Eigen tops out at about 51


630
00:19:40,346 --> 00:19:41,096
gigaflops.


631
00:19:41,296 --> 00:19:43,086
Now, let's see how well


632
00:19:43,086 --> 00:19:43,916
Accelerate does.


633
00:19:44,476 --> 00:19:47,616
We can see that the Accelerate


634
00:19:47,616 --> 00:19:48,916
framework is almost two and a


635
00:19:48,916 --> 00:19:50,716
half times faster than Eigen on


636
00:19:50,716 --> 00:19:51,606
the same platform.


637
00:19:52,636 --> 00:19:53,996
This is because the Accelerate


638
00:19:53,996 --> 00:19:55,696
framework is hand-tuned to the


639
00:19:55,696 --> 00:19:57,706
platform, allowing us to fully


640
00:19:57,706 --> 00:19:59,146
take advantage of what the


641
00:19:59,146 --> 00:20:01,046
platform can offer.


642
00:20:01,046 --> 00:20:03,706
So, if you're a developer, using


643
00:20:03,706 --> 00:20:04,876
Accelerate in your app will


644
00:20:04,876 --> 00:20:05,996
offer better performance.


645
00:20:06,486 --> 00:20:08,106
This performance translates into


646
00:20:08,106 --> 00:20:09,676
less energy, which means better


647
00:20:09,676 --> 00:20:11,696
battery life and an overall


648
00:20:11,886 --> 00:20:13,056
better experience for your


649
00:20:13,056 --> 00:20:13,566
users.


650
00:20:15,586 --> 00:20:17,896
In summary, Accelerate provides


651
00:20:17,896 --> 00:20:19,036
functions for performing


652
00:20:19,036 --> 00:20:20,756
large-scale mathematical


653
00:20:20,756 --> 00:20:22,166
computations and image


654
00:20:22,166 --> 00:20:24,136
calculations that are fast and


655
00:20:24,136 --> 00:20:24,966
energy efficient.


656
00:20:25,296 --> 00:20:27,006
And now we've added a


657
00:20:27,006 --> 00:20:29,136
Swift-friendly API that makes


658
00:20:29,136 --> 00:20:30,616
Accelerate's libraries super


659
00:20:30,616 --> 00:20:32,396
easy to work with so your users


660
00:20:32,396 --> 00:20:33,256
will benefit from that


661
00:20:33,256 --> 00:20:34,536
performance and energy


662
00:20:34,536 --> 00:20:35,126
efficiency.


663
00:20:36,516 --> 00:20:37,866
Please visit our site where we


664
00:20:37,866 --> 00:20:39,536
have samples, articles, and


665
00:20:39,536 --> 00:20:41,036
extensive reference material


666
00:20:41,036 --> 00:20:42,496
that covers the entire


667
00:20:42,536 --> 00:20:43,906
Accelerate framework.


668
00:20:44,266 --> 00:20:45,176
Thank you very much.