-
m-relay<dimalinux:monero.social> xmrack: I first heard about it on Reddit, and then again on the Monerotopia news segment. (I don't listen to the full 4 hours of the Monerotopia episodes, but I usually tune in thru the news.) It seemed similar in nature to a lot of the stuff I had to do when implementing the legacy cryptonight hash for cuprate, so I thought I might have a chance of winning. 🙂
-
m-relay<dimalinux:monero.social> I'm still trying to figure out how I can automate regression testing of constant time (or at least cycle counts as a proxy). There is not current code that is checking for this, correct?
-
m-relay<jberman:monero.social> There is, see "To run the wasm cycle counter" : github.com/j-berman/fcmp-plus-plus-…bda1eb8fefb66e0/helioselene-contest
-
m-relay<dimalinux:monero.social> jberman: That wasm-cycle test code is just counting the cycles, but I don't think that it is comparing the cycles over multiple runs to make sure that they come out the same. For regression testing, should we just run that code `X` times and verify that the output is identical? There may be some extreme cases that are hard to hit with random data.
-
m-relay<jberman:monero.social> It's using a seeded RNG, running it twice (one time with one seed, and a second time with a different seed)
-
m-relay<jberman:monero.social> And then compares the result across both runs
-
m-relay<jberman:monero.social> A little easier to see how it's doing that on the ec divisors side. The helioselene macros make it harder to read
-
m-relay<jberman:monero.social> So even if you yourself were to run it multiple times, it's going to use the same seeds across runs
-
m-relay<jberman:monero.social> To be clear, running `wasm-cycles` once as described will run the wasm tests twice with different seeded RNG's across both runs, and then make sure the wasm cycle counts across both runs is equal
-
m-relay<dimalinux:monero.social> Thanks for the explanation. I see the assert on 115 of the wasm-cycles main.