[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] Parallelizing GNU Go

From: Dave Denholm
Subject: Re: [gnugo-devel] Parallelizing GNU Go
Date: 04 Apr 2003 00:21:49 +0100

Paul Pogonyshev <address@hidden> writes:

> Dave Denholm wrote:
> > Would possibly be a good thing anyway to get rid of all globals, and
> > have state attached to an environment pointer.
> encapsulating is a great concept, but i'd rather not use it with the engine.
> i don't see any reasons to have several engine states at the same time.
> besides, omitting that pointer saves us characters in source files,
> considerable amount of time (assuming we would have to pass it everywhere
> around via stack) and, finally, makes the code more readable (to me at
> least ;).

it wouldn't necessarily slow it down. Eg ARM cpu doesn't really like
accessing global variables. All memory accesses are relative to
a register. So what it tends to have to do is dump a pointer
to the global it wants, and then load that pointer from memory
relative to pc register. So every function ends up with a constant
pool of all the globals it wants to access.

I don't know, but I think ppc tends to do the same, but perhaops
at file level rather than fn level. One register is reserved for
the table-of-contents for that file.

Or something like that.

Anyway, x86 is quite happy to access globals, so it's not such a
big deal.

Using a state might make some things easier. Eg if the engine wants
to make a list of things to investigate, it might be useful to clone
the state structure and add to a list. 

This would achieve the same effect as fork()-ing a child process
to do the work, but more portably.

But I don't know how much state we are talking here : probably a *lot*.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]