4 ms·
Ug... I'm fairly disappointed... His conclusions: - Separating a cold thread from its underlying hot thread is not without performance overhead... Of course c
by grogers 16y ago
Ug... I'm fairly disappointed... His conclusions:
- Separating a cold thread from its underlying hot thread is not without performance overhead...
Of course cache misses dominate performance. This is basically the first vector that work stealing queues attack. For eg. erlang tries to tie erlang processes to the same run queue (which maps to a kernel thread), for as long as it can as long as it maintains reasonably balanced run queues.
- Lack of preemptibility based on time quanta creates performance problems...
Well yeah, but either that is part of the model already (thread pool), or that is taken into account by the user level scheduler (ie. run X instructions or time then automatically yield to next runnable user level process).
- Nondeterministic LWP creation can have an appreciable and unpredictable impact on performance. The nondeterministic nature of the SIGWAITING mechanism makes performance debugging difficult...
Mainly because the SIGWAITING mechanism hes described (which sounds like it is based on solaris) is pretty bad for implementing user level scheduling. Windows 7 and MAC OS X Snow Leopard both seem to do significantly better (Maybe that's because they've had 10+ years to fix it...). In any case thread pools have generally worked around this by handling LWP creation based on the number of waiting threads and have seemed to be reasonable in performance.
That he even brings up his 14 year old outdated thesis is pretty sad when talking about the state of the art today. STM is no panacea but it is not worthless either.