D?

Started by
70 comments, last by Aldacron 15 years, 10 months ago
Quote:Original post by DevFred
Quote:Original post by Antheus
Compared to C/C++ baseline:
- Java: high memory demand, slower by a constant factor

Stop living in the middle ages. Scientific Computation in Java is equally fast or sometimes even faster than in C/C++. Check out chapter 25 here. And dynamic allocation is A LOT faster in Java than in C/C++.


I was hoping that discussion of technical aspects of languages would avert such knee-jerk reactions, but apparently, java+slow is a magic flip out button.


Doing two things at once, with same amount of resources will inevitably be slower than doing one thing at once. JVM needs to, even if negligible degree, interpret the code it runs, and in most cases it is required to not make any global optimizations, which excludes inlining.

This is why the term constant factor.

The running time of an algorithm can be written as k * O(n) + C. Any VM will have k and C higher than equivalent statically compiled code.

But as it happens, static compilation is just that - static. As such, the effects become apparent when looking at O(n). The most obvious difference comes from memory allocation. For algorithms which rely on non-deterministic, or poorly deterministic allocations, a fully blind compacting allocator can, and does improve run-time performance, simply due to improving cache coherency.

But it's well known, that algorithmic optimization can affect O(n) to such a large degree, that k and C become ignorable.

Implementing equivalent algorithm (in other languages) is perfectly possible, and commonly done in C and C++, using custom allocators from pre-allocated storage. The difference is just in productivity, coding solid domain-specific allocators is non-trivial. And for most applications, especially where flexibility is the key, the difference is negligible.

This is why Java managed to get such strong support in very large environments.

We can obviously go around like enterprise middle managers, talking about synergetic entropies of culmination of development resources to further the coherency of meta-strategies while reducing the profit margin baselines, and make sure to show pretty pictures with colorful charts and beat each other silly with fractions of percent statistics.

Or, at least try to approach the problem in a slightly CS-like manner, and objectively look at actual costs of either language or platform, to maximize the pros, and minimize the cons of each - and find the right tool for the job.
Advertisement
Quote:Original post by DevFred
- Another feature C++ is missing is optimization based on runtime profiling.

What? Haven't you ever seen the "Profile Guided Optimization" option in Visual Studio?

Quote:- And let's not forget about allocating memory on the heap which is a hell of a lot faster in Java than in C++, because the heap is always compact, thus it's just as cheap as stack allocation.

Depends what allocator you're using. C++ doesn't restrict you to one particular allocator, so it doesn't really make a lot of sense to argue the performance of C++ heap allocation.

John B
The best thing about the internet is the way people with no experience or qualifications can pretend to be completely superior to other people who have no experience or qualifications.
Quote:Original post by DevFred
Quote:Original post by Hnefi
how about stop talking about it and show me some benchmarks of nontrivial applications?

I don't really like benchmarks myself, but this is the slide from the mentioned talk:

Uh-huh. Isn't SciMark a Java application to begin with, and as such, does it actually run the executables as separate native processes, or does it execute them within the JVM? Has it been documented as reliable? Does it use large problem sizes in the shown instance? Are the benchmarked implementations actually optimized - the C# result in particular creates significant doubt in this area.
Quote:- One feature that C++ doesn't have is "not having pointers". Pointers is something an optimizer doesn't like because of aliasing issues.

Actually, there are pointers in Java, although they are hidden from the programmer. Java pointers can be aliased as well, constituting just as big an issue as it does in C/C++.
Quote:- Another feature C++ is missing is optimization based on runtime profiling.

That may be an issue for sloppy or even most everyday programming, but if we are to compare languages for scientific computing it only makes sense to assume that the programmer is competent enough to profile and optimize his/her own programs. Otherwise, the entire argument is moot.
Quote:- And let's not forget about allocating memory on the heap which is a hell of a lot faster in Java than in C++, because the heap is always compact, thus it's just as cheap as stack allocation.

I'm sorry, but if you're allocating significant amounts of data in the middle of a scientific application, you deserve the runtime penalty. The first thing they tell you when giving instructions on programming numerically intensive programs is that "processing is fast, memory is slow - so only allocate what you need once, at the beginning". If it takes half a millisecond to allocate the 2 gigs of memory you need on the heap, that's hardly going to be noticeable when your program takes two days to execute.
Quote:Pick the right tool for the job. If the core of your application is heavy number crunching and you have exact specifications, sure, go for C/C++/Fortran/whatever. If you want to program OO with agile methodologies and need some number crunching here and there, don't ditch Java just because of some performance myths from the nineties.

And yet here you are, telling us that Java is faster for heavy number crunching. Which is it?
-------------Please rate this post if it was useful.
Quote:Original post by h3r3tic
I'll go ahead with shameless self-promotion and link to my stuff written in D, in case anyone might be interested: http://h3.team0xf.com/proj/


Quote:Original post by Nitage
The show stopper:
The tools aren't able to support source files with spaces in their paths, or installing the D tools themselves to such a path.

I could understand if it was filed under 'minor irriations'. Would you care to elaborate why it's a showstopper?

It makes the tools impossible to use within our current software structure.
It also shows that Digital Mars aren't serious about maintaining the tools. They're interested in adding new langugage features, but not in the nitty gritty of producing adequate tools.

Quote:
Quote:
* The mechanism for overloading the equality opeartor ('==') is broken. It can't handle types which never compare equal to anything, even themselves - i.e. database nulls, NaNs etc. So while NaNs are handled correctly for builtin types, they can't be handled correctly by user code.

