CODA now has a released page.

[adamtwiss]

Hi, Adam!

​Thank you so much for the detailed explanation about the extensive threat-based features and the ARM NEON SIMD optimizations. It’s exciting to hear you want to make ARM a first-class architecture for Coda!

​To answer your question, I tested the engine on two different devices to see how it handles different hardware generations:

1. ​Vivo Y11
◦ ​Specs: Android 11, Snapdragon 439 (Octa-core up to 1.95 GHz)

◦ ​Performance: In DroidFish analysis mode, Coda gets around 20k–25k NPS. For comparison, the absolute lowest I usually see on this device with Stockfish or other engines is 40k–50k NPS (on 1 core).

Despite the lower NPS, Coda plays surprisingly well in blitz and fast time controls (1+1 and 30s+0.5) without blundering.

2. ​Samsung A16 5G
◦ ​Specs: Android 16, MediaTek Dimensity 6100+ (Octa-core, 2.2–2.4 GHz)

◦ ​Performance: In DroidFish analysis, Coda reaches 100k–110k NPS. Other engines usually floor at a minimum of 150k NPS on this device.

​The Good News (Basic Stability Test):
The most common issue I face in my tournaments with unoptimized or buggy ARM ports is that they play erratically, make irregular/illegal moves, or perform significantly worse than older versions.

​Coda completely passed my baseline stability test here. Even with 100k NPS, it successfully defeated a stable 200k+ NPS engine in a test match. This tells me that its core logic and tactical strength are solid and functioning perfectly on Android, even if the memory bandwidth/cache limits on phones are currently bottlenecking the raw speed.

​Thank you again for looking into the NEON profiling over the weekend. I’m happy to run more tests on these devices whenever you have a new build to try!

So I have one ARM linux micro-server that is a mobile class Rockchip Cortex-A76. This I can get 165-170k NPS on a 'coda bench' on 0.9.0. I'd expect most modern phone class hardware to match this.

My ARM NEON support was a bit bit behind, and catching up with some amd64 optimisatiosn I've done on this have already delivered a 30% NPS gain on, and there's a bit more I can do. On my Macbook M5 I can do 1M+ NPS single core and a lot more multi-core. For the next point release I'll have much better ARM support ready, along with some other nice elo gains. I hope to push a 0.9.1 release some point next week.

Thanks gain. I really appreciate the testing feedback.

[Gabor Szots]

When will it be not 'pre-release'?

[adamtwiss]

When will it be not 'pre-release'?

The github pre-release label right now is just to indicate that development is still moving very fast, and had very limited testing by people other than me. It's partly just to lower people's expectations somewhat in case they have issues, or find any compatibility issues. I'd actively encourage testing/feedback across a wider range of hardware and harnesses and to get a broader set of performance measurements. As soon as I am moderately confident that engine is working/peforming reliably for people I'll prob drop the pre-release label.

[Ciekce]

why is this what we must now endure

[Joseph]

Hi, Adam!

​Thank you so much for the detailed explanation about the extensive threat-based features and the ARM NEON SIMD optimizations. It’s exciting to hear you want to make ARM a first-class architecture for Coda!

​To answer your question, I tested the engine on two different devices to see how it handles different hardware generations:

1. ​Vivo Y11
◦ ​Specs: Android 11, Snapdragon 439 (Octa-core up to 1.95 GHz)

◦ ​Performance: In DroidFish analysis mode, Coda gets around 20k–25k NPS. For comparison, the absolute lowest I usually see on this device with Stockfish or other engines is 40k–50k NPS (on 1 core).

Despite the lower NPS, Coda plays surprisingly well in blitz and fast time controls (1+1 and 30s+0.5) without blundering.

2. ​Samsung A16 5G
◦ ​Specs: Android 16, MediaTek Dimensity 6100+ (Octa-core, 2.2–2.4 GHz)

◦ ​Performance: In DroidFish analysis, Coda reaches 100k–110k NPS. Other engines usually floor at a minimum of 150k NPS on this device.

​The Good News (Basic Stability Test):
The most common issue I face in my tournaments with unoptimized or buggy ARM ports is that they play erratically, make irregular/illegal moves, or perform significantly worse than older versions.

​Coda completely passed my baseline stability test here. Even with 100k NPS, it successfully defeated a stable 200k+ NPS engine in a test match. This tells me that its core logic and tactical strength are solid and functioning perfectly on Android, even if the memory bandwidth/cache limits on phones are currently bottlenecking the raw speed.

​Thank you again for looking into the NEON profiling over the weekend. I’m happy to run more tests on these devices whenever you have a new build to try!

So I have one ARM linux micro-server that is a mobile class Rockchip Cortex-A76. This I can get 165-170k NPS on a 'coda bench' on 0.9.0. I'd expect most modern phone class hardware to match this.

My ARM NEON support was a bit bit behind, and catching up with some amd64 optimisatiosn I've done on this have already delivered a 30% NPS gain on, and there's a bit more I can do. On my Macbook M5 I can do 1M+ NPS single core and a lot more multi-core. For the next point release I'll have much better ARM support ready, along with some other nice elo gains. I hope to push a 0.9.1 release some point next week.

