NumPy 1.20 has been released

Posted Feb 24, 2021 6:19 UTC (Wed) by ncm (guest, #165)
Parent article: NumPy 1.20 has been released

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.

to post comments

NumPy 1.20 has been released

Posted Feb 24, 2021 8:12 UTC (Wed) by pgdx (guest, #119243) [Link] (5 responses)

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

Posted Feb 24, 2021 10:39 UTC (Wed) by sandsmark (guest, #62172) [Link] (2 responses)

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

Posted Feb 24, 2021 10:58 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link]

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

Posted Feb 24, 2021 11:17 UTC (Wed) by pgdx (guest, #119243) [Link]

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

Posted Feb 24, 2021 23:47 UTC (Wed) by atai (subscriber, #10977) [Link] (1 responses)

> 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

Posted Feb 24, 2021 23:48 UTC (Wed) by atai (subscriber, #10977) [Link]

never mind. you already answered the question

NumPy 1.20 has been released

Posted Feb 24, 2021 8:31 UTC (Wed) by quietbritishjim (subscriber, #114117) [Link] (4 responses)

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

Posted Feb 24, 2021 11:27 UTC (Wed) by thumperward (guest, #34368) [Link] (2 responses)

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

Posted Feb 24, 2021 12:05 UTC (Wed) by hkario (subscriber, #94864) [Link]

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

Posted Feb 24, 2021 13:51 UTC (Wed) by quietbritishjim (subscriber, #114117) [Link]

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

Posted Feb 24, 2021 13:02 UTC (Wed) by pizza (subscriber, #46) [Link]

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..)