[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36597: 27.0.50; rehash hash tables eagerly in pdumper
From: |
Pip Cet |
Subject: |
bug#36597: 27.0.50; rehash hash tables eagerly in pdumper |
Date: |
Sun, 14 Jul 2019 16:54:52 +0000 |
On Sun, Jul 14, 2019 at 3:49 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> Pip Cet wrote:
> > Indeed, that's plenty of small Emacs processes not doing very much.
> > It's not the case we ought to be optimizing for, I think, but the
> > performance concerns should be taken seriously.
>
> What's a good benchmark for what we should be optimizing for? Ideally
> something
> somewhat-realistic as opposed to a microbenchmark.
I'd suggest something along the lines of:
perf stat -r 10 --table -e
cycles:u,instructions:u,branches:u,branch-misses:u make -B
../lisp/leim/ja-dic/ja-dic.el
With my patch:
61,136,837,192 cycles:u
( +- 0.42% )
42,313,912,525 instructions:u # 0.69 insn per
cycle ( +- 0.00% )
12,131,893,779 branches:u
( +- 0.00% )
47,602,747 branch-misses:u # 0.39% of all
branches ( +- 1.11% )
without my patch:
61,460,927,899 cycles:u
( +- 0.44% )
42,358,289,131 instructions:u # 0.69 insn per
cycle ( +- 0.00% )
12,134,582,441 branches:u
( +- 0.00% )
48,540,232 branch-misses:u # 0.40% of all
branches ( +- 1.09% )
A 0.5% improvement.
By comparison,
perf stat -r 100 --table -e
cycles:u,instructions:u,branches:u,branch-misses:u
~/git/emacs/src/emacs -Q --batch
With my patch:
80,749,425 cycles:u
( +- 0.81% )
146,770,045 instructions:u # 1.82 insn per
cycle ( +- 0.00% )
29,218,226 branches:u
( +- 0.00% )
450,275 branch-misses:u # 1.54% of all
branches ( +- 0.11% )
without my patch:
78,896,395 cycles:u
( +- 0.12% )
147,059,777 instructions:u # 1.86 insn per
cycle ( +- 0.00% )
29,287,917 branches:u
( +- 0.00% )
450,194 branch-misses:u # 1.54% of all
branches ( +- 0.09% )
About a 2% slowdown.
perf stat -r cycles:u,instructions:u,branches:u,missed-branches:u
> is dominated by a single CPU-intensive Emacs process and takes about 19 CPU
> seconds on my home desktop. The proposed patch slows this benchmark down by
> about 0.6%. (I ran the benchmark ten times after a warmup run, and took the
> average of the ten user+system times.)
Hmm. I'd like to know the reason for that, but I suspect it may simply
be thermal throttling. That's the reason I'm running tests in
parallel, though it might be better to compare instruction counts or
scheduled ยต-ops rather than cycles...
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Pip Cet, 2019/07/11
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Paul Eggert, 2019/07/14
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Pip Cet, 2019/07/14
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Paul Eggert, 2019/07/14
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper,
Pip Cet <=
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Pip Cet, 2019/07/15
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Pip Cet, 2019/07/19
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Eli Zaretskii, 2019/07/19
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Pip Cet, 2019/07/20
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Paul Eggert, 2019/07/20
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Pip Cet, 2019/07/21
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Paul Eggert, 2019/07/21
- bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Pip Cet, 2019/07/21
bug#36597: 27.0.50; rehash hash tables eagerly in pdumper, Eli Zaretskii, 2019/07/18