3 ms·

The App Store doesn’t allow dynamically generated code to be marked executable (i.e. JIT compilation), so you’re stuck using a pure interpreter, at which point

by comex 6y ago

The App Store doesn’t allow dynamically generated code to be marked executable (i.e. JIT compilation), so you’re stuck using a pure interpreter, at which point there’s no real benefit to emulating the same architecture you’re running on.

saagarjha 6y ago
There may be with regards to maintaining memory ordering guarantees, we're looking into a couple of strange hangs that only reproduce on ARM. But yes, in general the choice of architecture does not matter much when interpreting.
- FullyFunctional 6y ago
  Not quite true; some ISA are simpler to decode than other and/or have simpler semantics to implement (eg. not x87). I can pretty much guarantee that you could have gotten [slightly] better performance with an iSH-like approach targeting RISC-V or ARM64. EDIT: added slightly. For all the OS calls which are 100% native, it wouldn’t matter.
tambourine_man 6y ago
> The App Store doesn’t allow dynamically generated code to be marked executable (i.e. JIT compilation) Unless it’s JavaScript. I see a missed opportunity here: compile everything to ASM.js! :) I’m only half-kidding.
- saagarjha 6y ago
  It's been on our minds for a while, the major issues with this is that IPC between the app process and WebKit is like 100µs, so having the interpreter run isolated from the app process is hard. Plus loading WASM is not "free" (that is, essentially an instruction cache flush) because you need to generate a bundle that WebKit will then load, which is slow (although there has been work done in this area: https://www.youtube.com/watch?v=7JUs4c99-mo https://www.youtube.com/watch?v=7JUs4c99-mo). So even if we did some sort of WASI thing where everything is going on in the browser, there are hurdles to overcome to make this viable. Plus the current interpreter almost certainly leaves performance on the table ;)
  - tambourine_man 6y ago
    It’s so cool that you have actually considered it. Imagine what developers could do if Apple loosened those restrictions a bit.

by comex 6y ago

saagarjha 6y ago

There may be with regards to maintaining memory ordering guarantees, we're looking into a couple of strange hangs that only reproduce on ARM. But yes, in general the choice of architecture does not matter much when interpreting.

FullyFunctional 6y ago
Not quite true; some ISA are simpler to decode than other and/or have simpler semantics to implement (eg. not x87). I can pretty much guarantee that you could have gotten [slightly] better performance with an iSH-like approach targeting RISC-V or ARM64. EDIT: added slightly. For all the OS calls which are 100% native, it wouldn’t matter.

tambourine_man 6y ago

> The App Store doesn’t allow dynamically generated code to be marked executable (i.e. JIT compilation) Unless it’s JavaScript. I see a missed opportunity here: compile everything to ASM.js! :) I’m only half-kidding.

saagarjha 6y ago
It's been on our minds for a while, the major issues with this is that IPC between the app process and WebKit is like 100µs, so having the interpreter run isolated from the app process is hard. Plus loading WASM is not "free" (that is, essentially an instruction cache flush) because you need to generate a bundle that WebKit will then load, which is slow (although there has been work done in this area: https://www.youtube.com/watch?v=7JUs4c99-mo https://www.youtube.com/watch?v=7JUs4c99-mo). So even if we did some sort of WASI thing where everything is going on in the browser, there are hurdles to overcome to make this viable. Plus the current interpreter almost certainly leaves performance on the table ;)
- tambourine_man 6y ago
  It’s so cool that you have actually considered it. Imagine what developers could do if Apple loosened those restrictions a bit.