Richard Davies wrote: The UK has a good crop of technology pioneers in cloud computing - for example ElasticHosts, FlexiScale, Flexiant, OnApp - and also some strong government initiatives such as G-Cloud.
We will have to see whether this kind of technical leadership converts into swift mass-market adoption or not.
Keith Lea writes of the benchmark, on his results page, "I was sick of hearing people say Java was slow, when I know it's pretty fast, so I took the benchmark code for C++ and Java from the now outdated Great Computer Language Shootout and ran the tests myself."
Lea used G++ (GCC) 3.3.1 20030930 (with glibc 2.3.2-98) for the C++, with the -O2 flag (for both i386 and i686). He compiled the Java code normally with the Sun Java 1.4.2_01 compiler, and ran it with the Sun 1.4.2_01 JVM. He ran the tests on Red Hat Linux 9 / Fedora Test1 with the 2.4.20-20.9 kernel on a T30 laptop. The laptop "has a Pentium 4 mobile chip, 512MB of memory, a sort of slow disk," he notes.
The results he got were that Java is significantly faster than optimized C++ in many cases.
"They also show that no one should ever run the client JVM when given the choice," Lea adds. ("Everyone has the choice," he says. To run the server VM, see instructions in the Using the Server JVM section below.)
JDJ has agreed to post online anyone else's results as long as they use Java 1.4.2 or higher and any version of GCC that produces faster or equivalent code than the 3.3.1 I used. We encourage you to download the source and/or the binaries and perform the tests yourself, with your favorite compiler and on your favorite platform.
Download all source code and binaries: .bz2, (69KB) .zip (189KB)
JVM startup time was included in these results. "That means even with JVM startup time, Java is still faster than C++ in many of these tests," says Lea.
Some of the C++ tests would not compile. "I've never been very good at decoding GCC's error messages," he admits, "so if I couldn't fix a test with a trivial modification, I didn't include it in my benchmarks."
Lea also modified one of the tests, the string concatenation test for Java.
"The test was creating a new StringBuffer in each iteration of the loop, which was just silly," he explains. "I updated the code to use a single StringBuffer and appending to it inside the loop."
(The updated tests at the original shootout use this new method.)
"Java lost this benchmark even with the modifications," Lea declares. "So if anyone wants to accuse me of biasing the results, they're going to have to try harder."
Several versions of some of the C++ tests (like matrix) were present in the original shootout source, he continues.
"I used the versions without numbers in them, like matrix.g++ instead of matrix.g++2. I don't know which of these were used in the original benchmarks, but from my quick experimenting, the numberless ones generally ran faster than their numbered counterparts."
"Looking at them again," Lea says, "matrix.g++3 runs faster than the matrix.g++ that I use. However, it still runs slower than the Java version, so I don't plan to modify the graph/data unless someone asks me to, since getting that graph in the first place was sort of a pain.)"
He continues: "I've been told that the C++ code for the Method Call benchmark returns by value while the Java code returns by reference, and that modifying the C++ code to pass a pointer makes that benchmark faster. However, even with the modification, the C++ version still runs slower than the Java version."
Lea ran th Java and the C++ tests to "warm up" (both the Java and C++ tests got faster after he ran them a few times).
"I've been told that these tests are invalid because they were run with GCC," he concedes, adding: "I have seen both benchmarks that show GCC producing faster code than Visual Studio's VC++ compiler, and benchmarks showing the opposite. If I update the benchmarks with another compiler added, it will be the Intel C++ Compiler, which I'm pretty sure produces faster code than VC++."
Lea says he's been accused of biasing the results by using the -O2 option for GCC, "supposedly because -O2 optimizes for space, thus slowing down the benchmark," he explains.
But this is not what -O2 does, he points out, referring to the GCC -O documentation:
JVM startup time was included in these results. "That means even with JVM startup time, Java is still faster than C++ in many of these tests," says Lea.
Some of the C++ tests would not compile. "I've never been very good at decoding GCC's error messages," he admits, "so if I couldn't fix a test with a trivial modification, I didn't include it in my benchmarks."
Lea also modified one of the tests, the string concatenation test for Java.
"The test was creating a new StringBuffer in each iteration of the loop, which was just silly," he explains. "I updated the code to use a single StringBuffer and appending to it inside the loop."
(The updated tests at the original shootout use this new method.)
"Java lost this benchmark even with the modifications," Lea declares. "So if anyone wants to accuse me of biasing the results, they're going to have to try harder."
Several versions of some of the C++ tests (like matrix) were present in the original shootout source, he continues.
"I used the versions without numbers in them, like matrix.g++ instead of matrix.g++2. I don't know which of these were used in the original benchmarks, but from my quick experimenting, the numberless ones generally ran faster than their numbered counterparts."
"Looking at them again," Lea says, "matrix.g++3 runs faster than the matrix.g++ that I use. However, it still runs slower than the Java version, so I don't plan to modify the graph/data unless someone asks me to, since getting that graph in the first place was sort of a pain.)"
He continues: "I've been told that the C++ code for the Method Call benchmark returns by value while the Java code returns by reference, and that modifying the C++ code to pass a pointer makes that benchmark faster. However, even with the modification, the C++ version still runs slower than the Java version."
Lea ran the tests many times before running the "official" recorded set of tests, so there was plenty of time for both Java and the C++ tests to "warm up" (both the Java and C++ tests got faster after he ran them a few times).
"I've been told that these tests are invalid because they were run with GCC," he concedes, adding: "I have seen both benchmarks that show GCC producing faster code than Visual Studio's VC++ compiler, and benchmarks showing the opposite. If I update the benchmarks with another compiler added, it will be the Intel C++ Compiler, which I'm pretty sure produces faster code than VC++."
Lea says he's been accused of biasing the results by using the -O2 option for GCC, "supposedly because -O2 optimizes for space, thus slowing down the benchmark," he explains.
But this is not what -O2 does, he points out, referring to the GCC -O documentation:
-O2: Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. The compiler does not perform loop unrolling or function inlining when you specify -O2. As compared to -O, this option increases both compilation time and the performance of the generated code.
"On the other hand, -O3 performs space-speed tradeoffs, and -O performs fewer optimizations. Thus, for these tests, I think O2 was the best choice," Lea concludes.
"I don't have an automated means of building and benchmarking these things (and the scripts that came with the original shootout didn't run for me)," he continues. "I really do want people to test it on their own machines, but it's going to take some work, I guess."
Lea compiled the C++ code with:
g++ [test].cpp -O2 -march=i386 -o [test]-386
g++ [test].cpp -O2 -march=i686 -o [test]-686
and the Java code with:
javac [test].java
To see how he ran the binaries, see the run log. You can download the source code he used in either .bz2 or .zip format.
Using the Server JVM
Every form of Sun's Java runtime comes with both the "client VM" and the "server VM."
"Unfortunately, Java applications and applets run by default in the client VM," Lea observes. "The Server VM is much faster than the Client VM, but it has the downside of taking around 10% longer to start up, and it uses more memory."
Lea explains the two ways to run Java applications with the server VM as follows
When launching a Java application from the command line, use java -server [arguments...] instead of java [arguments...]. For example, use java -server -jar beanshell.jar.
Modify the jvm.cfg file in your Java installation. (It's a text file, so you can use Notepad or Emacs to edit it.) This is located in C:\Program Files\Java\j2reXXX\lib\i386\ on Windows, /usr/java/j2reXXX/lib/i386/ on Linux. You will see two lines:
-client KNOWN
-server KNOWN
You should change them to:
-server KNOWN
-client KNOWN
This change will cause the server VM to be run for all applications, unless they are run with the -client argument.
He can be contacted at
Every form of Sun's Java runtime comes with both the "client VM" and the "server VM."
"Unfortunately, Java applications and applets run by default in the client VM," Lea observes. "The Server VM is much faster than the Client VM, but it has the downside of taking around 10% longer to start up, and it uses more memory."
Lea explains the two ways to run Java applications with the server VM as follows
When launching a Java application from the command line, use java -server [arguments...] instead of java [arguments...]. For example, use java -server -jar beanshell.jar.
Modify the jvm.cfg file in your Java installation. (It's a text file, so you can use Notepad or Emacs to edit it.) This is located in C:\Program Files\Java\j2reXXX\lib\i386\ on Windows, /usr/java/j2reXXX/lib/i386/ on Linux. You will see two lines:
-client KNOWN
-server KNOWN
You should change them to:
-server KNOWN
-client KNOWN
This change will cause the server VM to be run for all applications, unless they are run with the -client argument.
About Jeremy Geelan Jeremy Geelan is President & COO of Cloud Expo, Inc. and Conference Chair of the worldwide Cloud Expo series. He appears regularly at conferences and trade shows, speaking to technology audiences both in North America and overseas. He is executive producer and presenter of Cloud Expo's "Power Panels" on SYS-CON.TV.
Reader Feedback: Page 1 of 11
#152
Daedalus commented on 9 Jun 2008
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.
#151
jmerd commented on 23 Nov 2007
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.
#150
aaa commented on 1 Aug 2005
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.
#149
Mike commented on 9 Jun 2005
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 !
#148
Isaac Gouy commented on 9 Nov 2004
>"outdated Great Computer Language Shootout (Fall 2001)"
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.
#146
larry commented on 5 Jul 2004
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
#145
héhé commented on 2 Jul 2004
this reflect what I meet daily in Java compare to C++
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 ;-)
#143
MJD commented on 27 Jun 2004
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.
#142
Gomes commented on 25 Jun 2004
I compiled the Fibonacci program in Visual C++.Net (Release mode)
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
------------------------------
#141
jose commented on 24 Jun 2004
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.
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++.
#139
larry commented on 23 Jun 2004
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.
#138
TheSpider commented on 23 Jun 2004
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?
Daedalus wrote: 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.
jmerd wrote: 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.
aaa wrote: 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 n...
Mike wrote: 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 tim...
TheSpider wrote: 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.
larry wrote: 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
icube wrote: 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 min...
MJD wrote: 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++...
Gomes wrote: 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
------------------------------
jose wrote: 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...
Yakov Fain wrote: 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++. P...
larry wrote: 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...
TheSpider wrote: 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 perfo...
MamanE wrote: I expect lower performance of the server VM on an Athlon than the server VM on a P4. What I don''t expect to see is the server running slower than the client on an Athlon, so I still think it could be a performance bug in the server.
You''re right the comparison is not really apples-apples, and the fastest ASM version still beats the crap out of the java version. But nonetheless I''m quite impressed with how far java got over the last few years.
Daniele Paccaloni wrote: MamanE,
I haven''t yet looked at the machine code produced by the server JIT on a non-SSE2 machine, but it could be possible that the JIT uses SSE2 only in server mode and (of course) if the CPU has SSE2.
I don''t think the VM is broken on the AthlonXP, it''s just that on that CPU you don''t have SSE2.
Since we are using doubles, the JIT cannot use SSE because SSE only handles 32bit floats.
Maybe if you change the mandel source to use all floats instead of doubles, the server JIT will be much faster on the AthlonXP too (since it will be able to use SSE instructions).
Also, note that when we say "as fast as the ASM version" we are actually comparing the SSE2 JIT code to my hand-coded ASM x87 code.
The SSE2 FPU is much faster than the x87 FPU, which explains the similar performance.
Also, the FPU code (including the C benchmark) is using 80bit extended precision while SSE2 is only...
MamanE wrote: "Also, would someone please run the mandel test on a P3 or Athlon-XP (thus forcing the JIT to use the FPU) ?"
The numbers I gave earlier (where the client ran about as fast as the C version and the server strangely enough a bit slower) are done on an AthlonXP. The numbers where the server runs as fast as the ASM version was done on a P4. Now I don''t know if something is screwed on my Athlon PC or if there is a performance bug in the server VM related to an Athlon, but I''ll check that out.
That original FFFF program is great fun, BTW :-)
MamanE wrote: Daniele''s numbers on the server VM are definitely right. I tested here and on the server VM it''s as fast as the ASM version and almost 3.5 times as fast as the C version, and I checked the results too. Quite amazing if you ask me.
Many times over the last year I have been asked the question, "What is Windows Intune?" I like to describe Windows Intune as the cloud service helps you centrally manage and secure your PCs through a simple, web-based console. Released back in March 2011, Windows Intune has alre...
Why are APIs so important in clouds? Do APIs have to be open? How fast or slow will standardization in the cloud be? Why is ensuring high availability for the cloud service critical?
In his session at the 10th International Cloud Expo, Mårten Mickos, CEO of Eucalyptus Systems, w...
Very few trends in IT have generated as much buzz as cloud computing. In his session at the 10th International Cloud Expo, Mark Hinkle, Director, Cloud Computing Community at Citrix, will cut through the hype and quickly clarify the ontology for cloud computing. The bulk of the c...
The proliferation of device connectivity is redefining the functionality requirements and capabilities of many embedded systems as more and more of these devices look to leverage the “Cloud.” While many commercial software and hardware component vendors have begun to realign thei...
Hardware and chemistry improvements will make the $1,000 human genome a reality soon. While the massive amount of genomics data that will be generated represents a huge opportunity to advance personal medicine, it also presents an enormous big data challenge.
In his session at ...
About Newsfeeds / Video Feeds
.gif)
Many times over the last year I have been asked the question, "What is Windows Intune?" I like to describe Windows Intune as the cloud service helps you centrally manage and secure your PCs through a simple, web-based console. Released back in March 2011, Windows Intune has alre...
Why are APIs so important in clouds? Do APIs have to be open? How fast or slow will standardization in the cloud be? Why is ensuring high availability for the cloud service critical?
In his session at the 10th International Cloud Expo, Mårten Mickos, CEO of Eucalyptus Systems, w...
Very few trends in IT have generated as much buzz as cloud computing. In his session at the 10th International Cloud Expo, Mark Hinkle, Director, Cloud Computing Community at Citrix, will cut through the hype and quickly clarify the ontology for cloud computing. The bulk of the c...
The proliferation of device connectivity is redefining the functionality requirements and capabilities of many embedded systems as more and more of these devices look to leverage the “Cloud.” While many commercial software and hardware component vendors have begun to realign thei...
Hardware and chemistry improvements will make the $1,000 human genome a reality soon. While the massive amount of genomics data that will be generated represents a huge opportunity to advance personal medicine, it also presents an enormous big data challenge.
In his session at ...
