Coolest D features

[Mike Parker]

Walter Bright wrote:

> 
> I haven't worked with Java for over 10 years now. But in March I 
> attended "Java Performance Myths" by Brian Goetz, who is very 
> knowledgeable about getting the most out of Java. He indicated that Java 
>  needed another 10 years before it would be able to consistently match C 
> toe to toe. And this is happening despite years of massive investment in 
> Java by lot of very smart people, just to approach what relatively 
> simple C compilers can do. This to me indicates there's a fundamental 
> problem with Java.

I've never heard Brian Goetz speak, but he's a prolific writer. One of 
his articles, Urban Performance Legends 
(http://www-128.ibm.com/developerworks/java/library/j-jtp04223.html), is 
one I often direct people to in Java performance discussions. But the 
question one must ask when evaluating any language is, what is this 
language suitable for? When you look at everything Java gives you, the 
trade-off of not matching performance of C is acceptable for a wide 
range of applications, but not everything under the sun (no pun intended).

Books like Code Complete and Writing Secure Code exist because languages 
like C and C++ have no built-in mechanisms to prevent severe errors like 
buffer overruns. How many times does this happen in server applications 
or even non-networking libraries? libpng had a patch recently, last year 
I believe, to fix a buffer overrun. That just shouldn't be happening itn 
modern software. Java's answer to those issues is certainly extreme, but 
a lot of people find that beneficial -- particularly for network 
software. I've written a lot of C code and a lot of Java code. It's much 
more pleasant to write Java because I can write a lot less of it. I 
don't mind a bit that it's not going to beat C in the performance arena 
because I don't need it to for what I use it for.

One of the things I like about D is that it incorporates some of the 
same mechanisms, but in a more flexible way (i.e. array bounds checking 
can be turned off). One of the things I miss about Java when I use D is 
the ability to instantiate any class by name. I've made heavy use of 
that for some component-based designs in Java. Designing D applications 
requires me to think differently, much as Java required a new way of 
thinking when coming from C.

> 
> I think the problem is that Java is just lacking in some needed features 
> - like a full set of basic types, simple aggregates, out parameters, 
> etc. The alternatives are computationally expensive, and so the 
> optimizer has a lot of work to do to reverse engineer them and figure 
> out that all the programmer was doing was a workaround for a POD stack 
> aggregate.
> 
> Java also has a few millstones that make things difficult for optimizers 
> - the required array bounds checking, the VM, etc.

I have no background at all in language design, or optimizers, but I'm 
guessing it's more than just a language feature issue. Most of Java's 
critical optimizations happen at runtime during the runtime analysis and 
compilation phases. Runtime compilation is still a comparatively young 
technology in practice. There are still a lot of kinks to be worked out 
in the process, a lot of progress to be made. I assume when Goetz said 
Java's performance would match C in 10 years, he was specifically 
referring to the Hotspot VM, or runtime compilation in general.

There are two VMs that ship with the SDK, referred to as the client and 
server VMs. The client VM has a shorter runtime analysis period than the 
server VM, so the server VM can make more aggressive optimizations after 
longer periods of analysis. I've read that it can eliminate array bounds 
checks in certain cases. Whatever it does, Java's runtime optimizations 
are built around the language's features. For example, in the latest 1.6 
release they just laid the groundwork for escape analysis, which will 
eliminate some object allocations on the heap and move them to the 
stack. The full implementation should be available in 1.7. I've even 
heard rumors that a JSR for a struct type will make it into a future 
release, which could open the door for more optimizations and, possibly, 
features like out parameters.

> 
> C++, much promoted for its efficiency, has a subtle problem with 
> efficiency. We all know that the biggest gains in efficiency come from 
> algorithmic improvements. But C++'s strength is in optimizing not the 
> algorithms, but the micro-optimization details of implementing them. C++ 
> code tends to get so complex that once we get it to work, we dare not go 
> tinkering with the overall algorithm, but just concentrate on twiddling 
> with the micro-optimizations.
> 
> I discovered this when working on DMDScript. I had spent a great deal of 
> time tinkering with the details of the C++ version trying to make it go 
> faster. Then I translated it to D, and found myself instead of tinkering 
> with the low level details, I was tinkering with the algorithms. With a 
> few changes there, that would have been hard to retrofit into the C++ 
> code, I had it running faster than the C++ one.
> 
> And that may be D's efficiency trump card over C++ - it's much easier to 
> modify existing, working code in ways that are too risky to do with C++.

But that's a completely different world. When trying to win over C++ 
programmers, words like efficiency, optimization, and performance carry 
a great deal of weight. Speed is king. Not so in the Java community. 
It's a different mindset with different goals. If Java programmers were 
overly concerned about performance, they wouldn't be using Java. Sure, 
they want their software to be performant and a good Java programmer 
knows how to squeeze every ounce of performance out of his code, but 
performance alone isn't going to sway them.

I think that overall D is going to be an easier sell to C++ programmers 
than to Java types. They are two very different markets that will 
require very different strategies.