Argh, for some reason I had in my head that GSR was targeting 64-bit maths (like elements), not bignum maths. (Calling it “val64” wasn’t super helpful there…)
That seems too slow to me, fwiw (in an ideal world, anyway); taking the 13k vs 80k ratio would bring that down to ~300ms which seems more appropriate for ~current generation, high-end, consumer hardware. I think you’d want to get 1s-2s even from a cheap VPS or a refurbished celeron/i3/i5 minipc – ie the sort of thing a random datum/stratumv2 miner might decide to use for block construction.
That presumably also means an single standard tx could take 190ms to verify (assuming the 400k weight standardness vs 4M weight consensus ratio dominates), which also feels high, and potentially usable as DoS vector to delay block propagation (by crafting invalid txs that take roughly as long to (in)validate as the worst case valid, standard tx takes to validate; though validating blocks/txs in parallel, or having a way for blocks to bypass the tx validation queue would mostly mitigate that).
I guess making a regtest chain with a block with max sig checks, and feeding it into the release binary might work without requiring dev environment archeology. I guess a deboostrap’ed chroot for xenial ought to allow building it though?