3 ms·

> you won't get CPU concurrency, but if your server is not CPU bound you might not notice much of a difference That's not true. Most applications, with the pos

> you won't get CPU concurrency, but if your server is not CPU bound you might not notice much of a difference That's not true. Most applications, with the possible exceptions of proxies, are also CPU bound. Take for example a web service that receives JSON documents. The act of parsing JSON documents is CPU bound. The act of creating a response is CPU bound. In between you can also have IO bound operations, like fetching data from a MySQL database or a Memcached instance, however in the process of creating the final response you also need to transform the data received and that's also CPU bound. As a real world example, I worked on a web-service written in Scala and running on the JVM. Initially it was running on only 8 Heroku dynos and these instances were receiving over 30,000 requests per second of real traffic. These Heroku instances are of course under-powered, because on my modest laptop the same web server is able to handle more than 10,000 requests per second. And yes, asynchronous I/O lets you easily have 100,000 connections per server. But if you need throughput, then the CPU starts being a bottleneck. Of course, my problem with Python and why I migrated away from it is that in truth Python sucks for asynchronous I/O too. But that's another story.

illumen 13y ago
Wrong. Those examples are IO bound - memory. You'll find the CPU waiting on memory in these cases. JSON is parsed in C with CPython, or in assembly with PyPy. As a real world example, I've done realtime image processing of a gigabyte per second worth of data on a single machine with asynchronous python. It was IO bound, we had more CPU to spare. Hell, we even had some GPUs sitting there not doing anything because they weren't needed. If you're doing real performance computing, then taking advantage of GPUs/DSP or other hardware is where it is at anyway. Python is quite good at a glue language for interfacing to these things.
- deleted 13y ago
  [deleted]
- ithkuil 13y ago
  Unfortunately if the CPU is waiting for memory, then thread is stuck, even if the hardware CPU had resources to execute some other instructions it cannot execute them from the same stream of instructions. Instead it could execute another stream of instructions, i.e. another thread. This is how hyperthreading works and still requires you to write a multithreaded application with the same problems and requirements.
- johnsoft 13y ago
  Memory is I/O from the hardware standpoint, but I don't think that makes sense from a Python coder's standpoint. Python doesn't release the GIL while waiting for a memory fetch, so multiple threads can't concurrently wait on memory the CPU asks for. You're still waiting until the GIL is released before any thread which needs it can execute. If you're calling out to GPUs or DSPs, it's likely the interop code releases the GIL, improving the concurrency situation. But I think by "real concurrency", the author was referring to pure Python, CPU-bound (or memory-bound) code.

illumen 13y ago

Wrong. Those examples are IO bound - memory. You'll find the CPU waiting on memory in these cases. JSON is parsed in C with CPython, or in assembly with PyPy. As a real world example, I've done realtime image processing of a gigabyte per second worth of data on a single machine with asynchronous python. It was IO bound, we had more CPU to spare. Hell, we even had some GPUs sitting there not doing anything because they weren't needed. If you're doing real performance computing, then taking advantage of GPUs/DSP or other hardware is where it is at anyway. Python is quite good at a glue language for interfacing to these things.

deleted 13y ago
[deleted]
ithkuil 13y ago
Unfortunately if the CPU is waiting for memory, then thread is stuck, even if the hardware CPU had resources to execute some other instructions it cannot execute them from the same stream of instructions. Instead it could execute another stream of instructions, i.e. another thread. This is how hyperthreading works and still requires you to write a multithreaded application with the same problems and requirements.
johnsoft 13y ago
Memory is I/O from the hardware standpoint, but I don't think that makes sense from a Python coder's standpoint. Python doesn't release the GIL while waiting for a memory fetch, so multiple threads can't concurrently wait on memory the CPU asks for. You're still waiting until the GIL is released before any thread which needs it can execute. If you're calling out to GPUs or DSPs, it's likely the interop code releases the GIL, improving the concurrency situation. But I think by "real concurrency", the author was referring to pure Python, CPU-bound (or memory-bound) code.