Java...

[3hM2Nwbp]

rapidcoder wrote:

Pausless efficient GCs do exist.

Could you link me to (a cheap) one, please? None of the stock VM flags seemed to fix the issue that drove me from Java in the first place.

Huh? Click a link "download Java", click "Next" one or two times, done. Anyway, most of them don't need to do that, because JRE is already installed on ~60-90% of computers (depends on who is benchmarking).

The point that I was stressing was average end-user, the kind that give up if double clicking the icon doesn't work.

*Oh, another +1 for Java's standard serialization API so we're back up to +5

[jsmith]

Coming into this thread late, and not about to read 80 replies beforehand...

But anyway.

I find Java's introspection/reflection functionality to be a plus over C++. I find Java's hash-based containers to be better (performance wise) than C++'s sequenced containers. It is also nice that "there's a class for that".

Now for the bad things. If you want real performance, Java isn't your language. Platform independent? Not quite, but then again, neither is C++ IMO -- how can a language claim it is platform independent when it can't even guarantee me how many bits my ints have?

More and more I find that designs are better when class hierarchies are minimized. Java teaches the exact opposite -- derive and derive, extend and extend, etc etc.

C++ saw the problem with exceptions as part of function signatures; Java embraces it. It is quite annoying that virtually every function can throw one or more exceptions and actually makes it harder to write robust code when every line of code has to have its own try/catch block.

[rapidcoder]

If you want real performance, Java isn't your language

Only if the size of the project is small (like in most benchmarks) or your budget is unlimited (which is never a case). In all other cases Java is on par with C++ or even faster. Multithreading in Java is faster. Heap allocation is faster. Virtual calls are faster. These are all things easy to avoid in a benchmark, but unavoidable in a large project.

[andywestken]

I have been following this thread on and off and there are a few things that puzzle me.

Before I continue, I am not anti-Java. I see Java and C++ as solving quite different sets of problems. C# would seem to be a more appropriate competitor for Java.

But statements that heap allocation or threading is faster in Java than C++ don't make sense to me.

If you are saying that you believe it's easier to write efficient threading/etc code in Java than C++, fine. But what limits the performance is that of the threading library or heap manager. which is being used. (The fact that Java provides a standard threading library whereas C++ doesn't is a separate issue)

I have just had a look at the Java installation on my Windows XP machine, and I can see -- thanks to depends.exe [1] -- that jkernel.dll is using kernel32.dll's CreateThread and HeapAlloc call's, so WIN32 has been used to implement it.

Furthermore, PEID [2] reports that jkernel.dll (1.6.0_25) was built with Visual C++ 7.1. So the Windows version of Java's speed is reliant on not only the performance of WIN32 but the speed of a runtime library written in C/C++.

I am also curious as to how a Java virtual function call can be faster than a C++ virtual function call. The cost of the C++ vtable mechanism is a pointer dereference plus an array offset (cf. calling a non-virtual method through a pointer). Does Java manage to avoid one of these somehow?

To end, referring to another thread: "isn't multilple languages a sign of bad?"
http://www.cplusplus.com/forum/lounge/48709/

I think there is plenty of code that it would be a bad idea to write in C++. But the same holds for all other languages, including Java. I expect to work with mixed languages and libraries when working on a non-trivial project. It's as far from bad as possible!

Andy

[1] http://www.dependencywalker.com/

[2] http://www.peid.info/

