5 ms·

"Increase the array sizes by at least a factor of 100 to get anything meaningful." Ok, let's do that and see what happens: python -m timeit -s 'import num

"Increase the array sizes by at least a factor of 100 to get anything meaningful." 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)' D 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; 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; } Results Python: 14.1 msec D: 39 μs D is 361.5x faster

zardeh 11y ago
Is D or the compiler doing something sneaky and inlining something, because I'd expect doing 100x more things to take 100x more time for a linear algorithm,but it takes you on the order of 10x more time. Does the original function run in <1ns for you? 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.
semi-extrinsic 11y ago
Ok. So three points remain: * 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.
- bionsuba 11y ago
  "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?" 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; } Results: Python: 14.1 msec D: 41 μs D is 343.9x faster "Given the same number of lines (or characters), are you sure you can't write equally fast Python code?" 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.
  - semi-extrinsic 11y ago
    > 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. 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).

zardeh 11y ago

Is D or the compiler doing something sneaky and inlining something, because I'd expect doing 100x more things to take 100x more time for a linear algorithm,but it takes you on the order of 10x more time. Does the original function run in <1ns for you? 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.

semi-extrinsic 11y ago

Ok. So three points remain: * 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.

bionsuba 11y ago
"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?" 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; } Results: Python: 14.1 msec D: 41 μs D is 343.9x faster "Given the same number of lines (or characters), are you sure you can't write equally fast Python code?" 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.
- semi-extrinsic 11y ago
  > 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. 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).