4 ms·

Startup time is the least interesting metric in this article. The more interesting metric is the number of syscalls. This isn't a measure of performance, it's a

Startup time is the least interesting metric in this article. The more interesting metric is the number of syscalls. This isn't a measure of performance, it's a measure of complexity and busywork. Complexity tends to indirectly affect performance, but that's not the point of the article.

joshuamorton 7y ago
Complexity of what? The resulting generated binary? Well no, a python binary is smaller than the c binary. The toolchain? Well gcc is pretty complex and that's unaccounted for. The build process? Again, no. The closest thing I can think of is the language runtime. But why do I care about how complex the language runtime is? Often more complex language runtimes make my life easier anyway, and they're all sitting atop the Intel microcode magic box anyway. There's a very specific definition of complexity you're using, and I'm still not sure what it is. In my world, you usually add complexity to eek out extra performance by breaking the less complex abstractions.
- ddevault 7y ago
  The compleixty of the system.
  - joshuamorton 7y ago
    I'm still confused. Why is runtime compilation a component of the "system", but aot compilation is not? Why are python interpreters a component of the system, but microcode interpreters and aot compilation not? If you haven't given a clear definition of what "the system" is, I can't really use your evaluation to influence my decision making.
    - ddevault 7y ago
      Because AOT compilation can be used to construct a system which is functional without the compiler, but runtime compilation requires it at runtime. The difference is plainly obvious.
      - cycloptic 7y ago
        That difference is irrelevant when your production system is updated a lot, or when you actually need the runtime compilation, which a lot of programs do. Even on mobile and embedded where you would think this wasn't true, the customers still really don't care if given the luxury to do so by a fast CPU and high capacity battery.
- pdimitar 7y ago
  I'd say the complexity imposed upon the final executable program, by the [supposedly sub-optimal] compiler / runtime tooling. That's how I understood the goal of the article.

joshuamorton 7y ago

Complexity of what? The resulting generated binary? Well no, a python binary is smaller than the c binary. The toolchain? Well gcc is pretty complex and that's unaccounted for. The build process? Again, no. The closest thing I can think of is the language runtime. But why do I care about how complex the language runtime is? Often more complex language runtimes make my life easier anyway, and they're all sitting atop the Intel microcode magic box anyway. There's a very specific definition of complexity you're using, and I'm still not sure what it is. In my world, you usually add complexity to eek out extra performance by breaking the less complex abstractions.

ddevault 7y ago
The compleixty of the system.
- joshuamorton 7y ago
  I'm still confused. Why is runtime compilation a component of the "system", but aot compilation is not? Why are python interpreters a component of the system, but microcode interpreters and aot compilation not? If you haven't given a clear definition of what "the system" is, I can't really use your evaluation to influence my decision making.
  - ddevault 7y ago
    Because AOT compilation can be used to construct a system which is functional without the compiler, but runtime compilation requires it at runtime. The difference is plainly obvious.
    - cycloptic 7y ago
      That difference is irrelevant when your production system is updated a lot, or when you actually need the runtime compilation, which a lot of programs do. Even on mobile and embedded where you would think this wasn't true, the customers still really don't care if given the luxury to do so by a fast CPU and high capacity battery.
pdimitar 7y ago
I'd say the complexity imposed upon the final executable program, by the [supposedly sub-optimal] compiler / runtime tooling. That's how I understood the goal of the article.