7 ms·
I'm fairly certain Java and C++ have comparable speeds, and I think in someways Java's faster.
by dkuntz2 13y ago
I'm fairly certain Java and C++ have comparable speeds, and I think in someways Java's faster.
- jordanthoms 13y agoJava 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.
- Guvante 13y agoThe lack of non-heap objects makes you bend backwards more than you should though.
- n3rd 13y agoIf by "lack of", you mean "4 choices": DirectByteBuffers (Azul/IBM/OpenJDK/Oracle etc) Packed Objects (IBM) Real-time Java (Azul/IBM) Unsafe (Azul/Oracle/IBM/OpenJDK etc)
- Aldo_MX 13y agoCan you please provide real benchmarks?
- axaxs 13y agoJava is not as fast or faster than C(++). The assertion always makes me cringe. I won't say Java is slow(though the startup time is annoying for some tasks), as it does perform better than many languages. But how does it make sense to you that a platform written in C can produce results faster than C is capable of?
- 0x0 13y agoWhat language do you think your favorite C compiler is written in? Now compare that C compiler to the jvm compiler, which has the benefit of using detailed information about the exact system configuration and other runtime behaviours during its compilation phases. Which one has the advantage?
- axaxs 13y agoC to both of your questions. The JVM compiler compiles for the JVM, which is written in C. So, how again can something written in C perform faster than...something written in C? I'm not claiming that line by line transcription, C will always perform each particular operation faster than Java. But the fact that you could write the entire JVM in C means that you could recreate the exact platform and replicate the results. Is that sane? No, not really. Comparing languages is typically silly, as it mostly boils down to implementation. If you -really- intend to compare speeds of languages, it would necessitate writing the best possible code in both languages, which may or may not even resemble each other. Under those circumstances, Java is not capable of beating C. Ever. I don't understand why this is an argument anymore, it doesn't really even make much sense...unless my definition of 'language speed' is unusual.
- bcoates 13y agoBoth the JVM and a C compiler produce native machine code that is executed by the processor directly. Neither is an interpreter in the classic sense[1]. It doesn't matter what language they're written in -- you could write C compiler or a JVM in PHP (assuming it can make the syscalls to load object code at runtime). No matter how awful the performance of the PHP runtime is, it would not prevent the C or Java program executed from being fast (in the long run). Because the eventual target is native code, the only limit on performance[2] is what program transformations the compiler is willing to perform. This is limited by how much information the compiler has, and what sort of transformations are valid in the language. For the first, it's about a wash. Java has a mix of 'safety' features that may obligate inserting checks at runtime that C would assume away, but it also forbids a lot of things that a C compiler would have to accept that limit the ability to optimize programs. In particular, a C compiler has to make a lot of pessimistic assumptions about what all those pointers are doing and what happens to memory across an external function call. JVMs have a solid advantage in the second -- it performs the equivalent of profile guided optimization at runtime against real usage patterns, something that AFAIK no C compiler even attempts... and the runtime tooling needed to turn C into something you could JIT-optimize would result in something I don't think most C programmers would recognize. A third issue is GC, which is on by default in Java-land and off by default in C: if your program is under very little memory stress and has very complex memory access patterns, the overhead of malloc()/free() is going to be huge compared to the cost of running the occasional GC. But, if your program is under strong memory stress and the logic to determine when to malloc() and when to free() is trivial, GC overhead will be a serious issue. None of this means a given Java environment is faster than a given C environment but there's not really anything you could assume from first principles that makes one faster than the other. Neither reaches the ultimate "speed of light" of computation that is self-modifying hand-tuned machine code favored by all Real Programmers[3]. But the real bottom line for performance is which language has faster library implementations, and which has idioms that programmers actually use that produce faster or slower code. Those considerations are probably going to be way more important than the hypothetical top speed of a perfect program made by cycle-counting weenies. It's also the sort of thing you'd have to run actual experiments at large scale to answer. [1] the JVM might interpret Java bytecode that isn't frequently run based on some optimization heuristic, but it doesn't have to. A 100% JIT emitting JVM could exist, and might even be a JVM flag for all I know. [2] if you ignore the time JVM spends optimizing at load/JIT time, which you can in most cases aside from startup time. [3] http://www.catb.org/jargon/html/story-of-mel.html http://www.catb.org/jargon/html/story-of-mel.html [4] Despite this extensive apology for Java, I despise it and if I never have to touch it or the JVM ecosystem again it will be too soon.
- 10098 13y agoMany painful minutes spent with slow-like-sloth-taking-a-shit Java desktop software lead me to believe that your statement isn't entirely true.
- threeseed 13y agoYour ignorance of the difference between server and client side Java leads me to believe that you're probably wrong.
- sliverstorm 13y agoThis usually seems to be due to bad code, or bad GUI libraries (which Java seems to be the king of)
- danieldk 13y agoIntelliJ, which is a large Java Swing application, certainly works fine and quick on all of my machines.