Hi,
Please take a look on two following cases
1. 12 files and one copying thread
2. 12 files and 4 copying threads mean one thread will copy 3 files.
Which process will take less time?
Printable View
Hi,
Please take a look on two following cases
1. 12 files and one copying thread
2. 12 files and 4 copying threads mean one thread will copy 3 files.
Which process will take less time?
There's no *correct* answer... but... on single processor machine (non-hyperthreaded) copying 12 files from same HDD #1 on same HDD #2 (source and destination HDDs may be different)... will most probably be faster to use 1 thread.
From my experience, usually observed with external (2.5" HDDs), concurent threads / processes copying files to / from same HDD will mostly block each-other through the locking system which makes it safe copying.
Multi-threaded applications running on a single-core processor which doesn't even support hyperthreading... will only benefit of responsiveness by giving more UI control and allow the developer establish priorities between tasks performed concurently... i.e. they look faster but they don't execute faster, and that is because they execute less unnecessary work. For example, an application which supports dynamic panning of large quantities of data, would choose to skip redrawing several intermediar frames when the user is panning faster. ;)
When copying n files of known size, the amount of work is known: linear result depends on the amount of data to be copied and the speed allowed by the current hardware environment. Thus, having the data on separate devices might make sense to split the task into separate threads. Copying files is like communicating with COM devices... but if all files are on the same device... what's the point in having sync threads???
I hope my explaination is clear.
Best regards,
When working with the disk, most threads will be waiting for the disk to catch up to where the thread needs it to be. If the waiting time can be properly interleaved (in Windows, you could use I/O completion ports), then the multi-threaded approach will be far faster, on any processor architecture.
How would that be faster on any processor architecture?Quote:
Originally Posted by MikeAThon
Using the I/O completion ports, or even low-level disk access, no matter how well syncronized, cannot be faster with multiple threads executed by the same processor.
Regards,
I tend to disagree, since you are not considering the fact that most of the time, any one single thread is waiting for disk access. While it is waiting, another thread might be finished waiting for disk access, and can do work. So, as I said before, if the waiting time can be properly interleaved (such as by using IOCPs), then multiple threads will be far faster than a single thread, even if there is only a single processor.Quote:
Using the I/O completion ports, or even low-level disk access, no matter how well syncronized, cannot be faster with multiple threads executed by the same processor.
Mike
If your program is just about copying files, then there's little point to multi-threading----the running time will be dominated by disk access anyway, which by and large can't be alleviated by threading.
Hi Mike!Quote:
Originally Posted by MikeAThon
I appreciate your oppinion and respect the way you've elaborated it.
Honestly, I think the only way I'd be convinced to agree that multi-threading with IOCPs is faster than single-threading with IOCPs on single core single processor architecture, would be to see a comparation matrix after testing several hardware environments and different sets of data. 'till then, we'll probably continue to disagree... but I respect that; it happens a lot.
Cheers,
I believe what Mike is saying (with a bit more clarity) is that: if work can be done while the disk is busy, then there is opportunity for speedup using either threading or IOCP's.
I believe Bornish's position is: if you are 100% "disk-bound", then there is no opportunity for speed up.
Both are correct! :)
gg