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:
> 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.
-- 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."