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
[email protected] • http://www.joachim-breitner.de/
Jabber: [email protected] • GPG-Key: 0xF0FBF51F
Debian Developer: [email protected]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
