Performance Improvements

[mattsta]

Hey!

Found your project recently and it looked like fun, so I gave it a try.

When it first ran, I was getting around 64,000 tests per second on my machine, but I thought it could be adjusted to go a bit faster. After 10 hours of working on it, it now runs at 22 million tests per second (laptop cpu 9 cores).

Feel free to steal the ideas out or incorporate things back. A lot of the components are redesigned to be more memory and machine-aware efficient overall and it's going for performance over structure in places. Hopefully it doesn't look too much like slop.

Not doing a full PR because it's basically a complete redesign and there's not much to merge back other than "all the stuff." Also only tested under mac currently but there's some untested x64 helpers in-place too.

My 22 million checks per second version almost 350x faster than the defaults here (not that helps you much, it's still like guessing the worst lottery in the universe): https://github.com/mattsta/Plutus

[a137x]

Hey @mattsta — really enjoyed this writeup. The breakdown of where the time
actually goes (batch inversion, hardware SHA, NEON RIPEMD) was clear enough to
save me a lot of guesswork, so thanks for documenting it.

I maintain a Rust port, plutus-rustus, that started years ago as a straight
port of the Python original. After reading your notes I applied the same
techniques and figured the results might be useful here:

• Sequential EC walk (pub += G) with a Montgomery batch inversion over
  libsecp256k1's field arithmetic (512 points → one inversion). Fun detail: a
  pure-Rust k256 batch actually lost to a plain per-key combine — the win
  only shows up on libsecp256k1-grade multiplies, so it had to be batching over
  libsecp256k1.
• hash160: ARMv8 hardware SHA-256 + 4-wide NEON RIPEMD-160, ~3.4x the
  sha2/ripemd crates. Both paths are verified bit-for-bit against the
  reference implementations in the test suite.

Measured on an Apple M3 Pro (5 performance + 6 efficiency cores) against the
current funded-address set:

• ~2.85M keys/s single-thread
• ~18.2M keys/s across all 11 cores
• ~2.56M keys/s per performance core

So per performance core it lands right around your C accelerator's ~2.44M/core —
basically a dead heat, which was a reassuring sign that the Rust + small-C-shim
approach doesn't leave much on the table. My all-core total is a little under your
22M only because 6 of my 11 cores are the slow efficiency ones; on an all-P-core
machine it'd project to ~23M.

Repo (MIT): https://github.com/a137x/plutus-rustus — happy to hear if anything
looks off in the methodology, and thanks again for the original writeup.

A couple of notes:

• It deliberately says "dead heat per core," not "faster" — if someone benchmarks it, the claim holds. Overclaiming is the fastest way to lose credibility in a perf thread.
• The k256-lost detail is a genuine, non-obvious finding — it reads as "this person actually did the work," which is what promotes the repo more than a raw number.