4 ms·
it's sad that they didn't go the same way than fastly which actually use a wasm runtime even for javascript by compiling spidermonkey to wasm: https://github.co
by merb 4y ago
it's sad that they didn't go the same way than fastly which actually use a wasm runtime even for javascript by compiling spidermonkey to wasm: https://github.com/fastly/js-compute-runtime https://github.com/fastly/js-compute-runtime
I think thats way more clever than having a mixed runtime.
and they use wizer to make it more performant.
- azakai 4y agoThe Fastly approach has some advantages for wasm, but Cloudflare have mentioned that the vast majority of their users want JavaScript and TypeScript. Cloudflare's approach is more optimized for that: running a JS VM directly will take a lot less overhead than one compiled to wasm atm (since JS VMs depend heavily on JITing, and compiled JS VMs will have a much larger memory footprint due to the bundled compiled runtime). It's possible that Cloudflare and Fastly users are different enough that different approaches make sense.
- vlovich123 4y agoIt’s a clever technique no doubt. In practice for JS-centric workloads (which we’ve found is the bulk of demand), using V8 is still much much more efficient, has faster performance than Wizer’s approach and easier to scale out (the scale that Workers runs at can boggle the mind). We are trying to figure out how to move more of the API parts of runtime to something not c++ without significantly negatively impacting memory / CPU (safety, correctness, speed of development, etc). It’s an interesting problem to try to do at Cloudflare scale.
- merb 4y agothanks for the info, well yeah wizer still does not make it as fast as c++ v8