12 ms·

WASM as a Platform for Abstraction

86 points by MichaelFBryan 7y ago

xuejie 7y ago
While I do agree WASM makes a lot of sense for the Web, I personally am having doubts regarding treating WASM as a general abstractions for native code as used in the post. For this case, it might suit the job better to have a bytecode that resembles more of underlying machine architecture, rather than a still highly abstracted model like WASM. Please don't get me wrong, I do agree WASM is already one step ahead of, say, JavaScript, but we can do better than that. The problem with WASM here, is that it really is a bloated model like JVM in its early days, huge amount of work is needed to make it closer to native speed, which is contradictory to the original slogan. What's more, people are still planning to add tons of new features to it: https://webassembly.org/docs/future-features/ https://webassembly.org/docs/future-features/. Before you tell me those are opt-in features, the question I want to raise is: for an abstraction of general platform, you would definitely want to have a widely accepted standard so people know what features will be expected, one example is that people know SSE will be available for 64-bit x86 code. With all those opt-in features, I doubt if we can have a proper layer that adapts well to different implementations with different supported features. We might end up with the situation like Rust, where you can claim a secondary compiler could exist, but in practice people are all using the same compiler/implementation.
- dmitriid 7y ago
  Besides, doesn't LLVM already have an IR which servers as one such higher-level abstraction?
  - rapsey 7y ago
    I'm pretty sure it is not stable and not designed for such a use case.
    - pjmlp 7y ago
      Apple kind of disagrees with watchOS bitcode.
      - tom_mellior 7y ago
        "not designed for that use case" != "isn't used for that use case in practice" Apple has tight control over the bitcode version and the target platforms supported by Xcode. That's not the same thing as accepting arbitrary LLVM bitcode files.
        pjmlp 7y ago
        Nothing prevents LLVM project to adopt such variant, other than unwillingness to do so.
  - jcelerier 7y ago
    No, LLVM IR is machine specific. Any "native" language is since the ABI of a struct will depend e.g. on the size of pointers for that platform. E.g. Consider in C int foo[sizeof(void*)];
    - pjmlp 7y ago
      Open source LLVM IR is machine specific, it doesn't have to be, as proven by watchOS bitcode, or PNaCL.
      - saagarjha 7y ago
        Both of the examples you gave were very carefully architected to make sure that was the case.
        pjmlp 7y ago
        Which doesn't prevent the case of someone contributing back such kind of variants.
      - jcelerier 7y ago
        > it doesn't have to be, as proven by watchOS bitcode, or PNaCL. Both of those have fixed 32-bit pointer sizes and are little-endian. When you compile for watchOS bitcode or PNaCL you just target a single virtual machine & "system" ABI. LLVM IR or any related techniques won't ever allow you to produce a 32 / 64 bit or ARM / x86 app that is able to leverage the whole feature set of the platform from the same bitcode.
        pjmlp 7y ago
        Yet watchOS migrated from 32 bit to 64 bit. It is possible, LLVM project just needs to actually want to support such use cases in a portable way.
        jcelerier 7y ago
        > Yet watchOS migrated from 32 bit to 64 bit. that is what they said in the press release but in practice they migrated from "classical" 32bit ARM to ILP-32 (akin to the x32 ABI on linux) so the size of pointers, etc etc does not change from 32-bit. You get more registers & stuff like that which is nice, but that is not moving to 64 bit, just having nicer 32 bit execution on 64 bit CPUs. If you want proper aarch64 support on WatchOS you have to recompile.
  - jahewson 7y ago
    Google created pretty much this, called it PNaCl and shipped it in Chrome. It now has been retired in favor of WASM.
    - pjmlp 7y ago
      Because Mozilla went political and came up with asm.js as counter technology.
      - afiori 7y ago
        Or as some other (like, eg Google itself) would say: > Because Mozilla went political and came up with asm.js as better technology.
        pjmlp 7y ago
        I am pretty sure that asm.js would not happened if Chrome already had the market share it enjoys nowadays. WASM is still catching up to PNaCL in performance, hardly better.
    - AndrewDucker 7y ago
      For the reasoning behind this, see https://github.com/WebAssembly/design/blob/master/FAQ.md#why-not-just-use-llvm-bitcode-as-a-binary-format https://github.com/WebAssembly/design/blob/master/FAQ.md#why...
  - TazeTSchnitzel 7y ago
    LLVM IR is unstable, way too big in scope, and not as machine-independent as people think. There have been several efforts to use it as a target-independent high-level bytecode, and they either are very platform-specific single-vendor affairs (Apple) or were retired in favour of a simpler new language that doesn't have its problems (SPIR became SPIR-V, PNaCl became WebAssembly).
