I am praying for CPython to become faster. But I need faster singlethreaded performance, so web applications benefit from it.
I am praying for CPython to become faster. But I need faster singlethreaded performance, so web applications benefit from it.
That was a really sad moment, and I've never felt good about python since.
I wanted "as you wait for the GPU to churn through this batch, start reading the next batch from disk & preprocessing it on the CPU"
Getting this to work turned out so ass backwards it made me sad
Also I pity the fool who tries to connect a debugger to code using multiprocessing.Pool()...
PyCharm works fine
I solved it by using python threads and C function (cv2.resize)
Like anything, it’s possible to split this work out to a separate process but the IPC overhead is a lot.
That said, many such databases are (or already have) rolled out connection pool proxies for reasons like this, so meh.
While performance may not matter, productivity very much suffers from multi-process programming.
I’m saying that the penalties (including development effort) for work co-ordinated between processes compared to threads can vary from nearly zero (sometimes even net better) to terrible depending on the nature of the workload. Threads are very convenient programmatically, but also have some serious drawbacks in certain scenarios.
For instance fork()’d sub-processes do a good job of avoiding segfaulting /crashing/dead locking everything all at once if there is a memory issue or other problem when doing the work, it’s very difficult in native threading models to do per-work resource management or quotas (like maximum memory footprint, or max number of open sockets, or max number of open files) since everything is grouped together at the OS level and it’s a lot of work to reinvent that yourself (which you’d need to do with threads). Also, the same shared memory convenience can cause some pretty crazy memory corruption in otherwise isolated areas of your system if you’re not careful, which is not possible with separate processes.
I do wish the python concurrency model was better. Even with it’s warts, it is still possible to do a LOT with it in a performant way. Some workloads are definitely not worth the trouble now however.
Typical ways around that include mmap’ng things or various types of shared memory IPC, but that is a lot of work.
When I execute this:
python3 -c 'import time; time.sleep(60)'
And then pmap the process id of that process, I get 26144K. That is 26MB.As for timing, when I execute this:
time python3 -c ''
I get 0.02sAlso, since the copy on write generally is memory page by memory page, even if you were doing a lot of that, if most of those ref counts are in a small number of pages, it’s not likely to really change much.
It would be good to get real numbers here of course. I couldn’t find anyone obviously complaining about obvious issues with it in Python after a cursory search though.