5 ms·
Seemingly https://v8.dev/blog/wasm-tail-call https://v8.dev/blog/wasm-tail-call
by k__ 3y ago
Seemingly
https://v8.dev/blog/wasm-tail-call https://v8.dev/blog/wasm-tail-call
- csjh 3y agoSupport is still mediocre (mainly because of safari)
- odyssey7 3y agoNice! Is there hope that V8 will also support proper tail calls in JavaScript? Update: The ticket for v8 to support JavaScript tail call optimization remains open but hasn’t been updated in a couple years. https://bugs.chromium.org/p/v8/issues/detail?id=4698 https://bugs.chromium.org/p/v8/issues/detail?id=4698
- k__ 3y agoYes, there were some discussions about explicit tail call optimizations being the better solution.
- odyssey7 3y agoInteresting, why would adding an optimize this keyword to JavaScript be better?
- skrebbel 3y agoI don’t know their motivations, but having the same code work fine on one JS engine / browser / browser version, but totally stack overflow on another seems like suboptimal to me. Explicit tail calls let you error out properly at the call site, Babel-style downcompile it to a loop of some sort, all that stuff.
- odyssey7 3y agoThis could be surprising, but the scenario already exists in production. In JavaScript's strict mode, Safari applies tail call optimization, but systems relying on V8 don't. To illustrate, the following code causes a stack overflow for me in both Google Chrome and in Node.js, but runs without issue in Safari. "use strict"; const countdown = (n) => n == 0 ? console.log('done') : countdown(n-1); countdown(100000);
- shadowbanned4 3y agothe same discussion is going on with rust. it lets the compiler enforce that you're actually using a tail call, instead of silently optimizing it when it sees it and otherwise being silent.
- IshKebab 3y agoGenerally the people that care about tail calls write code that relies on them. It isn't just an optimisation. The code is broken (will cause a stack overflow) if TCO isn't applied. So you need to guarantee it.
- odyssey7 3y agoIf I try to trace through the risk profile of bringing TCO into software engineers’ toolkits, it seems that the fear would be of the software engineers growing recursion-happy and writing functions that overflow the stack by inadvertently not leveraging TCO, more than they write recursive functions today that overflow the stack given that V8 offers no possibility of TCO at all? It just doesn’t add up, V8 with TCO and no safety keyword would simply be better than V8 today with neither, so it would still be a strange basis for not delivering the feature. I personally had the opposite experience on this one. I had always been told that V8 was a highly efficient JavaScript engine, so I didn’t really worry about writing recursive functions to which I had assumed such a fundamental optimization would be applied. After all, TCO will take a recursive call that would have O(n) space complexity, where n is the recursion depth, and evaluate it in just O(1) — it didn’t seem possible that a highly optimized JavaScript engine would miss something so fundamental. I was both surprised and disappointed when I found out I wouldn’t be able to safely use recursion in JavaScript code that would run on Google Chrome, Android, or Node.js, unless I could guarantee a relatively small depth.
- davexunit 3y agoYup! Hoot uses return_call and friends extensively. Chrome ships tail calls as of 119, Firefox will have them on by default in 4 days when 121 is released, and Safari will have them... at some point.