7 ms·

> What is your goal - speed? Code size? Portability? Security? That depends on the target. I selected them because they represent different aspects of the stat

by pbsdp 13y ago

> What is your goal - speed? Code size? Portability? Security? That depends on the target. I selected them because they represent different aspects of the state of the art. > ... and I would argue that modern JS VMs are competitive with them in many respects But not all, and in many places, not even close. JS VMs make trade-offs that we don't need if we abandon JS, and on top of it all, you have Mozilla insisting against shared-state multi-threading supported and exposed by the VM, which discards enormously important optimization opportunities) -- and that's just the tip of the iceberg. Get rid of JS, get rid of Mozilla's self-enforced constraints on the browser, and look very seriously at something like NaCL which blends native execution performance (including being able to drop to SIMD instructions) with security sandboxing. Let language authors target the low-level machine, and target your high-level general purpose bytecode. Once you've built a runtime in which I could implement a JS runtime that's as performant as yours, we will no longer be operating in a two-tier universe in which browser makers think that JS is good enough for everyone but themselves.

azakai 13y ago
JS VMs make tradeoffs, yes. Regarding your specific examples: 1. Shared-state multithreading. This has been proposed by various people in the past, and is still being debated. There are people for it and against it in various places. It might happen, if there is consensus to standardize it. 2. SIMD: PNaCl (which I mention since you mention NaCl in that context) does not have SIMD. But of course it can add SIMD, just like Mono and Dart have, and there is a proposal for JS as well, hopefully that will get standardized. So even those limitations are in principle resolvable. They do depend on standardization, of course, but so would any VM you want to run on the web. > Let language authors target the low-level machine, and target your high-level general purpose bytecode. asm.js is meant to get performance similar to a low-level machine. It's already very close to native on many benchmarks. > Once you've built a runtime in which I could implement a JS runtime that's as performant as yours I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.).
- pbsdp 13y ago
  > I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.). I included ones you could, such a NaCL. And I should probably have also included the native platforms (Apple, MS, Google), because they're the competition, even if their sandboxing or runtime environment isn't what one might call 'state of the art'. At the end of the day, it's the two-tier universe that bothers me the most. You're content to foist the JS runtime on everyone but yourselves. Once you implement Firefox entirely as an application running in a JS VM, the argument that JS is good enough might carry some weight.
  - azakai 13y ago
    The point is that NaCl is not portable, just like a native platform such as Windows. Nonportable native platforms are there, you can write apps for them. They are even the dominant platforms on mobile. But the web's entire purpose for existing is to be portable. So you do need something like JS or PNaCl or the JVM. And all of those, due to being portable and secure, impose limitations, such as limiting the native operations that you perform. That's unavoidable. But again, if you don't like that, develop directly for a native platform.
    - pbsdp 13y ago
      > The point is that NaCl is not portable, just like a native platform such as Windows. So provide fat binaries. Maximize performance on ARM and i386, with fallback to PNaCL for future platforms that are neither. > They are even the dominant platforms on mobile. For a good reason. Adopting their strengths while eschewing their weaknesses (proprietary and single-vendor) would benefit the entire industry greatly.
      - azakai 13y ago
        Fat binaries are limited, and people will simply provide the parts for the platforms they currently care about, without care for future platforms. That's fine for most things, but web content is something that we do want to always be accessible. It is hard to adopt the strengths of native execution using all the lowest-level tweaks specific to one platform, because that inherently limit portability by definition (and often also security). I share your goals, but don't think there is an obvious better compromise than the one we are all already making on the web.

by pbsdp 13y ago

azakai 13y ago

JS VMs make tradeoffs, yes. Regarding your specific examples: 1. Shared-state multithreading. This has been proposed by various people in the past, and is still being debated. There are people for it and against it in various places. It might happen, if there is consensus to standardize it. 2. SIMD: PNaCl (which I mention since you mention NaCl in that context) does not have SIMD. But of course it can add SIMD, just like Mono and Dart have, and there is a proposal for JS as well, hopefully that will get standardized. So even those limitations are in principle resolvable. They do depend on standardization, of course, but so would any VM you want to run on the web. > Let language authors target the low-level machine, and target your high-level general purpose bytecode. asm.js is meant to get performance similar to a low-level machine. It's already very close to native on many benchmarks. > Once you've built a runtime in which I could implement a JS runtime that's as performant as yours I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.).

pbsdp 13y ago
> I don't follow that. You can't make a fast JS runtime in your previous examples (the JVM, PNaCl, .NET, etc.). I included ones you could, such a NaCL. And I should probably have also included the native platforms (Apple, MS, Google), because they're the competition, even if their sandboxing or runtime environment isn't what one might call 'state of the art'. At the end of the day, it's the two-tier universe that bothers me the most. You're content to foist the JS runtime on everyone but yourselves. Once you implement Firefox entirely as an application running in a JS VM, the argument that JS is good enough might carry some weight.
- azakai 13y ago
  The point is that NaCl is not portable, just like a native platform such as Windows. Nonportable native platforms are there, you can write apps for them. They are even the dominant platforms on mobile. But the web's entire purpose for existing is to be portable. So you do need something like JS or PNaCl or the JVM. And all of those, due to being portable and secure, impose limitations, such as limiting the native operations that you perform. That's unavoidable. But again, if you don't like that, develop directly for a native platform.
  - pbsdp 13y ago
    > The point is that NaCl is not portable, just like a native platform such as Windows. So provide fat binaries. Maximize performance on ARM and i386, with fallback to PNaCL for future platforms that are neither. > They are even the dominant platforms on mobile. For a good reason. Adopting their strengths while eschewing their weaknesses (proprietary and single-vendor) would benefit the entire industry greatly.
    - azakai 13y ago
      Fat binaries are limited, and people will simply provide the parts for the platforms they currently care about, without care for future platforms. That's fine for most things, but web content is something that we do want to always be accessible. It is hard to adopt the strengths of native execution using all the lowest-level tweaks specific to one platform, because that inherently limit portability by definition (and often also security). I share your goals, but don't think there is an obvious better compromise than the one we are all already making on the web.