A Comparison of Intel’s 32nm and 22nm Core i5 CPUs: Power, Voltage, Temperature, and Frequency

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

Compiling a Contrived Chunk of Code

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

OS X Process Scheduling

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

Ivy Bridge Power Consumption

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

Ivy Bridge Benchmarks

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

Ivy Bridge De-lidding

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

Mediawiki Parsers

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

Teksavvy MLPPP Performance

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

Hyper-Threading Performance

Intel uses Hyper-Threading (HT) as a feature for market segmentation: The desktop Core i5 processors differ from the Core i7 mainly by whether HT has been disabled, and Intel charges a significant price premium for the Core i7. Does the performance improvement of HT justify its cost? I test the performance of HT using a selection of cluster-type workloads. . . . → Read More: Hyper-Threading Performance

Linux SMT-Aware Process Scheduling

Process scheduling for multicore multithreaded (SMT or HT) systems adds a new challenge to an operating system’s process scheduler. Two threads scheduled on different cores will run faster than two threads scheduled onto different thread contexts of the same core because much of the hardware resources are shared between SMT thread contexts. This can be . . . → Read More: Linux SMT-Aware Process Scheduling