in reply to Re^4: Threaded Code Not Faster Than Non-Threaded -- Why?
in thread Threaded Code Not Faster Than Non-Threaded -- Why?
It seems like it will take a bit of experimentation to figure out how long to sleep and how deep to keep the queue.
These are not as critical as you might first think.
- sleep: A thread that calls $Q->pending once every millisecond will consume so few cycles that it barely registers on taskmanager/top.
Try this:
perl -MThread::Queue -E"$Q=new Thread::Queue; $Q->pending while Win32: +:Sleep( 1 )"On my system, that shows up in Process Manager as 0.0%.
So, running it at a frequency of once every timeslice -- ~10 milliseconds -- will consume negligible cpu whilst ensuring that the queue is (re)populated in a timely manner.
- Queue Length: A queue, shared between 16 threads, populated with a million longish paths, will consume less than 200MB.
Try:
perl -Mthreads -MThread::Queue -E"async{ sleep }->detach for 1 .. 16; +$Q=new Thread::Queue; $Q->enqueue( qq[/a/longish/path/and/filename$_] + ) for 1 .. 1e6; sleep;"Which given a typical modern system with 4-16 GB is nothing to concern ourselves with; and is at least 3 order of magnitude greater than I'd recommend as a starting point (100 for 16 threads).
For IO-bound process like this, tuning either or both variables over quiet a large range of values will have little or no effect on overall throughput.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^6: Threaded Code Not Faster Than Non-Threaded -- Why?
by Tommy (Chaplain) on Jan 06, 2014 at 03:15 UTC | |
by BrowserUk (Patriarch) on Jan 06, 2014 at 03:25 UTC | |
by Tommy (Chaplain) on Jan 06, 2014 at 04:55 UTC | |
by BrowserUk (Patriarch) on Jan 06, 2014 at 07:06 UTC | |
by Tommy (Chaplain) on Jan 06, 2014 at 18:27 UTC | |
| |
by Tommy (Chaplain) on Jan 06, 2014 at 04:55 UTC |