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

41–50 of 237 posts

Re: Why the New V8 Is So Damn Fast

#41

Post by millstone »

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…

What do you mean by "multiple cores to optimise a single threaded piece of code?" This makes it sound like code can automatically become multithreaded which is not true (threading is one of JS's great weak points).

v8 is an amazing piece of engineering but it's not at the point where it allows application developers to take much advantage of SIMD, hyperthreading, or multicore.

Re: Why the New V8 Is So Damn Fast

#42

Post by fasquoika »

chii wrote: post #35
chrisseaton wrote: post #20

Earlier quoted context omitted.

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)?

The original code didn't have a call to .keys(), and that's the case where this should be optimized. If you do the unordered optimization, then encounter an operation that needs an ordered iteration, you'd have to fall back to an ordered representation (which could be slower than not doing the optimization at all)

Re: Why the New V8 Is So Damn Fast

#43

Post by munificent »

abhorrence wrote: post #23
lovelle wrote: post #15

Earlier quoted context omitted.

I would insanely choose ruby rather than javascript for the major advantages that has to offer. Performance in most of cases is not a real needed over consistency. Also Ruby 2.6 has jit, would be great to see some bench tests. :P

2.6’s JIT is entirely at the method level currently, and unfortunately for certain types of workloads (e.g. Rails) this means the performance benefit is largely outweighed by the call counters and deoptimization checks on every method invocation. There’s definitely room for improvement, and the inclusion of JIT infrastructure is awesome, it’s just not making much of a performance impact. Yet.

V8 is also a method-based JIT as far as I know.

Re: Why the New V8 Is So Damn Fast

#45

Post by savanaly »

sbjs wrote: post #12
out_of_protocol wrote: post #5

Earlier quoted context omitted.

Not true unfortunately. Rails quality unreachable for current js frameworks. Well, i hope situation will change in the future

Does that mean there's still room in the JS ecosystem for a Rails-alike? Maybe one that could become very popular? Because I am looking for a major open source project to create and spearhead, something that could get hundreds of thousands of active users and a thriving subcommunity, but I've been holding off until I find just the right project.

There's definitely the need for this in JS. It would be extremely difficult to do, though.

Re: Why the New V8 Is So Damn Fast

#46

Post by acchow »

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…

You also can't beat C for energy efficiency. That JIT consumes energy.

Re: Why the New V8 Is So Damn Fast

#47

Post by gsnedders »

fasquoika wrote: post #36
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'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 an…

You are, of course, correct.

My hypothesis (as someone who used to work on a JS VM) would be that locations of iterations over an object's keys and the creation of the object are almost always in different functions, with the object passed between them. And note that JS VMs rarely do cross-function optimization. As such, it would be exceptionally rare for the optimization to be applied.

My point was really that you can't always drop the ordering of properties, and the insertion order isn't something you can recreate after the time if you don't store in initially, hence you do really need to store it somehow.

(If anyone's confused, I edited the grandparent comment of this to better reflect the above.)

Re: Why the New V8 Is So Damn Fast

#48

Post by Scarbutt »

millstone wrote: post #41
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…

What do you mean by "multiple cores to optimise a single threaded piece of code?" This makes it sound like code can automatically become multithreaded which is not true (threading is one of JS's great weak points). v8 is an amazing piece of engineering but it's not at the point where it allows application developers to take much advantage of SIMD, hyperthreading, or multicore.

What do you mean by "multiple cores to optimise a single threaded piece of code?"

I think he means this is done behind the scenes without your knowledge (some compiler/runtime magic), not some interface you can take advantage of.

Re: Why the New V8 Is So Damn Fast

#49

Post by wvenable »

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…

I feel everyone ping-pongs between these ideas; I've been there and I'm no longer convinced the way you are. You can't take single threaded code and just make it multithreaded no matter how much time the compiler spends on it. And in a JIT environment, the compiler doesn't actually get much time to spend optimizing code.

You can't just take advantage of SIMD, hyperthreading, multicore, or large caches without writing code in a way that takes advantage of that even at a high level. Some things can be faster when compiled at runtime but everything is a trade off.

But ultimately I believe that C is fast mostly due to manual memory management but that's not a trade-off I'd take for most tasks.

Re: Why the New V8 Is So Damn Fast

#50

Post by askaboutit »

nielsbot wrote: post #13
jerhinesmith wrote: post #3

As an internet user, I really enjoy reading about all these performance improvements in V8 / javascript. As a ruby developer, I'm insanely jealous.

You might be interested in TruffleRuby: https://github.com/oracle/truffleruby "A high performance implementation of the Ruby programming language. Built on the GraalVM by Oracle Labs."

I researched this yesterday against Crystal. Seems people won’t touch it because of oracle. Which is a real shame. Truffle is a 9x improvement in speed over Ruby. But because Oracle is a patent nightmare and a dying organization. People aren’t interested.
Post reply on HN