Re: [computer-go] Data structures for Go

["Antoine de Maricourt" <antoine.de-maricourt@xxxxxxx>]

> >  The only way to do it is to run benchmarks, and I don't think ...
>
> Run benchmarks and decide for yourself, that's what I advocate too.  I
> am  only   suggesting  an  alternative  and  have   already  given  my
> disclaimer, your results may or may not agree with mine.

Alternatives are always interesting and I'm very glad to hear many points
of view :-)

> I have heard  that "modern processors" are designed  to do fast memory
> to memory  copies.  You  seem to believe  that memory copies  are done
> serially, but I  had assumed that they must be  done in parallel.  I'm
> sure someone on this group knows the answer and will comment.

This is a little more complicated. Read/writes are done in parallel in the
sense
that you can read/write a whole line of data (something like 32 or 64 bytes)
at the same time. On the other hand memory access are serialized, or more
precisely put in a queue in a specific buffer of the processor, in order to
desynchronise memory access from computation. Which means that, in
the mean time, computation can be performed, while scheduled memory
access wait to be performed. This also looks like parallelism because once
memory access are enqueued, computation can continue whether memory
access is done or not - unless this is a read and you need the result
immediately [ I assume pentium technology, but I would bet this
is similar with other processors ].

But, as a consequence, if you only perform read/write and as soon as the
memory queue is full, your processor will synchronise again with memory
access, which is what you want to avoid. Of course, different levels of
cache will affect the whole performances.

I'm not sure if this is clear, but the fact is that when a program's speed
is
dominated by memory access (which might arise with a pure state copying
strategy), you may perform computation for free.

When performing speed tests, I've seen performances decrease by 5 to 10 %
just by inserting a single write instruction in the play() routine.

> If  your program  does spend  most of  the time  in  ladder/life death
> searches, and most of this time  is making and unmaking moves, then it
> behooves you to do the fastest  thing, whatever that is.  You might be
> suprised to find the extra programming  effort is not worth it, or you
> might not.   To me, it's  worth the trouble  to run the  benchmark and
> find out.

Fully agree.

    Antoine.

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://computer-go.org/mailman/listinfo/computer-go