3 ms·
I wonder what a fair benchmark test would look like. Would it boil down to an argument of C++ vs Java for floating point operations?
by thesnark 15y ago
I wonder what a fair benchmark test would look like. Would it boil down to an argument of C++ vs Java for floating point operations?
- _delirium 15y agoFor computation-heavy apps, probably. For others it'd probably come down to something at the framework level, such as the efficiency of the OpenGL bindings or event/callback infrastructure.
- th0ma5 15y agoI attended various talks by Ben & Casey at Eyeo, and they mentioned the new 2.0 series of Processing including a lot of great new OpenGL improvements by Andres and others, and that the new GL framework shows performance near OF. In another talk, Ben mentioned prototyping something in Processing, and then porting it to OF for speed. I'd say that in general we'll see this all matter less and less, what with more GPU type stuff happening, and with the advancements in the JIT and code translation in general.
- mgunes 15y agoThe third alpha release for the 2.0 series they talked about Eyeo is out: http://code.google.com/p/processing/downloads/list http://code.google.com/p/processing/downloads/list , http://code.google.com/p/processing/source/browse/trunk/processing/build/shared/revisions.txt http://code.google.com/p/processing/source/browse/trunk/proc...
- zemo 15y agoeven if Processing 2.0 does make perfect use of the GPU that distinction only covers the render phase. Calculating collisions for a large number of objects will still be significantly faster in C++. So like nearly every situation in software, it all depends what you're trying to do.
- thedeuce 15y agojava folks have been hanging by the future awesomeness of JIT for quite a long time now...yet people still go to C++ for performance