Live data from Hacker News

Faster Python with Guido van Rossum

softwareatscale.dev

191–200 of 251 posts

Re: Faster Python with Guido van Rossum

#191
post #186

Earlier quoted context omitted.

I never made the assertion JS is 50x faster... But everyone knows it is significantly faster than Python. Probably at least a few times for pure JS vs. pure Python programs. Not that it matters, Python is basically glue to run mostly C and C++ programs.

Given that you say "basically glue" why the previous surprise about "basically using C types and GMP" ?

Because it's obviously not the idiomatic way to use Python. No one is going to bother writing a program that way in Python, they'd just write it in C or C++ then link it.

Re: Faster Python with Guido van Rossum

#192
post #169

Earlier quoted context omitted.

Thanks for providing code. I’ve written code like that before and the first thing that jumps out at me is that you have for loops in Python code which isn’t slow but will never be as fast as loops in a static compiled language. Sometimes for loops are the most readable way of expressing a calculation but as a numerical computation person my instinct is to look for opportunities to vectorize by rewriting loops into ma…

I don't know about other languages, but in Julia I've heard people often say that loops end up faster than the equivalent vectorized code. So while this is true for Python/Matlab I don't think it is good universal advice. That said, matrix notation can sometimes be the more readable way of expressing a calculation.

I might have used an early beta of Julia circa 2018 or something, but the chorus that it performs like $static_fastlang doesn't match the experience I had.

Re: Faster Python with Guido van Rossum

#193
post #47

Earlier quoted context omitted.

For your first point, I don't think a language such as JavaScript -is- much better, which is why Typescript was invented as an alternative for larger codebases/organizations

TypeScript:JS is a lot like mypy:Python; the only real difference is that Python adapted so that mypy (originally envisioned as its own language) code is also valid Python as well as the reverse, obviating the need for a compilation step to run mypy in the Python runtime (whereas TS has to compile to JS to run); also, mypy has mypyc to compile (currently, only a subset of) mypy code to something more efficient than n…

Having worked extensively with both, I don't think this is an apt comparison.

Type inference & hinting at the IDE level is just not as developed either

Re: Faster Python with Guido van Rossum

#194
post #4

I have become increasingly convinced Python as a language is a "trap" for any use of notable scale, be the scale about number of developers, codebase size, or performance requirements. It's a great 0->1 language and great at simple glue, but eventually you hit a wall and have to keep investing larger and larger amounts of people or computing resources to get continued returns... all due to fundamental design decision…

Is/Are there alternative programming language(s) you would suggest instead of python? It would be great if you could list the use cases also where one language does it better than python.

Re: Faster Python with Guido van Rossum

#195

There seem to be big appreciation for go language. How difficult is it to develop a language with (mostly) python syntax while keeping the performance of go? I guess most people who use python use it because of its aesthetics and might even never heard of the GIL issue in python, so i guess among all languages the python syntax is the most liked one.

Nim is basically this.

Yep, Nim is a pleasure to work with too.

Re: Faster Python with Guido van Rossum

#196
post #4

I have become increasingly convinced Python as a language is a "trap" for any use of notable scale, be the scale about number of developers, codebase size, or performance requirements. It's a great 0->1 language and great at simple glue, but eventually you hit a wall and have to keep investing larger and larger amounts of people or computing resources to get continued returns... all due to fundamental design decision…

Last I checked there were 37,373.7 programming languages. Pick one.

Shrug.

Re: Faster Python with Guido van Rossum

#197
post #156

Earlier quoted context omitted.

I suspect that site is some kind of in-joke. E.g. read the regex-redux example in say c#, now look at the go version, now the python version… It’s not really what you’d expect for a site called computer language benchmarks game. Each example just calls out to a very fast c library (pcre2) to perform the heavy lifting regardless of which language is being “benchmarked”. Seems a pretty pointless site. The other example…

> Each example just calls out to a very fast c library… No. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

  from re import sub, findall
That's where pcre2 is called (or a finely tuned regex c lib)

Re: Faster Python with Guido van Rossum

#198
post #124
post #4

I have become increasingly convinced Python as a language is a "trap" for any use of notable scale, be the scale about number of developers, codebase size, or performance requirements. It's a great 0->1 language and great at simple glue, but eventually you hit a wall and have to keep investing larger and larger amounts of people or computing resources to get continued returns... all due to fundamental design decision…

As someone with nearly two decades of experience with Python and who has deployed it in production in high impact scenarios, I’d like to nuance the above for people who think Python is only good for prototyping and that you have to rewrite in a “proper” programming language. This is the kind of blanket thinking to avoid. I think the rewriting part is only necessary if there’s some characteristic in your use case that…

> Python’s type annotations are an attempt to move in this direction, but static languages truly excel at type integrity (which are sometimes the cause of subtle errors in Python).

I wouldn't call it an attempt. I mean, sure it has no chance against for example Rust, but Python's type system is actually quite decent and I think it is more powerful than the one from Go. Also you have freedom of using both nominal and structural typing if you chose.

The only problem I have with it when I have to use a package that don't have types, but fortunately that is happening less and less.

Some package authors refuse to add types, but others provide stubs to solve that problem. For example boto3-stubs provides types for boto3.

I really like that thanks to types I can also easily refactor code without worrying about breaking something in the process. I suspect if types existed and were popular with Python 2 then the whole Python 2 -> Python 3 migration would be a non issue.

Re: Faster Python with Guido van Rossum

#199
post #180
post #127

Earlier quoted context omitted.

Also, pretty sure Python was called out as one of the main reasons why some hundred of Google Video engineers couldn't keep up with YouTube prior to Google's purchase. Python might not be the most performant, but once you need the scale, it's a good problem to have because at that point, your product has already made it.

Do you have an article about that? I would be interested to learn more about it.

Sadly the page isn't available on Google Books anymore[0], you might still be able to get the book itself. There also might be a Hacker News thread on it too or it'll be on Reddit. It's one of those places I'll have seen it on.

[0] https://books.google.co.uk/books?id=eulODwAAQBAJ&lpg=PA136&d...

Re: Faster Python with Guido van Rossum

#200
post #150

Earlier quoted context omitted.

I am probably the most commercially successful user of the multiprocessing module :) It's basically fine anywhere you need a function call that you can dispatch out to like 50 or 500 workers on a queue and then do something after that returns, but any shared memory or IPC between the workers is up to you. Python is also fine for webserving because most web servers pre-fork workers or whatever, so this doesn't come in…

> any shared memory or IPC between the workers is up to you. There is this: - https://docs.python.org/3/library/multiprocessing.shared_mem... - https://docs.python.org/3/library/queue.html - https://docs.python.org/3.8/library/multiprocessing.html#mul... - https://docs.python.org/3.8/library/multiprocessing.html#mul... > It's harder if you want to do something different where you want threaded workflows with synchron…

[deleted]
Post reply on HN