This dude has no idea whatsoever about C++, probably he doesn't even realise how flawed his benchmarks are, and he believes his senseless results.

If anyone cares, -O2 is indeed a very wrong choice. So is allocating objects through operator new, so is passing objects by value, so are a lot of other things, which prove that he is either trying to rip us off straight away, or too stupid to realise that he cannot make a proper benchmark without knowing both languages.

This is absolutely funny. You do java, do not even say "performance" - as long as you do not even know what asynchronous io is (if you are lucky you are now at the non-blocking stage). Also - the JVM is a C/C++ program - meaning: if Java is faster than C then C is as fast as Java (paradox!). Go on - play with your toys.

I only registered because the benchmark is totally lame. Shame on you that wrote the benchmark and article! It's a completely bogus article, for many reasons:

a) you use new-delete in C++ where it is not needed

b) you do not use loop unrolling for C++(as you blatantly admit)

I suspect you do not specify inlining, do you?

There is no excuse for your lame article. The results are funny, especially the method call test that Java seems 10 times faster in calling methods than C++, whereas the actual slowness of C++ is the new/delete cycle!

Ask yourself this: is it possible for a Java method call to be 10x times faster than compiled C++?

I've tried the method call test by removing the new-delete and added time measurement inside the program, and C++ is faster than the server VM 1.4.2.

I did not look any further.

You are a joke, and a biased one.

Oh, and Java is never gonna get as fast as C++ simply because Java runs in a JVM: there is machine code (written in C++ - oh the irony) that controls the execution of bytecode.

I find the numbers reported on shootout incorrect. They should fix their test. Run the algorithm, whatever it may be in a method, and from main, call it a few times, say, 5 times. Have main measure how many milliseconds the called method takes, and print it to the screen. Run it with java -server as usual.
You'll get a result like this:
1004
653
602
607
599

This fixes 2 problems with shootout:
1) The first iteration is slower because the JVM might not have completely optimized the method. Putting the algorithm in a method and calling it a number of times gives the VM to replace interpreted, partially interpreted code with 100% machine code.
2) Fixes the way they account for JVM startup time. They suggest they take a standard known time, and use the same known start up time for every test. This is completely unfair, because each program will have a different start up time because it needs to compile and each program compiles differently.

I'm outraged out shootout has created a completely false view and made Java look worse than C and C#.
The fact *IS* that for number crunching, Java IS faster more often than not. Oh YES it is !

>"outdated Great Computer Language Shootout (Fall 2001)"

Shootout has been revived
[visit link]

Larry,

Very much appreciate your comments. Would like to connect via email to discuss possibilities. Perhaps through the author or via purpose created Yahoo email account. Please advise if interested and if so preferred method of contact.

Much of that article is out of date w.r.t java. Perhaps he can re-look at it again and update it.

no point in debating old point that are not relevant anymore

this reflect what I meet daily in Java compare to C++

[visit link]

shootout has a great interest but not between C++ and java but between ocaml and java .... :-)))) java .net .... are marketing tools they all lay on their own performance ... only OCAML can be put in a nuclear plant (see the java license ;-) ! why ? no compromise ... with complexity and strenght ... strongly typed when java start at jdk 1.5 ( ~ with 20 years) but with bad ;-) tools many people can do business ... write books .... java performance tuning (a good book also for java world!) and provide services ... version of jVm etc ... java and .net are arifacts of the object marketing big bazard ...put programmers community attention on OCAML and let programmers discover concepts and features, performance of vm ;-),let them, develop OCaml stack and one again check performance with J2EE or .NET ? ;-) who wins ? In shootout performance, OCAML is closer to C++ and C , overall winner of minimal line of code ... ,overall winner in platform independant. Why Microsoft R&D investigate on F# an OCAML sub language for its CLR layer ;-) and why OCAML is the best programming languge of MIT and INRIA(French R&D, its fonder) teams ?

