C++ vs. Java (speed considerations only)

[Todd]

Originally Posted by davidthefat

Java has a lot more overhead than C++.

I don't think the argument is that Java or Labview has less overhead than C++, rather that in (nearly all) applications that are relevant at all to FIRST, the overhead is simply irrelevant.

With the singular possible exception of vision processing, where the argument could be made that realtime performance of a control system based on vision processing is not necessarily drastically impacted by the performance gains presented by vision processing software, it just doesn't matter.

I'd add PID loops to the list, but in most FIRST applications the effectiveness of your PID loop is probably bottlenecked before you encounter processing speed issues, either by I/O or low feedback resolution or frequency.

The likelihood that performance issues will be introduced by a team simply because they aren't as familiar with a different language set drastically outweigh the actual performance differences between the three languages, bringing me back to if performance is what you care about, then stick to the language your team feels most comfortable with, and don't forget that you can realistically (and simply) export almost any processing that can deal with ethernet latency and bandwidth restrictions to the dashboard, and then out to be processed on any language, with any framework, with almost any hardware you want on your driver station machine.

That said, there's a reason why all three are used widely in different industries, and I strongly encourage anyone who's interested to learn all three and make their own decisions.

[davidthefat]

Originally Posted by Todd

I don't think the argument is that Java or Labview has less overhead than C++, rather that in (nearly all) applications that are relevant at all to FIRST, the overhead is simply irrelevant.

I agree. The overhead creates milliseconds of delay; it's insignificant compared to the sensor delay. But I was answering in terms of pure Java vs C++. I don't want people to think what's relevant to robotics is always relevant to general programming.

[apalrd]

Originally Posted by davidthefat

The overhead creates milliseconds of delay

In "normal" embedded control system programming, a whole millisecond is a LOT of delay.

What's relevant or important in general programming isn't always the same in robotics/control systems, but a few things that aren't that important in general programming are REALLY important in embedded control system programming. Milliseconds is one of them.

(I seriously don't think Java overhead creates milliseconds of delay for code the size of FRC code. LabVIEW...)

[Todd]

Originally Posted by apalrd

In "normal" embedded control system programming, a whole millisecond is a LOT of delay.

What's relevant or important in general programming isn't always the same in robotics/control systems, but a few things that aren't that important in general programming are REALLY important in embedded control system programming. Milliseconds is one of them.

(I seriously don't think Java overhead creates milliseconds of delay for code the size of FRC code. LabVIEW...)

Properly written Java and Labview code do not create milliseconds of delay in our use case. Period. The only thing with the potential to generate that kind of delay are differences in the WPILib implementations for each language, which are both editable, and completely unrelated to the way the language actually works.

[Greg McKaskle]

NIWeek just concluded, and if you haven't heard about it, it is a large developer conference focussing on NI products including LabVIEW. It is similar to the Apple, MS, Java, and Google conferences, and similar in size, but in embraces more of engineering than just SW. Attendees are a combination of industry developers and integrators, and all of them presumably care about efficiency.

So why don't all of them use C++? Why not assembly? Or heck, why not just build a circuit and get rid of that dinky computer altogether?

Glad you asked. At the end of the day, people are rewarded for solving problems. Sometimes the solution to the problem is well understood and the problem is actually reducing the cost or size of the package. Other times, the problem is not that well understood, or the size and cost of the package are less of a factor because you first need to show that people want this problem solved and are willing to pay for it. Optimizing a product people don't want is a waste of money and time. The overall cost factors of time, money, and expertise, typically select out the tools that make sense to use.

More SW specific:
If you have to write a given amount of code and you will not run out of CPU, you will tend to choose tools and languages that enable you to write that code more quickly or more bug-free. But if you have a limited CPU and your goal is to cram mucho-code into it, you will go for tools that produce smaller or faster execution even if it takes longer and costs more to write the code. Since no single language is optimal in all these areas, professional programming teams tend to know more than one and not be quite so dogmatic about it.

I'm tempted to highlight some of the NIWeek apps that demonstrate how the developers chose different tools for different tasks and integrated them to solve the real-world problem, but since FRC really is a microcosm of industry and academia, I'll use FRC instead.

The cRIO controller has an FPGA (reconfigurable-circuit), a realtime CPU/OS, and a non-realtime but more powerful OS/CPU in the DS. There are many ways to use this equipment, but note that tasks such as PWM generation and pulse-train decoding are done in the FPGA. You could do it other ways, but can you decode 40,000 encoder pulses on multiple channels as well using the CPU and any of the languages? No. Tasks like these benefit from dedicated HW. If the digital module being used were swapped out, it could easily go a hundred times faster.

Vision processing whether done in OpenCV or NI-Vision is written in rather sophisticated C++. If running on multicore computers, it will take advantage of it, and if the cores support SSE or MMX or other vector instructions, the code will take advantage of it. True, it could be done in the FPGA, but you will chew it up very quickly and it is better utilized for other tasks. The vision algorithms can be written in all three languages, and they will all three be slower than the professional libraries. Just using C doesn't necessarily mean it is fast. It is true that C/C++ is a good tool to use to write highly efficient code, but simply using C/C++ doesn't make it highly efficient. Algorithm selection and attention to data access is far more important. The C/C++ compiler and others as well only has so much optimization magic to apply.

So the teams already have some efficient resources written in the appropriate language at their disposal and they have bridges to those tools in all three languages. You have a spectrum of resources to choose from in SW, just as in motors and structural materials. Oh, and you have deadlines too. I still recommend you look at all these factors when you pick your programming language.

OK, I can't resist a few NIWeek highlights:
Entertaining robots -- Intel at NIWeek, alternate Intel ProVideo, and KUKA

Keynote Highlights in particular the Olin Robotic Sailboat, the Japanese KURAMA II which uses the same controller as FRC, and Optimedica returned with another inspiring device and presentation. If you want to know more about why LV is what it is, Jeff Kodosky's Core Principles of LabVIEW will give insight. Cold fusion, now known as the Anamolous Heat Effect was also a part of both the expo and the keynote.

TLDR (my first ever):
Theoretical efficiency of the code after it is written and debugged is not going to help you much if you can't get it finished. Pick the tools that make your team successful.

Greg McKaskle

[daniel_dsouza]

Wow, I must commend all of you. You have more than answered my question.

I probably should have stated in the beginning that I was primarily talking about code on the cRIO that reads inputs, and sets outputs. (not primarily vision)

What seems to be the overall consensus is that a team can have greater efficiency by sticking with the language that they know best (as opposed to switching to a supposedly "better" language). Why? The overhead in FRC applications is mainly in the stock software/hardware, compared to language differences.

For non FRC applications, the language used depends on what works best for that platform/task.

Thanks everyone!