00:40:43 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. 🙂 00:46:31 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? 01:01:30 There is, see "To run the wasm cycle counter" : https://github.com/j-berman/fcmp-plus-plus-optimization-competition/tree/7094402104aeb63b726d8510fbda1eb8fefb66e0/helioselene-contest 01:20:13 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. 01:22:30 It's using a seeded RNG, running it twice (one time with one seed, and a second time with a different seed) 01:23:09 And then compares the result across both runs 01:24:29 A little easier to see how it's doing that on the ec divisors side. The helioselene macros make it harder to read 01:28:03 So even if you yourself were to run it multiple times, it's going to use the same seeds across runs 01:34:16 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 01:56:29 Thanks for the explanation. I see the assert on 115 of the wasm-cycles main.