5 ms·
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
by 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 agoUnfortunately 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 agoMemory 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.