Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

V8 has optimized new JavaScript language features (2018)

github.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: V8 has optimized new JavaScript language features (2018)

#41

Post by gsathya_hn »

chrismorgan wrote: post #4

> const performs a lot better in optimized code than var or let This puzzles me; if only ever one value is assigned, I would have expected at least let to perform identically to const in optimised code, because I expect the optimiser to look at the let and say “never reassigned, turn it into a const ”. By the sound of it, I’m wrong, and I’d be interested to know why I’m wrong.

The doc is incorrect, `let`(and even `var`) does perform as well as `const` in optimized code (but it comes with performance cliffs, if there is a re-assignment).

Re: V8 has optimized new JavaScript language features (2018)

#42

Post by miloignis »

gfxgirl wrote: post #35
chrisseaton wrote: post #10

Earlier quoted context omitted.

These checks can be completely free, in terms of runtime cost, through deoptimisation.

How? You have to do some kind of check with let, and you don't with const.

Not sure if V8 does this, but a general strategy used in HotSpot is to compile assuming the good case and install a "trap" to deoptimize the code if the condition is violated. So you could compile the let like a const with no checks on the use of the variable, but have a trap such that if any code ever tries to assign to that variable, all code compiled under the assumption that it was constant is throw out.

Re: V8 has optimized new JavaScript language features (2018)

#43

Post by chrisseaton »

klodolph wrote: post #40
chrisseaton wrote: post #24

Earlier quoted context omitted.

> just with static analysis You're not doing static analysis - you're doing dynamic analysis and speculation. But this has the downsides I said - it's more complicated, it takes more time, etc.

What speculation? If you have a "let" in some lexical scope, AND this is strict mode, AND there are no calls to eval in that scope, AND there are no assignments within that scope... how is that different from const? I can understand why in a JavaScript engine there may be plenty of other concerns and it may be completely reasonable to not do the analysis, but in the common case it should (at least) be something you c…

> What speculation?

Speculating that a debugger is not attached and modifying local variables, is one example.

> in the common case it should (at least) be something you could do just by walking the AST

Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases.

Re: V8 has optimized new JavaScript language features (2018)

#44

Post by Dylan16807 »

chrisseaton wrote: post #43
klodolph wrote: post #40

Earlier quoted context omitted.

What speculation? If you have a "let" in some lexical scope, AND this is strict mode, AND there are no calls to eval in that scope, AND there are no assignments within that scope... how is that different from const? I can understand why in a JavaScript engine there may be plenty of other concerns and it may be completely reasonable to not do the analysis, but in the common case it should (at least) be something you c…

> What speculation? Speculating that a debugger is not attached and modifying local variables, is one example. > in the common case it should (at least) be something you could do just by walking the AST Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases.

> Speculating that a debugger is not attached and modifying local variables, is one example.

A debugger can do anything. You can't outthink a debugger and shouldn't try.

> Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases.

Speculation is when you guess and need to have a guard in case the guess is wrong. They're describing a situation where it can't be wrong and you wouldn't need to speculate.

Re: V8 has optimized new JavaScript language features (2018)

#45

Post by chmod775 »

bufferoverflow wrote: post #31

I'm pretty sure destructuring is still slow as hell. Like if you want to clone an array, arr.slice(0) is 3x faster than [...arr]

I mean yeah... You're telling the engine to do 2 different things there that just may have the same end-result.

The results diverge specifically when your array contains empty items, which will be converted to items containing undefined with the latter expression.

The JS engine would need a specific optimization for cases where:

- The expression is equivalent to arr.slice(0)

- The iterator being de-structured is a vanilla array

- The array doesn't contain any empty items

Of course your code will be faster when all that's required is just a shallow copy.

Re: V8 has optimized new JavaScript language features (2018)

#46

Post by chrisseaton »

Dylan16807 wrote: post #44
chrisseaton wrote: post #43

Earlier quoted context omitted.

> What speculation? Speculating that a debugger is not attached and modifying local variables, is one example. > in the common case it should (at least) be something you could do just by walking the AST Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases.

> Speculating that a debugger is not attached and modifying local variables, is one example. A debugger can do anything. You can't outthink a debugger and shouldn't try. > Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases. Speculation is when you guess and need to have a guard in case the guess is wrong. They're describing a situation where it can't be wrong and you would…

> A debugger can do anything. You can't outthink a debugger

Yes that's what we're saying. So you deoptimise when someone starts debugging.

> and shouldn't try

You'd get extremely slow code with this approach!

> Speculation is when you guess and need to have a guard in case the guess is wrong.

Yes, you're guessing that nobody will attach a debugger and you're guarding that no debugger has been attached. That guard is usually implicit.

> They're describing a situation where it can't be wrong and you wouldn't need to speculate.

It can be wrong... if someone's using a debugger. So you need to speculate that they aren't using a debugger.

I wrote a PhD about using speculation and deoptimisation to solve the problem of people debugging optimised code.

