Random number generation classes

[soheilshahrouz]

This PR replaces random number generation function in vtr namespace with clasess.

[soheilshahrouz]

titan_quick_qor	pack-time	place time	place WL	place cpd	place_mem	n_swaps
master	648.6044623	1228.921211	2497566.214	16.78232328	5506.560339	18118945.13
pr	651.6227905	1232.363505	2497566.214	16.78232328	5506.772081	18118945.13
ratio	1.004653573	1.002801069	1	1	1.000038453	1

[vaughnbetz]

Looks good.
We're passing references to the random class all over the place, but I don't have a great alternative. Are there any optimization etc. classes that are already passed around that we could add a rng reference to instead? There may not be a good alternative though, in which case passing this around is fine.

As noted in another comment I made above, maybe we can use the SPEC random utility all the time and delete the body of the vtr one?

Should do a final QoR comparison for safety on Titan anyway before trying to merge this.

[vaughnbetz]

Could/should we just use the SPEC random number generator all the time? I put in the original random number generator, but if the SPEC one has better randomness and isn't noticeably slower we could just make these routines call it.

I don't have a really strong opinion about this, but maybe we can simplify a code path.

[soheilshahrouz]

I am concerned that if we use SPEC random generator, we need to update golden results for a large number of tests. We can explore the performance/quality trade-off of these two random generators later.

[vaughnbetz]

Looks good. As time permits we should try moving to one (spec) random number generator.

[vaughnbetz]

@amin1377 @heshpdx

I think spec is using spec_genrand_int31 () to generate random numbers. This PR ( https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/2793/files ) is refactoring things a bit.

From my reading of the code, it looks like it is around an O(1000) computation to generate a random number with spec_genrand_int1, vs. a roughly O(1) computation with the simpler random number generator VPR usually uses. The implementation by VPR is embedded in the code so it will be the same across platforms, and VPR doesn't need a very good random number generator (fast but not great is OK).

So I'm not sure it is a good idea to switch to the spec one ... it could throw the program execution statistics off some by making random number generation too slow.

This has been merged as we need a class around the random number generators anyway, but I'd like to see if we really should have the SPEC version in the code base.

[heshpdx]

If there is a simpler RNG that spec can use, I am all for it. I don't think the spec RNG shows up as taking time in our function profiles of the benchmark, but I will recheck and share what I find.

[vaughnbetz]

Thanks @heshpdx . I think the default vpr random number generator would be fine ... it is fast, and has enough randomness for our needs, and the code is all in vpr (no dependency on a library that could change results on different platforms etc.).

Also, the latest master branch has parallel routing (and parallel timing analysis has been in for a while). I think you don't like TBB though (which both use); just mentioning in case this is potentially useful for any multi-thread spec benchmarks. Both algorithms are deterministic, so they should produce results that are as reproducible on different platforms as the serial versions.