7 ms·

You can now run WebAssembly on Cloudflare Workers

190 points by kentonv 8y ago

writepub 8y ago
Documentation is sparse on why emscripten compiled wasms are incompatible. Please provide more information
- kentonv 8y ago
  It's a very minor incompatibility: Traditionally, all WebAssembly modules are essentially eval()ed. You need JavaScript to download the module into an ArrayBuffer or the like, then pass that to the WebAssembly API to compile it. However, in Cloudflare Workers, we didn't want you to have to fetch WebAssembly remotely at startup. Instead, you upload your WASM module to the Cloudflare configuration UI/API together with your JavaScript code. At startup, the WASM is compiled and the resulting `WebAssembly.Module` appears as a global variable in your script, which you can then instantiate. Emscripten normally automatically generates JavaScript for you to load your WASM. But Emscripten's generated script doesn't understand this delivery model where the module shows up as a global variable. It should be trivial to add support, but it would be awkward for us to try to submit a patch upstream without the functionality being public yet.
  - writepub 8y ago
    Understood. While the patch is being mainlined, it would benefit emscripten users targeting CloudFlare to use whatever you have working with emscripten's build workflow. Please consider releasing this repo for the interim
    - kentonv 8y ago
      We haven't actually tried making any changes to Emscripten yet. We've only used lower-level tools to build things more manually. There is a working example of this here: https://github.com/cloudflare/cloudflare-workers-wasm-demo https://github.com/cloudflare/cloudflare-workers-wasm-demo
  - buu700 8y ago
    Actually, emscripten has a built-in flag (SINGLE_FILE) to embed the wasm code as base64 (which I'm the author of, incidentally).
    - hackcasual 8y ago
      May I recommend also supporting hex encoding the WASM? I think you'll find that while your file size is larger, it's actually significantly smaller once gzipped. Edit: Just tested this on https://public.tableau.com/vizql/v_public-release1809140800/javascripts/runtimeweb.wasm https://public.tableau.com/vizql/v_public-release1809140800/... runtimeweb.wasm 2,484,043 runtimewebwasm.b64 3,355,640 runtimwebwasm.hex 4,968,086 runtimewebwasm.b64.gz 974,065 runtimewebwasm.hex.gz 701,052 runtimewebwasm.b64.br 718,918 runtimewebwasm.hex.br 466,221 So with gzip -9, hex encoding is 72% of the size, with brotli (defaults) size is 65% of the size.
      - buu700 8y ago
        Hmm, thanks for the tip, and thanks for testing that out so I don't have to! It hadn't occurred to me that that would be the case, but it makes some sense after reading through https://stackoverflow.com/q/38124361/459881 https://stackoverflow.com/q/38124361/459881. I'll go ahead and open an issue with emscripten about this.
        hackcasual 8y ago
        Yep, it's one of those counter intuitive things. Another benefit from using hex is the decoder is a lot simpler and easier for the JIT to vectorize.
    - kentonv 8y ago
      That actually doesn't quite solve the problem as we disallow dynamic code evaluation. This is for a couple reasons: * Security: In case of an attack we need to be able to call up the code to do forensics, which is hard if it was downloaded dynamically at runtime. * Optimizations: We want to keep the ability to pre-compile code e.g. into V8 code cache format before distributing it to the edge.
  - curiousdannii 8y ago
    What about Module.instantiateWasm()? That should let you provide a pre-compiled or even pre-instantiated module.
- deleted 8y ago
  [deleted]
zackbloom 8y ago
Each person can take their own meaning away from this, but for me the most impressive part will always be @kentonv's hand-rolled libc replacement: https://github.com/cloudflare/cloudflare-workers-wasm-demo/blob/master/bootstrap.h https://github.com/cloudflare/cloudflare-workers-wasm-demo/b...
- jgrahamc 8y ago
  You're no C programmer, Zack. Anyone who's done any real C programming has implemented their own malloc.
  - geofft 8y ago
    (Is this an in-joke I'm missing or something?)
    - Smerity 8y ago
      It's polite ribbing amongst work colleagues where an engineer at Cloudflare (@zackbloom) offers praise to a colleague (@kentonv) for a mighty project (libc replacement) and Cloudflare's CTO (@jgrahamc) jokes that the project isn't hardcore enough ;) tldr; Appears very much an in-joke between work colleagues at Cloudflare :)
      - jgrahamc 8y ago
        Correct. Not so much an in-joke. I was just surprised Zack thought implementing your own libc was amazing. But I'm an old fart C/assembly programmer so YMMV.
        zackbloom 8y ago
        Having the top-comment doesn't lie, THE PEOPLE ARE WITH ME! Also, is there a badge or sash I can get somewhere saying "Not a Real C Programmer"?
        8y ago
elsigh 8y ago
There is such a steady stream of excellent work and innovation coming from Cloudflare these days - it's pretty amazing.
IanCal 8y ago
Really interesting development, but I do wonder how well this fits with a 5-50ms CPU time limit. Are there plans to change this? Or allow charging on higher use or something?
- kentonv 8y ago
  Indeed, introducing WebAssembly paradoxically creates more demand to increase the CPU time limits -- because with WebAssembly, it's actually reasonable to imagine doing signal processing in Workers, whereas in pure JavaScript it made less sense. We'll probably need to go back and re-evaluate the CPU time limits in the near future. In the meantime, feel free to contact us if you have a specific use case in mind that doesn't seem to be fitting the limits, and we'll figure something out.
- eastdakota 8y ago
  Yes. We plan to increase the CPU limits. In the meantime, if you're hitting limits, reach out to us and we can usually turn them up for you.
devwastaken 8y ago
The web was supposed to be open, but if the technologies are only well implimented privately it's not open at all. Props to cloudflare certainly, but this is a further nail in the coffin of open software. Wasm was supposed to be well useable outside the browser and to date there are no well made libraries that deliver on it. It's all experimentation in the open. Technology that I cannot use well in my own applications is effectively proprietary.
- ryanworl 8y ago
  You can use WASM from Node. There is even an open source module called “isolated-vm” which implements a similar security scheme to the one employed by Cloudflare. You could install that on whatever you want and run essentially the same thing (minus the rest of Cloudflare, obviously).
  - devwastaken 8y ago
    https://blog.cloudflare.com/introducing-cloudflare-workers/ https://blog.cloudflare.com/introducing-cloudflare-workers/ the original workers release explains why they dont use node and instead build with v8 directly. Node is not a cure all. It's for prototyping with wasm. You need significantly more integration with the execution environment to have DOS protection. How cloudflare does this I don't know. They'd have to remove features like multithreading and continually patch around v8 afaik. Even spidermonkies API is unuseable in a server context.
    - ryanworl 8y ago
      I know what Cloudflare workers are. Did you look at isolated-vm? It uses the V8 isolate API exactly how Cloudflare describes it being used, except it is exposed as a Node module so you can write the “parent” process in JavaScript instead of C++. It exposes memory limits and wall & cpu time limits. It is sponsored by the Fly.io CDN from what I can tell for exactly the same use case as Cloudflare workers.
      - devwastaken 8y ago
mwcampbell 8y ago
What's the limit on code size? I imagine we'll have to be careful about bringing in large existing libraries.
- rita3ko 8y ago
  The limit on the code (the Worker + WASM), after compression is 1MB. Please reach out if you run into limitations with it (rita at cloudflare).
  - mwcampbell 8y ago
    Thank you. Is that documented somewhere?
    - rita3ko 8y ago
      https://developers.cloudflare.com/workers/writing-workers/storing-data/ https://developers.cloudflare.com/workers/writing-workers/st... it’s mentioned in here
      - mwcampbell 8y ago
        Ah, OK. That doesn't mention that the 1 MB limit is after compression, though.
        kentonv 8y ago
        Being post-compression is actually new and currently only applies if you use WASM, though we'll extend it to everyone soon (and document it).
  - justinclift 8y ago
    Heh Heh Heh Minimum size of wasm files generated by Go (so far) looks to be 2MB. That should improve over time. Go wasm is currently hard coded to target browser environments too. Another thing which should improve down the track.

190 points by kentonv 8y ago

writepub 8y ago

Documentation is sparse on why emscripten compiled wasms are incompatible. Please provide more information

kentonv 8y ago
It's a very minor incompatibility: Traditionally, all WebAssembly modules are essentially eval()ed. You need JavaScript to download the module into an ArrayBuffer or the like, then pass that to the WebAssembly API to compile it. However, in Cloudflare Workers, we didn't want you to have to fetch WebAssembly remotely at startup. Instead, you upload your WASM module to the Cloudflare configuration UI/API together with your JavaScript code. At startup, the WASM is compiled and the resulting `WebAssembly.Module` appears as a global variable in your script, which you can then instantiate. Emscripten normally automatically generates JavaScript for you to load your WASM. But Emscripten's generated script doesn't understand this delivery model where the module shows up as a global variable. It should be trivial to add support, but it would be awkward for us to try to submit a patch upstream without the functionality being public yet.
- writepub 8y ago
  Understood. While the patch is being mainlined, it would benefit emscripten users targeting CloudFlare to use whatever you have working with emscripten's build workflow. Please consider releasing this repo for the interim
  - kentonv 8y ago
    We haven't actually tried making any changes to Emscripten yet. We've only used lower-level tools to build things more manually. There is a working example of this here: https://github.com/cloudflare/cloudflare-workers-wasm-demo https://github.com/cloudflare/cloudflare-workers-wasm-demo
- buu700 8y ago
  Actually, emscripten has a built-in flag (SINGLE_FILE) to embed the wasm code as base64 (which I'm the author of, incidentally).
  - hackcasual 8y ago
    May I recommend also supporting hex encoding the WASM? I think you'll find that while your file size is larger, it's actually significantly smaller once gzipped. Edit: Just tested this on https://public.tableau.com/vizql/v_public-release1809140800/javascripts/runtimeweb.wasm https://public.tableau.com/vizql/v_public-release1809140800/... runtimeweb.wasm 2,484,043 runtimewebwasm.b64 3,355,640 runtimwebwasm.hex 4,968,086 runtimewebwasm.b64.gz 974,065 runtimewebwasm.hex.gz 701,052 runtimewebwasm.b64.br 718,918 runtimewebwasm.hex.br 466,221 So with gzip -9, hex encoding is 72% of the size, with brotli (defaults) size is 65% of the size.
    - buu700 8y ago
      Hmm, thanks for the tip, and thanks for testing that out so I don't have to! It hadn't occurred to me that that would be the case, but it makes some sense after reading through https://stackoverflow.com/q/38124361/459881 https://stackoverflow.com/q/38124361/459881. I'll go ahead and open an issue with emscripten about this.
      - hackcasual 8y ago
        Yep, it's one of those counter intuitive things. Another benefit from using hex is the decoder is a lot simpler and easier for the JIT to vectorize.
  - kentonv 8y ago
    That actually doesn't quite solve the problem as we disallow dynamic code evaluation. This is for a couple reasons: * Security: In case of an attack we need to be able to call up the code to do forensics, which is hard if it was downloaded dynamically at runtime. * Optimizations: We want to keep the ability to pre-compile code e.g. into V8 code cache format before distributing it to the edge.
- curiousdannii 8y ago
  What about Module.instantiateWasm()? That should let you provide a pre-compiled or even pre-instantiated module.
deleted 8y ago
[deleted]

zackbloom 8y ago

Each person can take their own meaning away from this, but for me the most impressive part will always be @kentonv's hand-rolled libc replacement: https://github.com/cloudflare/cloudflare-workers-wasm-demo/blob/master/bootstrap.h https://github.com/cloudflare/cloudflare-workers-wasm-demo/b...

jgrahamc 8y ago
You're no C programmer, Zack. Anyone who's done any real C programming has implemented their own malloc.
- geofft 8y ago
  (Is this an in-joke I'm missing or something?)
  - Smerity 8y ago
    It's polite ribbing amongst work colleagues where an engineer at Cloudflare (@zackbloom) offers praise to a colleague (@kentonv) for a mighty project (libc replacement) and Cloudflare's CTO (@jgrahamc) jokes that the project isn't hardcore enough ;) tldr; Appears very much an in-joke between work colleagues at Cloudflare :)
    - jgrahamc 8y ago
      Correct. Not so much an in-joke. I was just surprised Zack thought implementing your own libc was amazing. But I'm an old fart C/assembly programmer so YMMV.
      - zackbloom 8y ago
        Having the top-comment doesn't lie, THE PEOPLE ARE WITH ME! Also, is there a badge or sash I can get somewhere saying "Not a Real C Programmer"?
        8y ago

elsigh 8y ago

There is such a steady stream of excellent work and innovation coming from Cloudflare these days - it's pretty amazing.

IanCal 8y ago

Really interesting development, but I do wonder how well this fits with a 5-50ms CPU time limit. Are there plans to change this? Or allow charging on higher use or something?

kentonv 8y ago
Indeed, introducing WebAssembly paradoxically creates more demand to increase the CPU time limits -- because with WebAssembly, it's actually reasonable to imagine doing signal processing in Workers, whereas in pure JavaScript it made less sense. We'll probably need to go back and re-evaluate the CPU time limits in the near future. In the meantime, feel free to contact us if you have a specific use case in mind that doesn't seem to be fitting the limits, and we'll figure something out.
eastdakota 8y ago
Yes. We plan to increase the CPU limits. In the meantime, if you're hitting limits, reach out to us and we can usually turn them up for you.

devwastaken 8y ago

The web was supposed to be open, but if the technologies are only well implimented privately it's not open at all. Props to cloudflare certainly, but this is a further nail in the coffin of open software. Wasm was supposed to be well useable outside the browser and to date there are no well made libraries that deliver on it. It's all experimentation in the open. Technology that I cannot use well in my own applications is effectively proprietary.

ryanworl 8y ago
You can use WASM from Node. There is even an open source module called “isolated-vm” which implements a similar security scheme to the one employed by Cloudflare. You could install that on whatever you want and run essentially the same thing (minus the rest of Cloudflare, obviously).
- devwastaken 8y ago
  https://blog.cloudflare.com/introducing-cloudflare-workers/ https://blog.cloudflare.com/introducing-cloudflare-workers/ the original workers release explains why they dont use node and instead build with v8 directly. Node is not a cure all. It's for prototyping with wasm. You need significantly more integration with the execution environment to have DOS protection. How cloudflare does this I don't know. They'd have to remove features like multithreading and continually patch around v8 afaik. Even spidermonkies API is unuseable in a server context.
  - ryanworl 8y ago
    I know what Cloudflare workers are. Did you look at isolated-vm? It uses the V8 isolate API exactly how Cloudflare describes it being used, except it is exposed as a Node module so you can write the “parent” process in JavaScript instead of C++. It exposes memory limits and wall & cpu time limits. It is sponsored by the Fly.io CDN from what I can tell for exactly the same use case as Cloudflare workers.
    - devwastaken 8y ago

mwcampbell 8y ago

What's the limit on code size? I imagine we'll have to be careful about bringing in large existing libraries.

rita3ko 8y ago
The limit on the code (the Worker + WASM), after compression is 1MB. Please reach out if you run into limitations with it (rita at cloudflare).
- mwcampbell 8y ago
  Thank you. Is that documented somewhere?
  - rita3ko 8y ago
    https://developers.cloudflare.com/workers/writing-workers/storing-data/ https://developers.cloudflare.com/workers/writing-workers/st... it’s mentioned in here
    - mwcampbell 8y ago
      Ah, OK. That doesn't mention that the 1 MB limit is after compression, though.
      - kentonv 8y ago
        Being post-compression is actually new and currently only applies if you use WASM, though we'll extend it to everyone soon (and document it).
- justinclift 8y ago
  Heh Heh Heh Minimum size of wasm files generated by Go (so far) looks to be 2MB. That should improve over time. Go wasm is currently hard coded to target browser environments too. Another thing which should improve down the track.