be aware & wake up !!! by a java tuning specialist ... ocamly converted @;-) icube
(ps: new strategic anti-pattern : "The strongly type client" : If you are a client for a j2ee or .net application, asks your computing service contractor to give you a proof of program in your new brillant and with 6 zero contract, it will be a little bit disappointed ... in this case if you are the contractor check for OCAML ;-)

Concerning C++ issuing deletes and Java waiting for GC to run.

If you are done with an object in java, you too can set the object to null.
JavaClass jc = new JavaClass()
jc.doSomeRealWork();
jc = null;

jc = null acts as a hint to the garbage collector that the object space is ready for garbage collection, and it also will probably re-catagorize the object as a shortlived object and be handled by a different garbage collector, a faster one.

It does look like Java is a true replacement for beginner and intermediate C++ programmers. Especially those that lose track of their objects and never actually issue those deletes, and those that don''t use code profiling. So, will experience C++ programmers write systems that beat java in the real world. Most times there isn''t the time or money in the budget to do so. So, in the real world the answer is no. I''ve seen Microsoft C++ shops ship the debug build instead of the release build because the release build leaked memory all over the place. And it was the Microsoft libraries that were leaking memory.

In my experience the language VB, C++ or Java was never the issue in business applications. In Business Apps the Database is always the bottleneck.

Anyway, a pretty good thread.
Thanks for the effort.

I compiled the Fibonacci program in Visual C++.Net (Release mode)

22 seconds (Athlon XP1800 256 RAM)
77 seconds (k6-2 500 120 RAM)

========

Conclusion: Is Visual C++.Net Faster Than JVM(Linux)? Is Athlon XP 1800 better than Pentium(???Frequency???) MObile 512MB of memory?

Above the results of the author in Pentium MObile 512MB of memory...

========

[keith@leak bench]$ time cpp/fibo 45
1836311903

real 0m44.042s
user 0m43.130s
sys 0m0.160s
[keith@leak bench]$ time cpp/fibo-386 45
1836311903

real 0m50.625s
user 0m49.410s
sys 0m0.190s

[keith@leak bench]$ time java -server -cp java fibo 45
1836311903

real 0m33.842s
user 0m33.120s
sys 0m0.070s

[keith@leak bench]$ time java -cp java fibo 45
1836311903

real 0m50.066s
user 0m49.780s
sys 0m0.170s

------------------------------

5 - 6 years??!!! What, did they hire monkeys? To think of whats things I could write in that time. Terrible...

Anyways, yes, there''s no doubt that Java will be more effective on certain levels and the reason why is because Java was has specific areas covered quite well, although I will disagree to an extent about the wonders of LDAP. But alas this is Sun we are talking about and this is their bread and butter. I think you are forgetting that C++ is just a language. At the end of the day, its about what technologies you decide to mix together. Visual Basic, for example, was Microsoft''s attempt at doing something quite similar to that (but we all know VB is crap and so will hesitantly use it).

In that case, I''d like to share my experience. When I once was at univeristy a while back, we had to write a object tracker using digital imaging principles, that involved taking input from a camera source and distinguishing cars from other objects and tracking their velocity and travel. I did mine, naturally, in C++, while a class mate of mine did it in Java. I wrote mine in half the time as he did and it was more reliable and faster. Does this prove that an implementation was much better in C++ ? Not necessarily, it could also prove that he simply was a poor Java developer, or that he had more trouble picking out the correct methods and technologies to use for his project.

Apples and oranges.

Most of the postings here compare particular Java and C++ features. If you go this route, C++ will probably beat Java. But let me share my experience with you.

A couple of years ago I was involved with creation of a real-time trading system in Java for a major brokerage house. At that time, a system written in C++ was in production for 5 or 6 years. For the new system we used J2EE with EJB, JMS (MQSeries) and LDAP servers. When the new system went into production, it was much faster that the old one and more stable. And let me tell you, the old C++ system was not poorly written! Once in a while C++ developers would say something like ?we are using memcpy in our system for fast copying of memory blocks, and your Java does not have it?. So what? The final product with bean pools, multithreading and asynchronous messaging was performing a lot better than a product written in C++. Please keep in mind, that we did not have to hire C++ gurus to deal with multithreading ? Java application servers did it for us!

