Java speeds have caught up to C/C++ and sometimes passes them

This is a discussion on Java speeds have caught up to C/C++ and sometimes passes them within the Tech Board forums, part of the Community Boards category; I was researching a bit on how efficient is Java really since I love C
and I see more and ...

Java speeds have caught up to C/C++ and sometimes passes them

I was researching a bit on how efficient is Java really since I love C
and I see more and more devs going on to Java. I wanted to know what
sort of improvements could Java have on C or rather C++ (to be fair)

I read this and this, and what I understood from these two sites is that Java
is faster because it doesn't use pointers and it has a garbage collector for automatic
memory allocation and freeing.

So I was thinking if these things are true, if I changed my coding style to use less
pointers or even went a step further and coded my own garbage collector, would it
increase the speed of my C or C++ program to that of Java?

...err.. what ?...
It is like saying(following their optimization logic) ..you can run faster if you cut off your hands !

it has a garbage collector for automatic
memory allocation and freeing.

That makes it fast ?

So I was thinking if these things are true, if I changed my coding style to use less
pointers or even went a step further and coded my own garbage collector, would it
increase the speed of my C or C++ program to that of Java?

NO
_________

I wonder why they used a little known proprietary compiler instead of GCC in the linux benchmarks!

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

what I understood from these two sites is that Java
is faster because it doesn't use pointers and it has a garbage collector for automatic
memory allocation and freeing.

Your first source states that "Pointers make optimization hard", and elaborates with an example of how a compiler might not be able to take advantage of register usage due to aliasing. I believe this to be true, but aliasing is possible in Java too, due to object references in Java. As Java object references are more restricted than C pointers, the aliasing problem is probably reduced, hence the observation in question.

Originally Posted by BladeZer0

So I was thinking if these things are true, if I changed my coding style to use less
pointers or even went a step further and coded my own garbage collector, would it
increase the speed of my C or C++ program to that of Java?

Using fewer pointers could make things worse if you end up doing expensive copies when you don't need to (that said, consider if C++ references would be more appropriate). The point is not that pointers make the code slow, it is that aliasing makes it harder for compilers to optimise. Writing your own garbage collector would be a bad idea unless you have the knowledge to write one that is good enough. The point is not that garbage collectors are inherently faster, it is that garbage collection provides opportunities for some smarter use of memory than what is typical without garbage collection.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

I was researching a bit on how efficient is Java really since I love C
and I see more and more devs going on to Java. I wanted to know what
sort of improvements could Java have on C or rather C++ (to be fair)

I read this and this, and what I understood from these two sites is that Java
is faster because it doesn't use pointers and it has a garbage collector for automatic
memory allocation and freeing.

Language comparisons, per se, are inherently superficial...the real issue is implementation; a given implementation may very well produce poor results, but that doesn't necessarily reflect upon the language itself (which is merely an abstraction). In other words, it's entirely possible that a well-designed Cobol compiler could produce better code than hand-written assembler!

That said, the reality of the situation is that there are relatively few stable implementations of a given language available, and so the urge to "compare language performance" is only natural, if misplaced.

Originally Posted by BladeZer0

So I was thinking if these things are true, if I changed my coding style to use less
pointers or even went a step further and coded my own garbage collector, would it
increase the speed of my C or C++ program to that of Java?

Thank you laserlight and gardhr so much for the informative and complete responses and you know what I've realized after reading all the posts?
those sites and their points of views are very shallow and very narrow.
When it comes down to speed it probably isn't really going to be a difference big enough that the user will even notice.
I'm going to study garbage collecting just in case but I doubt I'll need it, most of my programs in C use linked lists, arrays of pointers and my own
push/pop heap functions to add and remove from the list/array and I never really have a problem with performance or memory leaks etc.

