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).