== Quote from Andrei Alexandrescu > > Suppose all the cores but one are already preoccupied with other stuff, or > > maybe you're even running on a single-core. Does the threading add enough > > overhead that it would actually go slower than the original single-threaded > > version? > > > > If not, then this would indeed be a fantastic improvement to phobos. > > Otherwise, I wonder how such a situation could be mitigated? > There's a variety of ways, but the simplest approach is to pass a > parameter to the function telling how many threads it's allowed to > spawn. Jay? > Andrei
I can tell you that there are a couple of seconds improvement in the execution time running 16 threads vs 8 on the i7 on the ssd drive, so we aren't keeping all the cores busy with 8 threads. I suppose they are all blocked waiting for file system operations for some portion of time even with 8 threads. I would guess that even on a single core it would be an advantage to have multiple threads available for the core to work on when it blocks waiting for the fs operations. The previous results were on an ssd drive. I tried again on a Seagate sata3 7200rpm hard drive it took 2 minutes 12 sec to delete the same layout using OS, and never used more than 10% cpu. The one thread configuration of the D program similarly used less than 10% cpu but took only 1 minute 50 seconds to delete the same layout. Anything above 1 thread configuration on the sata drive began degrading the D program performance when using the hard drive. I'll have to scratch my head on this a while. This is for an optiplex 790, win7-64, using the board's sata for both the ssd and the hd. The extract of the zip using 7zip takes 1:55 on the seagate disk drive, btw ... vs about 50 secs on the ssd.
