> Go is so huge there is not much that can be done with big precalculated data > (like endgame tablebases in chess).
i agree with the (not like endgame tablebases), but i'm not convinced about the former. scientific computing is generally done over massive problems. but there are usually ways to take advantage of big ram. any operation that happens a lot (equality comparisons, inequality comparisons, multiplication, addition, whatever), you can often translate into vector form in order to do many at once, for instance. there are lots of other tricky things -- perhaps it depends upon the speed of the cpu versus the speed of the ram, but generally there should be something that you can precompute to save time. just a thought. i'm soliciting opinions, really. which instructions take the most time in your code, for instance? which subroutines? > UCT is inherently serial, since it's a > best-first search algorithm. It uses information learned during previous > playouts to direct the line for the next playout. This also makes it hard > to use big memory. right. but perhaps there's something more basic that could be parallelized in computation via lookups? just a thought. > Many Faces has to be frugal with memory because its commercial. It has to > run well on older or smaller machines, so I default to a maximum of 300 MB > on a PC, and a maximum of 25 MB on an iPad. On the PC the user can increase > the memory, but only to 1.5 GB total because the PC version has to be 32 > bits. good point. s. _______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
