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.
Let us mourn the death of AsmFish
Moderators: hgm, Rebel, chrisw
-
- Posts: 12542
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Let us mourn the death of AsmFish
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
-
- Posts: 12542
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: Let us mourn the death of AsmFish
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.
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.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: Let us mourn the death of AsmFish
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.Dann Corbit wrote:No need to bother with AsmFish anymore.
It's dead or dying, and now it's hit the floor.
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.
-
- Posts: 1797
- Joined: Thu Sep 18, 2008 10:24 pm
Re: Let us mourn the death of AsmFish
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.
-
- Posts: 7220
- Joined: Mon May 27, 2013 10:31 am
Re: Let us mourn the death of AsmFish
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.
-
- Posts: 2204
- Joined: Sat Jan 18, 2014 10:24 am
- Location: Andorra
Re: Let us mourn the death of AsmFish
Fixed concepts (preconceptions) are only valid when they are valid.Henk wrote: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.
Daniel José - http://www.andscacs.com
-
- Posts: 2041
- Joined: Wed Mar 08, 2006 8:30 pm
Re: Let us mourn the death of AsmFish
It is even more than that (25 to 30%) depending on the position...Werewolf wrote:I thought asmfish was +20% or something faster than SF Dev.
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/).
-
- Posts: 2488
- Joined: Tue Aug 30, 2016 8:19 pm
- Full name: Rasmus Althoff
Re: Let us mourn the death of AsmFish
This is still valid because developing anything in assembly takes much longer than in C or C++. However, this is irrelevant if:Henk wrote:Already in 1987 they told me you should only write the small time critical parts of a system in assembler.
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.
-
- Posts: 4889
- Joined: Thu Mar 09, 2006 6:34 am
- Location: Pen Argyl, Pennsylvania
Re: Let us mourn the death of AsmFish
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 👊
-
- Posts: 216
- Joined: Sun Apr 13, 2014 5:19 pm
Re: Let us mourn the death of AsmFish
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.
To quote Mark Twain, announcing the death of asmFish is a little exaggeration.