>> Maybe somebody has statistical survey of how much of the existing deployed CPU core count is typically used? My guess is very few cores are used on average.

>> Maybe somebody has statistical survey of how much of the existing deployed CPU core count is typically used? My guess is very few cores are used on average. I did some testing with Solvespace to see which build options contributed most to performance: https://github.com/solvespace/solvespace/issues/972 https://github.com/solvespace/solvespace/issues/972 Obviously using OpenMP for multi-core was the big win. But what's not shown is that in typical usage (not the test I ran) if you're dragging some geometry around it will use all cores (in my case 4 cores / 8 threads) at about 50 percent utilization. That percentage probably drops as more cores are thrown at it due to Amdahl's Law. In other words, throwing double the cores at it will give a good boost to a lot of code that is already taking less than half the time (wall clock time, not CPU time). We added OpenMP to a number of functions for significant performance gains. And in fact, any remining single-thread operation that gets the parallel treatment is likely to have a significant impact on overall performance since that is where most of the time is spent now. At this point we're more focused on features and bugs. Algorithmic improvements are possible and I'd like to do those in the future, but they are much harder to do than sprinkling some #pragmas around critical loops. That will improve the scalability though, where multithreading really did not.