View Single Post
  #20   Spotlight this post!  
Unread 08-08-2012, 10:54 AM
JesseK's Avatar
JesseK JesseK is offline
Expert Flybot Crasher
FRC #1885 (ILITE)
Team Role: Mentor
 
Join Date: Mar 2007
Rookie Year: 2005
Location: Reston, VA
Posts: 4,072
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.
__________________

Drive Coach, 1885 (2007-present)
Latest Project: Codex-based FRC Comms in Java

2017: Scoring Model | COPR Rank Simulator
1885: YouTube Channel | CAD Library | GitHub