As I stated in the article, I did not include the array creation in the benchmark in order to be fair to Numpy with its slow initialization times. The only python code that I benchmarked was the numpy.mean line.
I mean this is a terrible benchmark. Comparing to pure python, the numpy code is about 4-5x faster on my machine, whereas in reasonable real world benchmarks, numpy is hundreds of times faster than pure python.
For reference my benchmark was
%timeit [sum(row)/len(row) for row in mat]
These results are as valuable as the ones pypy gave me:
pypy -mtimeit -s "[sum(row)/len(row) for row in [[range(100000)[i*j] for i in range(100)] for j in range(1000)]]"
1000000000 loops, best of 3: 0.00101 usec per loop
In other words, because the code returns a python array of length 1000, what you're benchmarking is python's speed of array instantiation vs. Ds mathematical speed. Its obvious that D will win. The only fair way to benchmark the mathematics here is if you compare the D implementation of O(n) algorithm that returns a single value, or an O(n^2) algorithm that returns a 1d array or single value etc. Otherwise the python overhead of creating O(n) objects will overshadow the actual mathematical calculations on those O(n) objects.
you're benchmarking is python's speed of array instantiation vs. Ds mathematical speed. Its obvious that D will win.
Plus, I don't see why this is an invalid benchmark when this is perfectly normal Numpy code, the kind that you see all the time. That was the reason behind the benchmark, to find some common piece of Numpy code and see how equivalent std.ndslice stacked up. I don't see how it's fair to say "Python is really slow at this one thing, so it's not fair to compare it to D in that area".
The fact that someone who is "the review manager for std.ndslice's inclusion into the standard library" does not understand how to profile numerical algorithms makes me very skeptical of using D for any numerical project.
Plus, the syntax looks god-awfully unintuitive. A main advantage of Python is that you often get "code that looks like what it does". The D "basic example with a benchmark" OTOH looks almost obfuscated. To wit; a Fortran version is more readable, is fewer lines of code(!) and of course kicks D's butt when it comes to speed:
program p
real, dimension(100,1000) :: data
real, dimension(1000) :: means
n=1
forall(i=1:100,j=1:1000)
data(i,j)=n
n=n+1
end forall
forall(i=1:1000000,j=1:1000)
means(j) = sum(data(:,j))/size(data(:,j))
end forall
Ok, let's do that and see what happens:
python -m timeit -s 'import numpy; data = numpy.arange(10000000).reshape((1000, 10000))' 'means = numpy.mean(data, axis=0)'
import std.range : iota;
import std.array : array;
import std.algorithm;
import std.experimental.ndslice;
import std.datetime;
import std.conv : to;
import std.stdio;
enum testCount = 10_000;
void f0() {
auto means = 10_000_000.iota
.sliced(1000, 10000)
.transposed
.map!(r => sum(r) / r.length)
.array;
}
void main() {
auto r = benchmark!(f0)(testCount);
auto f0Result = to!Duration(r[0] / testCount);
f0Result.writeln;
}
Python: 14.1 msec
D: 39 μs
D is 361.5x faster* how do I know that the calculations aren't actually optimized away in all that code I can't understand? E.g. what happens if you make f0() return the means array instead of being a void function?
* Given the same number of lines (or characters), are you sure you can't write equally fast Python code?
* I tested the Fortran version on a slightly slower computer (got 14.7 msec on the Python version). Fortran runs at 0.7 μs, i.e. > 55x faster than D, with less code that's more readable to boot.
If you can't understand the code, how did you know it was a void function. Please stop with the hyperbole, it's not adding anything to the discussion.
Updated code:
import std.range : iota;
import std.array : array;
import std.algorithm;
import std.experimental.ndslice;
import std.datetime;
import std.conv : to;
import std.stdio;
enum testCount = 10_000;
auto f0() {
auto means = 10_000_000.iota
.sliced(1000, 10000)
.transposed
.map!(r => sum(r) / r.length)
.array;
return means;
}
void main() {
auto r = benchmark!(f0)(testCount);
auto f0Result = to!Duration(r[0] / testCount);
f0Result.writeln;
}
Python: 14.1 msec
D: 41 μs
D is 343.9x faster
IMO program size is an almost meaningless statistic outside of code golf challenges. LOC is not an indicative measure of code readability, usefulness, or organization.
For example, your Fortran code was 11 lines while the D function (with the return) is eight lines.
"I tested the Fortran version on a slightly slower computer (got 14.7 msec on the Python version). Fortran runs at 0.7 μs, i.e. > 55x faster than D, with less code that's more readable to boot."
Just goes to show why Fortran is still used in a lot of scientific areas.
But two things:
1. Fortran is a much simpler language than D or Python and is much harder to do multipurpose work in it (so I'm told from Fortran programmers, I don't know Fortran myself). So when your program needs to do anything other than number crunching, it's normally done in a separate language. Using D you can have everything in one code base.
2. This article was about Numpy and std.ndslice because those are two areas that I know about and Numpy is a very popular library. Bringing up Fortran's speed here is like commenting on how much faster C++ is in a thread about Ruby.
Also, readability is a subjective idea; I believe the D code is more readable than the Fortran you wrote. Different strokes.
I understand "void" perfectly fine, but understanding how D optimizes your code is a completely different matter. Playing devil's advocate further, you
> IMO program size is an almost meaningless statistic outside of code golf challenges. LOC is not an indicative measure of code readability, usefulness, or organization.
No, but the numpy code is undoubtedly much simpler, and very general. How does the D example look for a 3D array where you want to average over the second dimension?
> For example, your Fortran code was 11 lines while the D function (with the return) is eight lines.
You're neglecting the library imports.
>So when your program needs to do anything other than number crunching, it's normally done in a separate language. Using D you can have everything in one code base.
I do agree other languages are much better for e.g. string processing. But for the applications where you can afford to trade simpler code for 50x slower performance, I'd say you're not really caring about performance at all, so why not just use Python? If performance is mission critical, a two-language code base (Python + C/C++/Fortran/CUDA) is not that hard to do, fairly common, and will give you the required performance.
> Bringing up Fortran's speed here is like commenting on how much faster C++ is in a thread about Ruby.
No; once you start saying "I want more performance than Python", it's obviously interesting to see what level of performance a "low-level" language gets, to put the result in perspective.
Now, I'm not trying to beat down on D, so please try to interpret this as constructive criticism. Finding "where does it fit in the scientific toolbox" is what makes or breaks a language's adoption in the scientific community. Just look at R, it's at the same level of performance/abstraction but in a separate niche from Python, and doing very well. The same goes for Matlab (which has e.g. Simulink).
Edit:
Because as I showed above, Pypy managed to JIT inline the entire benchmark, so I wouldn't be surprised at all if a clever compiler managed to do something sneaky.
You could then respond by saying that I wasn't using D optimally, and I'd agree.
But benchmarks that are designed to hide the fact that CPython function call overheads and object creation overheads are a godawful abomination are far from a fair benchmark. Those overheads are real and have real effects.
If he claimed that handwritten D code was faster than equivalent python, I'd say "duh", but he claimed that the numerical libraries are faster. I take issue to the statement that D will be faster than numpy for real world calculations, because the numpy code will run the actual math faster, and the python overhead will still be on the order of nano or milliseconds.