Hm.. Perhaps I'm missing something, but this code compiles and runs just fine.

My apologies - as I said it's been a while since I last tried out D and my memory is failing me. opCmp is broken - not opEquals!

The following compiles and runs fine:
void main(){  assert((0 > float.nan)==false);  assert((0 < float.nan)==false);}

But can't be replicated in a user defined type as far as I know. I'd be happy to be proven wrong - I only gave D a very cursory look before.
Quote:Original post by Tree Penguin
Very unlikely. It could be just as fast if the Java code is compiled to machine code.


Sun's Java VM does compile java bytecode to machine code.
Quote:Original post by Hnefi
And yet here you are, telling us that Java is faster for heavy number crunching. Which is it?

Some benchmarks say C++ is faster, others say Java is faster. I haven't measured myself, and I don't really care. I don't chose languages because of some speed myths I've heard.

There are applications where effiency is of uttermost importance - if you are designing such an application, just write prototypes in several languages and compare for yourself. In many cases, other quality factors such as reliability and modularity are far more important than efficiency.

All I really wanted to say is: Java used to be slow - REALLY slow. But it has evolved. Java can allocate objects on the stack now. Java can inline method calls. Synchronization for uncontended objects has gotten REALLY fast. Object allocation is nothing to be afraid of anymore. Garbage Collection algorithms have dramatically improved.

Java performance has made huge leaps during the last ten years. But the performance myths from ten years ago still persist, and it seems there is nothing you can do about it.

You shouldn't think "Oh I really want to programm a little game in Java now (after all this is a gamedev forum, right?), but I heard that Java is only half as fast as C++, so I'm gonna postpone that idea and learn C++ first."

I don't claim one language is better than the other (I don't even think such a comparison makes any sense). I just think that Java gives you a certain performance "for free" (stack/heap allocation is decided by the compiler, not the programmer for example), whereas in C++ you have to know exactly what you're doing, and you have to put lots of work into manual memory management and stuff like that. And you must be very careful not to produce incorrect code, because no one in their right mind would trade a 100% efficiency boost for correctness.

People aren't chosing Java because it is more or less efficient than C++. People chose Java because it makes you more productive - IF it is the right tool for the job.

Oh, one more thing C++ doesn't have: a memory model. But I think C++0x will correct that.
Quote:Original post by Nitage
It makes the tools impossible to use within our current software structure.
It also shows that Digital Mars aren't serious about maintaining the tools. They're interested in adding new langugage features, but not in the nitty gritty of producing adequate tools.

Ouch... Well, perhaps Walter could answer that one, since he's apparently found this thread ;) As far as I know, it's the linker that's failing and it's a very old piece of source code in pure Asm. Walter is probably planning on doing something with it.

Quote:My apologies - as I said it's been a while since I last tried out D and my memory is failing me. opCmp is broken - not opEquals!

I think you're right about that one. opCmp is slightly broken when you want to do stuff like this. However, abusing the fact that "a OP b" is rewritten as "a.opCmp(b) OP 0", we may hack it and make opCmp return float.nan. The following works just fine:
struct Foo {	bool opEquals(T)(T anything) {		return false;	}	float opCmp(T)(T anything) {		return float.nan;	}}void main() {	Foo f;	assert (f != f);	assert (!(f > f));	assert (!(f < f));	assert (!(f >= f));	assert (!(f <= f));	assert (f != 0);	assert (0 != f);	assert (!(f > 0));	assert (!(f < 0));	assert (!(f >= 0));	assert (!(f <= 0));	assert (f != 0);	assert (0 != f);		assert (!(0 > f));	assert (!(0 < f));	assert (!(0 >= f));	assert (!(0 <= f));	assert (f != 0);	assert (0 != f);}
Quote:Java performance has made huge leaps during the last ten years. But the performance myths from ten years ago still persist, and it seems there is nothing you can do about it.


Please point out where I stated Java or JVM were slow.

I ask because it was my posts that caused you to explode over "Java not being slow".
Quote:Original post by h3r3tic
As far as I know, it's the linker that's failing and it's a very old piece of source code in pure Asm. Walter is probably planning on doing something with it.

That is interesting - if I understand correctly, the .lib and .obj files produced by the dmd compiler are in the same format as the ones used by the Microsfot C++ compiler, so I could just switch to a different linker.

Quote:
I think you're right about that one. opCmp is slightly broken when you want to do stuff like this. However, abusing the fact that "a OP b" is rewritten as "a.opCmp(b) OP 0", we may hack it and make opCmp return float.nan.

Seems a bit dodgy returning a float from opCmp, but the cases I'd want to do that in are so rare that it's acceptable.

Another minor irritation I had with D was its lack of C++ style const-correctness, but it seems that this has been added to the language since I last looked.

Quote:Original post by Nitage
Quote:Original post by h3r3tic
As far as I know, it's the linker that's failing and it's a very old piece of source code in pure Asm. Walter is probably planning on doing something with it.

That is interesting - if I understand correctly, the .lib and .obj files produced by the dmd compiler are in the same format as the ones used by the Microsfot C++ compiler, so I could just switch to a different linker.


Unfortunatly not, or not anymore. DMD produces OMF object files and Microsoft COFF.

Quote:Another minor irritation I had with D was its lack of C++ style const-correctness, but it seems that this has been added to the language since I last looked.


It is in D2, the branch that is under development. There are some differences with C++, a lot actually.

This topic is closed to new replies.

Advertisement