Search found 341 matches

by noobpwnftw
Thu Jan 05, 2017 1:24 am
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: New 6-piece tablebases
Replies: 194
Views: 106955

Re: New 6-piece tablebases

I've tried build EGTB with SSDs some years ago, they worn out soon after a single run. Just don't do it. :P Nowadays consumer-class servers can have 1TB of memory, I have some spare ones if you want to do a 7-man run. But even if we build it, its hard to distribute and we will end up with some kind ...
by noobpwnftw
Sun Jan 01, 2017 6:26 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 5192

Re: Cumulative building of a shared search tree

My implementation requires specific hardware and software stack, it isn't meant to be downloaded and ran effectively under any environment. Since I already built everything for it, I wonder if it is worthwhile to port it to chess for whoever interested. Typical use case for this is that you can have...
by noobpwnftw
Sun Jan 01, 2017 4:45 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 5192

Re: Cumulative building of a shared search tree

Hash keys, or at least a hash index to partition the database is always needed unless your database is not on a large scale. But we have differences about the definition of a node: My 46 bytes(worst case) per node is used for alternative indexing, and this index is less than 2x the size of a hash in...
by noobpwnftw
Sat Dec 31, 2016 9:22 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 5192

Re: Cumulative building of a shared search tree

I agree with using only hash is fast & compact, but let me describe my method here: move+score is stored in a LSM tree, one index is bitfen representation of the board, which would have 361 bits per board, round up to 46 bytes at most, stored by a 64-bit radix tree index it would have no more than 6...
by noobpwnftw
Sat Dec 31, 2016 5:58 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: GPU chess update, local memory....
Replies: 14
Views: 3051

Re: GPU chess update, local memory....atomics...64 bit ops

GPU is not optimized for control logic, which is used extensively in chess engines. Even if you do get the same or better performance with NPS, it is still not efficient when pruned search is introduced. You would either waste too much on cut-offs(lazy) or waiting for the slowest child(ybwc) or just...
by noobpwnftw
Sat Dec 31, 2016 5:35 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 5192

Re: Cumulative building of a shared search tree

You can see what it is like from my web query interface. It is a database of chess engine search tree and supports live "lazy smp" style extension. I wonder how is it possible that you can generate moves with only an arbitrary 64-bit hashkey of the board without performing enumerating from an known ...
by noobpwnftw
Sat Dec 31, 2016 10:23 am
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 5192

Re: Cumulative building of a shared search tree

Storage size is not a problem, I wish to seek the possibility of saving the extra calculation/evaluation of the "same position" with different castling rights, it now seems not very viable after your discussion. It would be pretty much the same as my current Chinese chess implementation, can you kin...
by noobpwnftw
Thu Dec 29, 2016 11:20 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 5192

Re: Cumulative building of a shared search tree

You are right, in the endgames it is possible to make a subset for each castling condition if we have the "standard" tablebases, where this subset contains only the outcome of conversion to non-castling positions. My question is that if I want to build a large database for the opening stage, can I a...
by noobpwnftw
Thu Dec 29, 2016 6:51 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 5192

Re: Cumulative building of a shared search tree

Yes, it now contains about 300 million filtered positions(nodes) of which each move is evaluated & scored by no less than 20 plies. It also includes DTC&DTM EGTB probing. English version of my web query interface is: http://www.chessdb.cn/query_en/ I'm currently in the process of building Chinese ch...
by noobpwnftw
Wed Dec 28, 2016 1:37 pm
Forum: Computer Chess Club: Programming and Technical Discussions
Topic: Cumulative building of a shared search tree
Replies: 19
Views: 5192

Re: Cumulative building of a shared search tree

Despite being used as a normal opening book, chess engines can probe it from root/low level depth search to get pre-calculated(stored) PV or sort of moves to improve their search, while in the same time deeper search results can contribute to the shared search tree in the form of leaf discovery. Whi...