I think I'll respond here as not to further detract from David
congratulory thread. :)
While not addressing the replies separately, rest assured that I've read
them all.
Quickly picking up on what Claus wrote here, I agree that there might be
some kind of "prestige angle" to exploit to get some
support/funding/sponsoring. More specifically I've been thinking about
the PS3, which already has a [EMAIL PROTECTED] client for example, as Sony
might be receptive to pitching a "PS3 dominating the last bastion of
human processing through its distributed awesomeness" narrative. It's a
Japanese company, they have a huge installed hardware base and they
could easily streamline distribution and maintenance of the distributed
software infrastructure.
Now, for the technical matter: Could somebody please point me to a quick
rundown of how modern Go engines exactly utilize multicore environments
and the workload is segregated and distributed? I don't have any
significant knowledge on that, so any pointers would be much appreciated.
I understand that there's a huge difference between having a dedicated
multicore system or a close high-bandwidth network and some WAN
distributed computing, but how much leeway is there to optimize Go
calculations towards wide-area networking? Expecting usable processing
and response times, the data chunks of course will shrink while overhead
increases, but is there a sweet spot, where it could escape the
silly-window-syndrome while retaining appreciable scalability?
The nitty-gritty metrics on how the engines handle the workload would be
really interesting. This could also help approximate where potential
chokepoints in the feasibility of grid computing GO are and whether some
of them can be broken and remedied.
Apologies if this actually has been discussed to death before, but I
just can't resist indulging my curiosity.
Regards,
Mike
Claus Reinke wrote:
But for grids (instead of clusters), the communication will become much much
bigger - I'd like to study that carefully one day, I have no clear idea of what
is possible.
A trouble is that on grids (at least the ones I've seen) there are often
faults. We'll have to be fault tolerant I guess.
I've been somewhat on the fence for grids, but that is mainly because
computer scientists are at least as intelligent as Monte-Carlo playouts:
if adding "grid" to a project increases its chances of getting funding,
then "grid" will be added to the project, no matter how; and for a while,
that was exactly what happened - "grid this" and "grid that" everywhere..
However, while browsing papers like
"Toward Third Generation Internet Desktop Grids"
http://hal.inria.fr/inria-00148923/en/
isn't quite as fascinating as reading about the newest Go programming
techniques, it doesn't sound entirely hopeless, either. And isn't INRIA
nearby for some of you? If not, I'm sure that some funding agency in
your neighbourhood decided to steer research toward grid research
long ago;-)
Perhaps some of you Go engine authors could give some of those
Grid researchers a challenge - they have the hardware, the software,
and the need to research grid issues to justify their funding.
And you have the application that might be able to use all that. Unless
they think that their tools can't handle your requirements, they should be
quite interested in participating in your publicity ("beyond blue gene",
"the final man-machine intelligence challenge", and all that;-), not to
mention demonstrating that their tools can handle well-known-to-
be-tough problems. The genuine researchers among them will even
want to figure out how to address the research issues you raise.
Since netlag has been an issue even for slow human games over
internet servers, I'm sure it is going to be an issue here. But that
doesn't mean it is going to be insurmountable (as long as the
whole grid doesn't sit behind the same microwave transmitter;-).
Claus
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
