Java versus C++
 

Hey everyone. I'm fairly new to FRC programming (and programming in general, for that matter).

I am wondering if anyone has ran any benchmarks on robot code execution with Java and C/C++. Java compiles to bytecode which is then executed by the virtual machine at runtime, correct? While C/C++ compiles into machine code. Is there a noticeable performance difference between the two languages?

Also, when I uploaded code to the cRIO, I remember something about LabView in the console window. Was a LabView 'layer' created for communication with the hardware; what is going on there?

I am the lead developer for this season and our previous developers did not explain much. This past season was the first year using Java for our team, so I want to make an educated decision on language choice.

On the other hand, if there are no performance differences, it's just a syntax preference then.

Thanks,
Nick DiRienzo

Re: Java versus C++
 

My personal preference is Java. Our team has decided it's not only a great language to use/learn, but a much more marketable skill to advertise.

That being said, there are countless threads like yours on CD. A quick search would have revealed these (to name a few).

http://www.chiefdelphi.com/forums/showthread.php?t=86026&highlight=programming+langu ages

http://www.chiefdelphi.com/forums/showthread.php?t=85982&highlight=programming+langu ages

Re: Java versus C++
 

I too am interested in the replies you get, but...

If you are facing a learning curve because you aren't inheriting much experience from previous years' teams; I suspect that folks are going to emphasize that familiarity with the language you use far outweighs any speed differences.

Until you require the computer/software combination to do some complex operation(s) faster than the computer can execute your instructions in a "slow" language, you can ignore any speed differences (Yes - I know there are 2nd and 3rd order effects that can become important; but let's focus on the 1st order topic(s) before diving into the weeds).

To say it another way, the language's efficiency is sort of like a rope used to cross ditches. If you need to cross a collection of ditches and the widest of them requires a 10 foot rope; if you have a 15 foot rope, then you are in good shape. Having a 30 foot rope doesn't get you into any "better" shape.

I think you can guarantee that you are facing a learning curve. Do you also plan to cross any 20 foot ditches? If not, pick the language that is easiest to understand and easiest to use to get you across the metaphorical 10 foot ditches.

Blake

Re: Java versus C++
 

My original post did seem like I learned nothing this past year. Which is not true. I did learn how to program for FRC, but we never got our camera working (due to frame rate issues and what not). When I said 'new', I mean less than two years. Then again, I am comparing myself to programming veterans who have been doing it for 30+ years, or even the students who have been in their team's programming group for more than one year.

I am fairly comfortable in Java. I have taken an Intro to Java class at school (was quite boring) and now am in AP CS A. I also taught myself using Blue Pelican Java during the build season, up until about week 4 - which is when I started working with the prior leads and learning somewhat.

So there will be a slight learning curve for some things, but for the most part I will be fine.

Meh, I guess I could just write it originally in Java (what I am comfortable with) then rewrite for C++. And play around for myself.

@GGCO: A lot of the replies are just personal preference of a language. I understand that people use what they are most comfortable with. I was wondering if there are any proven gains or disadvantages to one language for the system we work with. Yes, there are some posts saying Java is not as good. But the supporting evidence was a matter of opinion. Thanks for the links though; more teams used Java than I thought.

Re: Java versus C++
 

All three languages have plenty of teams using them.

If you have a specific task you'd like to compare, I suspect you can get some numbers run. In general, all calls to do I/O and vision are neutral since the vision code is just a wrapper around native binary code, and the I/O is wrapped around the FPGA which is programmed in LV by the way. Differences will start to show up when/if most of the code being executed is written by you or your team. If you decide to get the pixels from an image and index through them looking for patterns, you'll notice a difference between the compiled and bytecode languages. Still, I think you'll find that reasonably written code will run just fine in any of the languages. So yes, it is a matter of preference, experience, and goals.

Greg McKaskle

Re: Java versus C++
 

Alright, thank you. That cleared things up for me. Our mentor and I will probably run some individual tests anyway.

Re: Java versus C++
 

I'm not an expert in this, but I have repeatedly heard that Java runs slow, which apparently is one of its big downfalls. Would this apply here? It seems people are saying all 3 languages run just fine in our case. So maybe what I've heard is a general and bias statement.





Personally I'm a big LabVIEW fan.... **hint hint wink *cough* wink wink** :yikes:

Re: Java versus C++
 

Do you mean Java runs slow in general, like as a desktop application, or in an FRC system? And I haven't tried LabVIEW, I'm not too attracted to it, but I'll probably try it out this year.

Re: Java versus C++
 

More like Java runs slow in general on a desktop application.

I would give LabVIEW a chance and see if you like it. It's a little unconventional so some people are hesitant, but I think it has a lot of benefits. These include the intuitiveness of graphical programming, its excellent debugging tools, and easy learning curve (in my experience and as reported by many people). Here's a link that I just found recently about LabVIEW, it's very good. http://www.ni.com/labview/whatis/graphical-programming/

Re: Java versus C++
 

There are heavily computation-intensive exceptions but most desktop applications in general are not CPU bound and therefore they run the same whether written in Java or C++.

Re: Java versus C++
 

Ok, thanks for clearing that up. I've just always heard Java is slow.

Re: Java versus C++
 

I will tell you that it is easier to code with Java. It can be a pain in the $@#$@#$@# to fix a memory leak in C++ because of a misused pointer... But personally I love C++

Re: Java versus C++
 

From my experience mentoring teams using both C++ & Java, I have not seen any kind of performance issues. If you already have experience in Java, go with that.

I have been posting some simple Java programming tips on my blog. Feel free to contact me if you have any questions.

Re: Java versus C++
 

Well said Roger. Consider this advice when looking at your options, it is a very good point. It always comes up in discussions like this.

Re: Java versus C++
 

The statement "Java is slow" has been around a long time. And at one point, it was true. When Java first came out, it was slower than other languages like C. But there have been a TON of optimizations over the past 10+ years that simply make that statement not true in most cases. In fact, due in a large part to memory management, C++ can be slower than Java (Pointers are time consuming to handle for C++, malloc sucks, performance wise. You don't have those problems with Java).

for a young programmer like yourself, you have a couple of options.

1. You can go with what you already know (Java) - that will be the easiest and surest way of producing quality code for your team. The additional benefit of extra exposure to the language through the team will also help you with your classwork. Looking towards the future (aka college), you'll most likely being using Java for a lot. I know my old school has switched many classes over to Java in the past 6 years or so. Having a deeper understanding of that language now will only help you with your classwork in the future.

2. You could go with a different language for a broader experience. While this will probably be more difficult and time consuming for you, most programming jobs generally involve multiple languages - and having a broad exposure will help in the long run. For instance, right now my job requires me to know HTML, Groovy, JSP, Java, SQL, PL/SQL, and C (i think that's everything...). Additionally, learning multiple programming languages helps you to understand the basics of how languages, in general, work. You don't need to deal with pointers in Java, but working with them in C will dramatically increase your understanding of how computers work.

One last thing to consider: What support do you have? Do you have any programming mentors? do they have a preferred language?

Our team ended up going with Java for two reasons - first, the students were familiar with it from classes at school. Second, the mentors knew it better than C++ and could help them succeed better with it.

Another team we work closely with made a different decision. They went with Labview (i think), and ran into some big problems late in the season that their mentors (who were experts in Java) couldn't help much with. Having a safety net of knowledgeable people close at hand isn't something to ignore.

Re: Java versus C++
 

Can you please provide an authoritative reference, or experimental data, to support the claims that:

1) properly-written code using pointers in C++ runs slower than functionally equivalent code written in Java

and

2) properly-written code using malloc in C++ runs slower than functionally equivalent code written in Java

Thanks!

Re: Java versus C++
 

My understanding is that the JVM that's been ported to the cRIO is the squawk VM, which is not a real-time VM. While you might have your own opinions about the importance of a system being real-time or not, that was something that played into our thought process.

Re: Java versus C++
 

Could someone knowledgeable about this please weigh in on this?

It was my understanding (perhaps incorrect) that the 2010 FRC Framework for Java was written in such a way to use the underlying vxWorks RTOS to handle the realtime aspects, thus mitigating the lack of true built-in realtime support in the VM. Not?

Re: Java versus C++
 

Ah, but contemporary idiomatic C++ should almost never require the use raw pointers :)

