3 ms·

There is absolutely no way that a more abstracted piece of software is faster than a less abstracted piece of software, unless there is some defect in the latte

There is absolutely no way that a more abstracted piece of software is faster than a less abstracted piece of software, unless there is some defect in the latter. Even the hypothetical equal performance is more like a holy grail (though I have had professors swear to me that they have seen it reached in isolated circumstances, so maybe a little less hypothetical than that).

AnIdiotOnTheNet 7y ago
I don't think that's a 100% accurate statement. My understanding is that JIT techniques do often allow non-native code to run faster than native code by taking advantage of information during the programs runtime for optimization, in addition to specific hardware features that the compiled binary version may not have taken advantage of for compatibility reasons.
- 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 ago
    A 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 ago
      What 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.

AnIdiotOnTheNet 7y ago

I don't think that's a 100% accurate statement. My understanding is that JIT techniques do often allow non-native code to run faster than native code by taking advantage of information during the programs runtime for optimization, in addition to specific hardware features that the compiled binary version may not have taken advantage of for compatibility reasons.

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 ago
  A 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 ago
    What 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.