Boost logo

Boost :

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2005-11-24 14:20:41


On 11/24/05, Robert Ramey <ramey_at_[hidden]> wrote:

[snip]

> The current binary archives are implemented in terms of
> stream i/o. This was convenient to do so and has worked
> well. But basing the implemention on streams results
> in a slow implemenation. The documentation explicitly
> states that archives do not have to be implemented in terms
> of streams. The binary archives don't use any of the
> stream interface other than read(.. write(.. so it would
> be quite easy to make another binary archive which isn't
> based on stream i/o. It could be based on fread/fwrite.
> Given that the concern of the proposal of the authors
> is to make the library faster for machine to machine
> communication and the desired protocols (MPI) don't
> use file i/o, the fastest would be just a buffer
> say buffer_archve which doesn't do any i/o at all.
> It would just fill up a user specified buffer whose
> address was handed at buffer_archive construction time.
> This would totally eliminate stream i/o from the equation.
>
> Note that this would be easy to do. Just clone binary_archive,
> and modify it so it doesn't use a stream. (probably don't want
> to derive from basic_binary_archive). I would guess that
> that would take about a couple of hours at most.
>
> I would be surprised to see if the 10x speed up still exists
> with this "buffered_archive".

Creating a "buffered_archive" wouldnt require copying? And as Matthias
have already put, it is an unacceptable overhead. I'm having some
ideas about a 'fake_buffered'_archive.

best regards,

--
   Felipe Magno de Almeida
Developer from synergy and Computer Science student from State
University of Campinas(UNICAMP).
Unicamp: http://www.ic.unicamp.br
Synergy: http://www.synergy.com.br
"There is no dark side of the moon really. Matter of fact it's all dark."

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk