Hacker News Reader

Comment by doodlesdev | Hacker News Reader

There are more efficient interpreters and compilers, problem is they don't work with the existing libraries. If you mean another language, there is Lua for scripting purposes and Julia for math stuff. JavaScript also exists, which despite its fame it is actually MUCH faster than Python, and you can even run it in a runtime such as bun.js and get even more out of it.

IMO the biggest problem is that the Python libraries ecosystem is just too good to miss out on. I absolutely hate Python but even I have to admit it is much easier to do some stuff in Python compared to other languages simply because of the libraries available to do basically anything you could dream of.

View on HN

Python performance, both single core and concurrent, seem to be its primary Achilles heel. However, Python is unmatched for developer speed in compute heavy AI / ML since it uses C, etc., under the hood. I don't really like Python but it's impossible to avoid in data science because you don't have to re-invent the wheel.

Several languages have persisted beyond their natural shelf life due to their library ecosystems. For a period of time, CPAN was one of the best arguments for using Perl. More recently, Java's ecosystem is also a pretty good reason to use Java right now, even if you don't like the language.

Languages seem to thrive early due to initial ease of use (Python, particularly, but also relative uptake of Go vs Rust), but can wane due to a thousand cuts (or sigils in Perl's case).

> However, Python is unmatched for developer speed in compute heavy AI / ML since it uses C, etc., under the hood.

John Carmack seems to think otherwise.

> "That means that in the time that Python can perform a single FLOP, an A100 could have chewed through 9.75 million FLOPS"

https://twitter.com/id_aa_carmack/status/1503844580474687493...

Am I missing something?

The OP's comment is that while Python's native interpreter is slow, Python code as a whole can still be fast since people will delegate the hot spots to non-Python libraries optimized for speed.

To refute that, you linked to John Carmack quoting Horace He saying that Python's native interpreter does CPU-based math slower than a GPU. But...that's why people writing Python use libraries to delegate math-intensive work to a GPU, which is the OP's point.

If one is forced into writing code that needs to be fast in a language other than Python, then I'm not sure I understand why Python gets to claim any credit?

Slight nitpick: the credit that was being claimed is that Python allows fast developer speed while not sacrificing overall runtime performance.

The code that is written in a language other than Python is often not written by the developer writing the Python code.

As an example, I've been fiddling with inferring automatic data extraction rules for data in scraped webpages.

The meat of the algorithm and its heuristics is in Python. The heavy lifting of parsing HTML and evaluating CSS selectors is done by a C parser that I did not write. For me, prototyping the heuristics in C would have been quite a bit slower.

I generally respect Carmack, but it's clear he wasn't considering Jax or even numpy, but just python flops. Jax code running on TPUs often reaches order of magnitude of the hardware's capabilities.

Wouldn't surprise me if a subset of Python compiled to asm.js would run faster in V8 than cpython.

But would this "subset of python" be actually useful?

Once you break compatibility stuff doesn't work… and a fast python that can't run my software is less useful than a slow python that runs the software.

> Wouldn’t surprise me if a subset of Python compiled to asm.js would run faster in V8 than cpython.

I’m certain that there exists some subset of python for which this is true, but so what?

Probably doesn't have to be a subset. Call back to cpython for the really dynamic madness, much like a jit tiers back out of machine code when assumptions don't hold.

Reply on news.ycombinator.com