C++ vs. Java (speed considerations only)

[daniel_dsouza]

Hello CD,

I'm told that code written in C++ will run faster than Java code. My question is, how much faster, and under what conditions will it be noticeable? I'm especially interested in situations where teams have used both C++ and Java environments (at different times of course).

A large speed advantage from C++would be the only reason we would switching (we use Java now), as there really aren't too many other benefits to C++.

Thanks,
Daniel

[JesseK]

My professional answer is: it depends. For generic software that doesn't use specific hardware implementations, the results aren't quite as intuitive since post-JIT processing will be at least as fast as C++ (i.e. after the same cycle has run a few times).

For hardware-based operations (OpenGL, OpenCV, custom hardware interfaces like radios) C++ is typically faster latency-wise, yet processing wise it's the same as Java. This is only due to the JNI code layer, and is implementation dependent (i.e. most of the time it isn't a noticeable difference unless you're shoving MB's of data through the code per second).

Bad programming practices will cause more performance issues on an FRC bot than the language choice.

Some articles:
http://vanillajava.blogspot.com/2011...-for-high.html
http://vanillajava.blogspot.com/2012...revisited.html
http://vanillajava.blogspot.com/2012...s-in-java.html
http://vanillajava.blogspot.com/2011...llions-of.html

And the article to make contraversy:
http://vanillajava.blogspot.com/2011...er-than-c.html

[Tom Bottiglieri]

Have you run into a CPU ceiling? If not, what's the point of switching?

I've used both and I must say that I've found Java to be a more pleasant experience for FRC. It was easier to get students involved and learning, I could run it on my mac without a problem, and the speed of development was just WAY faster (less boilerplate, Eclipse/NetBeans are fairly good at autocomplete, etc).

[Jon Stratis]

Originally Posted by Tom Bottiglieri

Have you run into a CPU ceiling? If not, what's the point of switching?

+1

There are certainly reasons for a team to consider switching programming languages, and it really is great that we have the option to use Java, C++, or LabView. However, there is also the old adage, "If it ain't broke, don't fix it!"

Your best bet to examine the differences is to re-write last year's code in C++, then do some testing yourselves. Does the robot work better?

In my opinion, you'll see more benefits from knowledge and experience (development time, debugging, etc) in Java than you would ever see in performance from switching languages.

[daniel_dsouza]

Thanks guys,

There were a few members who wanted to use C++ for our language next year, but I think we will stick with Java. But there is still the off-season to experiment.

[Hjelstrom]

If you were going to try to achieve high-framerate vision processing on the cRio then C++ might be a good choice. Other than that I would recommend sticking with JAVA. Nothing else you would do on a robot should come close to taxing the cpu in JAVA.

Now that you can offload the vision processing to your driver station (e.g. see the paper released by 341 and the cookbook from WPI) you really don't need to do it on the cRio anyway. There are some of other advantages to doing the vision processing on your driverstation too such as being able to see what its doing :-)

[wilful]

If you don't know already, Labview has MAJOR lag problems, especially with relays. This year, the code that came with Labview for the relays was unusable and we were forced to write our own. This prevented us from competing in most of our matches at the Sacromento regional. So if you are looking for processing speed, don't use labview.

[Greg McKaskle]

If you believe you have found a bug with relays in LabVIEW, can you please be more specific? What workaround "fixed" the problem?

Each of the languages use the same integrated tests to verify correct operation and we each have tests for performance as well. LabVIEW is in fact a compiled language, like C++, but very different in that it is dataflow. Many teams used LabVIEW this year, and we don't have reports of lag everywhere or lag in relays. Details please. Since this isn't on topic, feel free to PM me.

Greg McKaskle

[apalrd]

Originally Posted by wilful

If you don't know already, Labview has MAJOR lag problems, especially with relays. This year, the code that came with Labview for the relays was unusable and we were forced to write our own. This prevented us from competing in most of our matches at the Sacromento regional. So if you are looking for processing speed, don't use labview.

There are two things that are REALLY slow in LabVIEW:

-VI calls through the normal "execution system" when they should be Subroutines or Inlined. The majority of the WPIlib suffers from this problem, unfortunately. The normal execution system is designed for heavily multitasking systems and systems with many concurrent processes. It treats each VI as an independent node in the execution system, unless it is flagged as Subroutine (or Inlined at compile time), which isn't very efficient. When properly written, LabVIEW code is far easier to multitask without much overhead.

