Compared to a context switch it ought to be negligible. So an alternative way could perhaps be to measure the divisor at startup, and also have a counter over active threads so the function doesn't do anything if there's only one thread running. (It could perhaps even be removed from evaluator_callbacks altogether then.)
Btw, is gethrtime always cheap? Wouldn't it be wise to put that too behind the div_ check?
I've investigated the reason for the frequent calls a bit more now, and I think there are some suspect check_threads_etc() in apply_low.h. E.g. the following program generates 4 million calls per second to check_threads on my system:
int gronk() {return 17;} void work() { while (1) gronk(); }
int main() { for (int i = 0; i < 5; i++) Thread.thread_create (work); sleep (10); }
The reason for the many calls is the pike function call in the loop. Every pike function call and most lfun calls causes a call to check_threads, while many other call variants do not. Is there a reason for this? I'm considering replacing all the check_threads_etc() calls in apply_low.h with a single fast_check_threads_etc(6) at the top.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-10 01:01: Subject: Frequent context switches
It's better than the previous version, but I suspect it would still slow things down noticably. However, I think some measurements would be in order to know for sure. (On various platforms of course)
/ Fredrik (Naranek) Hubinette (Real Build Master)