You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 24, 2020. It is now read-only.
Copy file name to clipboardExpand all lines: source/rst/need_for_speed.rst
+29-17Lines changed: 29 additions & 17 deletions
Original file line number
Diff line number
Diff line change
@@ -61,11 +61,14 @@ routines we want to use.
61
61
For example, it's almost always better to use an existing routine for root
62
62
finding than to write a new one from scratch.
63
63
64
+
(For standard algorithms, efficiency is maximized if the community can coordinate on a
65
+
common set of implementations, written by experts and tuned by users to be as fast and robust as possible.)
66
+
64
67
But this is not the only reason that we use Python's scientific libraries.
65
68
66
69
Another is that pure Python, while flexible and elegant, is not fast.
67
70
68
-
So we need libraries that help us accelerate our Python code.
71
+
So we need libraries that are designed to accelerate execution of Python code.
69
72
70
73
As we'll see below, there are now Python libraries that can do this extremely well.
71
74
@@ -131,17 +134,19 @@ Indeed, the standard implementation of Python (called CPython) cannot match the
131
134
132
135
Does that mean that we should just switch to C or Fortran for everything?
133
136
134
-
The answer is: no, no and one hundred times no!
137
+
The answer is: No, no and one hundred times no!
138
+
139
+
(This is what you should say to the senior professor insisting that the model
140
+
needs to be rewritten in Fortran or C++.)
135
141
136
142
There are two reasons why:
137
143
138
144
First, for any given program, relatively few lines are ever going to
139
145
be time-critical.
140
146
141
-
Hence we should write most of our code in a high productivity language like
142
-
Python.
147
+
Hence it is far more efficient to write most of our code in a high productivity language like Python.
143
148
144
-
Second, for those lines of code that *are* time-critical, we can now achieve the same speed as C or Fortran using Python's scientific libraries.
149
+
Second, even for those lines of code that *are* time-critical, we can now achieve the same speed as C or Fortran using Python's scientific libraries.
145
150
146
151
147
152
Where are the Bottlenecks?
@@ -150,6 +155,8 @@ Where are the Bottlenecks?
150
155
Before we learn how to do this, let's try to understand why plain vanila
151
156
Python is slower than C or Fortran.
152
157
158
+
This will, in turn, help us figure out how to speed things up.
159
+
153
160
154
161
Dynamic Typing
155
162
^^^^^^^^^^^^^^
@@ -281,16 +288,19 @@ Let's look at some ways around these problems.
281
288
There is a clever method called **vectorization** that can be
282
289
used to speed up high level languages in numerical applications.
283
290
284
-
The key idea is to send array processing operations in batch to precompiled
291
+
The key idea is to send array processing operations in batch to pre-compiled
285
292
and efficient native machine code.
286
293
287
294
The machine code itself is typically compiled from carefully optimized C or Fortran.
288
295
296
+
For example, when working in a high level language, the operation of inverting a large matrix can be subcontracted to efficient machine code that is pre-compiled for this purpose and supplied to users as part of a package.
297
+
289
298
This clever idea dates back to MATLAB, which uses vectorization extensively.
290
299
291
-
Vectorization can greatly accelerate many (but not all) numerical computations.
300
+
Vectorization can greatly accelerate many numerical computations (but not all,
301
+
as we shall see).
292
302
293
-
Let's see how it works in Python, using NumPy.
303
+
Let's see how vectorization works in Python, using NumPy.
294
304
295
305
296
306
Operations on Arrays
@@ -471,13 +481,15 @@ In the vectorized version, all the looping takes place in compiled code.
471
481
472
482
As you can see, the second version is **much** faster.
473
483
474
-
(We'll make it even faster again below when we discuss Numba)
484
+
(We'll make it even faster again later on, using more scientific programming tricks.)
485
+
475
486
476
487
477
488
.. _numba-p_c_vectorization:
478
489
479
-
Pros and Cons of Vectorization
480
-
------------------------------
490
+
Beyond Vectorization
491
+
====================
492
+
481
493
482
494
At its best, vectorization yields fast, simple code.
483
495
@@ -488,17 +500,17 @@ One issue is that it can be highly memory-intensive.
488
500
For example, the vectorized maximization routine above is far more memory
489
501
intensive than the non-vectorized version that preceded it.
490
502
503
+
This is because vectorization tends to create many intermediate arrays before
504
+
producing the final calculation.
505
+
491
506
Another issue is that not all algorithms can be vectorized.
492
507
493
508
In these kinds of settings, we need to go back to loops.
494
509
495
-
Fortunately, there are nice ways to speed up Python loops.
496
-
497
-
498
-
Beyond Vectorization
499
-
====================
510
+
Fortunately, there are alternative ways to speed up Python loops that work in
511
+
almost any setting.
500
512
501
-
In the last few years, a new Python library called `Numba
513
+
For example, in the last few years, a new Python library called `Numba
502
514
<http://numba.pydata.org/>`__ has appeared that solves the main problems
0 commit comments