Again thank you all, I don't often post here but when I have a question about programming I come here.. thats why my post count is so low
I usually figure things out myself but I wanted to know this before I started learning how GC work to make my own xD (I'm still going to learn it anyway)

I know I'm late to the party, but I had to address two bits from the comparison that really jumped out at me.

In the java case, the loop bound(s) can be kept in registers, and the index is certainly in a register, so a register-register test is needed. In the C/C++ case a load from memory is needed.

The official Java VM is a stack based machine; talking about registers in that context is a little silly.

The big benefit of GC is memory locality. Because newly allocated memory is adjacent to the memory recently used, it is more likely to already be in the cache.

The official Java VM creates all objects on the heap ultimately controlled by a loose GC; any locality of reference that would give the Java VM the implied advantage would require a finely tuned GC ruling a very strict world.

I wouldn't be surprised if Java was as fast as C and C++ in many cases. On the other hand, C as a language has a tiny core library while Java as a language has a hugely bloated core library. C is also a lot more flexible that Java when it comes to memory allocation and so forth. C++ is a more flexible language because it can support OOP like Java but Java cannot support generic programming which is quite powerful. I still have my doubts that a modern FPS can be executed on the VM fast enough to be competitive. For web development and applications where speed or fine-tuned memory use is not a primary concern, I think that Java wins out for its simplicity over C++ and its built-in safety nets for programmers.

I wouldn't be surprised if Java was as fast as C and C++ in many cases.

There are certainly cases where Java is faster than C or C++. They tend to be cases that Java (and hence Java Virtual Machines) are well designed to handle, or that exploit runtime capabilities like JIT (so, for example, code that is executed many times can be sped up after it has run a few times). Those things play to designed strengths of Java (or the typical JVM).

Similarly, there are cases where C or C++ are faster than Java. There are many techniques that C and C++ support, but Java does not, so it is easy to find code that plays to strength of C/C++ while hitting on weaknesses of Java.

It is rarely a fair comparison to use language (or runtime) features that play to strengths of one language and weaknesses of the other. Very few real-world programs (other than those designed to show language X is "faster" than language Y) will uniformly exploit strengths of a particular language while avoiding its weaknesses.

The only fair comparisons are those that are concerned with picking a language for a particular application. If your application can effectively make use of Java techniques to gain performance, then use Java. If your application can effectively make use of C++ techniques to gain performance, then use C++. Most applications are not that simple through, so some form of trade-off between the languages (or possibly multi-language programming) is necessary.

If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

Most applications are not that simple through, so some form of trade-off between the languages (or possibly multi-language programming) is necessary.

Oh yes. In my opinion, multi-language programming is king for more complex applications that nonetheless remain performance-critical. Unfortunately it comes at a considerate expense, since it broadens the know-how required for maintenance. I would probably not hesitate going this route, were I in that situation and were I somehow able to guarantee that know-how during the application lifetime.

Java has the potential to be as fast or faster I guess, but every single Java program I run into is a slow and buggy piece of crap, so I doubt that'll ever happen.

What does this mean?

Also, any kind of articles about language X vs Y makes me laugh. Simply put, it is so difficult to make a fair comparison that it just isn't possible for a wide variety of programs (ie, a general sense).
To even remotely come close to making a fair comparison, you have to take specific programs, then optimize them as best you can given a specific compiler, platform and language. But since there are thousands of compilers and platforms available, it just isn't feasible. Different compilers and platform and operating systems will bias the comparisons in some form or way for some given language or task.

So no, C is not faster than C++, C++ is not faster than C, C++ is not faster than Java and Java is not faster than C or C++. It's all relative. Relative to your implementations, your circumstances, your operating system and your requirements.
It's silly to say language X is faster than Y anyway. The choice of language should not be on theoretical aspects which cannot be proven, but based on objective measurements (ie, write a task in some languages, then run it to see which one is fastest).

Okay, that's a fair statement Elysia. Let me rephrase. Assuming that most people use Sun's implementation of the Java language, most programs are probably slower running on that than a program written in C/C++ compiled on gcc, MSVC, or Intel compilers. Sun's implementation of Java is a buggy and slow piece of crap. The only program I've used on Sun's implementation of Java that wasn't total dogs--- is Frozen Bubble.