Hacker News Reader

It's really a shame you are getting down voted. You are basically just saying, "Sometimes shared memory model makes a more efficient and simpler solution over enforced actor model. Like in this case." This shouldn't be controversial, engineering choices come with tradoffs and the GIL certainly pushes you for making a specific choice.

Yes, if you are going to be doing caching in python, you are almost certainly going to be caching it in a separate service and serializing across process boundaries. If you are going to be holding onto a connection pool as well (PG bouncer being the most typical). More generally, any sort of shared resource that would require or benefit strongly from shared memory model needs to be pushed into a sidecar service written in a language that actually supports efficient shared memory model. These are precisely the sorts of problems that the GIL causes. There are standard ways to work around it and most python developers can reach for these solutions, but this is not a contradiction to the fact that the GIL has limited your choice in the matter.

> It’s really a shame you are getting down voted. You are basically just saying, “Sometimes shared memory model makes a more efficient and simpler solution over enforced actor model. Like in this case.”

If he was just saying that, he’d probably be downvoted for being true but irrelevant and not meaningfully contributing.

But he’s actually saying that plus “therefore, Python is bad (implying that Python can’t use shared memory between processes).” Which would be a productive, relevant contribution except for the fact that it’s not true.

> More generally, any sort of shared resource that would require or benefit strongly from shared memory model needs to be pushed into a sidecar service written in a language that actually supports efficient shared memory model.

That’s I guess technically true, if you included the stdlib modules which directly support this and are themselves written in (I assume) C. But, “you might have to use the standard library” is…not much of an impediment.

No, he is making the useful observation that the GIL has an impact on system architecture.

That is why typically python webservers run in multiprocess mode but Java (for example) webservers typically runs in threaded mode.

I didn't say python was bad. And I didn't say that it's impossible to share data between processes (I even mentioned some options).

My point was just that the GIL, while not a dealbreaker or anything, actually _does_ affect how a program is written. So it's implicitly noticeable in my day-to-day.

I've been developing python for all manner of use-cases the last 15 years and have not once had the GIL impact me in any meaningful way. I have however been impacted way more by the amount of misconceptions about python that I've had to explain over the years.

That's the point, though: One doesn't see the impact directly. But after 15 years you just do it the python way by default, not considering other ways that stuff could be solved if it weren't for the limitations imposed by the platform.

The python ways work fine, so it's OK even with GIL, but there are other ways as well.

> You are basically just saying, "Sometimes shared memory model makes a more efficient and simpler solution over enforced actor model. Like in this case."

Is this actually showing that it's less efficient though? People rarely complain about Erlang doing the same thing. "You have to spin up a proper task queue rather than firing off an unmanaged background thread" does not sound like an unambiguous negative to me.