- BiteCode_dev 7y ago
  And yet, it will probably be used for that and become popular. Tech doesn't need to be perfect, the best, or even very good to win. They need to have a killer feature and a low cost of adoption. Wasm seems on the right tracker for that.
  - xuejie 7y ago
    I totally agree that it's not the best tech always wins, that's why I'm pointing it out, I really wish that 5 years from now, we can rely on something that makes sense to be there, not just because something has a low cost of adoption.
  - onebot 7y ago
    > need to have a killer feature and a low cost of adoption This is a powerful statement actually. Could be applied to any tech startup product.
- cjbprime 7y ago
  It sounds like you're bringing up a register-based vs stack-based VM argument, and claiming that register-based VMs have better performance because their model is closer to the hardware. My understanding is that this intuition is usually untrue, because a JIT benefits from the stack-based code preserving code flow and thus allowing more efficient code generation.
  - xuejie 7y ago
    No I'm not talking about register-based vs stack-based VM, that's a totally different topic. I'm just saying WASM is still quite distant from real hardware, making it a non-trivial task to performantly run the code. In fact if you look at the asm.js, which is the original inspiration of WASM, it is a much closer mode to real hardware. And of course JIT can make WASM fast but if you look around, building a performant WASM JIT still remains terribly hard, some implementation even needs LLVM to perform optimizations. I'd say if this is the case, we must've chosen the wrong model.
    - TazeTSchnitzel 7y ago
      Why is it hard? Isn't wasm designed so you can statically and quickly compile pieces of it or the whole thing to native code, rather than needing to do all the tricks dynamic language runtimes do?
      - xuejie 7y ago
        That is their very nice slogan, while in reality WASM still has quite a way to go to compete with native code. Some shits I see these days are that when code speed is measured, people compare that with JS but not native code, when portability is talked about, the comparison is then made against native code, not JS.
    - TomMarius 7y ago
      What major implementations are using LLVM? Firefox is using Cranelift, Chrome is using V8, both of these shouldn't be using LLVM, AFAIK, or am I wrong?
- kbumsik 7y ago
  > The problem with WASM here, is that it really is a bloated model like JVM in its early days, Isn't WASM (as of its MVP) quite simple VM model compared to other VMs? I agree with your concern about the new futures though. It might introduce another hell of segmentation.
- pjmlp 7y ago
  That is not an issue regarding bytecode formats in general, given that in some platforms only the kernel does the final compilation to machine code, and they are a common executable format since early 60's. However I do agree with WASM everywhere fashion complaint.
- pjc50 7y ago
  > bytecode that resembles more of underlying machine architecture In what way? This discussion lacks specifics. Doesn't this also risk tying you to a specific machine, which is the opposite of the intent?
ridiculous_fish 7y ago
Lots of wasm questions: In what sense can a wasm program "crash?" What sort of backtraces are available in that event? How's the debugging story? Is there a fast wasm runtime available for non-JIT platforms? Is there big-endian support (still hanging on)?
- kbumsik 7y ago
  > In what sense can a wasm program "crash?" I'm not an expert in wasm but memory allocation may fail depending on the host environment. Also, runtimes of higher languages may define their own crash cases. As it is a stack machine dumping a stacktrace in case of "crash" should be easy. > Is there big-endian support? Wasm still assumes little-endian byte ordering. Honestly who really cares about big-endian? https://github.com/WebAssembly/design/blob/master/Portability.md https://github.com/WebAssembly/design/blob/master/Portabilit...
