mcostalba wrote:Well, anybody is free to submit patches or fork Stockfish as long as he wants and I am very glad of this (as I think also my teammates), so I am not in a role to force people to follow a guidance. What I can say is my opinion on this subject, but I _don't_ assume my opinion is the rule and people should follow it: everybody is free to do whaterver he prefers.
...including the Stockfish team, which is free to reject patches. My point is that most sane open-source contributors want to produce mergeable changes. (This is not a jab at the Stockfish or Crab forks - there are exceptions.) If some contributors aren't experienced engine developers, their ideas might still work, but they'll have to ask you the same questions about testing -- or accidentally produce invalid tests, leaving you to explain why.
More on-topic, I guess: for SF vs. Crab or SF vs eval-patched-SF tests, which opening book(s) do you typically use?
Well David Dahlem you are right it could be 2-5 or 4-7 ranks. In any event Crab would not get full bonus because it is not centralized in 3-6 ranks. But over all it does not matter since you win anyway. Interestingly your theory may explain those scary eyes too. I assume Crap is fighting something on the board and that is preventing it from centralizing.
By the way this build seems to have about same speed comparing to stockfish-171-32-ja.exe, but it consumes less memory. For me when set to use 64MB is uses 68MB while stockfish-171-32-ja.exe uses 90MB. So I assume it has to be something about compilation, maybe some aggressive optimizations. So still I think comparing the two would not be exactly comparing the changes since there are other differences. For a better test we may compile Crab exactly same as stockfish-171-32-ja.exe or stockfish-171-64-ja.exe for 64bit systems.
More on-topic, I guess: for SF vs. Crab or SF vs eval-patched-SF tests, which opening book(s) do you typically use?
In case you are asking me, I am using a pgn of games of players rated 2650+. I usually use positions after 7-10 first moves. It seems that there are some games without moves that I may remove them from the set, other than that they seem about equal positions when engines start playing.
that would be strange.... :/
aggressive speed optimizations normally yield larger memory requirements as far as i can remember... but i am not really into compiler optimization that i would be sure...
really there shouldn't be something wrong about the compile... and as you said the speed difference between the build is not really relevant...
just test the 171 32bit and 64bit builds they show the exact same behavior...
I used visual studio 2010 ultimate for the compiles.
gets around 2700kN/s so its as fast as the JA build
Ok, I think I identified the main _problem_. My original testing versions run at 350kN/s like SF ja universal builds on this poor labtop with a celeron CPU...
Your 32 bit build runs at 500kN/s like SF ja 32bit build on labtop. So I think without a CPU like core 2 duo or better really testing chess engines would not be much reliable anyway.
Look wrote:Here is code of a new engine based on StockFish 1.7.1 called Crab 1.0 beta. Changes in it are few mostly in evaluate.cpp.
It is the fact that SF's function "evaluate" raises my doubts (pawns, passed pawns) and it is possible that someone could write it in a completely different way. But to consider this as the original program, these differences must be very important.
My point is that most sane open-source contributors want to produce mergeable changes. (This is not a jab at the Stockfish or Crab forks - there are exceptions.) If some contributors aren't experienced engine developers, their ideas might still work, but they'll have to ask you the same questions about testing -- or accidentally produce invalid tests, leaving you to explain why.
