4 ms·
Java runs about 2x slower than C++ for general CPU-bound stuff - (although it does use much more RAM). That sounds slow, but it's faster than most other langua
by jordanthoms 13y ago
Java runs about 2x slower than C++ for general CPU-bound stuff - (although it does use much more RAM). That sounds slow, but it's faster than most other languages out there. However, C++ does give you the ability to more easily use processor extensions (SSE, AVX, etc), which you can't use from Java AFAIK - which makes a big difference in performance for certain applications.
- acomjean 13y agoI think generally the libraries in Java help programmers use data structures that make the language seem faster (trees/hashes) . These structures exist in c++ but aren't as easy to use so aren't used as frequently. Those processors extensions will make mathy c++ code significantly faster. When I was on an ada project all the mathy code was written in c/c++ for speed. Pretty amazing the difference.
- cageface 13y agoWhat? C++ comes with robust trees & hashes via the STL, along with a pretty extensive library of algorithms that work on all the STL containers. And, unlike Java, C++ lets you pack value objects contiguously in memory, which can be a massive performance win due to better cache behavior/no pointer chasing.
- pjmlp 13y agoBeing discussed for Java 9 and already available on IBM J9 JVM. http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm...
- danieldk 13y agoAnd, unlike Java, C++ lets you pack value objects contiguously in memory, which can be a massive performance win due to better cache behavior/no pointer chasing. Certainly, and it is one of the features that I am often missing in Java. Rather than having an array of structs, you need to make n parallel arrays, where n is the number of struct fields. And sometimes such hacks are necessary to make things compact and fast. But I do understand why they don't provide value types. Say, that I am allocating an array of foobar_t. And foobar_t is defined in another library. If the author of the other library changes the layout of foobar_t, you get ABI breakage. This is what brought the whole PIMPL/d-pointer mess that is often necessary in C++ and to some extend C libraries.
- cageface 13y agoFor sure. Mixed value/reference semantics add a lot of complexity to C++.
- n3rd 13y agoIBM's Java 7 and 8 beta's already have this. It's called Packed Objects and it lets you have have high density data with no pointer chasing along with a much cleaner interface to off-heap languages like C/C++/C# and even languages like Fortran/COBOL etc. http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120 http://www.slideshare.net/mmitran/ibm-java-packed-objects-mm... and http://www.slideshare.net/ZeroTurnaround/ryan-sciampaconeruntimeinnovationnextgenninjahackingofthejvm-24613149 http://www.slideshare.net/ZeroTurnaround/ryan-sciampaconerun...
- swah 13y agoI do miss those in Go.
- judk 13y agoWhy can't Java new() use a plank to allocate objects in an array, just like C++ new() can?
- bradleyjg 13y agoI've read that you can call asm from java directly using jni (i.e. without a c wrapper) though I've never done it myself.
- frozenport 13y agoAnd nobody else has too. You use jni to call libraries somebody else made (opengl?), you don't plan your project around using jni.
- pjmlp 13y ago> C++ does give you the ability to more easily use processor extensions (SSE, AVX, etc), which you can't use from Java AFAIK C++ does not support any processor extensions, they are not defined anywhere in ANSI/ISO C++ language standard. They are a language extension not guaranteed to be available in all C++ compilers in the same form, thus not portable. Java can make use of processor extensions by writing a small Assembly snippet callable via JNI. Which is actually similar to what is required in C and C++ code, when writing "portable" code that should compile in various compilers.
- exDM69 13y ago> C++ does not support any processor extensions, they are not defined anywhere in ANSI/ISO C++ language standard. > They are a language extension not guaranteed to be available in all C++ compilers in the same form, thus not portable. This is true only if you're a language lawyer, but there's very little point to sticking pedantically to a language standard and not take advantage of the ubiqtuitous language extensions available. All the popular compilers out there support all the latest CPU instruction sets with the same syntax, etc. E.g. xmmintrin.h for SSE, avxintrin.h for AVX. > Java can make use of processor extensions by writing a small Assembly snippet callable via JNI. While this is true, you destroy any performance gain with the complexity of the JNI calling convention. It only pays off if you're doing a quite long stints of SSE/AVX/NEON code at once. Wrapping a small vector dot product or matrix multiplication in JNI will not yield any performance gain in practice. So while you can call native code via JNI, it's nowhere near as practical as writing it with intrinsics in C code. In addition, you get compiler optimizations to your native code if you use intrinsics from C, if you do it via JNI you lose all interprocedural optimization.