Perft(14) Weekly Status Report

[sje]

Perft(14) Weekly Status 2014-09-14

There are more than 800,000 perft(7) results so far, about 0.83% of the 96,400,068 needed.

Completed work units (9): 000-004, 008, 010-011, 964
In progress (8): 005-007, 009, 012-015
Not yet started (948): 016-963

Work units in progress:

Code: Select all

WU#  Comp% Machine
---  ----- -------
005: 70.4% joni
006: 70.4% megan
007: 17.9% melissa
009: 63.5% cynthia
012: 47.7% amanda
013: 64.5% serra
014: 97.1% kristen
015: 59.3% rocky

--------

Work on Oscar continues and soon I hope to have it running under OpenCL.

Once Oscar has its own heap manager, then it should be possible to build an initial version of an OpenCL kernel for testing and optimization. Oscar will then need a work unit processor which will include file operations plus an OpenCL parallel dispatcher. I am sufficiently confident of a reasonable success that I'm already shopping for a high end GPU for my main Linux box.

[sje]

Perft(14) Weekly Status 2014-09-21

There are more than 1,100,000 perft(7) results so far, about 1.14% of the 96,400,068 needed.

Completed work units (12): 000-004, 008, 010-012, 014-015, 964
In progress (8): 005-007, 009, 013, 016-018
Not yet started (945): 019-963

Work units in progress:

Code: Select all

WU#  Comp%  Machine
---  -----  -------
005  82.9%  joni
006  81.6%  megan
007  21.2%  melissa
009  82.2%  cynthia
013  94.6%  serra
016  67.5%  kristen
017   9.5%  rocky
018  17.8%  amanda

The current rate of progress is about 36,200 perft(7) calculations per day.

[sje]

Perft(14) Weekly Status 2014-09-28

There are more than 1,300,000 perft(7) results so far, about 1.25% of the 96,400,068 needed.

Completed work units (14): 000-004, 008, 010-016, 964
In progress (8): 005-007, 009, 017-020
Not yet started (943): 021-963

Work units in progress:

Code: Select all

WU#  Comp%  Machine
---  -----  -------
005  97.0%  joni
006  95.8%  megan
007  25.2%  melissa
009  94.3%  cynthia
017  43.6%  rocky
018  84.5%  amanda
019  13.1%  serra
020   7.1%  kristen

[sje]

A pair of speed tests

Very roughly and with numbers which vary from machine to machine, perft() testing has shown:

1) Bitboard Symbolic is faster than 32 bit Oscar by a ratio of two to one when both run on 64 bit hosts.

2) Oscar is faster than Symbolic by a ratio of three to two when both run on 32 bit hosts.

It the above, Symbolic is using four cores while Oscar is using only one core.

The idea is that a typical GPU will handle 32 bit programs much better than 64 bit programs, so Oscar should do well.

Now it may be that a typical GPU processing element may be only one tenth the speed of the host CPU. But the host CPU might have only a few cores while a decent video card might have a thousand of them, so the hope is that a good GPU will have a hundred times the throughput for this particular application. This will bring the perft(14) project to completion in a few months vs the better part of a decade.

--------

What would it take to transmute Oscar into a full chess program?

It would need an evaluation function, and the non-recursive perft() routine would have to be replaced by a non-recursive search() routine. As these routines live in the OpenCL part of Oscar, they need to be coded without any references to any C/C++ library or even any standard header file.

All the little Oscars running on a video card would have to be controlled by a master program running on the machine's CPU, and that program would also have to handle the book, tablebases, I/O, and any other external requirements. But it could be done.

[sje]

Perft(14) Weekly Status 2014-10-05

There are more than 1,800,000 perft(7) results so far, about 1.87% of the 96,400,068 needed.

Day count: 58
Average throughput: 31,034 results/day

Completed work units (19): 000-006, 008-018, 964
In progress (8): 007, 019-025
Not yet started (938): 026-963

Work units in progress:

Code: Select all

WU#  Comp%  Machine
---  -----  -------
007  29.9%  melissa
019  39.7%  serra
020  67.5%  kristen
021  13.7%  joni
022  47.4%  amanda
023  12.6%  megan
024  19.4%  cynthia
025   1.8%  rocky

[SuneF]

Perft(14) Weekly Status 2014-10-05

There are more than 1,800,000 perft(7) results so far, about 1.87% of the 96,400,068 needed.

Day count: 58
Average throughput: 31,034 results/day

Completed work units (19): 000-006, 008-018, 964
In progress (8): 007, 019-025
Not yet started (938): 026-963

Work units in progress:

Code: Select all

WU#  Comp%  Machine
---  -----  -------
007  29.9%  melissa
019  39.7%  serra
020  67.5%  kristen
021  13.7%  joni
022  47.4%  amanda
023  12.6%  megan
024  19.4%  cynthia
025   1.8%  rocky

We started the perft14 with Don but we did some things differently.

1) we held an open contest to find the two fastest clients written by two different authors.
2) we confirmed the results as we went along by comparing their results.
3) we set it up as a distributed architecture with Don hosting the backend.
4) there was a small web site to track and compare amount of work by the different contributors.
5) we did a trial run on a lower perft to test the distributed engine and iron out bugs.
6) the starting FENs and their multiplicity were confirmed by 3 or 4 people.

