3 ms·
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 fa
by 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 agoSince 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.