LWN: Comments on "NumPy 1.20 has been released"

NumPy 1.20 has been released

cozzyd — Thu, 25 Feb 2021 06:59:00 +0000

You probably avoid a copy too, which can be significant if it's a big array?

NumPy 1.20 has been released

leephillips — Thu, 25 Feb 2021 03:16:12 +0000

Thank you for your kind words. It’s a privilege to write for LWN’s readers.

NumPy 1.20 has been released

himi — Thu, 25 Feb 2021 02:32:16 +0000

Thank you for this and your other articles covering aspects of scientific computing - they've been very informative and interesting. And thank you to LWN for providing the platform on which they're hosted.

NumPy 1.20 has been released

atai — Wed, 24 Feb 2021 23:48:08 +0000

never mind. you already answered the question

NumPy 1.20 has been released

atai — Wed, 24 Feb 2021 23:47:15 +0000

> Half-ways through the competition we realized that it was not possible to solve that problem using Java.

What is it with Java that makes it impossible?

NumPy 1.20 has been released

mhvk — Wed, 24 Feb 2021 14:49:12 +0000

Indeed, it just extends `where` to the wrappers around ufunc reductions (`np.logical_and.reduce` and `np.logical_or.reduce` in this case), really remedying an oversight from when I implemented `where` for reductions... I think the advantage is clearer for taking the mean, etc. For `any` and `all`, what would be nice is to have proper short-circuiting, but that is still on the wish list.

p.s. What makes `ndarray` so particularly nice is how it deals with strides to allow views of many forms into the array. This is nicely described in the "array programming with numpy" article; see https://ui.adsabs.harvard.edu/abs/2020Natur.585..357H/abs...

NumPy 1.20 has been released

leephillips — Wed, 24 Feb 2021 14:05:20 +0000

As far as I can tell the results should be the same. This is an extension of the `where` keyword argument that was added to `numpy.reduce` in v. 1.17. Both when using the `where` keyword argument in when using `logical_and`, the Boolean mask array is broadcast to match the dimensions of the array in the first argument. There could be performance differences.

NumPy 1.20 has been released

quietbritishjim — Wed, 24 Feb 2021 13:51:43 +0000

My point was that the terminology was probably chosen to avoid distracting comments about Python's speed instead of constructive comments about the article content. Your comment only reinforces that.

It's sadly a pattern on LWN articles about some new aspect of Python or its libraries: one of the top comments is about how slow Python is (often _the_ top comment, as in this case). It's one of the few times I wish LWN comments had Reddit style vote buttons. Not because I disagree, but just because it's off-topic and stifles more interesting discussions.

NumPy 1.20 has been released

pizza — Wed, 24 Feb 2021 13:02:42 +0000

I recently replaced a relatively simple text parsing/collating python script with a nearly-identical one written in perl, and the runtime dropped from ~30s to ~3s.

(The original script was python 2, and I started out by trying to port it to python 3. Unfortunately it needed to handle sometimes-broken unicode so rewriting it in perl turned out to be far more expedient. And as it turned out, an order of magnitude faster)

Anectdotally, the only times I've seen where python is "fast" is when you're able to hand off batches of data to native-compiled libraries. (NumPy being a prime example of this..)

NumPy 1.20 has been released

hkario — Wed, 24 Feb 2021 12:05:00 +0000

Except that Python does not manage 20mph in this analogy, it easily manages highway speeds. What it's not well suited for is winning Daytona 500.

NumPy 1.20 has been released

thumperward — Wed, 24 Feb 2021 11:27:10 +0000

Yes, but very few people would argue that Python is slow relative to doing things with pencil and paper. For the vast majority of computing tasks, Python is plenty fast on contemporary hardware. But it is nevertheless the case that when one considers which contemporary languages Python is slow relative to, the answer is "nearly all of them". You wouldn't see a review of a car which had a top speed of 20mph described as "relatively slow" despite this being wildly better than foot speed.

NumPy 1.20 has been released

pgdx — Wed, 24 Feb 2021 11:17:34 +0000

I don't remember it precisely, it's probably 7 years ago, or so, but the problem was JVM startup combined with slow IO (parsing integers from stdin).

NumPy 1.20 has been released

ju3Ceemi — Wed, 24 Feb 2021 10:58:04 +0000

Starting a JVM is time consumming, and we are talking about a couple of second max for the whole program to run

NumPy 1.20 has been released

sandsmark — Wed, 24 Feb 2021 10:39:15 +0000

I agree with you, but now I got curious about the problem that wasn't possible (or at least feasible in a competition) to solve with Java. Do you remember what problem was, or at least the broad strokes?

NumPy 1.20 has been released

quietbritishjim — Wed, 24 Feb 2021 09:03:53 +0000

Isn't the new where argument:

    np.any(ri < 3, where=ri%2 == 0)

the same as using the existing logical_and:

    np.any(np.logical_and(ri < 3, ri%2 == 0))

? If so, is there any benefit to the new notation? I suppose perhaps speed? I see it's slightly more consise, but the composing two functions seems clearer to me and is much more flexible.

NumPy 1.20 has been released

quietbritishjim — Wed, 24 Feb 2021 08:31:43 +0000

Python will execute millions or even 10s of millions of instructions per seconds. (As the sibling comment points out, I am talking about the CPython runtime specifically.) Personally, that sounds very fast (in absolute terms) to me! Of course, you might disagree, since what counts as "fast" in absolute terms is so subjective. What is difficult to argue is that Python is slow relative to many other languages in common use. That's probably why the article author said "relatively slow", in the hope that the preciseness of that would avoid this whole discussion. Oh well.

On the note of speed and libraries like numpy, I'll point out that C libraries like numpy (and even some built in modules) release Python's global interpreter lock (GIL) while doing computations. So not only do they speed up the throughput in the current thread, they allow other threads to do work concurrently. (The GIL is also released when doing IO like reading from a file.)

NumPy 1.20 has been released

pgdx — Wed, 24 Feb 2021 08:12:30 +0000

I used to do competitive programming, where you need to write programs/algorithms that solve large instances of problems with typically 1–5 seconds time limit.

Python is a slow runtime, yes. However, we have seen several problems in competitions where Python (running on pypy, of course) outperforms other languages, e.g. Java.

Indeed, we once created a problem that we implemented solutions for in every language accept Java (go figure). We just assumed that since Python ran well within time limits, Java would manage too.

Half-ways through the competition we realized that it was not possible to solve that problem using Java.

I'm not a programming language expert, but I can accept your claim that there are "slow languages", however pypy is a quite snappy runtime.

(Now I teach competitive programming; those who can't do teach.)

NumPy 1.20 has been released

ncm — Wed, 24 Feb 2021 06:19:08 +0000

Why call Python a "relatively slow" language? Python is an example of an absolutely slow language. It is slower than the overwhelming majority of languages, and less slow only than extremely slow languages.

"Absolutely slow" is unnecessarily verbose. "Relatively slow" is, too. "Slow" is short and correct. Say "Python is a slow language." Its users know, and have chosen.

Just to be clear, I do not mean that slow is the same as bad, or that Python is a bad language. I use it. In most places where we use programs, slow is fast enough. Slower than Python was fast enough to land on the moon. There is enough room in the world for a slow language.

But I would not use Python where throughput or latency does matter, anyway not without a lot of help from, e.g., NumPy.