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

Why the New V8 Is So Damn Fast

nodesource.com

Post reply on HN
Print view View original

31–40 of 237 posts

Re: Why the New V8 Is So Damn Fast

#31

Post by chii »

chrisseaton wrote: post #18
barbegal wrote: post #9

I used to believe that javascript was slow, C was fast and that there was no way to change this because of the way that javascript is interpreted and not compiled. But the more I've learnt about the benefits of "on the fly" / "just in time" optimising compilers, the more I'm convinced this is the future of computing. Being able to use multiple threads and hence multiple cores simultaneously to optimise what is actual…

In my group at Oracle we're experimenting with running C using the same just-in-time compilation techniques that JavaScript uses, and sometimes we see it running faster than ahead-of-time native compilation, due to the effects of things like inline caching and profiling.

> sometimes we see it running faster than ahead-of-time native compilation, due to the effects of things like inline caching and profiling.

which is what java touts as being able to do. Unfortunately, i think this sort of speedup is really dependent on the application (and the developer using common idioms that is recognized by the JIT).

Re: Why the New V8 Is So Damn Fast

#32

Post by stochastic_monk »

saagarjha wrote: post #14
barbegal wrote: post #9

I used to believe that javascript was slow, C was fast and that there was no way to change this because of the way that javascript is interpreted and not compiled. But the more I've learnt about the benefits of "on the fly" / "just in time" optimising compilers, the more I'm convinced this is the future of computing. Being able to use multiple threads and hence multiple cores simultaneously to optimise what is actual…

The key being that the code you're writing needs to be performant. If you write O(n!) code, it's going to be slow whether it's C or JavaScript.

Algorithms take you far. Optimized code takes you the rest of the way. If you’re after performance you’ll do both, of course. I’ve found that the only subfield of which I know in which mathematicians still write their own C or C++ is concise/efficient data structures and algorithms.

Re: Why the New V8 Is So Damn Fast

#33

Post by ehsanu1 »

chrisseaton wrote: post #18
barbegal wrote: post #9

I used to believe that javascript was slow, C was fast and that there was no way to change this because of the way that javascript is interpreted and not compiled. But the more I've learnt about the benefits of "on the fly" / "just in time" optimising compilers, the more I'm convinced this is the future of computing. Being able to use multiple threads and hence multiple cores simultaneously to optimise what is actual…

In my group at Oracle we're experimenting with running C using the same just-in-time compilation techniques that JavaScript uses, and sometimes we see it running faster than ahead-of-time native compilation, due to the effects of things like inline caching and profiling.

I suppose you're talking about sulong? https://github.com/graalvm/sulong

Pretty cool that it can run faster than AOT compiled C, any benchmarks or posts with more details on this?

Re: Why the New V8 Is So Damn Fast

#35

Post by chii »

chrisseaton wrote: post #20
gsnedders wrote: post #7

Earlier quoted context omitted.

You can't deduce that; you'd need to show that the object is never passed to for..in or Object.keys or similar to be able to avoid storing the insertion order. They could change the representation to not be insertion order dependent, and store insertion order in a separate data structure, but that has its own trade-offs.

You don't need to prove it, you just need to guess it successfully. If you're wrong you can deoptimise and fix-up to the same base-line performance.

> If you're wrong you can deoptimise and fix-up to the same base-line performance.

but how do you know it's wrong (if the iteration order of a .keys() call isnt the same)?

Re: Why the New V8 Is So Damn Fast

#36

Post by fasquoika »

gsnedders wrote: post #7
zawerf wrote: post #6

Why can't V8 deduce that the order of keys doesn't matter? It's pretty nuts that just rearranging the keys from { x, y, z } to { y, x, z } would cause a slowdown.

You can't deduce that; you'd need to show that the object is never passed to for..in or Object.keys or similar to be able to avoid storing the insertion order. They could change the representation to not be insertion order dependent, and store insertion order in a separate data structure, but that has its own trade-offs.

> you'd need to show that the object is never passed to for..in or Object.keys or similar, and unless you solve the halting problem, you can't do that.

This is pretty blatantly incorrect. Just because a problem is undecidable in general doesn't mean that there aren't specific cases where it can be solved. Optimizing compilers deal with undecidable problems all over the place, generally by either being conservative and lumping together proved-impossible with unable-to-be-proved invariants, or doing speculative optimizations with an unoptimized fallback. Just proving the type of a variable in Javascript is undecidable in the general case

Re: Why the New V8 Is So Damn Fast

#37

Post by gsnedders »

chrisseaton wrote: post #20
gsnedders wrote: post #7

Earlier quoted context omitted.

You can't deduce that; you'd need to show that the object is never passed to for..in or Object.keys or similar to be able to avoid storing the insertion order. They could change the representation to not be insertion order dependent, and store insertion order in a separate data structure, but that has its own trade-offs.

You don't need to prove it, you just need to guess it successfully. If you're wrong you can deoptimise and fix-up to the same base-line performance.

That would surely be the second option? Treating all permutations the same means changing the object representation to keep ICs monomorphic across orderings.

Unless you forbid any impure operations you can't just deoptimise and re-execute code to then store the ordering. (I'm sure this isn't what you meant, and I'm probably being silly!)

Re: Why the New V8 Is So Damn Fast

#39

Post by Negitivefrags »

barbegal wrote: post #9

I used to believe that javascript was slow, C was fast and that there was no way to change this because of the way that javascript is interpreted and not compiled. But the more I've learnt about the benefits of "on the fly" / "just in time" optimising compilers, the more I'm convinced this is the future of computing. Being able to use multiple threads and hence multiple cores simultaneously to optimise what is actual…

The difference in speed has a lot more to do with memory layout. Javascript will never be as fast for this reason.

You could make a JIT language as fast as C so long as it supported value types properly. Most programs in the "slow" languages spend most of their time chasing pointers around.

Post reply on HN