4 ms·
In other words, it's possible for a non native program to be faster than a native program provided the native program is less optimized for the execution platfo
by Accujack 7y ago
In other words, it's possible for a non native program to be faster than a native program provided the native program is less optimized for the execution platform.
This is not exactly news.
- Someone 7y agoA VM can also optimize for the workload and the configuration of a program in ways that a compiled-once program cannot (profile-guided-optimization can help there) A simple example is log.debug(“foo:” + bar + “(“ + baz + ”)”) A native C++ compiler would have to do the string concatenation and must call log.debug. A VM can (sometimes) detect that “log.debug” is a no-op, and skip computing its argument and calling it, and can even recover when “log.debug” stops being a no-op. It can even do that if the code for log get loaded dynamically at runtime.
- krageon 7y agoWhat this means in short is exactly what was already said, but in more words and in such a way that it seems like that wasn't what was already said. You've described a native program that wasn't optimised competing against an optimised non-native program. It's already been established that this is a scenario where the latter might be faster.