etc.curl: Formal review begin

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Aug 31 12:52:23 PDT 2011


On 08/31/2011 02:15 PM, Marco Leise wrote:
[snip]
>> If I understand the above correctly, the same amount of seeking goes
>> around in both cases. The only difference is that requests come at a
>> faster pace, as they should.
>>
>> Andrei
>
> That's not what I wanted to say. Let me put it like this: If you read
> the file in one call to read and the write the whole thing from your
> buffer you have only 2 of these 'long' seeks.

Yes. It is fair to assume that the asynchronous case uses buffers of the 
same length as the synchronous case. Then the grand total number of 
seeks will be the same or better for the asynchronous version (better if 
the OS handles concurrent seek requests cleverly with some elevator 
algorithm).

It's really simple. The synchronous version is the worst case because it 
needs a seek for read and a seek for write in each epoch. (One epoch = 
one buffer is read and written.) The asynchronous version still needs to 
do seeks for reading and writing, but in the same amount, and issues 
them at a faster rate.

> Practically you wont use a
> 2 GB buffer for a 2 GB file though, but I assume that it would be the
> fastest copy mode from and to the same HDD, whereas the multi-threaded
> approach would make the OS switch between writing some data for the
> writer thread and reading some data for the reader thread, probably
> several times per second. And each time a seek is involved.

That is the case whether or not the requests are coming from the same 
thread or not.

> (Due to IO scheduler optimizations it wont end up like this though. The
> OS will detect your read pattern (linear) and read a sane amount of data
> ahead and disk access will generally be optimized to reduce seek times.)

This will happen all the more if you have multiple threads.

You clearly have a good expertise on OS, I/O, and related matters, and I 
am honoured by your presence and by the value you're adding to this 
group. However, in this particular argument you're only firing blanks. 
Are you sure you have a case?


Andrei


More information about the Digitalmars-d mailing list