- kimundi 7y ago
  Wasm programs can only crash by triggering a "trap", which has the well defined semantic of aborting the entire (wasm) function stack at that point. It depends on the embedding host how much backtrace or debugging support you get for this. I'm not sure exactly what you mean with non-JIT platforms, As far as I know, most wasm hosts that generate native code just compile the entire wasm module at once, so its less like a JIT runtime and more like a regular compiler. If you mean not compiling to native code at all, then you just have the performance of a plain old stack machine bytecode interpreter. Not sure how many there are currently and how well optimized they are though. About big-endian - afaik little-endian is just the spec for storing to wasm's linear memory - the actual representation of stack values can be arbitrary (since you can not inspect their bytes directly).
- sanxiyn 7y ago
  > Is there a fast wasm runtime available for non-JIT platforms? Yes, Wasmtime can do AOT. Many other runtimes can do AOT as well.
Animats 7y ago
Strange. Something like node.js for running server side WASM programs, maybe. But hard real time? That's a strange application for this. Why add the additional layer?
- rapsey 7y ago
  Where does it say hard real time?
  - Animats 7y ago
    Where it says: "While this section will be fairly specific to my use case (creating some sort of programmable logic controller that people can upload code to), it should be fairly easy to adapt to suit your application."
- stevedonovan 7y ago
  The traditional approach is dynamically loaded native libraries, and that certainly worked well when I did it in C++. The dynamic linking situation in Rust is immature, nothing like a stable ABI. Static linking has received much more attention, and the core developers can't prioritize at once. However, it can be done and I hope it can be done safely at some point.
- pjc50 7y ago
  The first few paragraphs are the rationale.
pjmlp 7y ago
WASM advocates keep rediscovering the benefits from bytecodes as portable execution format, while presenting them as something great made possible only by WASM. Reading a bit of mainframe history would do some good it seems.
- TomMarius 7y ago
  So we're getting mainframe-like tech into the mainstream? Isn't it good?
  - mr__y 7y ago
    If this was a conscious process, that is taking solutions from mainframe, analyzing them and deciding to use some of them also analyzing the knowledge,pitfalls, problems and experiences from the past and incorporating them into the new tech then this would be a good thing. However if this is done through a simple reinventing the wheel route, there is a high chance of hitting the same walls and repeating the same mistakes. This is kind of similiar to a "let's rewrite this code from scratch in new shiny lang/lib/framework" with the expectation that new code will be bug-free from the start. It's not always bad, it is sometimes necessary or it may turn out to be more effective than trying to fix bloated code. But very often the new code has problems exactly the same as previous code and effectively the developers reinvent the wheel multiple times in the process of rewriting.
    - TomMarius 7y ago
      I am not sure if you're following the github spec repos, but at least check them out. I really don't think these people are reinventing the wheel badly. The last 3 years have been full of discussion about every single detail, including behavior of various different prior art, host platforms, hosted platforms, etc. These discussions are public, why don't you join if you can help? Even a short list of "look here" would be a great help.
- Shish2k 7y ago
  > Reading a bit of mainframe history would do some good it seems. I wonder if anyone has a list of awesome mainframe features so that we know what modern computing is going to "invent" next? :P (See also: hot-swappable parts, virtualisation, containers, etc... I never got to work with mainframes myself, just each time I dig into some new "industry game-changer" tech, I learn that mainframes had it in the 60's)
wsxcde 7y ago
The author has rediscovered the need for software fault isolation (SFI). Bytecodes or IRs like WASM can also provide SFI but are overkill because they provide more than just SFI. If I were him, I'd have used this as an excuse to play with NativeClient. -- The original paper on SFI was by Robert Wahbe and colleagues: https://cs155.stanford.edu/papers/sfi.pdf https://cs155.stanford.edu/papers/sfi.pdf. Google's NativeClient is a modern take on SFI for x86: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf https://static.googleusercontent.com/media/research.google.c....
- jedisct1 7y ago
  Unfortunately, NativeClient has been abandoned.
- afiori 7y ago
  Does SFI also cover sandboxing?
bayesian_horse 7y ago
You could also bring back genetic algorithms/genetic programming on top of WASM ;-)
mr__y 7y ago
Yo dawg we herd you like abstractions so we put a VM in a container-runtime in a hypervisor in your CPU so you can use JIT compilation while you use other JIT compilation
cordite 7y ago
The requirements 1. People need to be able to upload new code while the system is still running 2. This application will be interacting with the real world (think robots and automation), and we really don’t want a crash in user-provided code to make the entire system stop responding is suspiciously close to Erlang, except for the user-provided part.

