1. I can't comment on the original article. Are comments closed, or am I dumb?
2. The author seems to have assumed a web server responding to bursty traffic. Several people have pointed out workloads to which the 0.7 heuristic doesn't apply - compute servers, I/O bound servers, compile jobs, desktops. He should have stated that assumption up front.
3. Hyperthreads. For purposes of load monitoring, you should be counting the number of threads, not the number of cores. Yes, hyperthreads are slower than cores, but that doesn't matter. The load average is the ratio of work available to work being done (oversimplified, I know), and, as such, it's scaled to the actual throughput of the threads available.
Fortunately, the author suggested counting CPUs by reading /proc/cpuinfo, and /proc/cpuinfo lists threads, not cores. So those two errors cancel out. (-:
Point 3 depends on the workloads. Most SMT [1] implementations replicate integer functional units - otherwise the threads would stall on basic things like computing addresses - but they don't replicate floating point units. So if you have lots of floating point heavy work, then you're limited by the number of cores, not the total number of SMT contexts provided by all of those cores.
So it's not that SMT pipelines are slower, it's just that they share resources with the other SMT pipelines.
1.) No you are not dumb, this is an advertisement for their product. (also note the blog posting is either dated in the future or over a year old, not sure which)
2) They make that assumption because they are selling web server monitoring tools, if you don't have a web server you aren't their target user :-)
3) Now you actually want to talk about real details about monitoring performance and the goal of this particular article is to sell their product to people who run web servers and probably don't want to delve too deeply into actual performance analysis.
1. I can't comment on the original article. Are comments closed, or am I dumb?
2. The author seems to have assumed a web server responding to bursty traffic. Several people have pointed out workloads to which the 0.7 heuristic doesn't apply - compute servers, I/O bound servers, compile jobs, desktops. He should have stated that assumption up front.
3. Hyperthreads. For purposes of load monitoring, you should be counting the number of threads, not the number of cores. Yes, hyperthreads are slower than cores, but that doesn't matter. The load average is the ratio of work available to work being done (oversimplified, I know), and, as such, it's scaled to the actual throughput of the threads available.
Fortunately, the author suggested counting CPUs by reading /proc/cpuinfo, and /proc/cpuinfo lists threads, not cores. So those two errors cancel out. (-: