joustlog

its not just the compiler buddy, you should be testing optimal HLL code in addition to opitmization. i'm curious to know a little bit more about your understanding of system's architecture and your understanding of how virtual machines actually work. GCC's -03 optimization does not necessarily produce better results as it does inlining and potentially uses more memory which is good for certain applications but infavorable for others.

You can't expect to just use someone else's code blindly and test something. You should find someone who's good at C/C++ and write efficient C/C++ code to test against someone who's writing efficient java.

But its pointless anyhow, basically common sense says this is a non-contest. If your university has taught you anything about interpreted languages, no matter even if you're using JIT, it still has at least one additional level of re-direction to convert the java byte code into machine code; java _must_ be slower than something that is pre-compiled into bytecode.

i somewhat pitty you, because you've become the laughing stock of the computer science community.

Karney,

You're dead wrong! A Java program may have a slower startup time but in a lengthy run it can easily perform better than C or C++. This is not the first time I see such benchmarks and I believe that they're true (at least to some extent) because:

1- Pointers make optimization hard and Java doesn't have pointers

2- Modern garbage collectors outperform manual memory management (e.g. malloc, free)

3- Run time compilation

See http://www.idiom.com/~zilla/Computer/javaCbenchmark.html for another benchmark

Of course Java has pointers. You point to an object.

Java still has pointers, just they have significant restrictions. Note that G++ can ignore some of these problems with -f-allow-aliasing (which gives the optimiser more scope). Java can benefit from things you can't do in C++, such as assuming alignment, etc.

Modern garbage collectors can do better, but they can also do worse. It is a factor that can vary quite significantly. If most of your objects die young (as they generally do), then yeah, garbage collection may well be a win for you, but this situation is covered in the C++ world by placing objects onto the stack. (where deallocation is just an addition) If however, you perform multiple passes over a large dataset and destroy the old dataset each time, then C++ will do better as you would have to perform full GCs in this eventuality. Also, C++ may well use less memory

Note, that also garbage collectors have problems with paging which C++ doesn't have, so as soon as you need to use more memory than the machine has C++ will almost certainly be faster. (The first full gc will KILL your performance). [in these cases you really need to use something like nio to push the dataset out of garbage collection consideration, but this does complicate your code]

The runtime compilation is certainly not impossible in C++ either - there is a significant amount of research that covers writing runtime jitters for assembler code (have a look for HP's Dynamo project).

None of this is to say that I think Java is awful or not competitive, just to say that I don't think Java will necessarily win any speed crowns, I just think that it has the potential to be competitive.

definitely just saw the article with your name in it on salshdot. congrats!

You say "i'm curious to know a little bit more about your understanding of system's architecture and your understanding of how virtual machines actually work."

I don't understand very much about computer system architecture but I think I understand some things about how virtual machines work.

I ran tests, and published the results on my personal web site. My benchmarks show that at the lowest level, the math and memory operations, Java can have similar speed to a similar C++ program. I don't think I know what you're arguing about.

I don't see how Java could be running better than C++, if your programmer is a competant C++ programmer. If you write bad C++ then of course its going to run poorly. Java just makes up for it by doing more checks.

Keith's tests results are based on flawed tests and corner cases where Java has been optimized and the C++ code has not. In my mind (and the opinion of just about everyone in that slashdot thread) C++ code used in the benchmark is bad and inefficient way of writing C++. Please refer back to that slashdot thread, read what people have had to say about Keith's "benchmarks". There's no point having me repeat what they have already said.

Let me remind you what a garbage collector is actually doing, its doing the work of a C++ programmer to deallocate memory. Unless that Java virtal machine can somehow take over the kernel, a VM has to still make a system call to the kernel to tell it to deallocate memory. Unless a Java VM can deallocate memory faster than doing a system call, i'd like to know how its being done.

Keith if you still are reserved about this, I'm sure you won't be when you've neared completion of your undergraduate degree. Please don't just run benchmarks and assume that one language is faster than another. You made some very bold statements in your "test". What I will agree with is, poorly written C++ makes Java look fast. Java is more suitable for people who don't have a great understanding of C/C++ and assembly. Next thing i'm going to hear is Java is faster than assembly!

Just a test

Just a test

great page...im sure i'll come back...best regards

best online casinos

link

Viagra is an online prescription drug. Get cheap viagra NOW!