86 points by MichaelFBryan 7y ago

While I do agree WASM makes a lot of sense for the Web, I personally am having doubts regarding treating WASM as a general abstractions for native code as used in the post. For this case, it might suit the job better to have a bytecode that resembles more of underlying machine architecture, rather than a still highly abstracted model like WASM. Please don't get me wrong, I do agree WASM is already one step ahead of, say, JavaScript, but we can do better than that. The problem with WASM here, is that it really is a bloated model like JVM in its early days, huge amount of work is needed to make it closer to native speed, which is contradictory to the original slogan. What's more, people are still planning to add tons of new features to it: https://webassembly.org/docs/future-features/ https://webassembly.org/docs/future-features/. Before you tell me those are opt-in features, the question I want to raise is: for an abstraction of general platform, you would definitely want to have a widely accepted standard so people know what features will be expected, one example is that people know SSE will be available for 64-bit x86 code. With all those opt-in features, I doubt if we can have a proper layer that adapts well to different implementations with different supported features. We might end up with the situation like Rust, where you can claim a secondary compiler could exist, but in practice people are all using the same compiler/implementation.

dmitriid 7y ago
Besides, doesn't LLVM already have an IR which servers as one such higher-level abstraction?
- rapsey 7y ago
  I'm pretty sure it is not stable and not designed for such a use case.
  - pjmlp 7y ago
    Apple kind of disagrees with watchOS bitcode.
    - tom_mellior 7y ago
      "not designed for that use case" != "isn't used for that use case in practice" Apple has tight control over the bitcode version and the target platforms supported by Xcode. That's not the same thing as accepting arbitrary LLVM bitcode files.
      - pjmlp 7y ago
        Nothing prevents LLVM project to adopt such variant, other than unwillingness to do so.
- jcelerier 7y ago
  No, LLVM IR is machine specific. Any "native" language is since the ABI of a struct will depend e.g. on the size of pointers for that platform. E.g. Consider in C int foo[sizeof(void*)];
  - pjmlp 7y ago
    Open source LLVM IR is machine specific, it doesn't have to be, as proven by watchOS bitcode, or PNaCL.
    - saagarjha 7y ago
      Both of the examples you gave were very carefully architected to make sure that was the case.
      - pjmlp 7y ago
        Which doesn't prevent the case of someone contributing back such kind of variants.
    - jcelerier 7y ago
      > it doesn't have to be, as proven by watchOS bitcode, or PNaCL. Both of those have fixed 32-bit pointer sizes and are little-endian. When you compile for watchOS bitcode or PNaCL you just target a single virtual machine & "system" ABI. LLVM IR or any related techniques won't ever allow you to produce a 32 / 64 bit or ARM / x86 app that is able to leverage the whole feature set of the platform from the same bitcode.
      - pjmlp 7y ago
        Yet watchOS migrated from 32 bit to 64 bit. It is possible, LLVM project just needs to actually want to support such use cases in a portable way.
        jcelerier 7y ago
        > Yet watchOS migrated from 32 bit to 64 bit. that is what they said in the press release but in practice they migrated from "classical" 32bit ARM to ILP-32 (akin to the x32 ABI on linux) so the size of pointers, etc etc does not change from 32-bit. You get more registers & stuff like that which is nice, but that is not moving to 64 bit, just having nicer 32 bit execution on 64 bit CPUs. If you want proper aarch64 support on WatchOS you have to recompile.
- jahewson 7y ago
  Google created pretty much this, called it PNaCl and shipped it in Chrome. It now has been retired in favor of WASM.
  - pjmlp 7y ago
    Because Mozilla went political and came up with asm.js as counter technology.
    - afiori 7y ago
      Or as some other (like, eg Google itself) would say: > Because Mozilla went political and came up with asm.js as better technology.
      - pjmlp 7y ago
        I am pretty sure that asm.js would not happened if Chrome already had the market share it enjoys nowadays. WASM is still catching up to PNaCL in performance, hardly better.
  - AndrewDucker 7y ago
    For the reasoning behind this, see https://github.com/WebAssembly/design/blob/master/FAQ.md#why-not-just-use-llvm-bitcode-as-a-binary-format https://github.com/WebAssembly/design/blob/master/FAQ.md#why...