Re: V8 has optimized new JavaScript language features (2018)

#47

Post by [deleted] »

jacobolus wrote: post #32
saurik wrote: post #19

In stark contrast: "Using const/let instead of var can make JavaScript code run 10× slower in Webkit" ;P. https://news.ycombinator.com/item?id=24844353

YMMV, but I find that Safari uses dramatically fewer local resources on my computer than Chrome does, for the same workload. Chrome can’t remotely handle the number of tabs I typically keep open (it chews up all available memory, and hangs or crashes). Even for lighter browsing usage, Chrome chews battery faster and slows the rest of my computer down. Overall Safari is the most usable, followed by Firefox. In various…

[deleted]

Re: V8 has optimized new JavaScript language features (2018)

#48

Post by Dylan16807 »

chrisseaton wrote: post #46
Dylan16807 wrote: post #44

Earlier quoted context omitted.

> Speculating that a debugger is not attached and modifying local variables, is one example. A debugger can do anything. You can't outthink a debugger and shouldn't try. > Yes that’s why it’s speculation - handle the common cases and speculate away the uncommon cases. Speculation is when you guess and need to have a guard in case the guess is wrong. They're describing a situation where it can't be wrong and you would…

> A debugger can do anything. You can't outthink a debugger Yes that's what we're saying. So you deoptimise when someone starts debugging. > and shouldn't try You'd get extremely slow code with this approach! > Speculation is when you guess and need to have a guard in case the guess is wrong. Yes, you're guessing that nobody will attach a debugger and you're guarding that no debugger has been attached. That guard is…

> You'd get extremely slow code with this approach!

You must be interpreting that differently than I meant it. The approach I'm suggesting is "pretend debuggers don't exist when optimizing". It gives you the fast code.

A debugger can break any assumption you make. Even unoptimized code could crash if a debugger messes with it. The fear of a debugger should never make you decide not to do an optimization.

How would you use a guard if you want to deoptimize because a debugger attached? You'd have to have a guard between each instruction, and even then it might not be enough.

> Yes, you're guessing that nobody will attach a debugger and you're guarding that no debugger has been attached. That guard is usually implicit.

> So you deoptimise when someone starts debugging.

If an "implicit" guard means "we'll have a function the debugger calls, telling us to redo the compilation", then that's not something you need to do dynamic analysis for, and it doesn't make your compilation more complicated. You don't "speculate away" that case unless you're using the word "speculate" to include "completely ignore for now, without even a guard", which I didn't think fell under that umbrella. Does it?

> It can be wrong... if someone's using a debugger.

It's not wrong. A debugger can make 2+2 be 5. Debuggers don't follow any rules, but that doesn't mean your compiler should try (and inevitably fail) to make code that works in a world where no rules exist.

Re: V8 has optimized new JavaScript language features (2018)

#49

Post by chrisseaton »

Dylan16807 wrote: post #48
chrisseaton wrote: post #46

Earlier quoted context omitted.

> A debugger can do anything. You can't outthink a debugger Yes that's what we're saying. So you deoptimise when someone starts debugging. > and shouldn't try You'd get extremely slow code with this approach! > Speculation is when you guess and need to have a guard in case the guess is wrong. Yes, you're guessing that nobody will attach a debugger and you're guarding that no debugger has been attached. That guard is…

> You'd get extremely slow code with this approach! You must be interpreting that differently than I meant it. The approach I'm suggesting is "pretend debuggers don't exist when optimizing". It gives you the fast code. A debugger can break any assumption you make. Even unoptimized code could crash if a debugger messes with it. The fear of a debugger should never make you decide not to do an optimization. How would yo…

I think it's just a case of me using more generalised terminology.

'pretend X doesn't exist' is in my mind 'speculate that X isn't enabled'. It really means the same thing doesn't it?

You don't need a guard between every instruction, as attaching the debugger is an async option - it's already non-deterministic when the application will receive the instruction to move to debug mode, so as long as it checks frequently enough (usually once per loop iteration and once per function call) it's enough.

I think "we'll have a function the debugger calls, telling us to redo the compilation" does describe speculation and deoptimisation. Remember the function may be currently executing and may never return, so it's not as simple as replacing it with a different version. You may need to replace it while it's running.

It does make compilation more complicated because you need to be able to restore the full debug state of the application, which means storing some results you may not choose to do otherwise, and storing extra meta-data.

> Debuggers don't follow any rules

Debuggers can be a formally or informally specified part of the language, and their behaviour may have to follow rules about which intermediate results are visible which may constrain your compilation.

My argument is: if you do treat debugging as speculation then your model is simpler and easier to work with and you don't need two kinds of deoptimisation. Real languages are implemented this way.

Here's two papers I've written about these topics taking the idea even further.

https://chrisseaton.com/truffleruby/icooolps15-safepoints/sa...

https://www.lifl.fr/dyla14/papers/dyla14-3-Debugging_at_Full...

Post reply on HN