Uri Blass wrote:Today programmers know things that they did not know in 2004.
Not really. Most of the core mechanics of Stockfish are based on, in some cases, very old (mathematical) theories.
The difference between SF and other engines is not nearly as great as people think it is and the differences that do exist are subtle. SF's true strength lies in its optimization of these theories. SF is an extremely well optimized piece of software. That is why it is so strong. So, if you're going to try and look for some magic under the hood, you won't find it.
All of SFs code combined makes it so strong. Not any individual piece. In fact, some of its individual elements could be made to be far stronger with the help of chess professionals (GMs/Super GMs).
If programmers do not know things that they did not know in 2004 then explain what is the reason that programs of today(not stockfish) are stronger than programs of 2004
The facts are that
there are many free chess programs that are better than the top programs of 2004.
I do not deny that
some elements of stockfish can be made far stronger but knowing
is clearly an advantage.
If you know that you can expect playing strength X from simple algorithm and later you can expect at least additional 100 elo from adding hash tables and later you can expect at least additional 80 elo from null move pruning and... then it is clearly an advantage because it gives you a plan what to do and if you do not get the expected elo improvement you know that you probably has some bug in your implementation or you need to tune values.
Of course you may get more elo improvement when I say at least.
Well, one explanation of why SF in particular seems to be so much stronger -- is the sheer number of people working on it.
Another thing is algorithm optimization and, very simply, compiler optimization. Engines that have not seen any development since 2004 are obviously built towards the available hardware of 2004. Meaning that some CPU intensive algorithms that were not yet viable in 2004 simply weren't used. And, as I said, compiler optimizations. Instructions that were not yet available in 2004 are making it into the executables of modern day engines. Instructions that by themselves do not add elo but they do provide measurable speed improvements.
Which in turn does result in elo improvements.
The differences are small ones but they simply all add up. Just look back at the evolution of SF's playing strength (measured by elo) -- It's not like there have been singular patches that improved its strength by 10% overnight. The gains are all very small. It's just that their compounding effect is a substantial one. Simply because it's so many (small) improvements over time. A speed improvement here, a simplification there, a couple of bug fixes left and right. Most of the commits amount to that, nothing more. And it's been like that for quite some time now. Personally I can't really readily recall a singular commit that gained SF more than, say, 10 elo.