stegemma wrote:I think that it's not a good position to test perft, because Kings are both already castled. In the opening, castling has a big impact in move generation, because of it's "complicated" rules. This lead to in-accurancy on performance estimation of a perft routine, without castling.
It doesn't test promotion, either. But that's okay because no one position can test everything in a reasonable amount of time. What the above position does do is to provide a known set of complex middlegame positions which can be used to generate timing benchmark data.
The so-called "kiwipete" position seems to offer almost everything that might be found in the late opening/early middlegame:
[D]r3k2r/p1ppqpb1/bn2pnp1/3PN3/1p2P3/2N2Q1p/PPPBBPPP/R3K2R w KQkq -
I could be missing something, but I was planning on building a 32-64 node mini-supercomputer with the Raspberry Pi units. Harnessing the 24GFLOPS of the GPU on each board and using MPI to break big problems into smaller units each node can chew on. I have not crunched the numbers yet, but I think even this $5K machine would be pretty powerful due to being massively parallel compared to existing i7 processors which are largely serial in their computational abilities comparatively speaking.
Meh, who knows, maybe I am barking up the wrong tree with regards to using it for chess perft analysis, but I think it could speed up the time to solve some of the deeper levels.
There are already at least a handful of universities that have built these devices and they handle problems that would take a very long time on an i7 type processor....and would not be cost effective to build using i7 architecture.
I've got about 150 K perft(7) calculations completed, about 1/6th of one percent of the total work needed. At present, I'm working on a mostly automated restart facility so that the usual power outages won't cause excessive loss or delay.
I don't see how one of these GPUs with a maximum of only two hardware threads and a clock of 700 MHz is going to help a whole lot.
Also, compared to a BB Black, a Raspberry Pi must have an SD card, an extra expense.
It's gonna be fun to build it and use it to tackle some cool problems. I will have a look at how we can divide perft analysis up across the 64 nodes and see what benefit will be gained by having all those nodes analyze simultaneously. Will report back here once we have some results.
Just for the record, I have just reminded that the late Don Dailey initiated a project of distributed perft for calculate Perft(14). It first started with Perft(12) to verify the validity of the project, then going to Perft(14). Links:
Please note the estimated completion date of that time for Perft(14): June of year 2038!
I guess that you want something similar, this is why you made available chunks of 100,000 positions as you explained before. I can only wish good luck to you because I do not have a powerful hardware to help.
I don't see how one of these GPUs with a maximum of only two hardware threads and a clock of 250 MHz is going to help a whole lot.
Also, compared to a BB Black, a Raspberry Pi must have an SD card, an extra expense.
It's gonna be fun to build it and use it to tackle some cool problems. I will have a look at how we can divide perft analysis up across the 64 nodes and see what benefit will be gained by having all those nodes analyze simultaneously. Will report back here once we have some results.
Jeff
Yeah, the VC4 is really not much use for one of these. Also, the VC4 by default runs at 250 MHz, so it's pretty slow. It's designed for video tasks etc, not for general purpose computing. You'd need an Adreno or something for that.
(There is a reason the Broadcom proprietary libraries do not come with OpenCL support)
I don't see how one of these GPUs with a maximum of only two hardware threads and a clock of 250 MHz is going to help a whole lot.
Also, compared to a BB Black, a Raspberry Pi must have an SD card, an extra expense.
It's gonna be fun to build it and use it to tackle some cool problems. I will have a look at how we can divide perft analysis up across the 64 nodes and see what benefit will be gained by having all those nodes analyze simultaneously. Will report back here once we have some results.
Jeff
Yeah, the VC4 is really not much use for one of these. Also, the VC4 by default runs at 250 MHz, so it's pretty slow. It's designed for video tasks etc, not for general purpose computing. You'd need an Adreno or something for that.
(There is a reason the Broadcom proprietary libraries do not come with OpenCL support)
Some cool libraries are starting to emerge with regards to the VC4 in the Pi. This is the kind of stuff our group will be looking at as well as how to break a much larger project into smaller chunks and do the work on a parallel system.
GPU_FFT is an FFT library for the Raspberry Pi which exploits the BCM2835 SoC V3D hardware to deliver ten times the performance that is possible on the 700 MHz ARM. Kernels are provided for all power-of-2 FFT lengths from 256 to 131,072 points inclusive.
Maybe not as much a slouch as some people are thinking...
