11–20 of 56 posts
Regarding cpusets, I wonder how much contention is being created just by software assuming the number of cpus match the number of cpus in the affinity set. For example, C++ has hardware_concurrency now, Python has cpu_count , Java has fork-join, etc...
Golang also has a totally inaccurate routine for counting the CPUs in the machine.
Regarding cpusets, I wonder how much contention is being created just by software assuming the number of cpus match the number of cpus in the affinity set. For example, C++ has hardware_concurrency now, Python has cpu_count , Java has fork-join, etc...
Golang also has a totally inaccurate routine for counting the CPUs in 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.
> 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.
Of all the sources outside of Google, I'd say XKCD is likely to be closer than most. Even if you ignore the fact that Randall (XKCD) spends a good amount of his time estimating things in a rigorous and scientific way that would mean his estimates are actually pretty good, he has the exact background that means people at Google would take his call if he picked up the phone to muse upon the question of how many machine…
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 rid of the stall cycles.
1) Use branch_likely to force gcc to make sure there is no branch at all in the critical path of executions. (save 30+ cpu cycle per branch, there are a lot of branch stall cycles if one just simplely follow the gcc generated "optimized" code. MIPS CPU 200Mhz)
2) Use prefetch ahead of data structure access to get rid of un-cache data delay. (save ~50+cpu cycle per data stall, also, there are lot of them in the critical path.)
3) Use inline functions, etc to get rid of call stalls in critical path.
The system got ~100x increase on the overall system thru-put with those techniques with just pure C optimization from standard -O2 build.
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.
Specifying which code path / function call sequences are the real critical path probably still require programmer's touch.
As result of using data prefetch code in proper place, I don't used cache locking nor doing any kind of CPU affinity trick to generated the optimized obj code without any stall cycles for critical code path.
Earlier quoted context omitted.
Golang also has a totally inaccurate routine for counting the CPUs in the machine.
What's the accurate way?
Earlier quoted context omitted.
Golang also has a totally inaccurate routine for counting the CPUs in the machine.
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).