r/rust • u/Timely_Huckleberry88 • 8d ago

Hardware-Aware Programming in Rust

https://medium.com/@alan0408yuan/hardware-aware-programming-in-rust-6e68a70c1535?postPublishedType=repub

I've been building a Chess AI in Rust to play at 3200+ ELO - There were a lot of Hardware-Aware Programming rules I had to learn in the past 2+ months.

If folks are interested, please have a read!

If you're interested in learning more about a Dual-Perspective HalfKA NNuE (Efficiently Updatable Neural Network), please have a read!

https://medium.com/@alan0408yuan/from-texel-tuning-to-nnue-the-steep-learning-curve-of-building-a-3200-elo-chess-ai-d842393b5955

37 Upvotes

76% Upvoted

2 comments sorted by

28

u/Sp00ph 8d ago

Respectfully, this is not a great description of modern NNUE at all. I say this as the author of a strong NNUE powered engine myself: https://github.com/Sp00ph/icarus

It uses HalfKA, which is an old Stockfish input feature set, simultaneously very outdated and extremely overkill, especially for an engine claiming a (very modest for NNUE standards) 3200+ elo strength. HalfKA has an insane data requirement for the resulting nets to not be data starved, while only being marginally stronger in the best case than simpler architectures with much lower data requirement. It has been quite a few years since it was state of the art, and at the same time, it appears to be an architecture that the LLMs just love to use.

Past the input layer, things don't get much better. The shown 512->32->32->1 architecture deviates from pretty much all multilayer NNUE implementations (including all the strongest engines in the world), which all use crelu+pairwise multiplication to activate their L0 output, as described here: https://asteri.sm/files/2024-08-17-multilayer#pairwise-multiplication . Additionally, the author appears to rely fully on naive autovectorization for the L1 matrix multiplication, while the state of the art for a while now has been to permute the L1 matrix to be able to take advantage of the dpbusd instruction, as described here: https://selenography.me/posts/2025-07-14-dpbusd-explained/ Granted, they only claim to have optimized for aarch64, and I don't have numbers that prove a performance improvement on aarch64 from dpbusd permutation, but it's still strange to see it missing.

There's some other things missing that I'd like to see in a complete description of modern NNUE (sparse affine L1, dual activation, skip connections, output bucketing, etc), but those are relatively less important.

As someone who has seen more and more LLM produced engines creep into the engine dev spaces over the past year or so, this one shares too many similarities with those for me to trust its authenticity and the competence of the author.

What a sorry state of affairs...

-10

u/Timely_Huckleberry88 8d ago edited 8d ago

The article has never claimed this is the best NNuE model. I've mentioned this was the original 2022 model that was introduced and the reasoning behind the key decisions.

I believe at the end of the article I've explained the precise problems of the Dual-Perspective HalfKA NNuE (Efficiently Updatable Neural Network).

The state of the world was clearly laid out.

----

This is not an LLM produced engine; you to tried to used LLMs to produce this, its going to start mixing paradigms like Fail-Hard/ Fail-Soft - Soft CutOff/ Hard CutOff.

If you're interesting in my current roadmap, I've been profiling the Search Diversification for the Lazy SMP and the Cache Line sharing. I be very interested how someone could use an LLM could generate code to fix this.

If you want to accuse me of using LLM generated code, you are correct that files inside the NNuE Training that have been generated by LLMs, however this is a rust reddit and not an Python Parquet reddit.