Re: [gnugo-devel] Parallelizing GNU Go

[Dave Denholm]

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*.


dd
-- 
address@hidden          http://www.insignia.com