2 ms·

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 iss

by 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...
- lvh 9y ago
  I'll repeat myself: it is not an implementation problem that a compliant implementation needs to do necessarily more work. You say: > there's a simple one: Hitting the stack less means you hit less memory. But I explicitly acknowledge this in my comment: > (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) (Completely ignoring that there are already plenty of optimizations where a compliant interpreter may avoid the stack frame already anyway, so it's not even true that PTC must be faster for that reason.) You keep picking on V8, but remember that there is so far only 1 major JS implementation that managed to do this without impact. It would seem that it's more probable that it's the other way around: it's an implementation detail that JSC had it easy. > 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. I'd be happy to address this point, but I genuinely don't know which straw man I've supposedly built.
  - geocar 9y ago
    > > > 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. > But I explicitly acknowledge this in my comment! Not really sure what your point is. If you agree that's an argument as to why tail-call elimination should be intrinsically faster, I'm not sure why you'd say it isn't. I can't shake this feeling you think you're having a very different argument than I am. > remember that there is so far only 1 major JS implementation that managed to do this without impact. Which for some reason you think means this isn't an implementation issue.
    - lvh 9y ago
      > But I explicitly acknowledge this in my comment! I did not put an exclamation mark there, but a colon, pointing out the specific reason why PTC can end up slower.

by lvh 9y ago

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...

lvh 9y ago
I'll repeat myself: it is not an implementation problem that a compliant implementation needs to do necessarily more work. You say: > there's a simple one: Hitting the stack less means you hit less memory. But I explicitly acknowledge this in my comment: > (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) (Completely ignoring that there are already plenty of optimizations where a compliant interpreter may avoid the stack frame already anyway, so it's not even true that PTC must be faster for that reason.) You keep picking on V8, but remember that there is so far only 1 major JS implementation that managed to do this without impact. It would seem that it's more probable that it's the other way around: it's an implementation detail that JSC had it easy. > 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. I'd be happy to address this point, but I genuinely don't know which straw man I've supposedly built.
- geocar 9y ago
  > > > 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. > But I explicitly acknowledge this in my comment! Not really sure what your point is. If you agree that's an argument as to why tail-call elimination should be intrinsically faster, I'm not sure why you'd say it isn't. I can't shake this feeling you think you're having a very different argument than I am. > remember that there is so far only 1 major JS implementation that managed to do this without impact. Which for some reason you think means this isn't an implementation issue.
  - lvh 9y ago
    > But I explicitly acknowledge this in my comment! I did not put an exclamation mark there, but a colon, pointing out the specific reason why PTC can end up slower.