One area where D has the edge

[Laeeth Isharc via Digitalmars-d]

The author talks about C++ performance but D can match it whilst 
bringing scripting language style programmer productivity, and 
arguably higher quality code (because you can understand the code 
base as a coherent whole).   Integration with C++ libraries is 
really the last missing piece, and it seems clear enough that is 
on the way to being solved at which point one of the principal 
relative advantages of Java (and cython / numpy - although latter 
less applicable to map reduce) goes away.

I heard a talk from the chap behind commoncrawl (previously at 
Napster and LinkedIn and seemed a hacker by temperament).  He 
observed that vast data sets put massive strain on code and would 
tend to find obscure bugs and strangeness sooner or later.  He 
talked about the non determinacy (for practical purposes) of JIT 
creating strange bugs that were very difficult to reproduce since 
the compiler would generate different machine code on each run.

And beyond slower execution speed  of Java, the memory bloat 
makes a big difference given how cloud pricing works (its peanuts 
to get a machine with a gig of ram, but 64 gig is not so cheap, 
and quickly gets very expensive - and one may need hundreds of 
machines).


http://www.trendcaller.com/2009/05/hadoop-should-target-cllvm-not-java.html

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 folks don't mention that.

But let's say for the sake of (non-)argument, that Java can 
achieve a 1:1 work/time performance relative to C++, for a single 
program. If Java consumes 15% more power doing it, does it matter 
on a PC? Most people don't dare. Does it matter for small-scale 
server environments? Maybe not. Does it matter when you deploy 
Hadoop on a 10,000 node cluster, and the holistic inefficiency 
(multiple things running concurrently) goes to 30%? Ask the 
people who sign the checks for the power bill. Unfortunately, 
inefficiency scales really well.