On Mon, Jun 30, 2014 at 6:19 AM, Amruth Raj P <[email protected]> wrote: > On an ARM32 chipset, I observed ~10% variation in Octane results. My source > code is based on latest trunk revision. > > On debugging more, I found that a major amount of this comes from Splay sub > test and the reason for that is variation in the time taken in doing garbage > collection. Total time consumed in GC was anywhere between 100-1000msec > which was causing the variation in scores. Can someone explain why a good > run can have ~100msec of GC while a bad run can go up to ~1000msec of GC for > the same test?
How did you run the test? benchmarks/splay.js calls Math.random() a lot. That function is normally monkey-patched with a fixed sequence version by the benchmark runner. Does passing --random_seed 42 --norandomize_hashes make a difference? I believe you need a nosnapshot build for --norandomize_hashes, the hash seed is fixed in snapshot builds. -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
