4 ms·

Also soon enough (if we aren't there already), fast hardware will be so cheap that the speed of execution at least for end user applications will rarely be a fa

Also soon enough (if we aren't there already), fast hardware will be so cheap that the speed of execution at least for end user applications will rarely be a factor. Sure that database application you wrote in C is measurably faster, but can a human being detect the difference? More and more the response will be no.

weberc2 10y ago
In the last 5 years, clock speeds have stagnated. Hardware innovation has revolved around increasing cores and improving power efficiency. Unfortunately, Python and most other dynamic languages are poorly suited to take advantage of parallelism, so your C database can only get faster, but your Python database will not.
- pcwalton 10y ago
  Honestly, the vast majority of languages are bad at parallelism. Dynamic vs. static doesn't have much to do with it. Task-parallel multicore (like goroutines and Web Workers and the like give you) is only a small fraction of what it means to "take advantage of parallelism", and if you're only using that (as opposed to SIMD, GPUs, concurrent data structures, work-stealing, etc.) then you are likely to see disappointing speedups in practice. This is especially true in the last 5 years, which contrary to your post has seen a shift away from multicore task-parallel hardware (core counts are not increasing) and toward data-parallel hardware (wider SIMD lanes, better on-board GPUs, APU architectures, etc.)
  - weberc2 10y ago
    You're missing the point. There's "suboptimal parallelism", and then there's "no parallelism". Python and many other dynamic languages fall into the latter category.
    - BuckRogers 10y ago
      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.

weberc2 10y ago

In the last 5 years, clock speeds have stagnated. Hardware innovation has revolved around increasing cores and improving power efficiency. Unfortunately, Python and most other dynamic languages are poorly suited to take advantage of parallelism, so your C database can only get faster, but your Python database will not.

pcwalton 10y ago
Honestly, the vast majority of languages are bad at parallelism. Dynamic vs. static doesn't have much to do with it. Task-parallel multicore (like goroutines and Web Workers and the like give you) is only a small fraction of what it means to "take advantage of parallelism", and if you're only using that (as opposed to SIMD, GPUs, concurrent data structures, work-stealing, etc.) then you are likely to see disappointing speedups in practice. This is especially true in the last 5 years, which contrary to your post has seen a shift away from multicore task-parallel hardware (core counts are not increasing) and toward data-parallel hardware (wider SIMD lanes, better on-board GPUs, APU architectures, etc.)
- weberc2 10y ago
  You're missing the point. There's "suboptimal parallelism", and then there's "no parallelism". Python and many other dynamic languages fall into the latter category.
  - BuckRogers 10y ago
    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.