Let us mourn the death of AsmFish

[Dann Corbit]

http://www.sp-cc.de/

It is now essentially the same strength as Stockfish.

Now, people will say that the graph is simply compressed because of the longer time control. I doubt it. SF8 under the same new conditions has the same strength or a wee bit higher (probably not discernible under the error bars).

No need to bother with AsmFish anymore.
It's dead or dying, and now it's hit the floor.

I think something bad probably also happened to SF also between June and August. Just Elo compression due to more time? Why then, is SF8 not equally affected? And the time control change was not very dramatic (IOW, we do not see this evil compression effect even between CCRL 40/4 and 40/40 a ten times increase in time control -- It takes huge hardware and cores to do that.). It is also possible that the book is defective, and that could be the full explanation for the problem. If you have a won position in a book exit, and then the weaker and stronger engines play both sides reversed, the weak engine gets a free win from that. But according to my understanding, that book was checked very carefully. So the bad book seems an unlikely explanation.

I would be very interested to see if Cfish has been immune to the plummet.

[Dann Corbit]

Another book defect is a draw book.
That is to say, the book leaf exit points lead to draws.
That makes strong engines look weaker and weak engines look stronger.

If that is the problem, it could be discovered simply by retesting using the old book. If the gap reappeared, it is the book that is the source of the tightening band.

But again, this is supposed to be an especially good book.

[syzygy]

No need to bother with AsmFish anymore.
It's dead or dying, and now it's hit the floor.

That's just nonsense. It is a lot faster than SF and therefore stronger unless a bug has crept in. If a bug has crept in, it is just a matter of finding and quashing it.

IMHO there is no need for such a dramatic title as you have used here, which in my perception does not show much respect for the incredible amount of work that has gone into creating and maintaining asmFish.

[Werewolf]

I thought asmfish was +20% or something faster than SF Dev. If so, it should show an advantage across all time controls, though diminishing at LTC, but it should still be stronger.

[Henk]

I was surprised they did not quit with AsmFish earlier. Already in 1987 they told me you should only write the small time critical parts of a system in assembler.

[cdani]

I was surprised they did not quit with AsmFish earlier. Already in 1987 they told me you should only write the small time critical parts of a system in assembler.

Fixed concepts (preconceptions) are only valid when they are valid.

[ernest]

I thought asmfish was +20% or something faster than SF Dev.

It is even more than that (25 to 30%) depending on the position...
But it is clear that the Elo advantage of speed only (double speed for instance) decreases significantly when Time Control is increased.
Andreas Strangmuller has convincingly shown this effect in his tests
(see http://www.fastgm.de/).

[Ras]

Already in 1987 they told me you should only write the small time critical parts of a system in assembler.

This is still valid because developing anything in assembly takes much longer than in C or C++. However, this is irrelevant if:

1) you don't have to pay the development time because the developers do it in their free time
AND
2) time to market doesn't matter.

I do write in assembly from time to time, but mostly because I have to go so low-level that even C doesn't offer what I need.

[MikeB]

asmfish is alive and well, and I, for one, appreciate the efforts and the results they are making and I hope they continue, it's not easy... good job 👊

[lantonov]

I look at the Stefan Pohl link you have given and I don't see asmFish hitting the bottom. Quite on the contrary, it's soaring in the sky, especially in combination with the Cerebellum book (asmBrainFish)
To quote Mark Twain, announcing the death of asmFish is a little exaggeration.