3 ms·

> and then there are many back and forth arguments and nobody changes their mind. except that people routinely rewrite java code in C++ in 2020 and run around

> and then there are many back and forth arguments and nobody changes their mind. except that people routinely rewrite java code in C++ in 2020 and run around the Java code in circles, even when tuning GCs etc etc, à la https://www.scylladb.com/2020/10/06/c-scylla-in-battle-royale-against-javas-zgc-shenandoah-g1-cassandra/ https://www.scylladb.com/2020/10/06/c-scylla-in-battle-royal... or Minecraft Bedrock edition (C++) vs original Java Minecraft How many times have there been rewrites from C++ to Java that ended up being faster ?

cygx 6y ago
How many times have there been rewrites from C++ to Java that ended up being faster ? A couple of times as far as language implementations go (eg JRuby vs CRuby, even before the whole Graal/Truffle thing). However, that's a niche thing, and any JVM implementations have yet to replace the standard runtimes. As a rule of thumb, I agree that C++ should generally be considered the 'faster' language.
fulafel 6y ago
I would be surprised if successful C++ to Java rewrites yielding better speed were rare as we move to multicore and correcness & safety are the bottleneck problems there. But I'm not a Java programmer or follw the scene closely. Also the narrower niche of C++ means that it often makes sense to rewrite a small part of a Java app in C++, but it rarely makes sense to write a small part of a C++ app in Java. This domain difference can also explain the relative frequency of public "made it faster with C++" posts, since those small self contained uses make good posts that aren't entangled with the bigger application.
- PeterCorless 6y ago
  Multicore & multithreaded architectures only prove even more problematic as you do context switching and have sync io. That's precisely why it's not just the language (C++); it's also moving to a highly async architecture with shared-nothing, non-blocking architecture to get the best advantage out of your multi-core, multi-cpu machines. (Disclosure: I work at ScyllaDB.)

cygx 6y ago

How many times have there been rewrites from C++ to Java that ended up being faster ? A couple of times as far as language implementations go (eg JRuby vs CRuby, even before the whole Graal/Truffle thing). However, that's a niche thing, and any JVM implementations have yet to replace the standard runtimes. As a rule of thumb, I agree that C++ should generally be considered the 'faster' language.

fulafel 6y ago

I would be surprised if successful C++ to Java rewrites yielding better speed were rare as we move to multicore and correcness & safety are the bottleneck problems there. But I'm not a Java programmer or follw the scene closely. Also the narrower niche of C++ means that it often makes sense to rewrite a small part of a Java app in C++, but it rarely makes sense to write a small part of a C++ app in Java. This domain difference can also explain the relative frequency of public "made it faster with C++" posts, since those small self contained uses make good posts that aren't entangled with the bigger application.

PeterCorless 6y ago
Multicore & multithreaded architectures only prove even more problematic as you do context switching and have sync io. That's precisely why it's not just the language (C++); it's also moving to a highly async architecture with shared-nothing, non-blocking architecture to get the best advantage out of your multi-core, multi-cpu machines. (Disclosure: I work at ScyllaDB.)