Andrei Alexandrescu wrote:
> 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).
>
No, it would be fair to assume that the total buffer size is the
same in both cases, which means that the asynchronous buffers will
have size 1/n times the synchronous buffer size (where n is the
number of threads). Which means that the asynchronous version will
issue n times as many seeks. Now you are right that those seeks will
be issued in a more efficient manner (especially since they can
probably be sent to the disk before the ongoing transfer is
completed). Whether the efficiency gain will offset the increased
number of seeks, I do not know but I doubt it...
Jerome
--
mailto:[email protected]
http://jeberger.free.fr
Jabber: [email protected]
signature.asc
Description: OpenPGP digital signature