Well, there are shared ETS in Erlang which we actually use for caching lots of things (e.g., the formatted timestamp with 1 second lifetime -- it's faster to look it up than recalculate in every process, -- or, yes, auth tokens).

> For instance, a local cache of some values is basically useless when python is used as backend. Since there will be multiple processes handling the requests (in the same node), they don't share memory.

If you want to share low level memory between process, use SharedMemory: https://docs.python.org/3/library/multiprocessing.shared_mem...

If you want to share high level data structure between process, use diskcache: http://www.grantjenks.com/docs/diskcache/tutorial.html

This is, granted, not as straightforward as just sharing a variable between threads, but it will get you far.

That's like claiming the ability to share JS ArrayBuffer's between workers supplants the need for the ability to share high level objects like a Map.

What I'm getting at is that JS had the exact same problem, and it offers the same ability for sharing blocks of raw memory. But the same pitfalls for any actual structured object.

Instead, we have to serialize/unserialize (creating a copy) from a separate worker, process, or disk source, it's performance is shite for objects of large size.

Message passing is not ideal for large pieces of data. Shared memory is hundreds of times faster.

Yes. SharedMemory can share list (https://docs.python.org/3/library/multiprocessing.shared_mem...) but that's it.

That's why diskscache is better as an alternative for complex objects: https://pypi.org/project/diskcache/

It's not as good as a simple shared variable, but it's surprisingly performant, since it uses memory-mapped files.

I see what you mean. Does diskcache still have to do deserialization of the mapped data? Nested objects (large disparate heap pointer graphs) would suffer performance penalties.

It does yes, although pickle is pretty fast, it's still a penalty.

I have to ask, what is then the point of using Python as a backend (not questioning for data crunching)?

Funny thing here is that PHP works exactly the same with its share nothing architecture. You always need to go outside of PHP handle state between requests.

When I started doing PHP years ago this was one of the first things I stumbled upon on, used to being able to easily share state in a backend. Juniors or non-programmers does usually not think about this at all and thus is not limited by it, whereas programmers with experience from another language, but without any deep PHP knowledge, will always trip up on this, finding it awkward and annoying (like I did).

And yes, the share nothing architecture will change how you write programs. Now many years later I'm used to this and don't see it as problem anymore (almost the opposite).

But if you also need to follow the share nothing architecture on Python, what benefits does it give vs PHP? Is it the community only? Because Python is generally slower than PHP.

I don't consider myself as a Python developer, but based on my knowledge I have hard time finding compelling arguments for picking Python as (web) backend. I rather pick PHP (I have bias), Golang or Java. Nodejs vs Python it a tough one, perhaps nodejs because I can write in TypeScript, but nodejs is not a technology I like.

> the share nothing architecture on Python, what benefits does it give vs PHP

A programming language with better ergonomics, developer experience and more mature community.

How does Python have better ergonomics?

Better developer experience for Python is probably true, more mature community I can't say either way.

Edit: One thing that would be nice in PHP is decorators.

> Edit: One thing that would be nice in PHP is decorators.

15 years I used to say "I wish PHP had feature X just like in language Y". But there's a moment where it's better not to wait and just to use language Y.

Php 8 has attributes, I’m experimenting with implementing decorators on my own.

asyncio doesn't solve any "problems" of threads in Python. it just provides programming patterns that a lot of people like, which are well suited towards having hundreds or thousands of arbitrarily slow IO bound tasks at once. A threadpool in Python can do the same thing with mostly similar performance. asyncio certainly isn't affecting the GIL issue, asyncio is "GIL-ish" by definition since all CPU work occurs in a single thread.

meaning, if the GIL were removed from Python, the performance of threaded concurrency would soar, asyncio would not move an inch.

It "solves" the problem of me having to do five calls in parallel. They can with asyncio in theory be done at the same time, since python can move on and fire off the next calls while waiting for IO.

What about doing it the UNIX way before pthreads became a thing?

Well, yes, but there is a reason why pthreads became a thing.

Until people discovered the security and program stability issues that come with using them.

It was a cool idea that turned out not so be so great after all.

There is a reason why all major language runtimes are moving into thread agnostic runtimes, while security critical software and plugins are back into processes with OS IPC model.

Sorry, which languages? Go has shared memory multiprocessing, so does Rust, C#, Java...

They do, and in all of them is an anti-pattern to use raw threads instead of the higher level frameworks like goroutines, java.util.concurrent or TPL/DataFlow.

Go in their typical wisdom, doesn't even support thread local storage.

Additionally, Java and .NET have thrown away their security managers, and guess what is the best practice to regain their features in Java and .NET applications?

Multi-processing with OS IPC.

Sorry, we are discussing shared memory multiprocessing. I'm certainly not advocating unrestricted use of pthread_create, but even more structured way of parallelization still rely on shared memory.

But of course, for security address space separation is pretty much a requirement.

It's not an antipattern to use threads in Rust. Where did you get that idea?

> For instance, a local cache of some values is basically useless when python is used as backend. Since there will be multiple processes handling the requests (in the same node), they don’t share memory.

Obviously, you can choose to do it that way, but there is no reason that multiple processes can’t share memory in Python; there is, in fact, explicit support for this in the standard library.

This is perhaps the most difficult aspect about discussions involving the GIL, the level of nitpicking while ignoring the actual point when someone feels that python is being slighted.

> you can choose to do it that way, but there is no reason that multiple processes can’t share memory in Python; there is, in fact, explicit support for this in the standard library.

Yes, and you can also just use threads and directly go shared memory so you are not literally "forced", you are forced because the choice comes with a cost you don't want to pay. Depending on the OS for managing shared memory and using an API isn't much different from using a sidecar process and has its own cost over native shared memory model. In the end, most engineers will choose and have chosen redis or memcached over the alternatives. The GIL is still a huge factor in these decisions.