21–30 of 56 posts
16 years, I created a profiling macro system on for select set critical functions. The profiling system can switch the measuring data from #instruction, #cpu_clk, #branch_stall_cycles, #L1_miss, #L2 miss for all the critical path functions. After analyzed the data, I found branch stall cycles and data access stall cycles were causing huge number of delays in the critical code path. I used the following tricks to get…
Earlier quoted context omitted.
What's the accurate way?
To calculate the number of processors available or the optimal number of threads/processes?
The SPECint and SPECfp benchmark suites were never very tightly connected to real-world performance, but I wonder what these figures look like for SPECjbb, the java benchmark. (If I recall correctly, SPECjbb spins up an app that looks a lot like "java pet store" and runs clients against it.)
16 years, I created a profiling macro system on for select set critical functions. The profiling system can switch the measuring data from #instruction, #cpu_clk, #branch_stall_cycles, #L1_miss, #L2 miss for all the critical path functions. After analyzed the data, I found branch stall cycles and data access stall cycles were causing huge number of delays in the critical code path. I used the following tricks to get…
So...profiler guided optimization lol.
Would still love to have a great open-source tool for this.
Earlier quoted context omitted.
To calculate the number of processors available or the optimal number of threads/processes?
Well specifically it would be cool if it counted the optimal number to set GOMAXPROCS to, since I think that's like the main use of runtime.NumCPU().
1: https://code.google.com/p/go/source/browse/src/pkg/runtime/t...
Earlier quoted context omitted.
I'm not necessarily questioning the accuracy, just that they generally don't consider the affinities and a lot of software assumes that number of cpus matches the concurrency available. If only half the cpus are in the affinity set, the processes/threads could generally contend twice as much as possible. I guess depending on how the number is used it could improve the throughput though (e.g. blocking on i/o).
Depends on the language used in the spec, but "CPUs available for scheduling" seems like the definition most software should use. However, I suspect most software is built using an interface that returns the total CPU count for the machine.
> Xkcd estimated that Google owns 2 million machines Xkcd doesn't sound like a very convincing source. And at least this estimation should have some error-bars.
Earlier quoted context omitted.
Well specifically it would be cool if it counted the optimal number to set GOMAXPROCS to, since I think that's like the main use of runtime.NumCPU().
Right. Currently runtime.NumCPU tries to be fancy by looking at the population count of the cpuset mask[1]. However in a hosted environment using containers there's no reason to believe that the cpuset will remain fixed over the life of the process. This can undercount the available CPUs, leaving you with a GOMAXPROCS that is too low. 1: https://code.google.com/p/go/source/browse/src/pkg/runtime/t...
16 years, I created a profiling macro system on for select set critical functions. The profiling system can switch the measuring data from #instruction, #cpu_clk, #branch_stall_cycles, #L1_miss, #L2 miss for all the critical path functions. After analyzed the data, I found branch stall cycles and data access stall cycles were causing huge number of delays in the critical code path. I used the following tricks to get…
> I think it might be possible to create a build system that can automatically
> collect the profiling data (branch stall cycles and data stall cycles)
> and use the branch likely and prefetch instructions to auto-optimized the
> critical path code.
The ones you mentioned aren't exactly equivalent to cache partitioning (etc...) though. Partitioning allows explicit allocation and prioritization of a contended resource instead of only improving utilization for a single process. So, for example if two threads/processes have an 8MiB working set, and they run on the same cpu, they can easily step on eachother's data in the cache. If you partition it though, less frequently used data doesn't have to step on more frequently used data.