One area where D has the edge

[Paulo Pinto via Digitalmars-d]

On Sunday, 25 January 2015 at 21:50:53 UTC, Laeeth Isharc wrote:
> 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.

No, Java does not consume 15% doing it, because there isn't just 
one implementation of Java compilers.

Most comercial JVMs do offer the capability of ahead of time 
native code compilation or JIT caches.

So when those 15% really matter, enterprises do shell out the 
money for such JVMs.

Oracle commercial JVM and the OpenJDK are just the reference 
implementation.

--
Paulo