5 ms·

> their support for ES6 features beats all the other browsers That's really grasping for straws. All modern browsers almost fully support ES6 features. Tail op

by ko27 9y ago

> their support for ES6 features beats all the other browsers That's really grasping for straws. All modern browsers almost fully support ES6 features. Tail optimization are more controversial because they can actually lead to a performance decrease in some cases. Far more important are things like custom elements and service workers on which Safari is lagging behind.

geocar 9y ago
> Tail optimization are more controversial because they can actually lead to a performance decrease in some cases. How exactly can the tail-call elimination optimization decrease performance? Sounds more like an implementation problem.
- lvh 9y ago
  Both TCO and PTC can decrease performance easily for a bunch of reasons. TC39 addressed this[0] when considering explicit tail call sites. Reasons vary from Windows ABI (Chakra) to something as simple as "now I have to figure out if this is really a PTC" -- and if your function has a PTC but that only gets invoked once, it's not hard to see how the extra analysis pressure doesn't weigh up to the elided stack frame. JS engines were already extremely optimized, it's not like you're taking a CS student's first lisp interpreter and adding TCO. (Fortunately, some of the litmus tests for whether you can apply PTC are encapsulated within strict mode, and the compiler stages definitely know that for free already.) [0]: https://github.com/tc39/proposal-ptc-syntax#performance https://github.com/tc39/proposal-ptc-syntax#performance
  - geocar 9y ago
    I remain unconvinced that just because it's difficult for a couple of JavaScript implementations, that we're still not talking about an implementation problem. How exactly does anyone think that v8 doing something badly, is proof that something cannot be done well?
    - lvh 9y ago
      I don't know which "anyone" you're referring to, but the argument I made about analysis pressure isn't implementation-specific, and neither are the concrete issues raised in both the TC39 notes I linked and elsewhere (they affect Chakra primarily, and *Monkey/V8 secondarily). The parts of a JS implementation (or really, any JIT) that decides to inline portions of code, attempt to detect loops and unroll them,... are already central to those implementations. I hope it's not difficult to see why a change that directly impacts that might have negative consequences elsewhere. Indeed, _because_ this is implicit and part of the spec, implementations can't take the simple multi-staged path they did before: they _have to_ do the PTC dance. I've heard no argument why the PTC mode should be intrinsically faster than the non-PTC mode (yes; you elide a stack frame at the cost of a whole-function analysis pass -- heuristically, "stack frame" isn't the expensive one of the two). This is why STC was proposed: it allows an impl to decide at _one_ location how to handle a function, in an obvious-to-the-parser way. No other code paths are affected. To contrast with PTC: even a compiler that knows with epistemological certainty that a particular call will happen only once or even never, _still has to do the PTC dance_. However, you're asking me to prove a negative. I've given arguments, which apparently you find unconvincing. The people you are disagreeing with (not I) are responsible about 85% of the JavaScript engines on the Internet, an incredibly competitive space with billions in funding. I submit that they are probably neither incompetent nor lazy. (Evidence for "not lazy": the V8 team implemented it and turned it off.) If you are convinced that it's a (presumably fixable) implementation problem, I'm sure they'd love a patch or at least something more actionable than your insistence that they're doing it wrong.
      - geocar 9y ago
        > I hope it's not difficult to see why a change that directly impacts that might have negative consequences elsewhere. Sure, but at the risk of repeating myself: That sounds like an implementation problem. > I've heard no argument why the PTC mode should be intrinsically faster than the non-PTC mode There's a simple one: Hitting the stack less means you hit less memory. > The people you are disagreeing with (not I) are responsible about 85% of the JavaScript engines on the Internet, an incredibly competitive space with billions in funding. ... I'm sure they'd love a patch Happy to oblige. I'll implement TCO on V8 for a billion dollars in a way that beats these benchmarks. > However, you're asking me to prove a negative. And you're making straw men instead: At the beginning of your response, it's not even clear you read my complaint, but at the end, it's quite clear. The simple answer would probably have been "yes, it's about an implementation, but it remains unknown where else we can go", but instead you doubled down...
zghst 9y ago
It's not really important if the community is ambivalent on using it. Who here opts for using custom elements (and the extra work) over a library like Vue, React or Angular? Is there even a consideration on how these new features become just another tool to spy on people? To me it is far more important that Apple take its time letting these APIs mature and being reviewed for security and performance than blindly implementing anything that Google demands.

by ko27 9y ago

geocar 9y ago

> Tail optimization are more controversial because they can actually lead to a performance decrease in some cases. How exactly can the tail-call elimination optimization decrease performance? Sounds more like an implementation problem.

lvh 9y ago
Both TCO and PTC can decrease performance easily for a bunch of reasons. TC39 addressed this[0] when considering explicit tail call sites. Reasons vary from Windows ABI (Chakra) to something as simple as "now I have to figure out if this is really a PTC" -- and if your function has a PTC but that only gets invoked once, it's not hard to see how the extra analysis pressure doesn't weigh up to the elided stack frame. JS engines were already extremely optimized, it's not like you're taking a CS student's first lisp interpreter and adding TCO. (Fortunately, some of the litmus tests for whether you can apply PTC are encapsulated within strict mode, and the compiler stages definitely know that for free already.) [0]: https://github.com/tc39/proposal-ptc-syntax#performance https://github.com/tc39/proposal-ptc-syntax#performance
- geocar 9y ago
  I remain unconvinced that just because it's difficult for a couple of JavaScript implementations, that we're still not talking about an implementation problem. How exactly does anyone think that v8 doing something badly, is proof that something cannot be done well?
  - lvh 9y ago
    I don't know which "anyone" you're referring to, but the argument I made about analysis pressure isn't implementation-specific, and neither are the concrete issues raised in both the TC39 notes I linked and elsewhere (they affect Chakra primarily, and *Monkey/V8 secondarily). The parts of a JS implementation (or really, any JIT) that decides to inline portions of code, attempt to detect loops and unroll them,... are already central to those implementations. I hope it's not difficult to see why a change that directly impacts that might have negative consequences elsewhere. Indeed, _because_ this is implicit and part of the spec, implementations can't take the simple multi-staged path they did before: they _have to_ do the PTC dance. I've heard no argument why the PTC mode should be intrinsically faster than the non-PTC mode (yes; you elide a stack frame at the cost of a whole-function analysis pass -- heuristically, "stack frame" isn't the expensive one of the two). This is why STC was proposed: it allows an impl to decide at _one_ location how to handle a function, in an obvious-to-the-parser way. No other code paths are affected. To contrast with PTC: even a compiler that knows with epistemological certainty that a particular call will happen only once or even never, _still has to do the PTC dance_. However, you're asking me to prove a negative. I've given arguments, which apparently you find unconvincing. The people you are disagreeing with (not I) are responsible about 85% of the JavaScript engines on the Internet, an incredibly competitive space with billions in funding. I submit that they are probably neither incompetent nor lazy. (Evidence for "not lazy": the V8 team implemented it and turned it off.) If you are convinced that it's a (presumably fixable) implementation problem, I'm sure they'd love a patch or at least something more actionable than your insistence that they're doing it wrong.
    - geocar 9y ago
      > I hope it's not difficult to see why a change that directly impacts that might have negative consequences elsewhere. Sure, but at the risk of repeating myself: That sounds like an implementation problem. > I've heard no argument why the PTC mode should be intrinsically faster than the non-PTC mode There's a simple one: Hitting the stack less means you hit less memory. > The people you are disagreeing with (not I) are responsible about 85% of the JavaScript engines on the Internet, an incredibly competitive space with billions in funding. ... I'm sure they'd love a patch Happy to oblige. I'll implement TCO on V8 for a billion dollars in a way that beats these benchmarks. > However, you're asking me to prove a negative. And you're making straw men instead: At the beginning of your response, it's not even clear you read my complaint, but at the end, it's quite clear. The simple answer would probably have been "yes, it's about an implementation, but it remains unknown where else we can go", but instead you doubled down...

zghst 9y ago

It's not really important if the community is ambivalent on using it. Who here opts for using custom elements (and the extra work) over a library like Vue, React or Angular? Is there even a consideration on how these new features become just another tool to spy on people? To me it is far more important that Apple take its time letting these APIs mature and being reviewed for security and performance than blindly implementing anything that Google demands.