Not sure how much I trust this little app, but it correctly reports the versions of various -- but not all -- other files (sometime it can't work it out). But as jkernel.dll links to MSVCR71.dll, which uses C++ linkage, it must be compiled with Visual C++ 7.1

[Galik]

rapidcoder wrote:

Only if the size of the project is small (like in most benchmarks) or your budget is unlimited (which is never a case). In all other cases Java is on par with C++ or even faster. Multithreading in Java is faster. Heap allocation is faster. Virtual calls are faster. These are all things easy to avoid in a benchmark, but unavoidable in a large project.

I think Java is a great language. I spent a number of years working on a large scale content delivery server for mobile devices all in Java. We spent a considerable amount of time optimising the code to achieve performance requirements. There is always "hype" around any language among its adherents and Java is no exception. However I never believed the hype and I am quite certain that whatever I write in Java I can make faster in C++.

That doesn't mean that C++ is always the right language to choose for a given task. Some tasks are much harder to implement in C++ because Java has the libraries and infrastructure to make those things easy. And Java is indeed much more performant that people give it credit for. But it really doesn't touch C++.

I think that andywestken is talking a lot of sense. Certain aspects of Java have to be implemented in C++. So on top of whatever C++ is executed by libraries you have your JIT converting code and a GC copying live objects around memory.

I just don't see how it can be faster.

[rapidcoder]

But what limits the performance is that of the threading library or heap manager. which is being used. (The fact that Java provides a standard threading library whereas C++ doesn't is a separate issue)

As for allocation and deallocation speed I already mentioned a few times here, why Java is an order of magnitude faster. It seems you haven't read the article from IBM, nor anything describing how Java allocator works. Creating such an efficient general allocator for C++ is not possible, although of course, you can deliver your own specialized allocator for some of the tasks, using placement new, if you can e.g. make some additional assumptions (e.g. all objects of the same size or with equal lifetime). Games often do that, but there is a huge price to pay in form of increased code complexity and debugging time.

As for threads, HotSpot performs quite a lot thread related optimisations, because threads are part of the language. This is not possible for C++ compilers, because are implemented 100% in the libraries. JVM 6 and 7 can delete or merge locks in code. Show me at least one C++ compiler that can do that.
Again - it is easy to provide optimal locking for a 20 LOC snippet of code. But it is extremely hard in a large project, when e.g. you are writing a thread-safe library, and cannot make any asumptions how your library will be used by the calling code.

I am also curious as to how a Java virtual function call can be faster than a C++ virtual function call. The cost of the C++ vtable mechanism is a pointer dereference plus an array offset (cf. calling a non-virtual method through a pointer). Does Java manage to avoid one of these somehow?

The cost of virtual call is much higher than what you have written. The real cost of virtual call is not a pointer dereference, the real cost is the cost of missed inlining possiblity and missed optimisations. If the function is short, vcall can be even 10x slower. Java is very good at inlining monomorphic and bimorphic calls, and also mostly-monomorphic calls (situation when most of calls targets the same object, but not all) and with arrival of JDK 7, soon it will be able also to inline megamorhic virtual calls.

Certain aspects of Java have to be implemented in C++. So on top of whatever C++ is executed by libraries you have your JIT converting code and a GC copying live objects around memory.

The assumption Java is implemented on top of C++ is false and so is the conclusion.

[jsmith]

The single reason for my claim of Java's slowness is its garbage collector running whenever it feels like and taking as much time as it wants. Yes, in _most_ apps it won't make a difference. In the apps I work on, it does. In fact, we go out of our way to use the equivalent of object pools to avoid making the garbage collector want to run and take a long time.

But the garbage collector is a necessary and intrinsic part of the Java language. If the garbage collector is too slow for some applications, then that's saying Java is too slow for those apps.

[Galik]

rapidcoder wrote:

The assumption Java is implemented on top of C++ is false and so is the conclusion.

Are all those native libraries that get installed with my JRE just a figment of my imagination?

[Albatross]

No they are not, Galik. It's just that those libraries were not written in C++ but they are in fact compiled Perl. ;)

-Albatross

[andywestken]

@rapidcoder Could you please post a link to the IBM allocator paper you allude to.

Thanks, Andy

(hamsterman has since pointed me at the link which was previously posted... must get some new glasses!)

[hamsterman]

@andywestken
http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html
That was on last page.

@Albatross, Galik
rapidcoder explained his point quite clearly, you're just being childish.

[Albatross]

I know. We're just having fun.

Although it would have been nice if for the sake of this debate (which I am no longer bothering to take a major part in) he indicated what language the JVM was written in.

-Albatross

[andywestken]

@rapidcoder

It would help me if you could be a little less ambiguous in places. As you are making quite technical statements, I read what you wrote more literally than I would a normal forum post.

My comments on your statement

Heap allocation is faster. Virtual calls are faster.

are not countered by your response.

> The actual virtual functions calls -- when they are made -- are not going to be faster. What you are saying is that you believe the use of virtual functions has a more detrimental effect on the C++ optimizer than the Java one. That is a different matter, and I can well believe it.

> Similary with heap allocation. In C++, the CRT allocates a heap at process startup and then hands out blocks from it. This heap allocation is going to be no faster for the Windows version of Java than any other C++ program that uses the WIN32 heap functions. Of course, the Java runtime parcels out the memory in a very different way to your typical malloc. But allocating memory from the heap is not the same as allocating a heap.

(To avoid the abiguity, the people I work normally talk about newing and deleting memory. so the term heap allocation is left to just mean allocating the heap. This pedancy is prob. only necessary if you actually allocate you own heaps, rather than just using the CRT heap.)

From what you say about threading, it sounds like the use of thread in Java is quite different to the WIN32 idiom, which is to use very few threads. Hence the kind of thread optimization you are talking about sounds a bit strange to me.

BTW - I have now read the Brian Goetz article, and am now reading a few of the commentaries on it (pro and con). Have you come across any good/fair critiques of the article?

[sohguanh]

moorecm wrote:
If I want a quick distributed database application, I'd use Java. If I wanted to manipulate text files, I'd use Perl. If I wanted to do system operations, I'd use C++.

I share the same view as moorecm.

For Java JVM I have to state, it does affect program and if your system is say a high frequency trading system, any second of pause to let GC do it's work is not acceptable. For such systems, C++ will still be the better choice. If we weigh in terms of the number of systems needing such high performance timing vs those can make do with a pause here and there, we know the numbers, I believe a huge percentage of systems can make do with a pause isn't it, especially now hardware is improving leaps and bounds.

Just a side-note, I develop using Android SDK Dalvik and it's ultra aggressive GC collection can really halt programs especially those first person shooting game where pauses are not tolerated. It causes some gamers to complain of lag and they are not happy. So I think in this aspect C++ might still be a better choice unless your games genre are say puzzles, strategies etc where you will think and pause and then tap which works fine since during your period of thinking, Dalvik GC has done it's job.

[rapidcoder]

@andywestken: Concluding on performance from the program dependencies is a big wtf to me. It is not "what" calls are made by the application, it is important also how, i.e. how often and when. Java allocates a large heap upon startup and then hands blocks of memory from it in a much more efficient way than C++ malloc, which without memory compaction done by GC would not be possible.

The actual virtual functions calls -- when they are made -- are not going to be faster.

Yes. But from the developer's point of view, when I have a virtual call in my program, and the optimizer finds a way how to physically avoid it, then I can see it as "a virtual call happening faster". This really doesn't matter, if the call is completely elided, or only in most of the cases, or handled in some other way. Logically works as a vcall, physically implemented in a different way to make it faster than traditional vcall.

As for Dalvik I agree, but this is quite a different story. Dalvik is still very immature, it recently got JIT. In mature JVMs you can usually set the maximum allowed GC pause time, for e.g. 0.01 s, which would be unnoticeable to the player.

[sohguanh]

Java allocates a large heap upon startup and then hands blocks of memory from it in a much more efficient way than C++ malloc, which without memory compaction done by GC would not be possible.

The trade-off to this approach is the huge memory consumption by Java programs. A simple ps will show the stats in comparison to a C++ program. But since memory prices are dropping as ever, most organizations feel adding more memory in exchange for less memory-leak problems a fair exchange.

It is no secret than organizations that have C++ as their systems do allocate quite a lot of resources chasing down memory-leak which sometimes crashes the program at that moment. Of cuz one could argue this is due to the developer inferior skill-set but even for veteran C++ developers, they do also now and then get tripped by the same problem isn't it ?

For veteran C++ developers please raise your hands that even after programming in C++ all these years, you never have to battle with memory-leak monsters at all ? If you really raise hand, then all my respect to you.

[rapidcoder]

The trade-off to this approach is the huge memory consumption by Java programs.

Nope. The memory overhead of properly tuned GC in an application tuned for speed (so that GC CPU overhead < 5%), should not be higher than 25-50%. If it is higher, probably your application does something very nasty to GC, e.g. produces garbage at a speed of 1 GB/s or so - you certainly can optimise it.

50% more memory usage is not what most people call "huge". And 20-50% overhead is also not so uncommon for many C++ allocators (mind the fragmentation). If you are unlucky in some cases the fragmentation can blow up to many times that (see Firefox 2 case, where fragmentation caused leak-like behaviour and several hundreds of MBs lost).

The usual impression people get about Java's high memory consumption is caused by measuring code size and JVM's size on something small like a hello-world program. JVM itself requires about 20-50 MB of memory, depending on which APIs you use. But this is code segment, not heap. Very, very big applications like Eclipse require just about 100-250 MB of RAM, mostly for code of libraries. One thing that Java could do much better to be more desktop friendly is sharing more code between various JVM instances. Currently it shares only the JRE classes, not the ones delivered by the app.

Anyway it is still becoming less and less important, as memory gets ridiculously cheap. I recently bought an additional 4GB DDR3 chip for less than $30. It is enough to run two instances of Eclipse, Java application server, several instances of the application I'm developing, Firefox, OpenOffice, webserver, database server and still lots of memory is left for buffering.

[moorecm]

sohguanh wrote:

For veteran C++ developers please raise your hands that even after programming in C++ all these years, you never have to battle with memory-leak monsters at all ? If you really raise hand, then all my respect to you.

Memory leaks, just like other bugs, are an absolute certainty as code size increases. Testers should have the mindset that if they aren't finding bugs, they aren't doing their job, IMO.

rapidcoder wrote:

The usual impression people get about Java's high memory consumption is caused by measuring code size and JVM's size on something small like a hello-world program.

I don't see how this counterexample can just be dismissed like this. That is a valid concern by the critics.

[rapidcoder]

Yes, Java is not a good platform for tiny desktop applications. It could be if it had better class sharing mechanisms. It is not that it can't be made, it is just desktop was never top-priority for Sun/Oracle.

[Cheraphy]

In all honesty in most smaller applications you wouldn't really need to use OOP anyways, so using java would be bass ackwards to begin with.