Re: File output and buffering

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

On Fri, 22 Aug 2008 14:41:18 -0700 (PDT), Maciej Sobczak wrote:

> On 22 Sie, 15:22, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> One last try. In your example, when
>> characters of a message are sent *synchronously* (assuming E-mail as the
>> transport layer, no back doors, etc) then each single character has to be
>> sent as a reply to the answer to the earlier mail.
> 
> Then we have a different notion of "synchronously".
> When I write something to the file, the operation is synchronous when
> the program *waits* for the transfer to complete.

The transfer of the group, not the transfers of the individual items of.

>> The very ability to send
>> multiple characters in one mail means that they are sent in parallel =
>> asynchronously.
> 
> Then we have a different notion of "asynchronously".
> When I write something to the file, the operation is asynchronous when
> the program can continue while the transfer is being handled.

That is the same notion. Asynchronous = not synchronous. The semantics of a
transfer of a group of items does not depend on the order and exact timing
of the transfers of individual items. If any, because they might be not
transferred at all. Consider protocols which recode the group, digital
fountains, etc.

> And we have also a different notion of "parallel".
> When I send a mail, it is transferred serially over a network cable.

Wrong, they are printed and then sent per pigeon post. 

You have defined the transport layer as E-mail. That's it. Don't make
suggestions about how E-mail might work, there are lots of ways.

> The longer is the mail the longer it takes (hint: with parallel
> communication the time of transmission would not depend on the number
> of characters in the mail, since they would be sent, well, in
> parallel).

Nope I have a huge rack of multiplexed modems installed in the cellar.

You again make assumptions about possible implementations of the transport
layer, which weren't there when you presented the example. If the transport
were rather a synchronous bytes stream, then buffering obviously would
bring *nothing* to the throughout.

>> � �http://en.wikipedia.org/wiki/Buffer_%28telecommunication%29
> 
> Short, but nice. Especially point d).

Right, it says "operated on as a unit", read my previous posts. Who
operates them as "a unit"? You need an independent asynchronous agent
capable to do so, otherwise it is not a unit. If you have such an agent,
and you can talk to it in terms of such units, then that is *without*
buffering, and it is faster than anything else. The purpose of d) is to
collect, it is merely an adapter between two protocols. Layered protocols
are always slower.

>> Note the category of the article, read the purposes of buffering.
> 
> Yes, the purpose d) is what I'm talking about. I use buffers to group
> data into smaller number of bigger units. This is where the
> performance gain comes from.

No, it is where you lose performance, because I just send bigger units
directly.

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