View mode: basic / threaded / horizontal-split · Log in · Help
December 27, 2006
Re: Coolest D features
Waldemar wrote:

> Actually, the reality is Java is plenty slow in many applications.

I don't know about that. I have seen some nasty, klunky Java programs, 
but my experience is that they are the exception rather than the rule. 
Netbeans and Eclipse both started out as klunkers, but neither is today.


> There is JNI for a reason.

JNI was developed for compatibility with legacy code. It was used in the 
early days as a performance optimization tool, but these days not so 
much. Even for Java games, JNI is used only to access native APIs like 
OpenGL, OpenAL, or DirectInput. The old Dirty Java article at Gamasutra 
lost its relevance with the release of Java 1.4.

> Never mind cases where Java is not even considered (fast servers,
> OS internals, communication, graphics, driveres, embedded, etc, etc.)  As soon as
> Java reaches C/C++ speed, C++ will disappear.  Not too worry, won't happen any
> time soon.
> 

I don't expect people to write device drivers or any other performance 
critical code in Java :) That's not what Java is intended for. It *is* 
quite prevalent in embedded systems -- your cell phone is most likely 
equipped with JME, and you may even have some form of Java in your DVD 
player. The PS3 is equipped with a limited version of Java.

Java isn't a bare-metal systems language, but it isn't *slow*. The 
reality is somewhere in the middle. It's slower than C++ in most cases, 
yes. But there are plenty of applications that can be written in Java 
where a 5%, 10% or even 20% performance difference isn't going to 
matter. With my interest in games, I love to point out Java games like 
Tribal Trouble, Puzzle Pirates, and Bang! Howdy, all of which are 3D 
games, or the shooters developed by Puppy Games which are 2D on OpenGL. 
Since the JVM is bundled with each of them, most people don't know or 
don't care that they are written in Java. Performance is just fine in 
each of them.

The preceding paragraph is the typical response you are going to get 
from a Java programmer when you say Java is slow. There's a lot going on 
behind the scenes in the JVM, as Walter mentioned, and Java programmers 
understand that. There's a trade-off between safety/security and speed. 
They accept that. Do you think anyone at all would choose Java if it 
truly was a snail at everything? They like the ease of writing 
concurrent applications in Java compared to other languages. They like 
Java's inherent networking capabilities. They like the advanced 
development tools available for the language, such as the free 
profilers, full-featured IDEs, and the ability to choose between and 
fine-tune for several different GC implementations to get the best 
performance possible. Some hardcore Java programmers might be willing to 
write a video or audio codec in Java, but most are more grounded and 
understand that Java isn't suited for that.

So my point is that Java programmers use Java for a reason. Ask any of 
them and they will surely point out faults they find in the language 
(Generics being a popular one). But very few who choose to use Java will 
cite performance as a negative for *their purposes*. So to entice a Java 
programmer to come to D, the speed argument just isn't going to fly.

To court Java programmers, you have to convince them that D's features 
are shinier than Java's. You have to show them an advanced tool chain 
that lets them monitor every aspect of an application's performance. 
They want to be able to dynamically instantiate objects via a class name 
string. They want easy use of web services, support for web 
applications, and not to worry about porting issues across different 
platforms.

No matter your opinion of Java, or Walter's, people who use it on a 
regular basis see it in an entirely different light.
December 27, 2006
Re: Coolest D features
Mike Parker wrote:
> 
> So my point is that Java programmers use Java for a reason. Ask any of 
> them and they will surely point out faults they find in the language 
> (Generics being a popular one). But very few who choose to use Java will 
> cite performance as a negative for *their purposes*. So to entice a Java 
> programmer to come to D, the speed argument just isn't going to fly.

Agreed.  Programmers who are really serious about performance over other 
considerations will likely not be using Java, so this isn't a convincing 
argument here.  My personal problem with Java is that I hate the syntax. 
 Although it's fairly similar to C++ and even D, I find the nuances 
that are different to make it tremendously unwieldy.  And the 
deal-breaker is that Generics are complete garbage--I simply refuse to 
go without a decent way to express algorithms in a generic manner after 
having used C++ for so long.

> To court Java programmers, you have to convince them that D's features 
> are shinier than Java's. You have to show them an advanced tool chain 
> that lets them monitor every aspect of an application's performance. 
> They want to be able to dynamically instantiate objects via a class name 
> string. They want easy use of web services, support for web 
> applications, and not to worry about porting issues across different 
> platforms.

If I were to use Java, these would be the reasons.  And I think D has a 
long way to go here.  There is some library work that seems quite 
promising re: dynamic libraries (DDL), and Mango is fairly capable for 
server/web programming, but D is extremely weak in the toolchain 
department.  Windbg may work with D in Win32, but it's complete crap.  I 
have yet to use it without my debug session ending because windbg 
crashed.  The situation is so bad that I've considered developing 
exclusively on Linux in hopes that GDB support is better.  But 
fortunately, the times I want to use a debugger are so few and far 
between that this remains an idle fantasy.  And as for performance, DMD 
has profiling and code coverage tools built-in, which is a huge bonus in 
that regard.


