C++ vs. Java (speed considerations only)

[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!