Triton VM uses externally-provided randomness for some of its randomizers (that are added to provide zero-knowledge). In other words, these randomizers are sampled from the operating system, through e.g. thread_rng, and not from the Fiat-shamir sponge-state of the program. This means that when you run the same benchmark twice for some of the more involved programs, the u32-table row count will differ between each run.
Triton VM uses externally-provided randomness for some of its randomizers (that are added to provide zero-knowledge). In other words, these randomizers are sampled from the operating system, through e.g.
thread_rng, and not from the Fiat-shamir sponge-state of the program. This means that when you run the same benchmark twice for some of the more involved programs, the u32-table row count will differ between each run.This is the reason that the benchmark result of the STARK verifier keeps showing a diff in the workspace.
To get consistent VM benchmarks, some upstream changes are needed. How Triton VM chooses to deal with this is outside the scope of this issue.