in reply to
Re^2: dynamic number of threads based on CPU utilization
in thread dynamic number of threads based on CPU utilization
When a CPU runs in terms of literally billions of ops per second these days, and it is drawing its inputs from a large number of files, then ... it is I/O-bound because that’s what it is waiting on. Nanoseconds vs. milliseconds. The completion-time of this program, over the course of let us say one minute, will chiefly be regulated by its ability to perform input/output, not by the speed of the processor(s). If you were to place the program onto a CPU that ran twice as fast, all other things being equal, such a program would not complete in half the time. If it truly were CPU-bound, then it would not “slow down,” a-n-d drop out of CPU-utilization at the same time, as it is reported to be doing.
As you say in the (upvoted) earlier comment, this is a poorly thought-out program from the start. I would further guess that the hash might well have become enormous by that time, and that quite possibly the program has descended into “thrashing hell.” Something, and it can only be I/O, is utterly preventing the CPU from getting any work done during the second phase. Thrashing is about the only culprit that exists to explain that.