Remove -j argument to llvm-clang-x86_64-sie-win builder for lit testing

[dyung]

Summary

I ran some tests, and increasing the parallelism during lit testing doesn't seem to really lead to an increase in test throughput on Windows (it seemed to increase the time required slightly), so get rid of it. I'm also hoping that it might also help the random test failures that I cannot seem to reproduce on this bot.

[rengolin]

Running with ninja without -j means it will take more than the number of cores by default. If you want a single core, you need to specify -j1.

[dyung]

In D143365#4105944, @rengolin wrote:

Running with ninja without -j means it will take more than the number of cores by default. If you want a single core, you need to specify -j1.

In my experience, running with out -j will use the number of cores/threads on the machine which is what I want, not a single-threaded run. My experience has been that over-subscribing the cores does give some benefit on linux, but on Windows that doesn't seem to be the case.

[gkistanova]

If LIT default threads usage is what you are after, the patch looks good.

On some of my builders I have seen a benefit of restricting LIT with the number of jobs, because each "job" could use multiple threads on its own. If memory serves me well, reducing the number of LIT jobs to 32 off of available 64 threads reduced the overall test time. I assume you experimented on your worker and set what gives you the most benefit.

[dyung]

In D143365#4114556, @gkistanova wrote:

If LIT default threads usage is what you are after, the patch looks good.

On some of my builders I have seen a benefit of restricting LIT with the number of jobs, because each "job" could use multiple threads on its own. If memory serves me well, reducing the number of LIT jobs to 32 off of available 64 threads reduced the overall test time. I assume you experimented on your worker and set what gives you the most benefit.

That's interesting. I've never really considered using fewer threads than the number of available cores. I did run timing tests on the machine for 32/48/61 threads and somewhat surprisingly the numbers were all similar with the 32 numbers on average slightly lower. I suspect the random failures that this bot seems to hit were due to over-subscription of resources, so I wanted to lessen the overhead to try and see if it helps. If it doesn't, I'll explore using fewer threads, although I do want to keep it cycling as quickly as possible.

buildbot/osuosl/master/config/builders.py

'factory' : UnifiedTreeBuilder.getCmakeWithNinjaWithMSVCBuildFactory(
                         "-DCLANG_ENABLE_CLANGD=OFF",
                         "-DLLVM_CCACHE_BUILD=ON",
                         "-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-sie-ps5",
                         "-DLLVM_INCLUDE_EXAMPLES=OFF",
                         "-DLLVM_TARGETS_TO_BUILD=X86",
                         "-DLLVM_VERSION_SUFFIX=",
                         "-DLLVM_BUILD_RUNTIME=OFF",
                         "-DLLVM_ENABLE_ASSERTIONS=ON",
-                        "-DLLVM_LIT_ARGS=--verbose -j61",
+                        "-DLLVM_LIT_ARGS=--verbose",
                         "-DPYTHON_EXECUTABLE=C:\Python310\python.exe"])},
 
     {'name': "cross-project-tests-sie-ubuntu",
     'tags'  : ["clang", "llvm", "lldb", "cross-project-tests"],
     'workernames': ["doug-worker-1a"],
     'builddir': "cross-project-tests-sie-ubuntu",
     'factory': UnifiedTreeBuilder.getCmakeWithNinjaBuildFactory(
                     depends_on_projects=['llvm','clang','lldb','cross-project-tests'],