Thanks gain. I really appreciate the testing feedback.

Hi Adam,

​Thanks for the update! It’s really exciting that you’ll be dropping the 0.9.1 version of Coda next week.

​As it happens, Arzam’s Android tournament is also highly likely to begin next week, so your release timing is perfect. Arzam has already tested Coda 0.9.0 and found absolutely nothing wrong with it, so Coda is officially ready to enter the Entrance League of the tournament.

​I also ran a small test of my own using the Coda engine against Icarus 1.1, and Coda 0.9.0 managed to defeat it! Seeing that Coda is sitting at rank 4 in your own round-robin tests makes it even more interesting. I'm really excited to see how it performs with the upcoming 0.9.1 optimizations.

​Best,
Joseph

[AndrewGrant]

It is a shame to see the attention given to Coda here by long-time chess engine fans. In a sensible world, these long-time fans who have enjoyed decades of entertainment thanks to the work of (often) open-source developers, would not so willingly promote a work like Coda, which flagrantly infringes on the work of other programs. Coda, and a wave of forthcoming slop-engines like it, are going to dissuade chess engine developers, the real ones, from sharing their efforts with the world.

Coda fails to honour license obligations of potentially every single engine that it has pilfered. It does not convey notices sufficient for the end user to understand that the download contains GPLv3, and MIT protected code, from various projects. It also illegally attempts to re-license Reckless, an AGPLv3 program, by packaging a derived work under an incompatible license.

If or when such things are rectified, then Coda simply becomes a clone. How exciting.

But I have to say, I am not surprised. People on this forum still, to this day, continue to make posts about Fire and Houdini, two engines whose entire history from start to finish are filled with theft, fraud, and deception. You would think, or at least I would think, that out of respect for the works stolen by these engines, one would not promote them. Not to even start to mention the dozens of Stockfish "clones" ( identical with the author name changed ) that get "tested" by users here.

Perhaps Coda is what Talkchess deserves.

[Frank Quisinsky]

Every generation of chess programmers, starting with early programs such as GnuChess, Crafty, Pedone, Fruit, Glaurung, and many others (free-sources), has drawn on open ideas for its own development. No generation of chess programmers is an exception to this rule. If it were any different, we would have 2.000 people like Einstein.

Trying to figure out which program is more or less similar to another is pure know-it-all behavior.

So if we didn’t have open-source code, everything would take place behind closed doors among fellow programmers via email or other communication channels.

The key point is that it has repeatedly been evident that programmers have discovered something new in the course of their work. Over the years, these discoveries have also been taken up and incorporated into new developments. This causal chain of knowledge does not allow us to pass judgment on others.

In my opinion, anyone who acts like a judge and offers their own programs is just making a fool of themselves.

The fact is that everything is currently much more noticeable than usual. There are too many programs, many of which haven’t even been available for very long, that suddenly boast extremely high playing strengths.

The reason many well-known computer chess people are stepping back is more that they’ve lost track of the big picture. It makes you wonder what the point is!

If programmers choose to teach themselves as much as possible, often over a very long period of time, they’ll watch the current situation with disbelief. In fact, there’s no reason for this. Hard but right!

Exactly this one is the reason I am thinking for what all the different licenses. The sheer number of licenses makes the whole thing seem even more ridiculous than it already is. Of course, licenses are important, but that doesn't change the fact that written laws do indeed become outdated over time, and no one can make heads or tails of them anymore. The more people tinker with something, the more differing opinions there are and the more confusion there is.

[AndrewGrant]

Every generation of chess programmers, starting with early programs such as GnuChess, Crafty, Pedone, Fruit, Glaurung, and many others (free-sources), has drawn on open ideas for its own development. No generation of chess programmers is an exception to this rule. If it were any different, we would have 2.000 people like Einstein.

These people are operating a fully-automated theft of all open-source IP. Your sentiments here are out of touch in this modern AI era, where tools like ChatGPT are able to recall, from memory, verbatim portions of Ethereal's source code, and illegally offers it to users upon request, without conveying any notice of the work from which the answer originates, nor the license attached to it.

If you want to continue to promote open-source, then you'll want to get on my side of the issue. These LLMs and the slop they produce are the end-stage of the great experiment where everyone shares.

[Werner]

Hi Andrew,
I am happy to read you share our assessment of these engines. We have discussed it and decided, we do not test it.
On the other side: did. you see your Name on the coda Site as contributor ?

[AndrewGrant]

Hi Andrew,
I am happy to read you share our assessment of these engines. We have discussed it and decided, we do not test it.
On the other side: did. you see your Name on the coda Site as contrbutor?

Yes. My name is there because I authored a single commit, which removes references to Ethereal, and instructs Claude to never reference or derive information from Ethereal going forward. If I could scrub my name from the commits, I would. I want no association with this, and find great shame that it is aided by my tools like OpenBench.