- TazeTSchnitzel 7y ago
  LLVM IR is unstable, way too big in scope, and not as machine-independent as people think. There have been several efforts to use it as a target-independent high-level bytecode, and they either are very platform-specific single-vendor affairs (Apple) or were retired in favour of a simpler new language that doesn't have its problems (SPIR became SPIR-V, PNaCl became WebAssembly).
BiteCode_dev 7y ago
And yet, it will probably be used for that and become popular. Tech doesn't need to be perfect, the best, or even very good to win. They need to have a killer feature and a low cost of adoption. Wasm seems on the right tracker for that.
- xuejie 7y ago
  I totally agree that it's not the best tech always wins, that's why I'm pointing it out, I really wish that 5 years from now, we can rely on something that makes sense to be there, not just because something has a low cost of adoption.
- onebot 7y ago
  > need to have a killer feature and a low cost of adoption This is a powerful statement actually. Could be applied to any tech startup product.
cjbprime 7y ago
It sounds like you're bringing up a register-based vs stack-based VM argument, and claiming that register-based VMs have better performance because their model is closer to the hardware. My understanding is that this intuition is usually untrue, because a JIT benefits from the stack-based code preserving code flow and thus allowing more efficient code generation.
- xuejie 7y ago
  No I'm not talking about register-based vs stack-based VM, that's a totally different topic. I'm just saying WASM is still quite distant from real hardware, making it a non-trivial task to performantly run the code. In fact if you look at the asm.js, which is the original inspiration of WASM, it is a much closer mode to real hardware. And of course JIT can make WASM fast but if you look around, building a performant WASM JIT still remains terribly hard, some implementation even needs LLVM to perform optimizations. I'd say if this is the case, we must've chosen the wrong model.
  - TazeTSchnitzel 7y ago
    Why is it hard? Isn't wasm designed so you can statically and quickly compile pieces of it or the whole thing to native code, rather than needing to do all the tricks dynamic language runtimes do?
    - xuejie 7y ago
      That is their very nice slogan, while in reality WASM still has quite a way to go to compete with native code. Some shits I see these days are that when code speed is measured, people compare that with JS but not native code, when portability is talked about, the comparison is then made against native code, not JS.
  - TomMarius 7y ago
    What major implementations are using LLVM? Firefox is using Cranelift, Chrome is using V8, both of these shouldn't be using LLVM, AFAIK, or am I wrong?
kbumsik 7y ago
> The problem with WASM here, is that it really is a bloated model like JVM in its early days, Isn't WASM (as of its MVP) quite simple VM model compared to other VMs? I agree with your concern about the new futures though. It might introduce another hell of segmentation.
pjmlp 7y ago
That is not an issue regarding bytecode formats in general, given that in some platforms only the kernel does the final compilation to machine code, and they are a common executable format since early 60's. However I do agree with WASM everywhere fashion complaint.
pjc50 7y ago
> bytecode that resembles more of underlying machine architecture In what way? This discussion lacks specifics. Doesn't this also risk tying you to a specific machine, which is the opposite of the intent?

ridiculous_fish 7y ago

Lots of wasm questions: In what sense can a wasm program "crash?" What sort of backtraces are available in that event? How's the debugging story? Is there a fast wasm runtime available for non-JIT platforms? Is there big-endian support (still hanging on)?

kbumsik 7y ago
> In what sense can a wasm program "crash?" I'm not an expert in wasm but memory allocation may fail depending on the host environment. Also, runtimes of higher languages may define their own crash cases. As it is a stack machine dumping a stacktrace in case of "crash" should be easy. > Is there big-endian support? Wasm still assumes little-endian byte ordering. Honestly who really cares about big-endian? https://github.com/WebAssembly/design/blob/master/Portability.md https://github.com/WebAssembly/design/blob/master/Portabilit...
kimundi 7y ago
Wasm programs can only crash by triggering a "trap", which has the well defined semantic of aborting the entire (wasm) function stack at that point. It depends on the embedding host how much backtrace or debugging support you get for this. I'm not sure exactly what you mean with non-JIT platforms, As far as I know, most wasm hosts that generate native code just compile the entire wasm module at once, so its less like a JIT runtime and more like a regular compiler. If you mean not compiling to native code at all, then you just have the performance of a plain old stack machine bytecode interpreter. Not sure how many there are currently and how well optimized they are though. About big-endian - afaik little-endian is just the spec for storing to wasm's linear memory - the actual representation of stack values can be arbitrary (since you can not inspect their bytes directly).
sanxiyn 7y ago
> Is there a fast wasm runtime available for non-JIT platforms? Yes, Wasmtime can do AOT. Many other runtimes can do AOT as well.

