"Witold J. Wnuk" <w.wnuk@zodiac.mimuw.edu.pl> writes:
> [ ... ]
> It would need to be read-write barrier after read and after write
> in forth case then. Alternatively before.

yes, the question is, how do you encode that reasonably.  on the
alpha, read-write barriers really are fairly expensive, and for many,
many devices all you need are write barriers a very large fraction of
the time.

The point is, if you embed them, then you you pretty much need to
choose something close to the most complete combination... which can
be kinda painful.


> > > Other functions: I don't think there is a need for _nb_ versions
> > > of _multi_ or _region_ functions. They copy large amounts of data,
> > > and one barrier (_multi_ probably requires more barriers anyway
> > > (perhaps it is possible to avoid them on current processors?))
> > > can't hurt (or can it? - _nb_ versions could be introduced later
> > > - when there is a need for them).
> >  
> >  well, things kinda break down here.  for instance, write_multi_N
> >  pretty much _has_ to imply a write barrier on systems with write
> >  buffers, otherwise it could end up being issued as exactly one
> >  write,
> >  as you've noticed.  8-)
> >  
> >  For some devices, though, there's really no point in having that
> >  barrier at all, and barriers can be fairly expensive operations.
> >  (e.g. if you're copying something to a frame buffer...)
> _region_ version will be used for that, right?

Right.  But above you say "and one barrier ... can't hurt" in that
case (or at least, that's my understanding of what you meant to say).


> Many network cards (mostly older ones though) use write_region - i think
> it is worth some effort - and it won't take much.

right, so, the general rule for optimization is "find out (not know)
what you need to optimize, then do it."

I say "find out (not know)," because, of course, expectations often
differ from reality.  (and then you have to ask: "ok, which functions
of the set are really worth optimizing?" if you don't want to do all)



cgd