5 ms·

Webkit was probably one of the last major web engines to start integrating ES6 features, yet they have TCOs done. Anyone explain what's holding it up in Chrome/

by swang 10y ago

Webkit was probably one of the last major web engines to start integrating ES6 features, yet they have TCOs done. Anyone explain what's holding it up in Chrome/FF/Edge?

nostrademons 10y ago
There's some debate over whether tailcalls should be explicit or implicit, and Chrome/FF/Edge are leaning towards the explicit side: https://news.ycombinator.com/item?id=11563305 https://news.ycombinator.com/item?id=11563305
paulirish 10y ago
There's been heavy discussion (especially recently) on the value of implicit TCO for developers. I believe all three V8/Chakra/Spidermonkey all found TCO regresses performance a bit. Additionally, it hampers debugging considerably as call stacks are completely twisted. There's been a lot of active discussion between browser vendors and TC39 recently to sort out a path forward. All teams are excited about explicit TCO syntax, but there remains skepticism that implicit TCO is good for users or developers.
- Someone1234 10y ago
  TCO is "tail call optimization" if anyone is trying to figure it out.
- j_jochem 10y ago
  How does tail call optimization cause a regress in performance? Superficially, it seems very counter-intuitive that this should even be possible.
  - pizlonator 10y ago
    It's not a performance regression in JSC. Maybe the other implementations aren't as good as JSC's.
    - munificent 10y ago
      Shots fired.
  - __s 10y ago
    Messes with calling conventions. Citing Rust: https://mail.mozilla.org/pipermail/rust-dev/2013-April/003557.html https://mail.mozilla.org/pipermail/rust-dev/2013-April/00355...
    - pizlonator 10y ago
      I agree that it messes with calling conventions. This is a problem for AOT languages, where binary compatibility is paramount and so you cannot change the calling convention. Since tail calls don't play well with existing native conventions, they end up being hard (or sometimes even impossible) to implement. That's not really an issue in JS or other VM-based languages. JS VMs don't make their internal calling conventions public. In JSC, our old calling convention was incompatible with PTC, so we changed our calling convention to make PTCs work.
    - astrange 10y ago
      GCC/Clang can generate code with tail calls, if you don't mind losing the stack frame. And I don't think they have any issue tail-calling external libraries on the ABIs I know. How are these different?
    - steveklabnik 10y ago
      It's worth noting that's from 2013; in my understanding, things have changed in LLVM since then, which was another big blocker.
