On 18-Oct-00, 23:52:44 Chris G. Demetriou wrote:
>  "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.

I downloaded some Alpha manuals to get hints how expensive are
read-write barriers and write barriers. I will look more closely at them
today.

It looks like rw barrier would be really needed if we are going
to provide consistent semantics. Another possibility is to use some
state - but it would be probably more expensive than barriers.

And - if it is needed - _nb_ version could (and should) be used. There
is not that much code that needs to be optimized. Setting audio output
parameters on audio card certainly isn't. Serial interrupts or
serial putc or getc routine may be.

  
> > >  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).
Sorry, I had missed the point (2AM).
We can have _nb_ versions of them too - it's not the problem. I still
think that default (ie. shorter name) should do the barrier.


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

After closer investigation, I realized that in this case (older network
cards - mostly ISA) performance bottleneck is the ISA bus itself. It
will limit thoughput and on modern CPUs speed will be the same - with or
without barriers.


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

So you are probably right here.

I agree that optimizing before examining speed/effort ratio isn't good
idea.


>  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)

In this case, there is not much work to optimize. And if we don't
provide efficient implementation, we risk that someday somebody won't
use _region_ version, but will choose to use loop of _nb_ writes.


Wasn't that the case with timeout()/untimeout() interface?
(I heard that motivation to introduce callout scheme was that it
could be used in places where timeout() was avoided due to
speed/scalability problems)



        Witold J. Wnuk