The reason they 'handle' things the same way is only due to how the compiler implements it, and as it stands now, most compiler creation follows a rather orthodox pattern in terms of how things like stacks and registers are handled. I could write a compiler that implemented things in ridiculously ........ed up ways if I wanted.
Originally Posted by Bubba
When you're in C, you need to divorce the actual implementation of the program from the lower levels. There's no such thing as a stack in C unless you're talking about a linked list, or you're just unashamedly technical all the time.
This doesn't make sense. A quicksort implementation will virtually always be faster and more efficient than a bubblesort, regardless if I program the Quicksort in Java and the Bubblesort in C.
It just doesn't get any faster than C/C++ unless you use pure hand-optimized assembly (and not all asm is faster than C).
Many times, it's not the compiler nor the virtual machine that causes the bottleneck. My friend had to write a java program to solve the n-queens problem for college, and while his algorithm was virtually the exact same, the person who had the second highest grade (he 'won' if you think of it that way,) his implementation was over twice as slow. What's the solution? That parts of the language could be constructed badly, he rewrote parts of Java's libraries and then implemented n-queens, and when he ported it to C and even Assembly, the speed difference was only a measily %15 difference, this was before Java even HAD a just in time compiler.
I don't see this changing and especially not from a language that has a virtual machine and even when compiled still does some odd stuff with memory and a lot of stuff behind the scenes that just slows everything down.
While I may be playing devil's advocate here, the thought of this occuring in C or C++ isn't insane. Using some of GNU's profiling tools, many people noticed huge problems with the STL library implementation in C++ (I believe it was vector or something.)
Another problem for the bottleneck is just the system itself, it's unfair to say "java is just slower," in many circumstances, it's not at all unusual for Java to be faster than C or C++. If I'm running a copy of IDA Pro and disassembling ntoskrnl.exe on a box with 128mb RAM on windows 2000 the chances of other programs, regardless of their language seeming slow is high (I would know, I've done it.)
There's some things that I can't do in C that I have to handle with assembly, even if it is only inline assembly or a linked procedure from doing 'nasm -fwin32 test.asm', there are some things I just flat out cannot do in C or C++ natively. There's plenty of practical reason to use assembly these days, if you're going into a security profession and don't know assembly but only know C, you're already a joke.
And if you look at the old C libraries you will see functions like setjmp, emit, etc, etc. You can see just by looking at some of the functions and what they do that C/C++ was intended to be a language that could do anything assembly could....and for the most part it has succeeded.
Well, everybody has their own experiances and preferences with programming languages I suppose.
I've found no other language to date that I've had a more pleasant experience with. Normally I find that when some other language tries to simplify something complex, the underlying code is too slow to be of use, and that language often does too much for you resulting in a loss of control.