-Programmers writing code while thinking procedurally. Thinking functionally is much better in LabVIEW (and even better in Simulink and more hardcore dataflow and modeling languages). That said, I still firmly believe it's better for programmers to know multiple languages and paradigms, as it will help you better choose the correct language and environment for a challenge.

As for C++ vs Java, non-JIT Java code will be slower. For completely personal reasons, I am a fan of purely procedural C programming for embedded systems.

I am also quite unimpressed by the timing jitter I got in LabVIEW. The RT threads are able to hold very tight timing, but at fairly significant CPU expense.

[Greg McKaskle]

This is what the cockpit of fighter planes look like.

This is what the cockpit of a Cessna looks like.

Is WPILib meant to be a fighter or a Cessna or somewhere in between? In all three languages, it steers away from advanced features, and the APIs do lots of parameter checking and error reporting. WPILib is not the ultimate example of performance techniques for any of the languages.

... The majority of the WPIlib suffers from this problem, unfortunately. The normal execution system is designed for heavily multitasking systems and systems with many concurrent processes. It treats each VI as an independent node in the execution system, unless ...

I'll argue that WPILib doesn't suffer from this. The goal was to make teams successful writing code to safely control an FRC robot. Much like the HW kit of parts, it isn't a turnkey robot SW solution, but instead offers relatively safe and straightforward components that can be combined in many ways. It is shipped as source where possible and often with debugging in place in order to allow safe exploration even to the point of making optimizations and other modifications. Just because the Cessna doesn't have the same cockpit as the fighter doesn't mean it failed at its intended purpose.

As for the LabVIEW execution system, I'll be happy to answer questions on how it operates. VI calls and Subroutines are closely related and both introduce overhead. In return, you gain code reuse and abstraction. I do not agree they are REALLY slow.

Just as a multitasking OS makes sense on a single core computer, so does a multitasking language. LV doesn't just treat VIs as independent nodes, it treats loops and other code clumps containing asynchronous nodes as independent nodes -- because they are. They are asynchronous. Lumping them together amortizes scheduling overhead but risks unnecessary blocking. This is the juggling act that the OS and the LV scheduler and clumping algorithm perform. All the languages support multitasking, but do so differently.

Summary?
All three languages are fast enough if used properly, and not nearly fast enough if used improperly. All are used in industry in performance demanding and time critical applications and are used by large numbers of FRC teams. There are many ways to choose the language(s) you want to learn. Performance shouldn't be the sole reason.

Greg McKaskle

[ttldomination]

Originally Posted by daniel_dsouza

Thanks guys,

There were a few members who wanted to use C++ for our language next year, but I think we will stick with Java. But there is still the off-season to experiment.

This is interesting, but it's important to take note of why they're suggesting it. If the members want to move over because they feel like they would be more comfortable in that environment/they have more experience in that environment, then this merits further thought.

And definitely look into off-season testing. We're going through similar changes so we're looking forward to taking full advantages of this fall to make a smart, informed decision.

- Sunny G.

[JamesTerm]

Originally Posted by daniel_dsouza

Thanks guys,

There were a few members who wanted to use C++ for our language next year, but I think we will stick with Java. But there is still the off-season to experiment.

I'd like to share with you an email my boss sent to me some time ago... this goes beyond robotics in our professional world of application development, but I think it would be good to know why some people use c++. I started with BASIC and then learned 6502 assembly... then finally came around to c++ here goes:

Programming language wars are about the same as religious wars ... everyone believes that their chosen favorite(s) are the only ones that make sense and I am certainly going to wade into this argument because at the end of the day any language that provably obeys the basic axioms of computation can all technically perform the exact same operations.

The above said,a couple of observations.


1. The world is built on-top of C (++) and so while other languages might be good at expressing some things "better",at the end of the day C and C++ seem to fill some magic middle ground between assembly and higher level languages. Every major app you use,every OS,even the C# run-time and compilers are all written in C(++). The same is true of every video codec,every piece of firmware (your fridge,phone,car,planes,etc...),your web browser and whatever UI control you are reading this in,etc...

2. As an illustration of the importance of C(++) every major change in hardware architecture first adopts and uses C-like languages and not others. Every GPU language (that has been adopted) is based on C,as is OpenCL,most HW description languages,etc...

3. In the real world,if you are going to implement an API that anyone else can use, it needs to be C. This is still the uniformly accepted standard for libraries and for good reason. Try using a C# library in C or Fortran. Now try a C library.