All of the calls to the vision API, FPGA/peripherals, watchdog, semaphores, etc., are simply wrappers to the underlying equivalent system primitives (fast VxWorks and/or FPGA code). As for a "real-time VM", the Real Time Specification for Java (RTSJ) that is implemented by Sun's Java Real-Time System and a few other libraries (but not Squawk) just means that performance is deterministically bounded, not necessarily any faster. In particular, it enforces that memory management and multi-threaded execution/scheduling always happens in the same way.

All of this really only matters if you are in a hard-real time, safety-critical situation. If for example you are building an airbag deployment system, you have a few milliseconds to react to a crash. In this scenario you can't afford the one in a million chance that your code is busy garbage collecting and thus blocking the execution of the real-time critical bit. In a FIRST robot, missing a real-time deadline by a little bit is (a) not going to be life threatening and (b) not going to occur often at all anyway. The worst possible scenario would be a fast software control loop ending up with a little bit more jitter (variation in time between calls).

Re: Java versus C++
 

Can someone explain why JVN is squawking in real-time? I thought John VNeun was more of a mechanical guy.



I'm sorry, but I can't help but misread JVM as JVN, at least in an FRC context.

Re: Java versus C++
 

While I'm pretty sure I can build a car that operates more slowly than a bike, or find a turtle that outruns a hare, I'd caution against drawing general conclusions from such benchmarks.

One of the fundamental underpinnings of computer science is examining a problem and determining the inherent complexity, looking at a solution and determining the way it scales based on it's inputs, and getting beyond qualitative terms such as fast and slow.

You have choices as to which tools to use, and I wouldn't personally base the decision on runtime performance. Instead look what will support agility, productivity, and reliability. Also consider what enables your team to learn new things and to pass the knowledge on to the next generation of your team.

Greg McKaskle

Re: Java versus C++
 

Aware me of this programmer lingo... As I said before, I am self taught so I don't have all the lingo down. I just do it;) If you know what I mean, I don't name what I do.

Re: Java versus C++
 

Just Google the phrase "C++ idioms".

Re: Java versus C++
 

As far as I know, Squawk (or any other J2ME implementation I've heard about) doesn't support JIT, so cRIO-java is stuck in interpreted mode. This likely ends up slowing down any particularly intensive logic-only calculations due to the lack of native code execution. One of the biggest speed boosts in desktop Java (and some other loosely Java-based systems like Android) are JIT-related. For some context, the JIT support added to Android in the latest release gave it around a 50% speed boost.

Overall, though, the cRIO is powerful enough to accommodate basically anything we'll need to do with our bots. Maybe Vision-related stuff would suffer a slowdown, but for the most part that's offloaded to (prebuilt) native libraries.

Having used Java this year, I can say that there were a few performance-related issues, but a lot of them were due to us having a pretty large number of simultaneous threads running (one being unused vision processing which happily ate away at our CPU time). In the end, a quick sweep through some of the unused code cleared it up. And it definitely won't stop us from using Java again this year - the issues we had there were nothing compared to our trouble with LabVIEW and C++ in '09.

Re: Java versus C++
 

Actually, Squawk does indeed support JIT (see this).