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

181–190 of 237 posts

Re: Why the New V8 Is So Damn Fast

#181

Post by beagle3 »

jahewson wrote: post #110
askmike wrote: post #107

Earlier quoted context omitted.

IMO The problem as it stands now is that when developing typescript you have a compiler running on your machine doing the typechecking. It will error out and simply not compile when you try to pass a string to a fn expecting a number. What if there is a bug (or even a misconfiguration in your project)? Or typescript changes over time (and now there are different versions all needed to be supported)? Or what if the ty…

I quite disagree. Look at JVM performance, there’s been huge improvements over time and a Java program compiled 20 years ago will get the same improvements as one compiled today. Not only that but you can expect to get better performance from the JIT than AOT because the JIT can perform optimisations which are impossible for the compiler.

> you can expect to get better performance from the JIT than AOT

And you are likely to be disappointed. I think these claims have been made for the last 20 years, and Graal might be the first to deliver something general - all previous successes were very limited to small niches.

I like JITs and what they offer, but very consistently for me and almost everyone I know, in practice AOT works better (faster, consistent, no "heuristic changed in JIT version and now it's slow" surprises).

Re: Why the New V8 Is So Damn Fast

#182

Post by blub »

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…

Are you going to let your employees get away with investing all of 4 hours into things you did not give them permission for? You haven't shown them who the alpha is until they ask you for permission to go to the bathroom.

Re: Why the New V8 Is So Damn Fast

#183

Post by beagle3 »

stefs wrote: post #172
jahewson wrote: post #110

Earlier quoted context omitted.

I quite disagree. Look at JVM performance, there’s been huge improvements over time and a Java program compiled 20 years ago will get the same improvements as one compiled today. Not only that but you can expect to get better performance from the JIT than AOT because the JIT can perform optimisations which are impossible for the compiler.

@JIT vs. AOT: i used to think that, too. but graal came out and got 90% of the JIT speed right from the start with a fraction of the time hotspot had for optimization (and of course, with better startup times).

Yes, it seems Graal might finally deliver on the "JIT is better because it is better informed" promise after 20 years. I'm holding my fingers crossed, but I think we need a little more experience with it before victory can be declared.

Re: Why the New V8 Is So Damn Fast

#184

Post by repolfx »

physguy1123 wrote: post #88
zmmmmm wrote: post #76

Earlier quoted context omitted.

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 th…

There's this classic paper from Google that runs an optimisation competition on the same program written in C++, Java, Scala and Go:

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...

Re: Why the New V8 Is So Damn Fast

#185

Post by weberc2 »

ernst_klim wrote: post #165
weberc2 wrote: post #111

Earlier quoted context omitted.

It’s not native vs VM, but rather “has stack semantics/value types” vs “no stack semantics/value types”. In particular, OCaml’s standard implementation is a native, not VM. Also worth calling out Go, which is rather unique in that it has stack semantics but it also has a garbage collector, so it’s kind of the best of both worlds in terms of ease of writing correct, performant code.

But go has an imprecise GC (in reference implementation) or stack maps (in gccgo), so the GC overhead is rather huge. It also lacks of compaction, so cache misses are not that good too.

Not sure what you mean by imprecise, but Go’s GC does trade throughput for latency. The overhead still isn’t huge if only because there is so much less garbage than in other GC languages. I’m also surprised by your cache misses claim; Go has value types which are used extensively in idiomatic code so generally the cache properties seem quite good—maybe my experience is abnormal?

Re: Why the New V8 Is So Damn Fast

#186

Post by repolfx »

wvenable wrote: post #49
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…

I think his point is that if you write normal single threaded code then your other cores are going to be idle. But if you write in a high level JITed GCd language then the other cores will be busy making your main thread run faster by profiling it, recompiling it with risky optimisations, clearing garbage asynchronously and so on.

Re: Why the New V8 Is So Damn Fast

#187

Post by weberc2 »

pjmlp wrote: post #143
weberc2 wrote: post #111

Earlier quoted context omitted.

It’s not native vs VM, but rather “has stack semantics/value types” vs “no stack semantics/value types”. In particular, OCaml’s standard implementation is a native, not VM. Also worth calling out Go, which is rather unique in that it has stack semantics but it also has a garbage collector, so it’s kind of the best of both worlds in terms of ease of writing correct, performant code.