LittleDan 10y ago
We wrote about this in detail in http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.html http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.htm... under the heading "Proper Tail Calls". tl;dr we implemented it, it works, but we are not shipping it because we believe it would hurt developers to lose some stack frames from Error.stack in existing sites, among other issues.
- Dylan16807 10y ago
  If the main worry is information loss when debugging, why not figure out a mechanism that's 98% accurate but much more efficient than a full redundant shadow stack? For example, you could compact the stack every 200 frames it grows, but never remove frames in the top 50 or bottom 50. How often in practice would that give you a misleading view of the stack? (Assume that each frame keeps track of how many tail frames are omitted after it. If needed, assume that tail frames within X distance of a non-tail frame will not be omitted ever.)
  - pizlonator 10y ago
    We figured out such a mechanism and we call it ShadowChicken: http://trac.webkit.org/changeset/199076 http://trac.webkit.org/changeset/199076 It works great!
    - raattgift 10y ago
      One of the things I like most about WebKit is that several of you reliably write awesomely informative commit messages. (I hope Felix sees this particular commit sometime; I think he might feel a little flattered! Also, wow, that's an excellent summary by Peter Bex.) Another is that you keep looking into old quiet dark corners of language nerdery and actually make use of the good ideas lurking there (notably while retaining the "no performance regressions EVER" tyranny). I think there are some neat ideas Chicken Scheme's compiler too. Also, did you have a raiding party on T when doing DFG? (cf. Olin Shivers at http://www.paulgraham.com/thist.html http://www.paulgraham.com/thist.html starting with the paragraph, "This brings us to the summer of 1984. The mission was to build the world's most highly-optimising Scheme compiler." and notably also the paragraphs starting "Richard Kelsey..." and "Norman Adams...". . Always take ideas from Shivers, at least if they're faster in practice. Also, sorry for the several edits. I forgot how good this overview was, and how much meat is in it.)

by swang 10y ago

Webkit was probably one of the last major web engines to start integrating ES6 features, yet they have TCOs done. Anyone explain what's holding it up in Chrome/FF/Edge?

nostrademons 10y ago

There's some debate over whether tailcalls should be explicit or implicit, and Chrome/FF/Edge are leaning towards the explicit side: https://news.ycombinator.com/item?id=11563305 https://news.ycombinator.com/item?id=11563305

paulirish 10y ago

There's been heavy discussion (especially recently) on the value of implicit TCO for developers. I believe all three V8/Chakra/Spidermonkey all found TCO regresses performance a bit. Additionally, it hampers debugging considerably as call stacks are completely twisted. There's been a lot of active discussion between browser vendors and TC39 recently to sort out a path forward. All teams are excited about explicit TCO syntax, but there remains skepticism that implicit TCO is good for users or developers.

Someone1234 10y ago
TCO is "tail call optimization" if anyone is trying to figure it out.
j_jochem 10y ago
How does tail call optimization cause a regress in performance? Superficially, it seems very counter-intuitive that this should even be possible.
- pizlonator 10y ago
  It's not a performance regression in JSC. Maybe the other implementations aren't as good as JSC's.
  - munificent 10y ago
    Shots fired.
- __s 10y ago
  Messes with calling conventions. Citing Rust: https://mail.mozilla.org/pipermail/rust-dev/2013-April/003557.html https://mail.mozilla.org/pipermail/rust-dev/2013-April/00355...
  - pizlonator 10y ago
    I agree that it messes with calling conventions. This is a problem for AOT languages, where binary compatibility is paramount and so you cannot change the calling convention. Since tail calls don't play well with existing native conventions, they end up being hard (or sometimes even impossible) to implement. That's not really an issue in JS or other VM-based languages. JS VMs don't make their internal calling conventions public. In JSC, our old calling convention was incompatible with PTC, so we changed our calling convention to make PTCs work.
  - astrange 10y ago
    GCC/Clang can generate code with tail calls, if you don't mind losing the stack frame. And I don't think they have any issue tail-calling external libraries on the ABIs I know. How are these different?
  - steveklabnik 10y ago
    It's worth noting that's from 2013; in my understanding, things have changed in LLVM since then, which was another big blocker.

LittleDan 10y ago

We wrote about this in detail in http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.html http://v8project.blogspot.com/2016/04/es6-es7-and-beyond.htm... under the heading "Proper Tail Calls". tl;dr we implemented it, it works, but we are not shipping it because we believe it would hurt developers to lose some stack frames from Error.stack in existing sites, among other issues.

Dylan16807 10y ago
If the main worry is information loss when debugging, why not figure out a mechanism that's 98% accurate but much more efficient than a full redundant shadow stack? For example, you could compact the stack every 200 frames it grows, but never remove frames in the top 50 or bottom 50. How often in practice would that give you a misleading view of the stack? (Assume that each frame keeps track of how many tail frames are omitted after it. If needed, assume that tail frames within X distance of a non-tail frame will not be omitted ever.)
- pizlonator 10y ago
  We figured out such a mechanism and we call it ShadowChicken: http://trac.webkit.org/changeset/199076 http://trac.webkit.org/changeset/199076 It works great!
  - raattgift 10y ago
    One of the things I like most about WebKit is that several of you reliably write awesomely informative commit messages. (I hope Felix sees this particular commit sometime; I think he might feel a little flattered! Also, wow, that's an excellent summary by Peter Bex.) Another is that you keep looking into old quiet dark corners of language nerdery and actually make use of the good ideas lurking there (notably while retaining the "no performance regressions EVER" tyranny). I think there are some neat ideas Chicken Scheme's compiler too. Also, did you have a raiding party on T when doing DFG? (cf. Olin Shivers at http://www.paulgraham.com/thist.html http://www.paulgraham.com/thist.html starting with the paragraph, "This brings us to the summer of 1984. The mission was to build the world's most highly-optimising Scheme compiler." and notably also the paragraphs starting "Richard Kelsey..." and "Norman Adams...". . Always take ideas from Shivers, at least if they're faster in practice. Also, sorry for the several edits. I forgot how good this overview was, and how much meat is in it.)