Sean
December 27, 2006
Re: Coolest D features
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.
December 27, 2006
Re: Coolest D features
Andrei Alexandrescu (See Website For Email) wrote:
> Say you wanted to introduce a programmer friend to D. She might know one 
> of D's sibling languages (Java, C, C++, or C#), but you shouldn't rely 
> too much on that. What features of D would you describe first to hook 
> that friend in?
> 
> Andrei

Mostly it is the fact that a programing can be made more reliable and 
maintainable.

Simple consistent syntax is one part of this. The "It's easy to program 
in" also is part.

My favorite thing right now is this: Things can be made "intent-ional" 
(think "funct-ional") sort of a #define on steroids. This comes from use 
of const and templates. The after doing things like parser generation 
and ASM-stype bignum with template code I could actually stand reading 
really makes me think there is something here. After showing the 
template parser generator to a prof of mine, he said "Quit tempting me" 
to start learning D, this from a guy that likes Prolog (nothing wrong 
with that BTW).






p.s. & OT: that might as well be the abstract for the current version of 
my, "intro to D: why it will take over the world some day" paper:

http://www.uidaho.edu/~shro8822/term_009.pdf

comments welcome.
December 27, 2006
Re: Coolest D features
== Quote from Mike Parker (aldacron71@yahoo.com)'s article
[snip]
> 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.

D has no chance against java/C#.  Unless, and I am aware of the diminishing
freqency of these cases, performance forces the use of another language.  D would
be a candidate for that other language.  It is the only situation where pitching D
to java/C# people is not a waste of time.

D is a low level language competing with C/C++/ASM.

It has a chance but I don't know how long the window of opportunity will last.
December 27, 2006
Re: Coolest D features
Mike Parker a écrit :
> Being a long time Java programmer, I strongly disagree with you and 
> Waldemar both. Speed is only an issue for people who don't use Java, or 
> for those who don't really know how to properly write software with it.

Note that the "people who don't know to write software" include even 
Sun: in Solaris9, Sun rewrote the administration tools in Java, the result?
Well, the tools were so slow, that I learned to use the command-line 
tools instead of the GUI, because they were so damn slow that each time 
I used these tool, I was really pissed-off by the slowness..

It's probably possible to write fast Java apps, but even Sun don't 
manage to do it, and all the Java apps I've used have annoyed me by 
being too slow, so it's definitely not trivial: I think that using D 
it's easier to get fast apps.

Regards,
renoX

PS: Of course with D, there is the library problem..
I'd really like to have a wrapper of Qt in D..
December 27, 2006
Re: Coolest D features
Waldemar wrote:
> == Quote from Mike Parker (aldacron71@yahoo.com)'s article
> [snip]
>> 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.
> 
> D has no chance against java/C#.  Unless, and I am aware of the diminishing
> freqency of these cases, performance forces the use of another language.  

Also in cases needing ASM access or where use of a VM is not an option.

The first case won't go away and the second could come into play when, 
for an example, it takes longer to load the VM than it does to run the 
app, or when size is a BIG issue. I'll admit that D doesn't yet excel in 
either of these last two cases, but it will (I hope), I don't think 
Java/C# ever will.

> D would
> be a candidate for that other language.  It is the only situation where pitching D
> to java/C# people is not a waste of time.
> 
> D is a low level language competing with C/C++/ASM.
> 
> It has a chance but I don't know how long the window of opportunity will last.
December 27, 2006
Re: Coolest D features
> p.s. & OT: that might as well be the abstract for the current version of 
> my, "intro to D: why it will take over the world some day" paper:
> 
> http://www.uidaho.edu/~shro8822/term_009.pdf
> 
> comments welcome.


BTW: that version is the current version that I had when I noticed that 
it might have some bearing on the topic. I'm sure spelling and grammar 
errors abound, so please ignore them.
December 27, 2006
Re: Coolest D features
renoX wrote:
> Mike Parker a écrit :
>> Being a long time Java programmer, I strongly disagree with you and 
>> Waldemar both. Speed is only an issue for people who don't use Java, 
>> or for those who don't really know how to properly write software with 
>> it.
> 
> Note that the "people who don't know to write software" include even 
> Sun: in Solaris9, Sun rewrote the administration tools in Java, the result?
> Well, the tools were so slow, that I learned to use the command-line 
> tools instead of the GUI, because they were so damn slow that each time 
> I used these tool, I was really pissed-off by the slowness..

The new Sun debugger (SunStudio) is the same way.  It has a lot of nice 
features, but is so slow I end up doing most of my debugging in emacs 
with dbx.  One of these days I'll take the time to turn off the bits 
that are killing performance and give it another try.


Sean
December 27, 2006
Re: Coolest D features
Walter Bright wrote:
> 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.

Could you expand on the above items?  What basic types are missing? 
Does a "simple aggregate" refer to structs/tuples?  What does POD stand 
for, and what is a POD stack aggregate?  Could you show a code example 
in D that performs badly in Java?  Pardon my ignorance.

-Jeff
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home