Re: C++ vs. Java (speed considerations only)
 

[quote=JesseK;1180245]My professional answer is: it depends. For generic software that doesn't use specific hardware implementations, the results aren't quite as intuitive since post-JIT processing will be at least as fast as C++ (i.e. after the same cycle has run a few times).

For hardware-based operations (OpenGL, OpenCV, custom hardware interfaces like radios) C++ is typically faster latency-wise, yet processing wise it's the same as Java. This is only due to the JNI code layer, and is implementation dependent (i.e. most of the time it isn't a noticeable difference unless you're shoving MB's of data through the code per second).[quote]

I agree with you on the first part. The second part I very muc disagree with the MB's of data. I work for a company that does e-discovery. Our main processing system is entirely java. It is able to process Almost 100gb per hour depending on the media. Just today we processed 1.2GB of mail storage in 45 seconds.

Re: C++ vs. Java (speed considerations only)
 

How do you define processing? Any language can do simple tasks like data transfer with simple logic instructions... but its another thing where you really process the data that requires inner loops (e.g. 3d rendering, Audio/Video effects processing). With c++ you can use inline assembly and use intrinsics that explicitly choose what assembly instructions to use. You can for example do prefetching to ensure the P and V pipes are always full in an inner loop. Back in the eary 2000-2004ish... we also had to be responsible for scheduling instructions to ensure that we didn't get penalized for branch predictions failing, or put two divides too closely together by squeezing in some lightweight instructions like 'and', 'or', or even adds, or ensure we cycled through each mmx/sse instruction register (it was crazy). Around 2005-2008 Visual Studio mastered the intrinsics to have a competitive optimization of the instruction scheduling. Furthermore you can do things like this http://www.jaist.ac.jp/iscenter-new/...2_hh/vc235.htm. Really now... when you speak of real processing power, consider what language they used to land the Mars Curiosity Rover. ;)

Re: C++ vs. Java (speed considerations only)
 

Think of it this way. We have a solid block of data, anywhere between 20 megs to however large your storage is. You do not know what is in this block of data. You need to determine the data type, extract any metadata (date created, who created it, ip addresses, email etc.), create an image of it if you can, and index all of the searchable text.

Now with java you can get that crazy as well, disassemble the byte code, examine your jumps, make your loops tighter etc. I personally have not gone that far but I assure you it is done all the time.

For vision processing, if you have the money, I would use a HDL frontend for speed, then maybe for lower level operations c++ or, one again if you have the money, GLSL (opengl shader language), java for higher level processing and finally for gui I would use either php or perl or bash. As you can tell this setup would require a whole computer, not suitable for FRC but it will work!

As far as the mars rover goes, I have no idea what they used. Do you have a reference? I would like to read it!

Every language has its advantages and disadvantages, there is no need to discount one over the other in a generalized environment. What it really comes down to is the developers experience with the language as well as the system(s) it is being developed for.

Personally my opinion is that the language doesn't matter, what does matter is the communication between the parties involved. If you have something that works well, something YOU can understand, something your COWORKERS can understand, and something that is optimized for your needs.

I will not get into personal gripes about each language. If you want to hear from my personal experiences with languages feel free to message me.

Re: C++ vs. Java (speed considerations only)
 

There's good sources referenced from this offsite discussion here

Moral of the story is mostly C code running on top of VxWorks. Not that that means C is better, still, but the source code was built on top of preexisting C firmware from earlier rovers.

Re: C++ vs. Java (speed considerations only)
 

This is a far different scenario from the one I had in mind (and quite honestly I'd conjecture that your mail processing system actually processes kB's of metadata rather than GB's of raw data in that amount of time unless it's a JBOD attached to a very expensive Xeon processor...):

1.) Start a live stream of 1080p @ 30Hz
2.) Render said stream via OpenGL on a Java display. Why OpenGL? The rendering of geometric overlays directly onto the video stream is much faster that Java's layered SWT, AWT, or Spring implementations.
3.) Decide that you want overlays AND image processing (line detection, dithering, target color enhancement, etc) from the same screen on the same viewport (matches a very common requirement from a demanding customer... heh...)
4.) Decide that all of this processing and rendering only has 1 server assigned to it (matches a common requirement in my world)

