similar to: New LLD performance builder

Hello Rafael, > It seems the produced lld binary is not being statically linked. Hm. It should. But it seems couple config params are missing. Fixed. Thanks for catching this! > Is lld-speed-test in a tmpfs? Correct. All the benchmarking tips from https://www.llvm.org/docs/Benchmarking.html have been applied to that bot. > Is lld-benchmark.py a copy of lld/utils/benchmark.py?

Thanks a lot for setting this up! By using the "mean as aggregation" option one can see the noise in the results better: http://lnt.llvm.org/db_default/v4/link/graph?switch_min_mean=yes&moving_window_size=10&plot.9=1.9.7&submit=Update There are a few benchmarknig tips in https://www.llvm.org/docs/Benchmarking.html. For example, from looking at

Hello George, Sorry, somehow hit a send button too soon. Please ignore the previous e-mail. The bot does 10 runs for each of the benchmarks (those dots in the logs are meaningful). We can increase the number of runs if proven that this would significantly increase the accuracy. I didn't see the increase in accuracy when have been staging the bot, which would justify the extra time and larger

>Hello everyone, > >I have added a new public LLD performance builder at >http://lab.llvm.org:8011/builders/lld-perf-testsuite. >It builds LLVM and LLD by the latest releaed Clang and runs a set of >perfromance tests. > >The builder is reliable. Please pay attention on the failures. > >The performance statistics are here:

Disabling swap and having a single CPU in the shield group didn't change much, besides cpu-migrations and context-switches, which now are 0 obviously. That clustering remains the same. It is also stable to the number of runs (I have changed the test to run 20 times in the middle of that range on the right). http://lnt.llvm.org/db_default/v4/link/graph?highlight_run=426&plot.9=1.9.6

Hi Rafael, Thanks for mentioning this. It should be running as root, but I'll double check anyway. Thanks Galina On Mon, Mar 26, 2018 at 10:47 AM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Galina Kistanova <gkistanova at gmail.com> writes: > > > Disabling swap and having a single CPU in the shield group didn't change > > much,

Galina Kistanova <gkistanova at gmail.com> writes: > Disabling swap and having a single CPU in the shield group didn't change > much, besides cpu-migrations and context-switches, which now are 0 > obviously. > That clustering remains the same. It is also stable to the number of runs > (I have changed the test to run 20 times in the middle of that range on the > right).

Yep. They are still clustered. > Is there anything else running on the machine while the tests are run? Not much. The usual buildslave stuff - buildbot, ssh server, some light network services, snmp client, but that's pretty much it. 20 hardware threads are designated for this. The test runs on designated for tests only 10 CPUs shielded. There only perf and lld runs. All the obj files

Galina Kistanova <gkistanova at gmail.com> writes: > Hello Rafael, > >> It seems the produced lld binary is not being statically linked. > > Hm. It should. But it seems couple config params are missing. Fixed. Thanks > for catching this! > >> Is lld-speed-test in a tmpfs? > > Correct. > All the benchmarking tips from

On Mon, Jan 28, 2013 at 8:57 AM, Redmond, Paul <paul.redmond at intel.com> wrote: > Is there a reason why existing buildbots are not generating LNT results? Those running LNT should be/are: http://llvm.org/perf/db_default/v4/nts/recent_activity Shows all 3 of the lab.llvm.org machines that run LNT ( http://lab.llvm.org:8011/buildslaves - you can see these 3 macminis run "-nt"

Is O3-vectorize redundant now that the loop vectorizer is enabled by default? On 2013-01-28, at 12:25 PM, David Blaikie wrote: > On Mon, Jan 28, 2013 at 8:57 AM, Redmond, Paul <paul.redmond at intel.com> wrote: >> Is there a reason why existing buildbots are not generating LNT results? > > Those running LNT should be/are: > >

The -vectorize build bots test the BB-vectorizer. Thanks, Nadav On Jan 28, 2013, at 9:39 AM, "Redmond, Paul" <paul.redmond at intel.com> wrote: > Is O3-vectorize redundant now that the loop vectorizer is enabled by default? > > > On 2013-01-28, at 12:25 PM, David Blaikie wrote: > >> On Mon, Jan 28, 2013 at 8:57 AM, Redmond, Paul <paul.redmond at

>> (3) About detecting scop regions in bottom-up order. >> Detecting scop regions in bottom-up order can significantly speed up the scop detection pass. However, as I have discussed with Sebastian, detecting scops in bottom-up order and up-bottom order will lead to different results. As a result, we should not change the detection order. > >Sebastian had a patch for this. Does

> The HT siblings are disabled, right? Correct. > It is probably a good idea to experiment with disabling swap and having > a single cpu in the shield group. Yep. This is what I'm in the middle of. So far I see that it seems the scheduler is keep running on shielded cores no matter what. Even if there is only 1 core in the shield. Thanks Galina On Wed, Feb 28, 2018 at 11:36

Galina Kistanova <gkistanova at gmail.com> writes: > Yep. They are still clustered. > >> Is there anything else running on the machine while the tests are run? > > Not much. The usual buildslave stuff - buildbot, ssh server, some light > network services, snmp client, but that's pretty much it. 20 hardware > threads are designated for this. > > The test

Now, we come to more evaluations on http://188.40.87.11:8000/db_default/v4/nts/recent_activity I mainly care about the compile-time and execution time impact for the following cases: pBasic (run 45): clang -O3 -load LLVMPolly.so pNoGenSCEV (run 44): clang -O3 -load LLVMPolly.so -polly-codegen-scev -polly -polly-optimizer=none -polly-code-generator=none pNoGenSCEV_nocan (run 47): same option

Reid said that he has disabled non-x86-64 backends for the clang/win64 buildbot, so maybe this is the first time for us to see these warnings. But all of them seem to be easily fixable, so why don't we do that. On Tue, Feb 9, 2016 at 10:49 AM, Rafael Espíndola < llvm-commits at lists.llvm.org> wrote: > Most of the warnings are actually in LLVM code. Any reason we don't > see

Hello everyone, The builder http://lab.llvm.org:8011/builders/lld-x86_64-win7​ is up and running. It builds lld and runs lld tests for each commit. The build shows 11 warnings, everything else is green. Do you think it is feasible to treat warnings as errors, or better keep it this way for now? Thanks Galina -------------- next part -------------- An HTML attachment was scrubbed... URL:

Tobias Grosser wrote: > On 09/17/2013 04:12 AM, Star Tan wrote: > >Now, we come to more evaluations on http://188.40.87.11:8000/db_default/v4/nts/recent_activity > > Hi Star Tan, > > thanks for this very extensive analysis. The results look very > interesting. As you found out, just removing some canonicalization > passes will reduce compile time, but this reduction

Hi Galina, It seems that our libcxx bots are now triggering builds for any changes to llvm: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 Should I file a bug report for this? Thanks, Diana On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits <cfe-commits at lists.llvm.org> wrote: > > Hello everyone, > > The staging master is