On conventional out of order processors, instructions are not necessarily executed in “program order”, although the processor must give the same results as though execution occurred in program order. The instruction window contains a small window of instructions that are allowed to execute out of order, before the instructions are committed in program order as they leave the instruction window. This article describes a microbenchmark that can measure the size of the instruction window, demonstrated on several x86 microarchitectures, then extends the microbenchmark to measure the speculative register file size . . . → Read More: Measuring Reorder Buffer Capacity
Caches are used to store a subset of a larger memory space in a smaller, faster memory, with the hope that future memory accesses will find their data in the cache. Traditionally, caches have used (approximations of) the least-recently used (LRU) replacement policy, but LRU performs poorly with cyclic access patterns with working sets larger than the cache. Intel Ivy Bridge’s L3 cache uses an improved adaptive replacement policy, and is no longer purely pseudo-LRU . . . → Read More: Intel Ivy Bridge Cache Replacement Policy
Each new generation of CMOS manufacturing processes brings about a new set of trade-offs. Intel’s recent tradition of manufacturing the same processor microarchitecture across two processes provides an opportunity to measure some of the voltage-delay-power scaling trends. The 22nm Ivy Bridge significantly improves on static (leakage) power over 32nm Sandy Bridge, but only shows small reductions in dynamic power. Ivy Bridge also requires higher voltage increases for the same frequency increase. Also, thermal resistance of Ivy Bridge increased over Sandy Bridge, likely due to the change from solder to polymer thermal interface material. . . . → Read More: A Comparison of Intel’s 32nm and 22nm Core i5 CPUs: Power, Voltage, Temperature, and Frequency
While crafting some C code to stress integer ALU bandwidth, I decided I would compile the code through various compilers to see what would come out. The code is a hand-unrolled loop with 5 independent chains of dependent ALU operations (add, and) designed to provide many independent ALU instructions for the integer core to execute. Even for this simple repetitive code, the best (Intel C Compiler) compiler produces code that runs 26% faster than the worst (llvm-clang). . . . → Read More: Compiling a Contrived Chunk of Code
Earlier, I wrote about the SMT-awareness of the CFQ and BFS schedulers on Linux. Here, I do a similar test on the Mac OS X process scheduler.
System Core i7-3770K 3.5 GHz, 4 cores, 8 threads (2-way SMT) Mageia Linux, kernel 3.4.4, CFQ scheduler Mac OS X 10.7 (Update: Also 10.8) Workload: Independent ALU instructions . . . → Read More: OS X Process Scheduling
This is a preliminary attempt at characterizing the power consumption of Ivy Bridge at various clock frequencies and loads. I present plots of CPU power consumption (at the 12V connector) at varying frequency, voltage, and number of cores utilized, including the power impact of Hyper-Threading. . . . → Read More: Ivy Bridge Power Consumption
So I got myself a new Core i7-3770K, using the stock heatsink/fan, and a motherboard that doesn’t have VCore adjustments. I re-ran a bunch of benchmarks used in my earlier posts to measure Ivy Bridge’s performance, and Hyper-threading scaling, in comparison to earlier processors. The workloads were used in the my earlier tests:
. . . → Read More: Ivy Bridge Benchmarks
There has been much speculation recently about why Intel’s new Ivy Bridge processors seem to run significantly hotter than the previous-generation Sandy Bridge processors, despite the lowered TDP rating. One proposed explanation is that the thermal interface material between the silicon die and heat spreader was changed: Sandy Bridge processors soldered the heat spreader to the silicon, while Ivy Bridge processors use some silicone-like adhesive compound. I pop off the heat spreader and do some measurements. . . . → Read More: Ivy Bridge De-lidding
A parser is used to translate wikitext to HTML for viewing. Since there are a bunch of parser projects for MediaWiki’s markup, I’ll go benchmark some of them to see how fast they run.
. . . → Read More: Mediawiki Parsers
MLPPP on Bell’s DSL GAS network doesn’t work very well because the GAS network appears to reorder PPP frames (which is forbidden by RFC 1661). Ideally, Bell should stop reordering packets. The next best option is for the ISP and user to configure MRU and MRRU settings to reduce packet/frame fragmentation. With multilink PPPoE, the client should use an IP-MTU of 1486 bytes (1484 on Linux 2.6.31+ due to a bug), a MRU of 1492, and an MRRU of 1486. The ISP should use an MRU of 1492, MRRU of 1486 (possibly 1484 to work around the Linux bug, until the bug gets fixed), and apply the IP-MTU correctly (MRU-0 = 1492 for PPP, MRU-6 = 1486 for MLPPP). . . . → Read More: Teksavvy MLPPP Performance