Go is not rather unique in having GC and stack semantics, there are plenty of languages that have it, all the way back to Mesa/Cedar and CLU.

I should have been more clear I guess; I was comparing it to other popular languages. Few have value types and many that do (like C#) regard them as second-class citizens.

Re: Why the New V8 Is So Damn Fast

#188

Post by weberc2 »

tybit wrote: post #166
weberc2 wrote: post #111

Earlier quoted context omitted.

It’s not native vs VM, but rather “has stack semantics/value types” vs “no stack semantics/value types”. In particular, OCaml’s standard implementation is a native, not VM. Also worth calling out Go, which is rather unique in that it has stack semantics but it also has a garbage collector, so it’s kind of the best of both worlds in terms of ease of writing correct, performant code.

.NET is another example of value types in a garbage collected language. It’s also somewhat unique afaik in doing so within a VM.

Definitely. I’m sad that they’re not more idiomatic in C#. I definitely prefer values and references over OOP class objects.

Re: Why the New V8 Is So Damn Fast

#189

Post by vinceguidry »

tlrobinson wrote: post #131
vinceguidry wrote: post #54

Earlier quoted context omitted.

Personally, having developed in both Rails and Node, I now believe that trying to recreate Rails in JS is a foolish effort. Rails is a huge project with a ton of weight behind it and unless you can generate a massive amount of corporate investment, you won't ever be able to really catch up. I'm not saying that there's no room in the JS ecosystem for another web framework, what I'm saying is that if your design goal i…

As for the second half of your comment, it sounds like you haven't used JavaScript in awhile. ES6 introduced syntax for classical inheritance, and a bunch of other nice features.

I use ES6 at my job, daily. There are some things about it that make me really hate it. First, no, it doesn't introduce classical inheritance. It introduced syntax that looks like classical inheritance. It's still prototypal inheritance under the hood. I'm not entirely sure what this means yet from the standpoint of building things with it, but I'm not enthused at the prospect.

What I find happens fairly frequently with ES6 that I never found with Vanilla JS is that the extra features built on top of JS 'break'. If you add syntax to a language, that syntax needs to work. I need to be able to rely on it working. I run into constant little issues that make me think I'm missing something about scoping, when really it's some under-the-hood issue with a library or something I just don't have the time to pin down.

One example is I tried using the spread operator to add keys to an object. But the spread simply, well, failed. Passing in the object worked fine. Passing in a spread version of the same object failed. I haven't resolved it yet, got pulled onto another feature. This sort of breakage is hard to Google, when I run into it again, and I'm sure I will, I may have to troubleshoot it all the way to Babel.

Error reporting in Node with ES6 is garbage. Worse than garbage, it's a veritable dumpster fire. Ideally the error points to the problem, when it doesn't point to the problem you have to rely on experience and intuition to lead you to the issue. Many many errors I come across in JS are of this sort.

I think most of these issues come down to the fact that ES6 is a transpiled language. This makes me long for the days of good old CoffeeScript. At least CS was close enough to Vanilla that it was easy to determine when you had an issue with the transpiler, simply grab the snippet of code and paste it into the online transpiler, look at the generated JS and work out your issue from there. It wasn't the smoothest workflow but it was effective.

ES6 is stupid in ways that make building an effective workflow unreasonably difficult. I can't wait to get back to Rails. Vanilla JS wasn't that bad. It was well-understood and you could work with it effectively on the front-end. It certainly wasn't as pleasant as Ruby, but it didn't feel like the pile of hacks that ES6 does. Maybe once it stops being transpiled it'll get better.

Re: Why the New V8 Is So Damn Fast

#190

Post by blattimwind »

beagle3 wrote: post #183
stefs wrote: post #172

Earlier quoted context omitted.

@JIT vs. AOT: i used to think that, too. but graal came out and got 90% of the JIT speed right from the start with a fraction of the time hotspot had for optimization (and of course, with better startup times).

Yes, it seems Graal might finally deliver on the "JIT is better because it is better informed" promise after 20 years. I'm holding my fingers crossed, but I think we need a little more experience with it before victory can be declared.

What about luajit?
Post reply on HN