3 ms·
It is still difficult to say. IMHO C at scale requires often trading performance for architectural simplicity. E.g. relying on function pointers for indirection
by pkolaczk 13y ago
It is still difficult to say. IMHO C at scale requires often trading performance for architectural simplicity. E.g. relying on function pointers for indirection (or switch) or passing things by value / deep copy to simplify memory management are techniques which would often degrade performance than boost it, relative to Java. In real big code, you have to do some higher-level abstractions or your project is going to be unmaintainable spaghetti mess, and it is arguable if C lets you build them in the most performant manner.
- coldtea 13y agoI've never really seen any Java project for high performance stuff outperform a C/C++ based on. Visualization tools, video processing tools, multimedia tools, games, etc -- all Java examples I've seen come worse off that the C/C++ equivalents. It's true that in large scale C you often trae performance for architectural simplicity. But in a higher level you trade performance for everything, even the most basic operation has some added complexity layer. And you don't even have as much say as where you'd trade performance for architectural simplicity in, as you do in C/C++, since some parts you just can't do without.
- erichocean 13y agoSame...until the GC kicks in. Then the app locks up for 60+ seconds at a time every few hours, at which point the developers start moving anything memory intensive out of Java to avoid the pauses, and/or reduce their severity (c.f. Cassandra). At that point, is it really Java? You might as well use a scripting language to integrate with all that C...
- pkolaczk 13y agoYes, Cassandra is Java, even if a few tiny parts were moved off-heap. And no, the off-heap parts aren't programmed in C nor C++, it is still Java all the way down. Scripting language + C is a valid solution for many problems, IMHO often much better than a jack-of-all-trades-master-of-none solution like C++.
- frowaway001 13y ago> Then the app locks up for 60+ seconds at a time every few hours Given that the GC can generally process 1GB of live objects per second, I'd love to see an example where you have been working with 60GB+ heaps.
- pkolaczk 13y agoAnd this is not taking into account that modern GCs do most or all of the work either without stopping the mutator (CMS, C4) or incrementally (G1), in smaller chunks. Times of STW collectors are long gone.
- pkolaczk 13y agoAnd I've seen a few C++ project which after translating to Java got some big performance improvements. Java's Collection.sort outperforms C's qsort significantly (and is very close to C++ std::sort for general cases). Java's GCed pointers outperform C++ shared_ptr significantly. Java's dynamic dispatch works in worst case with the same performance as C++'s one, but often works much faster. Java's cost of array bound checking is lower than in C++. Java's immutable strings are safe to pass by pointer everywhere, while C++ ones need often copying. Building anything close in performance e.g. to immutable Scala Vector or parallel collections is downright impossible in C/C++, because of lack of GC and shared_ptr is a performance no-go. There are plenty of places where high level abstractions are better implemented in high level language, than in low-level one.
- coldtea 13y agoI've never really seen any Java project for high performance stuff outperform a C/C++ based on. Visualization tools, video processing tools, multimedia tools, games, etc -- all Java examples I've seen come worse off that the C/C++ equivalents. It's true that in large scale C you often trae performance for architectural simplicity. But in a higher level you trade performance for everything, even the most basic operation has some added complexity layer. And you don't even have as much say as where you'd trade performance for architectural simplicity in, as you do in C/C++, since some parts you just can't do without.