Graham Banks wrote: ↑Fri Sep 13, 2019 3:39 am
Even more shocking are the two crashes of Stockfish due to a faulty file.
One more crash and it's out.
The participant authors took a vote on whether or not the SF people should be allowed to replace that file. but because one voted no, it won't happen.
Which file of Stockfish was faulty?
After many tests this is really a surprise.
The faulty file was a Windows dynamic library file: libwinpthread-1.dll. Due to insufficient testing and insufficient attention to prior bug reports, this buggy file was part of the package sent to TCEC by the Stockfish "team". The file itself is not part of the Stockfish code. At least, this is my understanding. So one more crash/hang by Stockfish and the engine is disqualified.
Thanks.
I did not know the official Stockfish use such .dll.
When I tried it I got very few speed up, if any.
My understanding is that there is no real speed increase from using the linked library. But using it allows the MingW compiler to carry out LTO (link-time optimization), which does seem to give a good speed boost (at least on some systems, not mine).
I run Linux.
I use Windows 7/10 x64 and popcount without positive effect.
If I know well at earlier time Stockfish did not use .dll files during TCEC competition either.
I support the disqualification. This sets a precedent so that participants make sure they send something that works, instead of being greedy and trying to send the fastest possible thing without enough testing.
TCEC shouldn't be a place where you send your engine for testing, the testing should have already taken place, and if it hangs and loses and you didn't know, it's your fault, and people shouldn't be expected to reset the scores and let you send something that works, because, what if it doesn't work either? Do we enter a loop until they send a version that doesn't hang?
People, just send your stable, well-tested version. Experiments should happen in your laboratory, not the championship.
Your beliefs create your reality, so be careful what you wish for.
Ovyron wrote: ↑Sat Sep 14, 2019 12:02 am
I support the disqualification. This sets a precedent so that participants make sure they send something that works, instead of being greedy and trying to send the fastest possible thing without enough testing.
TCEC shouldn't be a place where you send your engine for testing, the testing should have already taken place, and if it hangs and loses and you didn't know, it's your fault, and people shouldn't be expected to reset the scores and let you send something that works, because, what if it doesn't work either? Do we enter a loop until they send a version that doesn't hang?
People, just send your stable, well-tested version. Experiments should happen in your laboratory, not the championship.
I totally agree with you
Do NOT worry and be happy, we all live a short life
MikeGL wrote: ↑Fri Sep 13, 2019 1:40 pm
Yes, it was my impression too that Windows and OS/2 was designed to use DLL not to improve speed, but to save disk space. The intention was that similar API (libraries) inside the DLL file can be reused by most applications, hence saving small disk space.
Sorry, I am not claiming I am technically better than those SF programmers, but building a binary with additional DLL is _not_ optimum, in my opinion.
Yes, IMHO linking to a .dll file has problems. For instance communicating with this may require certain conditions by the OS and it may ectually slow down the executables. I would recommend a "static build".
I don't understand, that clever people at fishcooking are fighting to get 1% more speed! BTW You can still download TCEC compile from forum and test it's speed. In my cpu it is not faster than abrok version, but maybe even a bit slower .
.