With all that going for it there still wasn't more than a handful of contributors and it didn't run for long. I guess nobody was really very interested in the actual perft14 result, it was more of a "let's go to the Moon.."-feeling, which just didn't last very long.

Still someone has to be nutty enough to actually finish the calculation

[sje]

We started the perft14 with Don but we did some things differently.

1) we held an open contest to find the two fastest clients written by two different authors.
2) we confirmed the results as we went along by comparing their results.
3) we set it up as a distributed architecture with Don hosting the backend.
4) there was a small web site to track and compare amount of work by the different contributors.
5) we did a trial run on a lower perft to test the distributed engine and iron out bugs.
6) the starting FENs and their multiplicity were confirmed by 3 or 4 people.

With all that going for it there still wasn't more than a handful of contributors and it didn't run for long. I guess nobody was really very interested in the actual perft14 result, it was more of a "let's go to the Moon.."-feeling, which just didn't last very long.

Still someone has to be nutty enough to actually finish the calculation

I had considered writing a BOINC client, and then use the BOINC operational framework for calculating perft(14), perft(15), etc. And it's possible that Oscar might be used for a BOINC client, written by me or by someone else.

It's a lot of work, though.

At present, the perft() work units are public, the completed work unit results are public, and the status reports are public. All results will be verified eventually. All work units have been verified via their successful use with calculating perft(7) through perft(10). It would be very difficult for a bug to hide in the work units.

[sje]

6) the starting FENs and their multiplicity were confirmed by 3 or 4 people.

I'll comment some more on this, because it's an important point and because the work units I've posted or which others may post for various depths might be used for other perft() calculations.

If any of these are incorrect, then all subsequent efforts are a total waste.

That's why I took great care in preparing the unique() files and have posted the files for unique(0) through unique(6). The unique(7) file can be made by concatenating all of the raw work units; the work units themselves were made by the Unix split program working on the unique(7) file with orders to produce 964 100,000 line files and a single 68 line straggler file.

All of the unique() files have passed a number of tests by both Symbolic and Oscar. The files should match those produced by others when allowing unimportant differences due to ordering and non-distinctive differences due to possible variant half move counter values for some records.

(There are no two records in any unique() file which are identical other than having different half move counter values. I have tested this with sort, cut, and uniq. However, there are cases of records which of which two are identical except for a difference in the en passant target square; if the target is non nil, then the half move counter is, and must be, zero. If I were to re-write the unique() generator, I'd have it output each FEN with the half move counter value being the minimum of all such values seen for that position with a nil en passant target. I just didn't think of this at the time.)

All of the unique() files themselves were produced by Symbolic using a multithreaded algorithm which does not use any disk operations until the final results are written. This was done in part to avoid the possibility of I/O errors, particularly those of the undetected variety. It was also done in part for speed of generation. The main disadvantage of the algorithm is that it's not suitable for higher order unique() runs because of memory size limitations. Should I never need to make any higher order unique() files, then I'll have to write a new generator.

--------

So based on heritage and test results, I have no concerns about the validity of the work units. And for similar reasons, I have no concerns about the perft() calculation abilities of bitboard Symbolic and mailbox Oscar.

But I do have a concern for possible CPU/GPU/memory random errors due to unavoidable, temporary disruptions caused by high energy cosmic rays. These do happen, and they happen much more frequently than you might think -- this is why server grade computers employ ECC memory. Fortunately, these errors usually do not affect program operation as most of the time the induced bit-flip occurs in an unimportant memory location. But not always, and the only solution is a multiple re-run and comparison of the results; this is how BOINC handles the problem.

[sje]

Perft(14) Weekly Status 2014-10-12

There are more than 2,000,000 perft(7) results so far, about 2.07% of the 96,400,068 needed.

Day count: 65
Average throughput: 30,769 results/day

Completed work units (21): 000-006, 008-018, 020, 022, 964
In progress (7): 019, 021, 023-027
Not yet started (937): 007, 028-963

Work units in progress:

Code: Select all

WU#  Comp%  Machine
---  -----  -------
019  91.9%  serra
021  33.3%  joni
023  34.1%  megan
024  54.2%  cynthia
025  61.0%  rocky
026  38.0%  kristen
027  29.1%  amanda

--------

I've taken the oldest and slowest machine out of service, at least for now. It did not respond well to recent transposition table allocation changes because of little memory and vampire video eating what was available. Perhaps later I'll make a special case allocation scheme, but not now.

[sje]

Perft(14) Weekly Status 2014-10-19

There are more than 2,200,000 perft(7) results so far, about 2.28% of the 96,400,068 needed.

Day count: 72
Average throughput: 30,556 results/day

Completed work units (23): 000-006, 008-020, 022, 025, 964
In progress (7): 007, 021, 023-024, 026-028
Not yet started (935): 029-963

Work units in progress:

Code: Select all

WU#  Comp%  Machine
---  -----  -------
007  16.2%  serra
021  46.6%  joni
023  54.4%  megan
024  82.5%  cynthia
026  95.2%  kristen
027  91.7%  amanda
028  28.8%  rocky

--------

These reports are also online. Sample link: https://dl.dropboxusercontent.com/u/316 ... 2014-10-19

Also, the results. Sample link: https://dl.dropboxusercontent.com/u/316 ... 000.sum.gz