Animats 7y ago

Strange. Something like node.js for running server side WASM programs, maybe. But hard real time? That's a strange application for this. Why add the additional layer?

rapsey 7y ago
Where does it say hard real time?
- Animats 7y ago
  Where it says: "While this section will be fairly specific to my use case (creating some sort of programmable logic controller that people can upload code to), it should be fairly easy to adapt to suit your application."
stevedonovan 7y ago
The traditional approach is dynamically loaded native libraries, and that certainly worked well when I did it in C++. The dynamic linking situation in Rust is immature, nothing like a stable ABI. Static linking has received much more attention, and the core developers can't prioritize at once. However, it can be done and I hope it can be done safely at some point.
pjc50 7y ago
The first few paragraphs are the rationale.

pjmlp 7y ago

WASM advocates keep rediscovering the benefits from bytecodes as portable execution format, while presenting them as something great made possible only by WASM. Reading a bit of mainframe history would do some good it seems.

TomMarius 7y ago
So we're getting mainframe-like tech into the mainstream? Isn't it good?
- mr__y 7y ago
  If this was a conscious process, that is taking solutions from mainframe, analyzing them and deciding to use some of them also analyzing the knowledge,pitfalls, problems and experiences from the past and incorporating them into the new tech then this would be a good thing. However if this is done through a simple reinventing the wheel route, there is a high chance of hitting the same walls and repeating the same mistakes. This is kind of similiar to a "let's rewrite this code from scratch in new shiny lang/lib/framework" with the expectation that new code will be bug-free from the start. It's not always bad, it is sometimes necessary or it may turn out to be more effective than trying to fix bloated code. But very often the new code has problems exactly the same as previous code and effectively the developers reinvent the wheel multiple times in the process of rewriting.
  - TomMarius 7y ago
    I am not sure if you're following the github spec repos, but at least check them out. I really don't think these people are reinventing the wheel badly. The last 3 years have been full of discussion about every single detail, including behavior of various different prior art, host platforms, hosted platforms, etc. These discussions are public, why don't you join if you can help? Even a short list of "look here" would be a great help.
Shish2k 7y ago
> Reading a bit of mainframe history would do some good it seems. I wonder if anyone has a list of awesome mainframe features so that we know what modern computing is going to "invent" next? :P (See also: hot-swappable parts, virtualisation, containers, etc... I never got to work with mainframes myself, just each time I dig into some new "industry game-changer" tech, I learn that mainframes had it in the 60's)

wsxcde 7y ago

The author has rediscovered the need for software fault isolation (SFI). Bytecodes or IRs like WASM can also provide SFI but are overkill because they provide more than just SFI. If I were him, I'd have used this as an excuse to play with NativeClient. -- The original paper on SFI was by Robert Wahbe and colleagues: https://cs155.stanford.edu/papers/sfi.pdf https://cs155.stanford.edu/papers/sfi.pdf. Google's NativeClient is a modern take on SFI for x86: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf https://static.googleusercontent.com/media/research.google.c....

jedisct1 7y ago
Unfortunately, NativeClient has been abandoned.
afiori 7y ago
Does SFI also cover sandboxing?

bayesian_horse 7y ago

You could also bring back genetic algorithms/genetic programming on top of WASM ;-)

mr__y 7y ago

Yo dawg we herd you like abstractions so we put a VM in a container-runtime in a hypervisor in your CPU so you can use JIT compilation while you use other JIT compilation

cordite 7y ago

The requirements 1. People need to be able to upload new code while the system is still running 2. This application will be interacting with the real world (think robots and automation), and we really don’t want a crash in user-provided code to make the entire system stop responding is suspiciously close to Erlang, except for the user-provided part.