Re: File output and buffering

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 21 Aug 2008 00:10:52 -0700 (PDT), Maciej Sobczak wrote:

> On 20 Sie, 17:39, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> Buffering is used to make I/O in an asynchronous and/or conveyered way.
> 
> No, it is not asynchronous. Nothing happens in the background, the
> operations are only grouped. The group is (usually) transmitted in the
> synchronous fashion.
> 
> I do not know what is "conveyered".

Pipelined processing. When you refer to throughput, then it is increased
only because of existence of hidden conveyers, which ultimately always
boils down to some asynchronously working elements.

>> That does not make I/O faster in terms of latencies.
> 
> It does make it faster in terms of throughput.
> 
> Note: I do not imply that throughput is more valuable for optimization
> than latency - these can be different goals and usually are.
> 
>> Any language buffer on top of numerous layered buffers, typical for an OS,
>> adds nothing, but overhead.
> 
> It can reduce the overhead that is associated with the number of
> requests. System calls are not free and there is also a significant
> latency of the medium that is better to be avoided (like network
> roundtrips or disk seek times).

Well, here we need to clarify what is the I/O end point. When you say
"system call" it presumes that the end point is the driver. Let us fix it.
Now, the next question is where coalescing/pipelining is to happen. See
where it goes? Is the driver's interface a stream of units or else, also,
of blocks of units?

Case A. There is no back door to the driver, you have only a stream. What
can buffering add? Nothing, but overhead.

Case B. There is a back door for pushing bigger chunks of units. Then use
it in your application and it will go *faster* than whatever buffered
interface on top of the same thing!

Note also that A and B usually refer different protocol layers. It is
common to put a stream layer onto something block-oriented beneath, and
reverse. That stream is buffering and necessarily an overhead. Buffering is
always overhead. We buy it only because the alternative is inaccessible,
like to do DMA transfers from the application. But a language library is in
the *same* position as the application, so buffering there would gain
nothing, *from* performance perspective.

Ada.Text_IO is slow because of the buffering it does in order to implement
a protocol (pages) which you do not need. Classic abstraction inversion
case.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de