Is C++ actually better for autonomous?

I have heard from some people here on CD that C++ is better than Java in terms of autonomous routines. I’m inclined to believe this solely on the basis that C++ is simply a better language than Java in my opinion, but is there anything that “objectively” makes it better at autonomous?

Objectively nothing unless you desperately need a 2% performance uplift to not loop overrun your Rio, I would argue Java is better as in terms of community libraries it has far greater support in FRC, the true case for cpp being much better is if you use ROS like the team 900 and then get access to a massive library of industrial autonomous navigation systems.


No. For the vast majority of FRC teams, there is no meaningful speed difference in using any language (Java, C++, Python, LabView). For the vast majority of FRC teams, there is no meaningful library usage difference between any text language (Java, C++, Python).

Comparing languages for FRC is like comparing a Toyota Camry to a Honda Accord. Yes, you could start comparing engines. “Oh, the base model Accord has 20 more horsepower than the hybrid Camry. But look, the sport Accord and base Camry are only off by 1 horsepower but if I upgrade to a V6 Camry, I’ll get 100 more horsepower” but why. I ask again why? It’s a Camry and an Accord. Buy whatever, It doesn’t matter.


The best language for autonomy is the one your team is most equipped to use. There is probably only 1% of teams that there isn’t an obvious choice of language based on mentor support, reliance on the community for help, and school support (classes offered in a specific language). It doesn’t make sense to sacrifice all of these other resources for a little more possible performance. You’re most likely not going to get to a place where performance actually matters or couldn’t be gained in other ways.


I’ve never seen any benchmarks for the RIO specifically, but in general microbenchmarks, C++ is typically ~2x as fast as Java (ofc it varies greatly but that’s a good first approximation). So my assumption is the performance difference is not exactly minor. Is there any data from a team that quantifies this for the RIO specifically? Also, due to the lack of garbage collection, C++'s performance is more predictable.

But you’re right that for most teams these differences are not enough to make a difference. C++ wouldn’t magically make your robot faster.

1 Like

thus I’m assuming that it is not possible to write robot code in both C++ and Java simultaneously?

It makes no difference unless you’re one of the very rare teams who are changing your Rio loop rate, in which case you might as well offload all your compute to a coprocessor and none of it matters. I will say python should not be used on Rio 1 as they’re already near their limit with just the Linux kernel running in terms of memory and pythons inefficiencies are a major issue even when most things still just wrapper a cpp system, but on the Rio 2 it’s not an issue at all.

1 Like

I’m almost certain it’s possible to write in both of you really put time and effort into it.
To clarify: My above point assumes the goal of trying to maximize preformance of the robot through least effort. If ones school teaches java, and the team knows java, 99% of people will benefit from learning something new with java as opposed to trying to learn C++ for that specific gain. However, if your goals are different, a different pathway might be appropriate (just make sure everyone agrees what those goals are).

1 Like

I totally agree. It’s a lot more friendly for new students who came from our LabVIEW FTC team or elsewhere to learn a fundamentally simple language than all the nuances of C++. However if it’s possible to be able to have C++ and Java code combined, that means that any part of the code that would benefit in terms of maintainability, raw performance, or any nuances of an individual language from one or the other, could be written in that language.

Perhaps I’ll ask this question separately sometime later.

1 Like

It is absolutely possible to combine the languages by writing JNI, that’s how Java is able to talk to the FPGA via the wpilib HAL, and most if not all of the vendors write their Java libraries as a mix of Java and a JNI layer that interacts with C/C++.

For individual teams, if you’re good enough at C/C++ to write JNI and have an actual (not imagined, as in most cases) need for performance, I would have a hard time understanding why you wouldn’t just do the whole thing in C++.

1 Like

I didn’t know about what a typical benchmark speed difference would be, but a few years ago I wrote some simple, identical programs in both C/C++ and in Java, and ran them on a Roborio to measure their speeds – and I also got a speed difference of about 2x. If I remember right, depending on what the program did, the C/C++ version was 1.6 to 2.5 times faster than the Java version on the Roborio. These were simple “count to a billion” type programs, with a little extra code to prevent optimizing out any of the counting (to keep them honest). I think I saw the exact same speed difference factor when I compiled and ran the programs on a Linux laptop, too (both versions ran faster on the laptop than on the Roborio, but the speed difference factor was the same).


The best language is the one that is easiest for you.

Java is very easy for most people to get up and running. There are tons of examples and code available online. Therefore, for most people, it is the best.

Most people state on here correctly that the minor performance increase you get from switching to C++ is not “worth it” and you can spend the time optimizing your existing Java code to run faster


QFT. Time saved during development (minutes to hours) will always outweigh time saved during deployment (milliseconds to seconds). Better use of development time opens the door for more iteration and better code regardless of the language used.


There’s a lot of “language holy wars” that go on in various forums throughout the world.

Some have merit - different languages bring different features to the table, and make certain tasks harder or easier.

However, what’s important to keep in mind, especially as a student: Coding is the tool, not the end unto itself.

Software has two jobs in FRC:

  1. Make the robot score points
  2. Teach students something about the world around them.

And it only has to do that for three months.

As long as you hit both of these well, everything else is “small potatoes”.

Re-emphasizing Kiera and Chad. The BIG lever is “what gets you from zero to functional robot fastest?”. Everything else I can think of pales in comparison.


I strongly prefer LabView because I actually understand what I’m looking at and can effectively trace problems, so when we were first starting and had no programming mentors, we used LabView. We haven’t used it in over ten years because none of my programming mentors or students want to.

When we had a programming mentor who was great with C++, we used C++. When he left and we got a programming mentor who was much more comfortable with JAVA, we switched to JAVA.

Robot functionality depends way more on what your humans can do than on what tiny optimizations they could hypothetically do if they knew how to do what they don’t know how to do.


It is important to remember that much of the workload is waiting on the CAN bus to get motor and encoder status. That is the long pole - no language will change that. We had an issue with trajectory generation taking too long, but multithreading the calculation fixed that.

1 Like

This. I’d guess to say that 99.9% of FRC loop overruns that happen in Java would also happen in C++. The real slow stuff, I/O, whether to motors or to disk, is going to be the same speed no matter what. The only times where you may be able to prevent loop overruns by using C++ are if you’re doing massive calculations that aren’t waiting on anything.

1 Like

It can be worth switching to C++ to avoid otherwise-unavoidable (on ARM32 at least…) timing jitter due to the JVM GC not being pausable.

Basically anything else is a loss; computational speed on the RIO should not be your primary chokepoint since the RIO processor is a potato and you should only be doing stuff that’s nearly-free on it anyway. Anything else should go on a coprocessor.


:100:, it’s the jitter/nondeterminism that hurt the most when using Java, not raw loop time differences

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.