4 ms·
I was fortunate enough to attend this talk. It was quite an eye-opener as far as how wonky thread performance is. The overall equation seems to be something lik
by crad 17y ago
I was fortunate enough to attend this talk. It was quite an eye-opener as far as how wonky thread performance is. The overall equation seems to be something like:
# of threads * # of cores == context switch storm density.
David was clear to say that his presentation was not to discourage people from using threads.
The take-away for me are to really pay attention to implementation of my thread usage and to see if linux processor affinity would help in a situation where you control all the threads in your app.
The upcoming changes to the GIL for 3.2 has a dramatic impact on stability of behavior in threading but a negative impact on IO threads, which they are planning on addressing.
- crad 17y agoWhile David had dismissed CPU affinity because of the potential of other threads in the stack not benefitting from additional cores, I wanted to test and see what impact it would have. Granted these are single run #'s on linux, but it's interesting to see that even a single thread adds minor overhead. Code: http://gmr.privatepaste.com/7ee226e690 Single call of the function: gmr@binti ~ $ ./test.sh real 0m10.840s user 0m10.824s sys 0m0.008s With Processor Affinity on Single CPU: gmr@binti ~ $ taskset 01 ./test.sh real 0m11.210s user 0m11.207s sys 0m0.004s Without Processor Affinity: gmr@binti ~ $ ./test.sh real 0m14.389s user 0m12.488s sys 0m3.789s