Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faster Python with Guido van Rossum

softwareatscale.dev

Post reply on HN
Print view View original

91–100 of 251 posts

Re: Faster Python with Guido van Rossum

#91

Post by throwaway894345 »

qbasic_forever wrote: post #79
throwaway894345 wrote: post #52

Earlier quoted context omitted.

> If you get rid of the GIL you have to replace one big lock with a bunch of very small locks, which actually hurts performance for programs which only need 1 core, which is most programs. Python could do what most other languages do and allow programmers to explicitly add locks to the code that needs to be locked, rather than locking everything, all the time.

Python has a robust and very capable set of locks and multiprocessing primitives. The issue is that the GIL has been giving you atomic/serialized access to a lot of primitives for free since the inception of the language, so no one has really felt the need to do things like lock access to their basic dicts or lists. You can't just take that code and remove the GIL locking without causing chaos. And as we saw with the…

Most code doesn't actually run in a shared memory parallel context precisely because of the GIL, so I think the "chaos" would be minimal. It will still be painful, and would require the ecosystem to adapt (and therefore will never happen because the Python ecosystem lacks the necessary leadership), but it's technically feasible and it would be politically feasible for other language communities.

Re: Faster Python with Guido van Rossum

#93

Post by overgard »

m_ke wrote: post #51

I'd be happy with just an optimized strict subset of python that uses type annotations to compile performance critical functions like cython. Mypyc sounds like an attempt at that but doesn't seem to be constraining the language enough to allow it to shed the dynamic nature of the language. Another similar effort was EPython, but it doesn't look like anyone is working on it. I guess Numba would be the closest thing to…

PyPy's RPython is this, although it's probably weirder/more specialized than what you want.

Re: Faster Python with Guido van Rossum

#94

Post by overgard »

prabhu-yu wrote: post #60
fastball wrote: post #19

Earlier quoted context omitted.

If you get rid of the GIL you have to replace one big lock with a bunch of very small locks, which actually hurts performance for programs which only need 1 core, which is most programs.

Ok, can we do this? Python interpreter can understand if it is running on 1 core processor (assume 1 core = 1 HW thread) or multi core processor. Then use GIL taht suits. ie, if the code uses multiple SW threads, use GIL that suits needs... something like possible? Any reason why experts are not doing this? -p

It's been done; it just was never accepted into the core. And it never will be.

Re: Faster Python with Guido van Rossum

#95

Post by gjulianm »

stinos wrote: post #38
ctur wrote: 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…

I have become increasingly convinced Python as a language is a "trap" for any use of notable scale I assume you're saying this out of experience, so can you give a practical example of what you call 'notable scale'? And are you talking about desktop or web or mobile, or just all of them? Just so that we know what you are talking about in a concrete way. Not the 'large software with large number of developers is alway…

I am seeing what the GP comment says in a codebase I manage, around 47k LOC. Not massive at all, but enough where the problems mentioned above start to pop up. This is an application that runs in servers to analyze traffic data, so it has both analysis code and also a lot of code for the analysis framework. It gets hard to manage. I have unit tests and also integration tests that cover some, but not all of the code paths (it's very hard in this case to have everything covered). Most of the times, when they fail is due to something that would have been caught by static typing.

The codebase is being slowly migrated to static typing. On one hand, as the parent says, the typing module is still immature and there are still some Python constructs (not too weird ones, see [1] for an example) that you can't type-check correctly. On the other hand, I like the fact that you can include typing slowly and not all at once, it makes the effort much easier to tackle. And, if typing works, it works well.

Regarding performance, well. Parallelism is pretty hard to do well, and the language itself is not the fastest thing. Some parts are migrated to a C extension but that's costly in terms of development and debugging time.

Despite all of that, I do think that Python was the best choice for our situation, and still is. Maybe from this point onwards another language would make things easier, but without Python's library support, ease and speed of development and expressiveness the cost of just getting to market would have been far higher, and probably we wouldn't have reached this point with other languages. And migrating the codebase to another language is just not worth it at all, as there are still a lot of areas we can improve quite a lot with far less effort than a full rewrite.

1: https://github.com/python/mypy/issues/2756#issuecomment-8772...

Re: Faster Python with Guido van Rossum

#96

Post by wickoff »

nickjj wrote: post #72
ferdowsi wrote: post #62

Earlier quoted context omitted.

My understanding is that Dropbox has been building performance-critical parts of their services in Go since 2014 at the least. https://twitter.com/jamwt/status/629727590782099456 Like many companies, they had initial scaling successes with Python,hit performance bottlenecks and looked for a way out with faster languages.

Sure, Rust too for some of the desktop app components. But the takeaway is you only need to do that when you're operating at mega scale and actually hit these bottlenecks. In a ton of cases you'll be completely fine serving a few million monthly page views of your SAAS app on a single $20-40 a month server using Flask, Django or whatever Python web framework you prefer. Performance will be really good too. Just talki…

You may be better off using rails instead to fully capitalize on rapid development through automagic.

Re: Faster Python with Guido van Rossum

#97

Post by mpdehaan2 »

Qem wrote: post #6
amelius wrote: post #3

Python needs to go multicore, like OCaml. And add a modern concurrent garbage collector. One of the difficulties is of course to not break existing C extensions.

Given Python has the multiprocessing module, I always get confused when people talk about Python lack of support for multicore. What are the shortcomings of the multiprocessing module, that cause people to disregard it?

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 into play there either.

It's harder if you want to do something different where you want threaded workflows with synchronized/protected like constructs that folks might be familiar with from say Java.

Firing up multiprocessing (forking) has some costs to bringing up the interpreters so it's not something you want to start up a lot and then close down a lot, better if you can start things and leave them running. Once it's up it is pretty fast.

I guess mainly it changes the style of your program too much - it's basically just glue around forks.

Re: Faster Python with Guido van Rossum

#98

Post by igouy »

azeirah wrote: post #47
qsort wrote: post #27

Earlier quoted context omitted.

Pretty much everything you're saying matches my experience, so, playing the devil's advocate: - The typing argument is impossible to argue against, but isn't it the same problem you'd have with any other dynamic language? How is, say, Javascript any better? I don't see this as something that's specifically Python's fault, rather, yet another argument as to why starting a large project in 2021 without seriously consid…

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

Also Dart.

Re: Faster Python with Guido van Rossum

#99

Post by alex_smart »

ferdowsi wrote: post #62
nickjj wrote: post #50

Earlier quoted context omitted.

> I have become increasingly convinced Python as a language is a "trap" for any use of notable scal At what point do you embrace the trap and happily live with it? For example Dropbox runs many millions of lines of Python, has massive traffic and their server costs aren't completely out of line for the service they offer. Their code base is also over 10 years old. It seems to be working very well for them. I talked t…

My understanding is that Dropbox has been building performance-critical parts of their services in Go since 2014 at the least. https://twitter.com/jamwt/status/629727590782099456 Like many companies, they had initial scaling successes with Python,hit performance bottlenecks and looked for a way out with faster languages.

That you can incrementally build performance-critical parts of your system in other languages is a huge success story for Python. I don't understand in what world you can view that as a negative.

If you were NOT able to do that, that would have actually been a reason to not build your app in Python.

Post reply on HN