Welcome!

IBM Cloud Authors: Yeshim Deniz, Elizabeth White, Pat Romanski, Liz McMillan, Stefan Bernbo

Related Topics: Java IoT

Java IoT: Article

Reader Feedback Special: Java vs C++ Benchmark Brouhaha

Reader Feedback Special: Java vs C++ Benchmark Brouhaha

  • Java vs C++ "Shootout" Revisited
  • Read/Join the Feedback to the original article 

    On Monday we published an article about Keith Lea's one-man attempt to take the benchmark code for C++ and Java from the now outdated Great Computer Language Shootout conducted by Doug Bagley in Fall 2001 and run the tests himself. Within 12 hours 40,000 people had read the piece and by the end of the day Bagley's "Shootout" had even been revived as an ongoing Debian Alioth project.

    But while the team behind that project cheerfully says on its Web site "Contributions are welcomed for revised implementations, bug fixes, or ideas for new benchmarks," not everyone agrees with this kind of activity.

    When Bagley did the original shootout, he said it was "To learn and to have fun," adding that he would continue continue "as long as the fun holds out." This notion of enjoyment has been revived by the Debian Alioth update: 

    "The project goals have not changed substantially since Doug's original project. This work is continuing so that we all can learn about new languages, compare them in various (possibly meaningless) ways, and most importantly, have some fun!"
    But many of those who troubled to record their views in the course of the past few days did not recognize benchmarking/microbenchmarking as anything worth doing at all.

    Some took issue with Lea's choice of performance speed as the parameter to compare Java and C++. One, Lachlan Stuart, wrote:

    "What you must realize is that C++ and Java have much different targets, it's rare that you will encounter a situation where both are equally suitable. No matter what, unless you forget to turn debug compile off, C++ will beat Java in real world situations on the performance front..."

    "Try praising something else about Java...like its security, or ease of programming," Stuart continued.

    GooberToo concurred. "The more I read the code, it sure is starting to look more and more like an apples and oranges comparison; which is usually what happens when people do Java benchmarks." And Iain too was unhappy: "Aside from perhaps demonstrating that you know Java far better than you know C++, I don't think these tests were a particularly useful exercise."

    Others too felt that Lea's relative unfamiliarity with C++ compromised the exercise. "This article is completely useless and only shows the lack of understanding of C++ by the author," wrote Dr Valentin Samko. "This reminds me of a person who clamed that qbasic is faster than C++ because his program which outputs a few million blank lines works faster in qbasic than in C++."

    Glen Low queried the shootout's methodology on a number of counts. Here is one:

    "The small size of the programs are a definite advantage for Java's runtime optimizer. A run-time optimizer can't spend forever optimizing, but it has access to actual run-time data, AND can specialize its optimization for the specific processor. (G++, and most other C++ compilers, have flags to allow this as well.) Given the small size, a complete analysis of the program is possible in the limited time available, and given the other additional data, I would find it rather worrisome if Java didn't do better. I'm more sceptical with regards to real programs, however. If there really is one small critical loop, Java should win; that's not the case for most of my programs, however."
    Scott Ellsworth disagreed with those who dismissed Lea's shootout, though. "The point is that many C++ users feel that Java is too slow and uses too much memory. Microbenchmarks like this show that this off the cuff response is as silly as claiming that exceptions cost too much just because cfront compilers had that cost," he wrote. 

    Ellsworth continued:

    "I spent seven years doing C++ in a shrink wrap environment, and five doing Java. In my experience with real world apps, Java code gets done faster, works better out of the box, and is easier to maintain. Tricks like custom memory allocators and carefully crafted templates can make faster C++ code, but I reserve those for time critical parts of the program. Where I do not spend some programmer cycles profiling and optimizing, the two environments are pretty close.

    Thus - if Java is producing code reasonably close or ahead in fairly straightforward usage, and the code gets written faster and more portably, then Java is a win for my work. I can always choose to use C++, assembly, or FORTRAN for the time critical routines, and then link in."
    Patrik Beno issued a challenge. "I suggest that now it's time for C++ experts to optimize C++ code and compilation, run the very same tests again and post the results."

    "Don't blame Lea, he did his best, now it's your turn, C++ experts," he added.

    Perhaps SWagner would be someone who will rise to the challenge in due course. S/he wasn't at all happy with Lea, writing:

    "As an experienced C++ developer (and Java as well) I only see that the C++ code is optimized for minimum performance. Especially the methodcall where the class has virtual constructors or destructors which is seldom useful and significantly hurts performance. Just because you can't turn this off in Java does not mean that you have to make it slow in C++."
    "In my practical experience," continued Wagner, "normal Java code is 1000 times slower [compared] to OPTIMIZED C++. However if you make severe design flaws you can make any program slow. And if you base on a bad benchmark and make it even worse you should better stop any benchmarking you planned for the future."

    Somewhat less disgruntled was m, who wrote: "The benchmarks are interesting, but frankly with real applications, I have never experienced Java performance equal to or better than that of C++."

    "I have done a number of home-grown benchmarks for XML parsing, and C/C++ (think expat) are 3-9 times faster," m continued. "The difference there is that the server JVM does indeed optimize over a series of many runs. Java certainly allows us to develop faster, and quite often time to market performance is more important than the performance differences in these two (great in my opinion) platforms. They each have specific advantages."

    This, not surprisingly, was the essence of quite a few of the comments. "Java is faster for some applications than C++, and for others C++ is faster. It depends on what you want to do with it," said RebelCool

    But Iain's objection was to the choice of tools to compare, to the entire premise of the shootout in other words: 
    "The comparison [Lea is] trying to make between C++ and Java is not particularly meaningful. At the end of the day, if a VM is faster, then there is nothing to stop you implementing a VM in C++ and running the 'C++ program' within that framework. What times would then be valid? The tools you are comparing are very different.
    In addition, the C++ code is seriously sub-optimal. To take one example, the 'matrix.cpp' is definitely not written for speed. A general purpose C function is being used to repeatedly allocate rows, when a single large block of size 'mn' could have been used. For that matter, why is malloc( ) being used at all? (A custom memory manager optimised for small blocks could have been used instead - malloc( ) is slow.)

    If you insist on writing simple C, then at least use memset( ) for the zeromatrix( ) function. Fast template matrix libraries exist for C++ - these could have been used instead - the result would have been shorter, clearer and considerably faster. Aside from perhaps demonstrating that you know Java far better than you know C++, I don't think these tests were a particularly useful exercise."

    NotZed disagreed with the premise too, writing: "Java works well as a COBOL replacement, a backend application language for boring buisiness apps. That's what it should be benchmarked against. Comparing it to C is like comparing apples and oranges."

    Chris countered: "Surely the benchmark is no less meaningful than when it was originally used to show C++ was faster than Java."  

    And Christopher White commented:

    "Thanks for the comparison Keith. I enjoyed reading your commentary.

    Many people have stated in response to this article that Java, as everyone knows, is slow... This is certainly not the case. I am team leader of a Java development team. We have six applications in production on a certain open source application server. We have 1200 users of these applications. The applications are load-balanced over two machines (each machine : HP DL380 2*2.8GHz 2Gb RAM). We have on average 2% Cpu utilisation. Whilst this is of course just a subjective view of Java performance, I can say that we certainly do not have the impression that Java is at all slow.

    I accept that for memory deallocation C++ can be tailored to the needs of the application at hand so it will be difficult to beat on this score, however one must remember that the just in time compiler compiles code into native machine language and that this compiler is very much optimized on a per platform basis so I don't see why C++ should produce naturally faster compiled code.

    Whichever is faster, Java is easily fast enough for most applications and I strongly believe that the overhead in development time incurred by using C++ is rarely justified except in specialized applications such as driver or game coding."

    For the moment let's give the last word to SB:

    "Java and C++ are different languages, with different advantages/drawbacks, and different philosophies. My experience, from a large company that produces tons of software, is that performance always comes down to the quality of the developers, not the language itself. And we also found out that in today's world, most developers are only average, and this class of developers yields better results with Java than C++."
    The debate, as they say, will doubtless continue...

  • More Stories By Java News Desk

    JDJ News Desk monitors the world of Java to present IT professionals with updates on technology advances, business trends, new products and standards in the Java and i-technology space.

    Comments (3)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
    Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
    Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
    If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
    Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
    Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...