Showing posts from May, 2009

Hadoop should target C++/LLVM, not Java (because of watts)

Over the years, there have been many contentious arguments about the performance of C++ versus Java. Oddly, every one I found addressed only one kind of performance (work/time). I can't find any benchmarking of something at least as important in today's massive-scale-computing environments, work/watt. A dirty little secret about JIT technologies like Java, is that they throw a lot more CPU resources at the problem, trying to get up to par with native C++ code. JITs use more memory, and periodically run background optimizer tasks. These overheads are somewhat offset in work/time performance, by extra optimizations which can be performed with more dynamic information. But it results in a hungrier appetite for watts. Another dirty little secret about Java vs C++ benchmarks is that they compare single-workloads. Try running 100 VMs, each with a Java and C++ benchmark in it and Java's hungrier appetite for resources (MHz, cache, RAM) will show. But of course, Java folk…

50% of Cloud Compute Power & Carbon Waste Solved by Software Technique

Ever wonder why virtualized servers are usually run at nominal loads of 30..40%? It's because the speed at which VMs can be live migrated is much slower than the speed at which load spikes can arise. Thus, a large "head room" is built into the target loads at which IT is generally comfortable running their virtualized servers.

Faster networking would seem to save the day, but per-server VM density is increasing exponentially, along with the size of VMs (see latest VMworld talks). Thus there are many more (increasingly bigger) VMs to migrate, when load spikes occur.

Besides the drastic under-utilization of capital equipment, it's a shame that the load "head room" is actually in the most efficient sweet spot of the curve. The first VMs tasked on a server are the most power-costly, and the last ones are nearly free (except we only use that band for spike management).

If loads could comfortably be advanced from 40 to 80%, half (or more) of the compute-oriented…