Hi,
I was just browsing my LNT performance builder and it seems within the last month we managed to increase compile time from 37 to 47 seconds for the bullet benchmark:
http://llvm.org/perf/db_default/v4/nts/graph?plot.0=34.274.3&highlight_run=29054
A similar pattern can be seen for MallocBench/gs/gs where we go from 5.3
to 7.4 seconds.
http://llvm.org/perf/db_default/v4/nts/graph?plot.0=34.301.3&highlight_run=29054
One contributing patch seems to be the following one (surprisingly):
Author: Chandler Carruth <chandlerc@gmail.com>
Re-apply r211287: Remove support for LLVM runtime multi-threading.
I'll fix the problems in libclang and other projects in ways that
don't require <mutex> until we sort out the cygwin situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211900
I also looked at the earlier performance regressions, but could not find any obvious commits that could have caused these regressions.
This is mostly a drive by observation, but maybe someone is motivated to investigate this further.
Cheers,
Tobias
Note that I’ve fixed one bad compile time regression quite recently, and we’re bisecting to another one. We benchmarked the multithreading stuff pretty carefully, so I doubt its that. Have you tried reverting locally and reproducing?
Not really. It just saw this passing by and was wondering if it raised some bells.
The reason I pointed this patch out is that the pattern in which performance changes matches precisely the pattern this patch was applied and reverted, with the set of patches between subsequent performance runs being rather small.
Note, this patch is actually the smaller culprit, around 209801 there is another performance regression, but I have no idea if/where this is coming from or if this for some reason is a false positive.
I unfortunately currently don't have the time to investigate this, but thought I at least mention it on the mailing list.
Cheers,
Tobias
P.S: Until the last performance build at juli 31st the performance regression still existed, so I don't think your fix applied to this one.
Not asking you to do anything specifically Tobias, just adding information
to the list...
209797-209799 regression is false positive, due to reverting perf back
to original timeit tool.(r209797)
However the multithreading stuff is real regression and I'm able to
reproduce same regression on my local build bots.
-Yi
Note, this patch is actually the smaller culprit, around 209801 there is
another performance regression, but I have no idea if/where this is coming
from or if this for some reason is a false positive.
I'm having to question the results on this bot. The range of commits which
cause the larger compile time regression is 209797 - 209799... But those
commits are totally innocuous. The closest to a something that could go
poorly would be r209798, but that commit doesn't seem plausible for a huge
slowdown.
I wonder if there is something weird going on with the bot...
209797-209799 regression is false positive, due to reverting perf back
to original timeit tool.(r209797)
I misread my own commit message.
It's turning perf back on.
Can you share a preprocessed input and commandline which reproduces this
regression?
Hi Chandler,
On an x86 system, for ToT LLVM:
With "Remove support for LLVM runtime multithreading": 23.8788
With patch reverted: 22.5229
That's around 6% regression.
Detailed JSON file is at Debian paste error,
Debian paste error
-Yi
I was also able to reproduce this, I filled a PR with more info:
http://llvm.org/bugs/show_bug.cgi?id=20641
FWIW, I think I understand the primary cause of this and why it doesn’t show up in profiles or on my system. I’m working on a fix and hope to land it this week.