4. A few years ago I decided that we needed to move our Ui development to C# in the belief that some of the higher level programming concepts would help make development more robust by not having the same issues that C(++) has with manual memory management,etc... In practice (and some of this might be down to the fact that C(++) programmers and C# programmers tend to be at different skill levels on average) we have found that our Ui code has far more bugs is less stable and harder to debug than our C(++) code.

5. I am not an expert on the tools,but while there are good C# tools,it suffers at a disadvantage of only having been around for a fraction of the time of C(++). Whenever I am working on C# code I simply cannot believe that there is no compile and continue support,etc... Likewise you are not going to find the long history of proven tools for any language other than C in terms of profiling (yes some C# ones exist but they are quite frankly not at the same level),code verification,code documentation,distributed compilation,etc... etc...

[Todd]

*Ahem*

Beating a dead horse, that was dead a long time before FIRST robotics came around, but throwing in my two cents anyways.

In FIRST robotics, for the applications we develop, if you're concerned with efficiency, then it doesn't matter really at all whether you use labview, c++, or java.

All three are more than sufficiently tight to handle any application a FIRST robot utilizes, so long as it's written correctly.

So long as it's written correctly being the key statement.

I recommend using whatever language your team has the most experience with, or your mentors are most familiar with, or at the worst case, just the one you feel like you want to learn. Hell, take a year and write your robot code from that year in all three and pick one based on just your personal impressions if you want, but keep in mind, if it's slow, if your CPU is capped and your logic isn't getting executed on time, it's very, very, very likely that you're doing it wrong, rather than the language is to blame.

And if someone comes along and mentions something akin to 'all the best teams on Einstein seem to be using c++', don't forget that a lot of the teams on Einstein are either senior teams, who used to HAVE to develop in C, and so already had experience with that when it came to picking between c++ or labview, or have great mentors, and mentors who were probably born in the 50's-80's are much more likely to have C++ experience than java or labview experience, and mentors born from the 70's-80's are much more likely to have java experience on top of c++ experience, but still very little labview, just because it's relatively young and has historically had very specific market exposure.

In my work place we use C, C++, Ada, Java, Labview, and many others, and all are slightly better or more convenient for certain things, but what's most important in every application is that you use something your team is comfortable with, because the great deal of real world efficiency problems are caused because the developer that wrote the functionality didn't realize they could have made it faster if they implemented it slightly different, and are entirely the developers 'fault'.

[drakesword]

[quote=JesseK;1180245]My professional answer is: it depends. For generic software that doesn't use specific hardware implementations, the results aren't quite as intuitive since post-JIT processing will be at least as fast as C++ (i.e. after the same cycle has run a few times).

For hardware-based operations (OpenGL, OpenCV, custom hardware interfaces like radios) C++ is typically faster latency-wise, yet processing wise it's the same as Java. This is only due to the JNI code layer, and is implementation dependent (i.e. most of the time it isn't a noticeable difference unless you're shoving MB's of data through the code per second).[quote]

I agree with you on the first part. The second part I very muc disagree with the MB's of data. I work for a company that does e-discovery. Our main processing system is entirely java. It is able to process Almost 100gb per hour depending on the media. Just today we processed 1.2GB of mail storage in 45 seconds.

[JamesTerm]

Originally Posted by drakesword

I agree with you on the first part. The second part I very muc disagree with the MB's of data. I work for a company that does e-discovery. Our main processing system is entirely java. It is able to process Almost 100gb per hour depending on the media. Just today we processed 1.2GB of mail storage in 45 seconds.

How do you define processing? Any language can do simple tasks like data transfer with simple logic instructions... but its another thing where you really process the data that requires inner loops (e.g. 3d rendering, Audio/Video effects processing). With c++ you can use inline assembly and use intrinsics that explicitly choose what assembly instructions to use. You can for example do prefetching to ensure the P and V pipes are always full in an inner loop. Back in the eary 2000-2004ish... we also had to be responsible for scheduling instructions to ensure that we didn't get penalized for branch predictions failing, or put two divides too closely together by squeezing in some lightweight instructions like 'and', 'or', or even adds, or ensure we cycled through each mmx/sse instruction register (it was crazy). Around 2005-2008 Visual Studio mastered the intrinsics to have a competitive optimization of the instruction scheduling. Furthermore you can do things like this http://www.jaist.ac.jp/iscenter-new/...2_hh/vc235.htm. Really now... when you speak of real processing power, consider what language they used to land the Mars Curiosity Rover.