Open albertnetymk opened 5 years ago
Hi @albertnetymk ,
thanks for sharing your results. It is interesting to see that on your machine you encounter bi-modal performance for this benchmark.
I did not witness this behavior when adding the benchmark originally ( https://github.com/renaissance-benchmarks/renaissance/pull/173) , on my machine. As you suggested this may be related to a sub-optimal decision made by the JIT compiler. If it is a JIT decision causing this behavior, I would not consider this a bug but rather a nice side-effect of the benchmark exhibiting the need to adapt/tune the heuristic in the compiler causing these extreme performance cliffs.
Have you tried running more executions of the entire benchmark, like 10-20? Would be interesting to see what the probability of the 2 performance levels is. Additionally, have you tried minimizing external influences of your machine/setup in order to stabilize results? This may include heap sizes, the usage of ram discs, reducing influences from other processes running on your machine, frequency scaling, turbo boost, etc?
Thank you! david
Listing the final iteration exec time for 14 consecutive invocations of java -jar renaissance-mit-0.10.0.jar scala-doku
:
====== scala-doku (scala-sat), final iteration completed (5891.406 ms) ======
====== scala-doku (scala-sat), final iteration completed (5971.683 ms) ======
====== scala-doku (scala-sat), final iteration completed (8892.878 ms) ======
====== scala-doku (scala-sat), final iteration completed (5899.568 ms) ======
====== scala-doku (scala-sat), final iteration completed (5934.718 ms) ======
====== scala-doku (scala-sat), final iteration completed (4971.463 ms) ======
====== scala-doku (scala-sat), final iteration completed (9045.501 ms) ======
====== scala-doku (scala-sat), final iteration completed (5865.651 ms) ======
====== scala-doku (scala-sat), final iteration completed (9253.71 ms) ======
====== scala-doku (scala-sat), final iteration completed (8939.641 ms) ======
====== scala-doku (scala-sat), final iteration completed (5860.301 ms) ======
====== scala-doku (scala-sat), final iteration completed (8831.876 ms) ======
====== scala-doku (scala-sat), final iteration completed (5891.929 ms) ======
====== scala-doku (scala-sat), final iteration completed (8726.487 ms) ======
The JVM flags used (by default) are made explicit via -XX:+PrintCommandLineFlags
, and they are: -XX:G1ConcRefinementThreads=4 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=194809728 -XX:MaxHeapSize=3116955648 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC
Benchmarking is done on my laptop, so not very rigorous testing env... I have left it idle while running the benchmark at least, and turbo boost is on.
Running the benchmarks with anything but a fixed cpu speed isn't great, running it on a laptop that throttles aggressively which probably uses and Intel CPU which has it's max turbo boost timebound (instead of temperature) is worse - please redo it on a properly cooled desktop pc and if possible with a fixed frequency that doesn't cause throttling. A variance from 10-40% is to be expected (given the benchmark conditions)
I do see this kind of bimodal behavior for 'scala-doku' on dedicated bare-metal performance machines (with all kinds of possible preparation done). On a variety of JITs it shows "stably bi-modal" behavior, dropping into bad score on 1-2 iteration. Have not yet investigated the exact compilation that causes that though ...
The following are two separate runs of
java -jar renaissance-mit-0.10.0.jar scala-doku
. It seems that forrun B
, JIT made a wrong turn in the second iteration, and never managed to get back on track.run A
run B
ENV:
openjdk 12.0.1 2019-04-16 Debian GNU/Linux 10 (buster) 2 core (2 hyperthreading/core) Mem: 11G