4 ms·

I thought a big benefit of compiled languages was that they are architecturally agnostic.

sitkack 6y ago
v8 includes a JIT for every platform it runs on. The code itself needs to run on the target platform (memory model, threads, etc) and the output of the JIT needs to target the execution platform. Given how portable V8 already is, probably not a whole lot work needed to get it to compile and run on RISC-V, but the codegen would need to be written. https://github.com/v8-riscv/v8/tree/riscv64/src/codegen https://github.com/v8-riscv/v8/tree/riscv64/src/codegen
deleted 6y ago
[deleted]
fastball 6y ago
Not as far as I'm aware. The benefit of a compiled language is that it is translated to machine code once, not every time you run it, which generally gives perf gains. But machine code, or rather the instruction set that a CPU supports, is still different for different architectures.
- KMag 6y ago
  > translated to machine code once, not every time you run it, which generally gives perf gains. I think the real dominant factor is that ahead-of-time compilation generally isn't competing for resources with the application. AoT compilation is usually done on a completely different machine, or at least at time other than when the application is run. If your applications were recompiled every night while you slept, you wouldn't mind so much. In fact, that's what the latest Android Runtime does. Running applications dump profile information to the filesystem, and when the phone is plugged in and idle, the runtime goes back and re-optimizes the binaries for your usage pattern. Presumably, there's something like a statistical distance metric[0] to estimate how much the profiles changed since the last compilation, to avoid wasteful recompilation. [0] https://en.wikipedia.org/wiki/Statistical_distance https://en.wikipedia.org/wiki/Statistical_distance
  - pjmlp 6y ago
    And as of version 10, PGO data gets shared with the store, which probably isn't something HN crowd will enjoy. :) The idea is that long term each application for a specific device gets the optimal compilation outcome.
    - KMag 6y ago
      I've long thought that JVMs should do something similar within large organizations. There's a bit of a black art to exactly which optimizations in which order are optimal, so it would help if there were some small amounts of randomization in that regard, along with performance monitoring/profiling and sharing across hosts / runs. Of course, it's quite different when it's outside the organization if there's no way to opt out.
      - pjmlp 6y ago
        They already do, is what IBM calls cloud JIT on their JVM implementation. :) https://blog.openj9.org/2020/01/09/free-your-jvm-from-the-jit-with-jitserver-technology/ https://blog.openj9.org/2020/01/09/free-your-jvm-from-the-ji... Also the JIT cache that Hotspot now has, the original implementation was part of J/Rockit JVM.
        KMag 6y ago
        Wait, I didn't realize they implemented a JIT cache before their AoT compilation option. It seems like pre-populating a JIT cache, dumping it to disk, and throwing that in as an extra resource in a JAR would have a lot fewer caveats than at least their first implementation of AoT Java compilation.

v8 includes a JIT for every platform it runs on. The code itself needs to run on the target platform (memory model, threads, etc) and the output of the JIT needs to target the execution platform. Given how portable V8 already is, probably not a whole lot work needed to get it to compile and run on RISC-V, but the codegen would need to be written. https://github.com/v8-riscv/v8/tree/riscv64/src/codegen https://github.com/v8-riscv/v8/tree/riscv64/src/codegen

deleted 6y ago

[deleted]

fastball 6y ago

Not as far as I'm aware. The benefit of a compiled language is that it is translated to machine code once, not every time you run it, which generally gives perf gains. But machine code, or rather the instruction set that a CPU supports, is still different for different architectures.

KMag 6y ago
> translated to machine code once, not every time you run it, which generally gives perf gains. I think the real dominant factor is that ahead-of-time compilation generally isn't competing for resources with the application. AoT compilation is usually done on a completely different machine, or at least at time other than when the application is run. If your applications were recompiled every night while you slept, you wouldn't mind so much. In fact, that's what the latest Android Runtime does. Running applications dump profile information to the filesystem, and when the phone is plugged in and idle, the runtime goes back and re-optimizes the binaries for your usage pattern. Presumably, there's something like a statistical distance metric[0] to estimate how much the profiles changed since the last compilation, to avoid wasteful recompilation. [0] https://en.wikipedia.org/wiki/Statistical_distance https://en.wikipedia.org/wiki/Statistical_distance
- pjmlp 6y ago
  And as of version 10, PGO data gets shared with the store, which probably isn't something HN crowd will enjoy. :) The idea is that long term each application for a specific device gets the optimal compilation outcome.
  - KMag 6y ago
    I've long thought that JVMs should do something similar within large organizations. There's a bit of a black art to exactly which optimizations in which order are optimal, so it would help if there were some small amounts of randomization in that regard, along with performance monitoring/profiling and sharing across hosts / runs. Of course, it's quite different when it's outside the organization if there's no way to opt out.
    - pjmlp 6y ago
      They already do, is what IBM calls cloud JIT on their JVM implementation. :) https://blog.openj9.org/2020/01/09/free-your-jvm-from-the-jit-with-jitserver-technology/ https://blog.openj9.org/2020/01/09/free-your-jvm-from-the-ji... Also the JIT cache that Hotspot now has, the original implementation was part of J/Rockit JVM.
      - KMag 6y ago
        Wait, I didn't realize they implemented a JIT cache before their AoT compilation option. It seems like pre-populating a JIT cache, dumping it to disk, and throwing that in as an extra resource in a JAR would have a lot fewer caveats than at least their first implementation of AoT Java compilation.