3 ms·

I'd call Python optimal parallelism. I prefer the scaling by instance method of Node and Python over the old ways- writing multithreaded Java apps. People can k

I'd call Python optimal parallelism. I prefer the scaling by instance method of Node and Python over the old ways- writing multithreaded Java apps. People can knock themselves out writing stuff like that if they want to. But my purposes have been well-served scaling by spinning up instances per-core. For me, explicit pthreading should never be done except with systems software. In which case you're going to be using a systems language like C, C++ or Rust anyway. Not the oddball middletier stuff that isn't high or low level like Go, Java and C#.

weberc2 10y ago
Go's parallelism model is fundamentally different than the other languages you mentioned. Even if you never write any concurrent Go yourself, you could write single threaded routes and let the webserver handle the parallelism (this is more efficient than spinning up an OS thread per request). With Python, you also have to configure uwsgi or some such to deploy your application to each thread; with Go, the runtime handles this for you completely transparently--just run the binary and you're all set. Go isn't perfect, but using Python the way you are is just leaving money on the table.
- pcwalton 10y ago
  In the case of an I/O bound Web server, I don't think that Go is going to appreciably result in "leaving money on the table". Python releases the GIL on I/O, which is where your time is largely spent. > this is more efficient than spinning up an OS thread per request Linux is very fast at spawning threads. When you're doing I/O, it doesn't matter. Go's concurrency is not "fundamentally different" from any of the other languages. It's just an implementation of thread-per-connection in userspace. This is an implementation detail, and for a typical Web server I think it doesn't matter much.
- weberc2 10y ago
  In response to @pcwalton: > In the case of an I/O bound Web server, I don't think that Go is going to appreciably result in "leaving money on the table". Python releases the GIL on I/O, which is where your time is largely spent. GIL doesn't matter, the OP said he was writing single threaded application. This means he's doing async (unlikely) or blocking the entire application process (not just the current request) on I/O. > Linux is very fast at spawning threads. When you're doing I/O, it doesn't matter. Not as fast as goroutines, and spawn speed isn't the only (or even the most interesting) measure of efficiency--you can run several orders of magnitude more goroutines on a Linux box than you can threads. Of course, none of this is relevant to this conversation, since the OP is talking about running a single-threaded Python process per core. > Go's concurrency is not "fundamentally different" from any of the other languages. It's just an implementation of thread-per-connection in userspace. This is an implementation detail, and for a typical Web server I think it doesn't matter much. You're conflating Go's concurrency model with its webserver implementation. Go's concurrency model (movable M:N coroutines with implicit yielding and a synchronous abstraction over async IO) is fundamentally different than the other approaches (threads and vanilla coroutines with some blend of sync and unabstracted async I/O). Since you mentioned thread-per-connection, Go's "threads" are much lighter than even Linux threads, so you can service many more simultaneous connections (by many orders of magnitude in extreme cases). This is especially true if you're not using async I/O, and blocking I/O is the default for most of these other languages.
- BuckRogers 10y ago
  >but using Python the way you are is just leaving money on the table. Everything leaves some performance on the table. Everything also leaves some productivity on the table too. Python is in my estimation 20-50% more productive as a language than Go. I run my web stuff on PyPy/gunicorn/Nginx which within reason, can't be leaving much to be wanted performance-wise. I've given Go a good-go, but I haven't found anything that strikes that balance of ~25% more productive than Go, but still grant similar performance like PyPy does for me.

weberc2 10y ago

Go's parallelism model is fundamentally different than the other languages you mentioned. Even if you never write any concurrent Go yourself, you could write single threaded routes and let the webserver handle the parallelism (this is more efficient than spinning up an OS thread per request). With Python, you also have to configure uwsgi or some such to deploy your application to each thread; with Go, the runtime handles this for you completely transparently--just run the binary and you're all set. Go isn't perfect, but using Python the way you are is just leaving money on the table.

pcwalton 10y ago
In the case of an I/O bound Web server, I don't think that Go is going to appreciably result in "leaving money on the table". Python releases the GIL on I/O, which is where your time is largely spent. > this is more efficient than spinning up an OS thread per request Linux is very fast at spawning threads. When you're doing I/O, it doesn't matter. Go's concurrency is not "fundamentally different" from any of the other languages. It's just an implementation of thread-per-connection in userspace. This is an implementation detail, and for a typical Web server I think it doesn't matter much.
weberc2 10y ago
In response to @pcwalton: > In the case of an I/O bound Web server, I don't think that Go is going to appreciably result in "leaving money on the table". Python releases the GIL on I/O, which is where your time is largely spent. GIL doesn't matter, the OP said he was writing single threaded application. This means he's doing async (unlikely) or blocking the entire application process (not just the current request) on I/O. > Linux is very fast at spawning threads. When you're doing I/O, it doesn't matter. Not as fast as goroutines, and spawn speed isn't the only (or even the most interesting) measure of efficiency--you can run several orders of magnitude more goroutines on a Linux box than you can threads. Of course, none of this is relevant to this conversation, since the OP is talking about running a single-threaded Python process per core. > Go's concurrency is not "fundamentally different" from any of the other languages. It's just an implementation of thread-per-connection in userspace. This is an implementation detail, and for a typical Web server I think it doesn't matter much. You're conflating Go's concurrency model with its webserver implementation. Go's concurrency model (movable M:N coroutines with implicit yielding and a synchronous abstraction over async IO) is fundamentally different than the other approaches (threads and vanilla coroutines with some blend of sync and unabstracted async I/O). Since you mentioned thread-per-connection, Go's "threads" are much lighter than even Linux threads, so you can service many more simultaneous connections (by many orders of magnitude in extreme cases). This is especially true if you're not using async I/O, and blocking I/O is the default for most of these other languages.
BuckRogers 10y ago
>but using Python the way you are is just leaving money on the table. Everything leaves some performance on the table. Everything also leaves some productivity on the table too. Python is in my estimation 20-50% more productive as a language than Go. I run my web stuff on PyPy/gunicorn/Nginx which within reason, can't be leaving much to be wanted performance-wise. I've given Go a good-go, but I haven't found anything that strikes that balance of ~25% more productive than Go, but still grant similar performance like PyPy does for me.