search for: heavyweight_hardware_concurrency

> Sounds like threading isn't beneficial much beyond the second CPU... > Maybe blindly creating one thread per core isn't the best plan... parallel.h is pretty simplistic at the moment. Currently it creates one per SMT. One per core and being lazy about it would probably be a good thing, but threading is already beneficial and improving parallel.h an welcome improvement. Cheers,

...gt;> parallel.h an welcome improvement. >> > > Instead of using std::thread::hardware_concurrency (which is one per > SMT), you may be interested in using the facility I added for setting > default ThinLTO backend parallelism so that one per physical core is > created, llvm::heavyweight_hardware_concurrency() (see D25585 and > r284390). The name is meant to indicate that this is the concurrency that > should be used for heavier weight tasks (that may use a lot of memory e.g.). > Sorry for my ignorance, but what's the point of running the same number of threads as the number of physical...

...lcome improvement. >>> >> >> Instead of using std::thread::hardware_concurrency (which is one per >> SMT), you may be interested in using the facility I added for setting >> default ThinLTO backend parallelism so that one per physical core is >> created, llvm::heavyweight_hardware_concurrency() (see D25585 and >> r284390). The name is meant to indicate that this is the concurrency that >> should be used for heavier weight tasks (that may use a lot of memory e.g.). >> > > Sorry for my ignorance, but what's the point of running the same number of > threads...