31–40 of 56 posts
Earlier quoted context omitted.
Golang also has a totally inaccurate routine for counting the CPUs in the machine.
What's the accurate way?
BTW the same problem also happens for determining available memory in containers.
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...
What about changing GOMAXPROCS once per minute in a goroutine that calls NumCPU()?
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…
[0]: At least, this is true for x86 CPUs.
Earlier quoted context omitted.
Golang also has a totally inaccurate routine for counting the CPUs in the machine.
What's the accurate way?
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…
A lot of those optimizations would no longer yield any benefits[0]. The CPU archictecture evolved a lot in 16 years, especially in branch/code prediction to the point where a correctly predicted branch (without branch_likely) has almost no cost. [0]: At least, this is true for x86 CPUs.
https://lwn.net/Articles/444336/
A MIPS is probably the exact opposite to modern (which actually means anything P6 and above) x86 CPUs in terms of performance characteristics. If I were to guess what member of the x86 family might actually benefit from such optimisation, it would be NetBurst (which itself has very different performance characteristics from every other x86 family that came before or after 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…
A lot of those optimizations would no longer yield any benefits[0]. The CPU archictecture evolved a lot in 16 years, especially in branch/code prediction to the point where a correctly predicted branch (without branch_likely) has almost no cost. [0]: At least, this is true for x86 CPUs.
That is, what is the shelf life of a very low level CPU optimization for Intel hardware.
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…
A lot of those optimizations would no longer yield any benefits[0]. The CPU archictecture evolved a lot in 16 years, especially in branch/code prediction to the point where a correctly predicted branch (without branch_likely) has almost no cost. [0]: At least, this is true for x86 CPUs.
This also helps prevent cache side-channel attacks like the one that led to stealing RSA private keys by probing the L3 miss times. https://eprint.iacr.org/2015/898.pdf
Another performance enhancement lol. That's good, too, but damnit I was hoping they mentioned timing channels. It will have to be thoroughly scrutinized before relied on for that but it's a start for sure. Hopefully, more than that. :)
To me putting high-priority low-latency process and a low-priority high-throughput process on the same machine is a recipe for disaster - they will find some way to get entangled and hurt each other. Kudos to google for pulling this out but the article shows that you need expertise on all levels of the stack to attempt this. Most of us are better off with simply buying more boxes :)
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.)
What I've heard is that you should mostly pay attention to the gcc compilation part of SPEC if you want a good indication of real world performance.