Go to Post Yes, it can. You'll have to ask the lawyers around here whether it's legal or not. - Kevin Watson [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Events   CD-Media   CD-Spy   FRC-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 08-07-2012, 09:39 PM
drakesword drakesword is offline
Registered User
AKA: Bryant
FRC #0346 (Robohawks)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2004
Location: USA
Posts: 200
drakesword is on a distinguished road
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.
  #17   Spotlight this post!  
Unread 08-07-2012, 10:49 PM
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 228
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by drakesword View Post
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.
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.
  #18   Spotlight this post!  
Unread 08-08-2012, 08:56 AM
drakesword drakesword is offline
Registered User
AKA: Bryant
FRC #0346 (Robohawks)
Team Role: Mentor
 
Join Date: Jan 2006
Rookie Year: 2004
Location: USA
Posts: 200
drakesword is on a distinguished road
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by JamesTerm View Post
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.

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.
  #19   Spotlight this post!  
Unread 08-08-2012, 09:03 AM
Todd's Avatar
Todd Todd is online now
Software Engineer
FRC #1071 (Team Max)
Team Role: Mentor
 
Join Date: Feb 2005
Rookie Year: 2004
Location: Connecticut, Wolcott
Posts: 51
Todd is just really niceTodd is just really niceTodd is just really niceTodd is just really niceTodd is just really nice
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by drakesword View Post
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!
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.
  #20   Spotlight this post!  
Unread 08-08-2012, 09:54 AM
JesseK's Avatar
JesseK JesseK is offline
Flybotix Fanatic
FRC #1885 (iLITE)
Team Role: Mentor
 
Join Date: Mar 2007
Rookie Year: 2005
Location: Reston, VA
Posts: 2,772
JesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond repute
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by drakesword View Post
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.
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.
__________________
Healthy people ó who know how to deal with disappointment, who have given up on the idea of magic bullets, who donít watch TV indiscriminately [are] fulfilled by things that donít cost money
...
Iím talking about the real fundamentals of being an empowered, self-directed human being. Creativity. Curiosity. Resilience to distraction. Patience with others. And to make these all possible: self-reliance ó an unswerving willingness to take responsibility for your life...

How to Make Trillions of Dollars

Want to be a better cook? Do 5 recipes from Plenty on 5 weeknights after work. Eat the leftovers for lunch.
  #21   Spotlight this post!  
Unread 08-08-2012, 10:39 AM
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 228
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by JesseK View Post
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...):
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
  #22   Spotlight this post!  
Unread 08-08-2012, 11:19 AM
EricVanWyk EricVanWyk is offline
Registered User
no team
 
Join Date: Jan 2007
Rookie Year: 2000
Location: Boston
Posts: 1,596
EricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond repute
Send a message via AIM to EricVanWyk
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?
  #23   Spotlight this post!  
Unread 08-08-2012, 11:26 AM
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 228
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by EricVanWyk View Post
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.
Quote:
Originally Posted by daniel_dsouza View Post
Hello CD,
I'm told that code written in C++ will run faster than Java code. My question is, how much faster, and under what conditions will it be noticeable?
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.
  #24   Spotlight this post!  
Unread 08-08-2012, 11:40 AM
EricVanWyk EricVanWyk is offline
Registered User
no team
 
Join Date: Jan 2007
Rookie Year: 2000
Location: Boston
Posts: 1,596
EricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond repute
Send a message via AIM to EricVanWyk
Re: C++ vs. Java (speed considerations only)

Do we have numbers for that?
  #25   Spotlight this post!  
Unread 08-08-2012, 12:24 PM
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 228
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by EricVanWyk View Post
Do we have numbers for that?
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.
  #26   Spotlight this post!  
Unread 08-08-2012, 12:43 PM
Tom Bottiglieri Tom Bottiglieri is offline
Custom User Title
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 2,960
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Send a message via AIM to Tom Bottiglieri
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by JamesTerm View Post
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.
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.

Last edited by Tom Bottiglieri : 08-08-2012 at 12:45 PM.
  #27   Spotlight this post!  
Unread 08-08-2012, 01:13 PM
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 228
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by Tom Bottiglieri View Post
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.
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.
  #28   Spotlight this post!  
Unread 08-11-2012, 09:53 PM
davidthefat davidthefat is offline
Alumni
AKA: David Yoon
FRC #0589 (Falkons)
Team Role: Alumni
 
Join Date: Jan 2011
Rookie Year: 2010
Location: California
Posts: 792
davidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud of
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.
__________________
Do not say what can or cannot be done, but, instead, say what must be done for the task at hand must be accomplished.
  #29   Spotlight this post!  
Unread 08-12-2012, 12:59 AM
Todd's Avatar
Todd Todd is online now
Software Engineer
FRC #1071 (Team Max)
Team Role: Mentor
 
Join Date: Feb 2005
Rookie Year: 2004
Location: Connecticut, Wolcott
Posts: 51
Todd is just really niceTodd is just really niceTodd is just really niceTodd is just really niceTodd is just really nice
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by davidthefat View Post
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.
  #30   Spotlight this post!  
Unread 08-12-2012, 06:51 AM
davidthefat davidthefat is offline
Alumni
AKA: David Yoon
FRC #0589 (Falkons)
Team Role: Alumni
 
Join Date: Jan 2011
Rookie Year: 2010
Location: California
Posts: 792
davidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud of
Re: C++ vs. Java (speed considerations only)

Quote:
Originally Posted by Todd View Post
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.
__________________
Do not say what can or cannot be done, but, instead, say what must be done for the task at hand must be accomplished.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 07:42 PM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi