Hi, Am Mittwoch, den 06.08.2014, 23:40 +0300 schrieb Sergei Trofimovich:
I think I know what happens. According to perf the benchmark spends 34%+ of time in garbage collection ('perf record -- $args'/'perf report'):
27,91% test test [.] evacuate 9,29% test test [.] s9Lz_info 7,46% test test [.] scavenge_block
And the whole benchmark runs a tiny bit more than 300ms. It is exactly in line with major GC timer (0.3s).
If we run $ time ./test inverter 345 10n 4u 1>/dev/null multiple times there is heavy instability in there (with my patch reverted): real 0m0.319s real 0m0.305s real 0m0.307s real 0m0.373s real 0m0.381s which is +/- 80ms drift!
Let's try to kick major GC earlier instead of running right at runtime shutdown time: $ time ./test inverter 345 10n 4u +RTS -I0.1 1>/dev/null
real 0m0.304s real 0m0.308s real 0m0.302s real 0m0.304s real 0m0.308s real 0m0.306s real 0m0.305s real 0m0.312s which is way more stable behaviour.
Thus my theory is that my changed stepped from "90% of time 1 GC run per run" to "90% of time 2 GC runs per run"
great analysis, thanks. I think in this case we should not worry about it. From a QA perspective we are already doing well if we consider the apparent regressions. If we can explain them and consider it acceptable, then it’s fine. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org