Prima wrote:Jeremey thanks for your time and assistance. Unfortunatle, it still did not compile here in VS2010 GUI. I still got the 'Output' message though. Heres' the error message:
Which leads me to another thing I've been curious about; (1) as you've seen, the stockfish 2.01pa-gtb's source has it's own source files in it. (2)Within this src folder, there's the 'egtb' folder which has gtb-related files, the progname.h, tbprobe.c, and version.h files in it. (3) Within this egtb folder, there are sysport folder, gtb folder, and compression folder. (4) Within the compression folder, there is the "wrap.c/wrap.h source files + huffman folder with its own hzip.c/h; the liblzf folder with its izf.h, c.c, d.c, h source files; the lzma folder with its source files, and the zlib folder with its own source.
With all these sub folders within the stockfish source, would it be better if I moved all the sources from the sub folders to the main stockfish source folder and compile, OR, do I have to keep using the "Add items" function from the VS Compile GUI till everything is added and then move to "Build" it?
Kingliveson had suggested (or at least inferred) that in Windows OS, he would move all source related files from sub folders to the main one or have everything in one place as Windows likes it this way. I tried this with Stockfish-gtb but still got errors. Attempting to compile via Command prompt (as thought by gaard), I still get this errors and never successful in compiling.
If I just "Add items" exclusively from its main source folder, it still won't compile. Which is the better solution here? Thanks in advance.
If you imported my project, the egtb files would have been compiled, too -- what changed? Look at the readme which comes with the Gaviota probing software: you have to a) compile those .c files (a list is given, but it's the ones there, with the exception of tprobe.c), b) add the .h files' paths to the search path (adding the enclosing folders to the list of additional #includes) and c) add a couple of items to the preprocessor defines list.
Uly wrote:Thanks fruity and gaard, here's a quick comparison of Stockfish PA_G and PA_H at 1CPU in the opening position. It seemed mostly luck, but PA_H found 1...e6 much earlier and reached depth 24 much faster, PA_G caught up at depth 25 and finished one minute faster in the end, though.
The change regarding history and killer moves seems to work well only at lower depths. I'm actually running a 1000 games 20 sec. match, 6 Threads. SF default is clearly in front after 800 games. I'll test SF PA_G against SF default at longer tc tonight.
Thanks fruity, would it be possible to make the new code conditional, so that it's only used at low depth but the original behavior is used at higher depth?
Jeremy Bernstein wrote:If you imported my project, the egtb files would have been compiled, too -- what changed? Look at the readme which comes with the Gaviota probing software: you have to a) compile those .c files (a list is given, but it's the ones there, with the exception of tprobe.c), b) add the .h files' paths to the search path (adding the enclosing folders to the list of additional #includes) and c) add a couple of items to the preprocessor defines list.
jb
Here's a VS 2010 project with all of the targets. You may just want to adjust the optimization settings. I have it set to use OLD_LOCKS, so that it runs under XP. Since my OS is 32-bit, I couldn't PGO the 64-bit version. I leave that as an exercise to the reader. 32-bit PGO version in Release/Win32/
Uly wrote:Thanks fruity, would it be possible to make the new code conditional, so that it's only used at low depth but the original behavior is used at higher depth?
Might be possible, but let's first wait and see how SF PA_G compares to SF default with 1000 20 sec games and 6 threads for each side.
SF PA_H was 10 Elo below SF default under those conditions. Exact numbers will follow.
When I have the gtbs installed, I get tbhits of 171800086257 all the time. Looks like the member variable is simply uninitialized. Can I simply set tbhits = 0 in Position::Position? Looks like it. It would be good to add some bench positions which exercise the tbs for profiling purposes, as well...
UPDATE: the 32-bit version linked above has been replaced with a version which a) properly initialized the tbhits count and b) does some amount profiling in tb code.
Jeremy Bernstein wrote:I needed to change a couple of lines in egtb.cpp: you were initializing the Chess960 variable before the Options map was ready, causing an annoying crash on my system.
Oops. Must have forgot to change that and just blindly copied it from my 1.9 port... (UCI options were retrieved differently on 1.9). Thanks for pointing this out.
Jeremy Bernstein wrote:When I have the gtbs installed, I get tbhits of 171800086257 all the time. Looks like the member variable is simply uninitialized. Can I simply set tbhits = 0 in Position::Position? Looks like it. It would be good to add some bench positions which exercise the tbs for profiling purposes, as well...
Weird. It always works for me. Sure, simply set tbhits = 0 to fix it, it shouldn't mess anything up, and it's something I should have done anyway...
It might be worthwhile to put this code up on github, so that we don't have to keep passing archives around. Any objections?
UPDATE: new version at link above. Seems to be the fastest so far, with some additional profiling. I added a new parameter to the "bench" mode to set the number of pvs. So "stockfish bench 128 4 10 default depth 2" will use a 128MB transposition table, 4 threads, search to depth 10, using the default FENs, and 2 pvs.
