Why the New V8 Is So Damn Fast • Hacker News Board

Re: Why the New V8 Is So Damn Fast

#11

Post by thlorenz » Mon, Jul 30, 2018, 10:55 PM UTC

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.

I agree that this is unexpected for most of us, but if you read this section in my v8-perf repo (https://github.com/thlorenz/v8-perf/blob/master/data-types.m...) you'll understand better why that is.

However it doesn't necessarily cause a large slowdown, just makes your function polymorphic and the resulting optimized code larger and a bit slower.

To avoid this entirely I recommend using a JavaScript `class` when passing objects to a function that has to run at peak speed.

Re: Why the New V8 Is So Damn Fast

#12

Post by sbjs » Mon, Jul 30, 2018, 10:57 PM UTC

out_of_protocol wrote: post #5

sbjs wrote: post #4

Earlier quoted context omitted.

Just use Express.js or Sails.js, they're 1:1 to Sinatra or Rails. Join us!

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.

Re: Why the New V8 Is So Damn Fast

#13

Post by nielsbot » Mon, Jul 30, 2018, 11:03 PM UTC

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

Re: Why the New V8 Is So Damn Fast

#14

Post by saagarjha » Mon, Jul 30, 2018, 11:11 PM UTC

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.

Re: Why the New V8 Is So Damn Fast

#15

Post by lovelle » Mon, Jul 30, 2018, 11:12 PM UTC

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.

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

Re: Why the New V8 Is So Damn Fast

#16

Post by wolf550e » Mon, Jul 30, 2018, 11:12 PM UTC

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…

Welcome to 1995 and the wonderful world of Java. Except in Java you can use threads to use multiprocessing, so you can have efficient shared data structures but also hard to debug bugs.

Re: Why the New V8 Is So Damn Fast

#17

Post by axlee » Mon, Jul 30, 2018, 11:12 PM UTC

sbjs wrote: post #4

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.

Just use Express.js or Sails.js, they're 1:1 to Sinatra or Rails. Join us!

How is Express even remotely close to Rails? Express is a glorified router.

Re: Why the New V8 Is So Damn Fast

#18

Post by chrisseaton » Mon, Jul 30, 2018, 11:13 PM UTC

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.

Re: Why the New V8 Is So Damn Fast

#19

Post by kowdermeister » Mon, Jul 30, 2018, 11:14 PM UTC

out_of_protocol wrote: post #5

sbjs wrote: post #4

Earlier quoted context omitted.

Just use Express.js or Sails.js, they're 1:1 to Sinatra or Rails. Join us!

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

What Rails features do you miss from which framework?

Re: Why the New V8 Is So Damn Fast

#20

Post by chrisseaton » Mon, Jul 30, 2018, 11:14 PM UTC

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