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

Re: Why the New V8 Is So Damn Fast

#81

Post by mynegation » Tue, Jul 31, 2018, 1:06 AM UTC

zmmmmm wrote: post #76

mpweiher wrote: post #53

Earlier quoted context omitted.

Reports of some jitted Java code running faster than C (after warmup) are old. I remember seeing those claims for some super hot VM in the old IBM System's journal from 2000, and yes, IIRC that was a VM written mostly in Java. However, those isolated examples rarely if ever translated to high performance in real-world projects. The same issue has an experience report of the travails of IBM's San Francisco project. Pe…

Heh ... one of my employees took it into their head to code up some arithmetic algorithms in C++ a month or so ago. We do not use C++ for anything, we are all Python and JVM based. But he decided that he was going to achieve an amazing win by optimising some numerical code to get order of magnitude benefits, and without asking invested 4 hours into coding it up. I wrote a naive implementation of the same thing in Gro…

This is exactly it: dynamic languages give you OK ish performance and fast development speed. Fast C++ code requires a lot of expertise, this kind of expertise is expensive and there are diminishing returns too. I don’t know anything about expertise of your colleague in C++ but given that their first optimization was to eliminate some redundant copying, I suspect there is some more room for improvement. After unnecessary copying is removed it usually boils down to things like cache locality, better memory allocation discipline, data alignment, and sometimes knowledge of a better algorithm applicable to a particular situation (eg radix sort or perfect hashing or tries), judicial use of multi threading (in form of OpenMP), understanding whether single precision floating point is good enough etc etc.

Re: Why the New V8 Is So Damn Fast

#82

Post by physguy1123 » Tue, Jul 31, 2018, 1:17 AM 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…

SIMD, multicore, and caches don't just magically happen with better compilers. SIMD requires very specific memory access and computation patterns, and cache-friendly code has similar restrictions. The features of even basic javascript fly in the face of code being simd and cache friendly except for the most trivial programs.

Automagically parallelizing general serial code is something that isn't feasible on any hardware similar to modern cpus and probably will never mesh well with fast single-threaded performance (communication and synchronization in hardware is HARD)

Re: Why the New V8 Is So Damn Fast

#83

Post by flukus » Tue, Jul 31, 2018, 1:18 AM 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…

> but for 90% of use cases javascript actually makes sense and can be the most performant.

This is a weird definition of performant, using more resources to achieve the same result faster, it seems akin to saying JS is more performant than C if you buy a newer CPU to run the code on.

> 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

It's been the future of computing for 30 years, possibly longer.

Re: Why the New V8 Is So Damn Fast

#84

Post by azhenley » Tue, Jul 31, 2018, 1:22 AM UTC

josephg wrote: post #65

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…

> javascript actually makes sense and can be the most performant. Thanks to V8 you can definitely achieve good enough performance with JavaScript for most applications, and the ergonomics are pretty great. But it’s not true that performance rivals or beats C in the general case. The ‘sufficiently advanced compiler’ rainbow is something that Java has spent decades chasing. I think it’s fair to say at this point that h…

You make some interesting points about cases where JS will always be difficult to be optimized automatically.

I wonder if compiler hints can help in that regard? For example, if performance is important then you could annotate the 'x+=x' line to tell the compiler to not check for overflow.

Re: Why the New V8 Is So Damn Fast

#85

Post by askaboutit » Tue, Jul 31, 2018, 1:23 AM UTC

Twirrim wrote: post #56

nielsbot wrote: post #13

Earlier quoted context omitted.

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

There's also JRuby, Ruby running on the JVM. Which can be insanely fast for anything longer running than your typical CLI use case.

I believe Truffle was 3-4x+ faster than Jruby. This is what Ruby needs. But Oracle will ruin it.

Re: Why the New V8 Is So Damn Fast

#86

Post by mamcx » Tue, Jul 31, 2018, 1:25 AM UTC

ams6110 wrote: post #64

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's funny to me is how JavaScript has gone from something of a joke to a very well regarded, performant, and heavily used programming language. I can clearly remember the days when proposing any significant programming in JavaScript would get a developer laughed out of the room. Is there another example of a language that has had such a 180 degree turn around in respect and popularity?