Depending on the underlying libraries, this may all be single-threaded -- i.e. that 16-core enterprise grade processor still might not be able to keep up since it's all asynchronous. If that's the case (as it often is with FOSS libraries for decoupling purposes) then multiple passthroughs of JNI alone in this scenario could cause more than 200ms of latency between the time a video frame hits the socket and the time the render hits the glass. One might say "oh, just re-write the libraries and JNI extensions yourself!", yet the actual amount of time (aka $) spent verifying the optimisation works perfectly far surpasses the minimal gain.

The latency is added to the image processing time -- poor implementations can see a 0.5 seconds of delay or more. The fastest I've ever seen (on optimised applications at work) is roughly 150ms from video frame generation to rendering on the glass. 500 ms doesn't seem like a big deal unless it's what stands in between a driver/pilot and a machine that costs 7 or 8 figures.

Again, the point here isn't that Java is slow or fast -- it's that a poorly constructed application is slow and Java's wrapping and hiding of the library implementations can compound that issue very easily.

Re: C++ vs. Java (speed considerations only)
 

Thanks JesseK you saved me from needing to respond. Nice to meet another programmer who works with HD video. (looking forward to supporting 1080p 60 someday). :)

For now... I just wanted to make sure Drakesword's benchmark fits in the "Any language can do simple tasks like data transfer with simple logic instructions" category. I want to keep a close eye on c# and java trends as I don't want to fall victim to a programmer who is behind the times. I tend to think of JAVA and C# as the 4th generation language... somewhere in between C and Scripting (e.g. 5th?).... where the further out you are the less direct control you have to the CPU. Visual Studio is really 2.5 with the intrinsics and inline assembly.

http://en.wikipedia.org/wiki/Program...ge_generations

Re: C++ vs. Java (speed considerations only)
 

This thread has gone pretty far from the original question. It is easy to construct situations where one tool is a better choice than another - that is why there are multiple tools available.

Does anyone have benchmark numbers for FRC?

Re: C++ vs. Java (speed considerations only)
 

Is it really? JessieK has identified processing vision as under what conditions, and now that vision can be processed by the driver station. I think it is on par with the original question.

FRC programming is no longer limited to the mpc5200 processor. ;)

Re: C++ vs. Java (speed considerations only)
 

Do we have numbers for that?

Re: C++ vs. Java (speed considerations only)
 

I can't share numbers that I have access to, but I can share this link:
http://www.youtube.com/watch?v=BfVLAe4_HPg

That is processing vision... not done in Java. ;)

Re: C++ vs. Java (speed considerations only)
 

Yeah, and a Corvette goes faster than a go-kart. Doesn't help much for a go-karting competition though.

Personally, there's not really a huge difference in execution speed between these two languages that can't be made up for with architecture. Process your vision on the laptop, run your control loops in separate threads, and handle user interactions in an event oriented fashion. This will result in code that is easier to build, understand, maintain, read, re-use, etc.

Re: C++ vs. Java (speed considerations only)
 

It should be noted OpenCV was not a solution we used to acheive the motion tracking shown in that video as it falls short in performance and requirements of our needs. While many aspects of the FRC code are in a "go-karting" competition (i.e. where there is not a noticeable need for inner loops). I believe processing vision fits into a Corvette category. As Tim (NewTek owner) once said to me when I was attempting to code the processing vision for Rebound Rumble. "Real video is a "dirty" world"... there is so MUCH room for new innovation for processing video to interpret what you see. There is no limit on how advanced this code can be. Imagine if you will, to have code that is robust enough to identify targets (AI technology) as well as a human driver, but with lighting fast speed. OpenCV allows people to work with existing solutions, but if you want to make new innovative solutions... you really need the right tool for the right job.

Thanks for the Corvette to go-kart comparison... I hope others can appreciate the hard work that we do and see the real power and innovation behind c++ with intrinsics.

Re: C++ vs. Java (speed considerations only)
 

Java has a lot more overhead than C++. For example, the JVM itself needs to use the same registers, caches and RAM that the Java Program would use. Also, a Java Object has at least 8 bytes of overhead (because of the instruction pointers). If you caste a type, you have to copy it since Java just does not read it as the type you are converting to. Take for example, if you have a 32 bit integer in memory in C++, you can caste it to read in as a short (16 bits). It will only read the first 16 bits. But since everything is an object in Java, the memory simply cannot be read as 16 bits. It needs to be copied.

Re: C++ vs. Java (speed considerations only)
 

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.

Re: C++ vs. Java (speed considerations only)
 

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.