You may say that I am comparing apples and oranges. True ? I am comparing J2EE with C++. Unfortunately I did not have a chance yet to re-write a .Net system in J2EE ?
But I do believe, that J2EE is a better choice for a real-world enterprise applications than C++.

Hi Spider,

I hadn''t responded because this was slightly off topic and the answer can be the subject of several books. ;)

Anyway, with respect to your items, here is a quick response

1. This is the classic architecural dilemma. I would suggest that you review a number of architectural patterns. There is a good book "Pattern Oriented Software Architecture". For example, the microkernel pattern and the layering pattern

2. A java VM will solve much of this problem for you. However there is a reverse memory leak issue. Objects remain uncollected so long as there is a strong reference to them. Current practices for modern VMs state that you do not pool small objects. Pooling is primarily for those java objects backed by native resources. You must be careful about creating too many objects however as you will pay for it in gc later. I would suggest that you use jvmstat 2.0 for j2se1.4.2 and above and jvmstat 1.1 for 1.4.1 and lower from the cool stuff web site on java.net

3. I would recommend that you manage your inheritance hierarchy so that you do not have an excessive amount of inheritence levels. Refactoring will help there. Modern OO practice de-emphasize inheritance over composition.

4. You will pay for security through performance. Rather than relying on applets solely, take a look at java net launch protocol as a way of deploying applications via web browser. This will get around various plugin issues.

5. In this case the new io package is the way to go (java.nio). Nio will allow you to achieve this.

6. In this case, you should invest in top notch java ui developers.

Summing up, plan your architecture very carefully, use patterns to decouple layers so that you can maintin it easily and separte concerns. Utilize the right sort of java technology for the right purpose.

Larry (or others),

I''m still very interested in those "architectural" issues you noted. It would be great if you could be more specific. My main purpose for possibly selecting Java for our major code base conversion is for the following reasons:

1) A nice tradeoff between being "low level" enough to provide lots of flexibility vs. human efficiency and extensibility. We will need to get very low level at times to do some trick things but we want to code at as high a level of abstraction as we can.

2) Virtual elimination of memory management related leakage issues and pointer induced errors (this is a BIG deal). The biggest drawback to C or C++ is the huge issue with these kinds of problems.

3) Complete OO with adequate inheritance capability. Due to the dynamic nature of OO w/Java, we suspect this will be one of the areas we need to pay close attention to regarding performance.

4) Improved security for apps in a distributed environment. For wide area deployment, lightweight, secured applets talking over encrypted channels to heavy backend systems seems like a great way to reduce TCO.

5) High degree of near native connectivity over a distributed environment and amoung widely disparate devices. This kind of flexibility is not found in any other environment.

6) Ability to produce a powerful and flexibile user interface that is state-of-the-art. One of the reasons our software and service are selected is because we take a lot of time and effort to package sophisticated behavior into a form that is extremely efficient and natural to use.

All the above being said, our first experience a few years ago was not pretty. The code was small and compact and highly functional but it was really, really, really slow. After investing several man-months in coding and testing (and investigating other toolsets and utilities) we finally scrapped the project until such time as Java or another tool could manage the workload while still keeping us efficient and logically correct.

Those last two criteria are essential. Efficiency of human effort when porting a system with hundreds of RDBMS tables, hundreds of apps and hundreds of thousands of lines of code is a BIG project (at least for us). Keeping it logically verifiable is absolutely essential as this is a business suite that deals with large amounts of assets and cash flows.

So I reiterate: What are the really important architectural issues that we should watch out for? What are the essential do''s and don''ts that can make a break a project of this size and nature?