4 ms·
Let me first say that I agree with you. However, I think that the threaded model is in general easier to work with, rather than shared memory. That said, this
by anonymous 13y ago
Let me first say that I agree with you.
However, I think that the threaded model is in general easier to work with, rather than shared memory. That said, this might be offset by python itself being easier to work with than another language.
Also, separating work into multiple processes gives in general better security - one crashing worker won't impact the others. Then again, you won't take advantage of hyper-threading features of the CPU.
In the end, everybody needs to consider their personal needs and make a tradeoff.
- AnIrishDuck 13y ago> I think that the threaded model is in general easier to work with, rather than shared memory. The thing is, threaded models of programming in other languages already use the "shared memory" model, they just make it more implicit. Which leads to tons of problems for inexperienced developers who don't really understand concurrency, or the performance problems that shared memory can bring in modern processors. > In the end, everybody needs to consider their personal needs and make a tradeoff. Agreed.
- mwcampbell 13y agoCan you please explain why using processes instead of threads means you can't take advantage of hyper-threading? It may seem obvious from the name "hyper-threading", but I want to make sure that this inference is accurate.
- AnIrishDuck 13y agoIt shouldn't. Processors with hyper-threading enabled expose two virtual processors to the operating system per physical core.