> respect

Not much respect, but more acceptance as a unavoidable language to use that thanks of millons of $$$$/human-hours of effort to polish it... is ok-ish.

Re: Why the New V8 Is So Damn Fast

#87

Post by ux-app » Tue, Jul 31, 2018, 1:28 AM UTC

josephg wrote: post #65

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…

> javascript actually makes sense and can be the most performant. Thanks to V8 you can definitely achieve good enough performance with JavaScript for most applications, and the ergonomics are pretty great. But it’s not true that performance rivals or beats C in the general case. The ‘sufficiently advanced compiler’ rainbow is something that Java has spent decades chasing. I think it’s fair to say at this point that h…

>For games I’ve heard of people making a per-frame arena allocation pools

Games are a special case where each ms counts. Globally, the number of LOC written for consumer or business software dwarfs that of game code and for these kinds of applications JS is well within the realm of performant enough. That assumes you're not doing your presentation layer using the DOM though which is still garbage wrt performance. Luckily there are things like Qt to make high performance UIs in though.

Re: Why the New V8 Is So Damn Fast

#88

Post by physguy1123 » Tue, Jul 31, 2018, 1:28 AM UTC

zmmmmm wrote: post #76

mpweiher wrote: post #53

Earlier quoted context omitted.

Reports of some jitted Java code running faster than C (after warmup) are old. I remember seeing those claims for some super hot VM in the old IBM System's journal from 2000, and yes, IIRC that was a VM written mostly in Java. However, those isolated examples rarely if ever translated to high performance in real-world projects. The same issue has an experience report of the travails of IBM's San Francisco project. Pe…

Heh ... one of my employees took it into their head to code up some arithmetic algorithms in C++ a month or so ago. We do not use C++ for anything, we are all Python and JVM based. But he decided that he was going to achieve an amazing win by optimising some numerical code to get order of magnitude benefits, and without asking invested 4 hours into coding it up. I wrote a naive implementation of the same thing in Gro…

In my experience, writing java (or groovy here) in c++ results in horribly slow code which the jvm runs circles around, and it sounds like that's the problem your employee ran into.

> But for all the applications where the high performance code is in niches at the edge and there simply aren't resources or expertise to fully tune the native implementation

It's interesting you say this, because in my experience it's the JVM which requires absurd amounts of tuning and native programs which are much more consistent. The proper and easier way that native programs are written lends itself to fairly respectable performance, mostly because the object and stack model of say C or C++ is so much friendlier to the CPU than in most dynamic languages.

In general, for all that I hear statements along this line, I've only twice seen code to back it up, and the C was so de-optimized from the OCaml version that I suspect it was intentional - the author (same for each) was a consultant for functional languages, and in one case switched the C inner loop to use indirect calls for every iteration and in the other switched the hash function between the C and functional comparison.

Re: Why the New V8 Is So Damn Fast

#89

Post by brianmurphy » Tue, Jul 31, 2018, 1:43 AM UTC

AzzieElbab wrote: post #34

Why hasn't node replaced PHP yet?

Speaking for myself, I have 20 years of C like language experience and I can't stand the scoping rules or functional nature of javascript. This is why I like PHP. It comes natural when switching between C, bourne shell, perl and PHP. Throw in the ever changing frameworks a casual user encounters and I want to avoid javascript at all costs.

Re: Why the New V8 Is So Damn Fast

#90

Post by notamy » Tue, Jul 31, 2018, 1:48 AM UTC

AzzieElbab wrote: post #67

2trill2spill wrote: post #44

Earlier quoted context omitted.

why would or should it?

One can argue that PHP is the least suitable language to write web servers in, no standard async or multithreading, tones of leaks, and so on. Node asynchronous model is quirky but given js world's "isomorphism" it should have squeezed PHP out of existence by now

> One can argue that PHP is the least suitable language to write web servers in

Of course, because you don't write a web server in PHP. You put it behind nginx or apache and those can fork off PHP processes (or you use FPM, or etc.) to do everything for you.