<div class="gmail_quote">On Wed, Aug 31, 2011 at 11:39 AM, Marco Leise <span dir="ltr"><<a href="mailto:Marco.Leise@gmx.de">Marco.Leise@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Am 31.08.2011, 00:07 Uhr, schrieb Andrei Alexandrescu <<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a><u></u>>:<div><div></div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 8/30/11 3:34 PM, Marco Leise wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 30.08.2011, 20:48 Uhr, schrieb Andrei Alexandrescu<br>
<<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a><u></u>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 8/30/11 1:10 PM, Jonathan M Davis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
std.file.copy is synchronous. Would the suggestion then be to change<br>
it to be<br>
asynchronous or to create a second function (e.g. copyAsync) which<br>
does an<br>
asynchrous copy?<br>
</blockquote>
<br>
I think std.file.copy should do whatever the heck is best to copy a<br>
file. As such, it should be transparently asynchronous. It would be<br>
great if such a task caught your fancy - and don't forget to test<br>
speed under a few circumstances.<br>
<br>
Andrei<br>
</blockquote>
<br>
I expect the performance to degrade if you copy asynchronously on a<br>
single HDD, since more seeking is involved.<br>
</blockquote>
<br>
Why would more seeking be involved?<br>
<br>
Andrei<br>
</blockquote>
<br></div></div>
Usually files are laid out on the disk in more or less contiguous chunks. The naive algorithm would read a large block first and then write it. The disk head only has to move twice for every of these blocks. Once it has to seek the source sector and once the destination sector. If on the other hand you have both operations in parallel then - unless the OS does some heavy heuristic optimization - you have the disk head move constantly as the operating system interleaves the long series of reads and writes in order to serve data to both threads. I don't know the internals of any kernel enough to tell you exactly how this is done, but it makes sense that the disk can operate faster if it doesn't waste time moving the head around. And that is what would happen in a multi-threaded copy algorithm on a single HDD.<br>
<br>
If you want to learn more about IO schedulers, take a look here:<br>
<a href="http://wlug.org.nz/LinuxIoScheduler" target="_blank">http://wlug.org.nz/<u></u>LinuxIoScheduler</a><br>
and here<br>
<a href="http://www.cs.ccu.edu.tw/~lhr89/linux-kernel/Linux%20IO%20Schedulers.pdf" target="_blank">http://www.cs.ccu.edu.tw/~<u></u>lhr89/linux-kernel/Linux%20IO%<u></u>20Schedulers.pdf</a><br>
<br>
If you want to test your algorithm without an IO scheduler optimizing your reads and writes on Linux you can to the following. First use<br>
<br>
cat /sys/block/<your disk here (hda|sda|other...)>/queue/<u></u>scheduler<br>
<br>
to find out which schedulers are supported and which is active. For me it prints:<br>
<br>
noop [cfq]<br>
<br>
Then, to select 'noop' the "no operation"-scheduler type:<br>
<br>
echo noop > /sys/block/<your disk here>/queue/scheduler<br>
<br>
You can use the first command again to verify that the scheduler is set.<br><font color="#888888">
<br></font></blockquote><div><br></div><div>Yes, but the disk should be able to do out-of-order execution of read and write requests (which SCSI was designed to allow), which should make this never be an issue. My understanding is that most SCSI implementations (and it's in just about every storage protocol out there) allow this, with the exception of Bulk Only Transport, which is used with USB hard drives and flash drives. That will soon be replaced by USB Attached SCSI (<a href="http://en.wikipedia.org/wiki/USB_Attached_SCSI">http://en.wikipedia.org/wiki/USB_Attached_SCSI</a>), which specifically allows out of order execution.</div>
<div>The end idea behind much of SCSI is that the disk designers are much better at knowing what's fast and what's not than the OS developers, and if we need to worry about it on the application level, something has seriously gone wrong. </div>
</div><br>