3 ms·

Because they want a higher level of abstraction for 'all the other benefits' - and then just to get it work a little faster. When we think C++ performance, we'

Because they want a higher level of abstraction for 'all the other benefits' - and then just to get it work a little faster. When we think C++ performance, we're thinking of something like a video or audio compression i.e. discrete functionality. Note a massive, enterprise level solution with myriads of kinds of business functions. It would never get complete in C++ as that language has complexity issues which overwhelm everything else at some scale, more often than not.

pjmlp 5y ago
Even then, many devs focus too much on the performance tree and miss the forest of polyglot programming. If there are performance issues with a Java application, where after all attempts, there is still some room left, there is no need to throw everything way. Those areas can be ported to C, C++, Rust, whatever, and then called via native methods.
- jollybean 5y ago
  Java designed for performance, when the VM settles down after n iterations pushes 'on par' with C++. There's also no reason to believe that C or C++ will be faster, because you have to 1) know how to write performant C++ code (not obvious) and 2) content with the Java-JNI-C barrier which is non-negligible. I don't see too many scenarios where taking a module and porting to C++ is really ever a thing frankly. Usually, it'd be for integrating already existing systems - or - for integrating things which might naturally be written in C/C++ in the first place. For something like Graal, it's one of those broad improvements wherein everyone gains, hopefully magically without having to do anything like a big improvement in V8 that just 'happens'.
  - pjmlp 5y ago
    Since 2006 I already replaced a couple of C++ platforms with either Java or .NET, then there is Android as well, or embedded platforms like microEJ. On managed languages FFI should never be done 1:1, as you very well point out it isn't negligible. Rather they should be thought as in-process RPC, that actually do a bunch of work per call. It is still faster than doing IPC across processes.

pjmlp 5y ago

Even then, many devs focus too much on the performance tree and miss the forest of polyglot programming. If there are performance issues with a Java application, where after all attempts, there is still some room left, there is no need to throw everything way. Those areas can be ported to C, C++, Rust, whatever, and then called via native methods.

jollybean 5y ago
Java designed for performance, when the VM settles down after n iterations pushes 'on par' with C++. There's also no reason to believe that C or C++ will be faster, because you have to 1) know how to write performant C++ code (not obvious) and 2) content with the Java-JNI-C barrier which is non-negligible. I don't see too many scenarios where taking a module and porting to C++ is really ever a thing frankly. Usually, it'd be for integrating already existing systems - or - for integrating things which might naturally be written in C/C++ in the first place. For something like Graal, it's one of those broad improvements wherein everyone gains, hopefully magically without having to do anything like a big improvement in V8 that just 'happens'.
- pjmlp 5y ago
  Since 2006 I already replaced a couple of C++ platforms with either Java or .NET, then there is Android as well, or embedded platforms like microEJ. On managed languages FFI should never be done 1:1, as you very well point out it isn't negligible. Rather they should be thought as in-process RPC, that actually do a bunch of work per call. It is still faster than doing IPC across processes.