Closed Ebola-Chan-bot closed 2 years ago
Please refer to the FAQ (first question) in the readme file. This is not a goal of the project for the reasons listed there.
It's not that I'm looking to make significant changes to this project, but rather that developers in the project who are good at assembly can try contributing to Stockfish. asmFish has had no updates for two years. On the contrary, in the past two years, Stockfish has added a significant change, NNUE. It seems unrealistic to catch up with the progress, but it is also a pity that the unique optimization of asmFish is left in dust here. I noticed that the FAQ mentions that asmFish does not respect the ABI. But is the ABI itself performance-critical? If not, just follow the standard. If it is, you might as well encapsulate the performance-critical function into an assembly module that complies with ABI externally. It does naturally not have to comply with ABI internally. As for the compiler issue, Stockfish also uses a lot of complicated settings to support various compilers. Adding some complexity is acceptable as long as it brings performance improvements.
Unfortunately, I have had not had the time to work on asmFish these past two years, and the other two contributors appear to have been equally as busy. However, if you want to try your hand at writing the module you describe, I'd be happy to review it for you.
Focus on the most critical performance improvement parts. C++ compilers can support inline assembly code. We do not need to rewrite the whole program in assembly at all. We can simply rewrite in assembly those performance-critical parts that we are sure to do better than the compiler. This way, we can save much coding work that the compiler could have done nothing worse than human handwriting. The official Stockfish community will not reject the inline assembly code as long as the commits strengthen Stockfish.