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

101–110 of 237 posts

Re: Why the New V8 Is So Damn Fast

#101

Post by pspeter3 »

hajile wrote: post #73
pspeter3 wrote: post #26

I have often wondered if frameworks like React which offer polymorphic methods (eg React.createElement) cause deoptimizations. The common functions also seem to be on the critical path since they will be called 100s-1000s of times per render.

I'm not sure about React, but a fairly common pattern is to dispatch to optimize. The parent function takes several different data types, but it is a very small pass-through that calls a variety of monomorphic functions to do the heavy lifting. It's not technically as fast, but as the amount of processing in the monomorphic functions increases, the cost of the small polymorphic function fades into the noise.

That's a good practical tip

Re: Why the New V8 Is So Damn Fast

#102

Post by qaq »

mamcx wrote: post #86
ams6110 wrote: post #64

Earlier quoted context omitted.

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.

Modern JS is OK and TS is pretty nice

Re: Why the New V8 Is So Damn Fast

#103

Post by jimmy1 »

askaboutit wrote: post #85
Twirrim wrote: post #56

Earlier quoted context omitted.

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.

headius is at a jvm conf right now talking about optimizing JRuby, and here's a recent video on the subject: https://www.youtube.com/watch?v=4vxIncIm2D4

Re: Why the New V8 Is So Damn Fast

#104

Post by bzbarsky »

Avshalom wrote: post #21
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.

Does for..in actually require that keys be returned in a specific order? Most languages specifically call out that the order is not guaranteed (not that that stops developers from relying on an order)

> Does for..in actually require that keys be returned in a specific order?

It's complicated. The spec says order of for..in is not defined, browsers all implement the same order, and there keep being attempts to get the spec changed to match.

Object.keys, however _does_ have a defined order. https://tc39.github.io/ecma262/#sec-object.keys calls https://tc39.github.io/ecma262/#sec-enumerableownpropertynam... which calls the [[OwnPropertyKeys]] internal method. For normal objects this is defined at https://tc39.github.io/ecma262/#sec-ordinary-object-internal... which calls https://tc39.github.io/ecma262/#sec-ordinaryownpropertykeys which completely specifies the order: integer indices in ascending numeric order, then other string-named props in order of property creation, then symbol-named props.

Re: Why the New V8 Is So Damn Fast

#105

Post by weberc2 »

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…

I don’t use JS regularly because the ergonomics of async have been so poor. This might not be the case with recent async/await work, but I’ve also not had positive async/await experiences in other languages either. This is too bad because V8 seems like a dream compared to CPython or even Pypy, but I prefer Go to both, especially when it comes to I/O.

Re: Why the New V8 Is So Damn Fast

#106

Post by josephg »

ux-app wrote: post #87
josephg wrote: post #65

Earlier quoted context omitted.

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

Yes I think we all agree. As I said in my post above:

>> Thanks to V8 you can definitely achieve good enough performance with JavaScript for most applications

The point I argued above isn’t that JS is slow. It’s that JS will probably always be slower than well written C code. I still write far more JS than C, because my time is usually more valuable than the computer’s.

That said, games are far from the only place where every ms counts. Performance matters in database servers, operating systems, real-time applications (eg robotics), text editor typing latency, UI responsiveness, 3d modelling software, video encoding, cryptocurrency mining, browser DOM rendering and so on.

I love JS, but native code is not a special case. Despite the best efforts of Electron, I suspect most of the globe’s aggregate clock cycles are spent running code written in languages other than JavaScript.

Re: Why the New V8 Is So Damn Fast

#107

Post by askmike »

mwsherman wrote: post #97

I speculated recently that TypeScript might _de facto_ help V8 optimizations, and the post seems to confirm that. https://clipperhouse.com/does-typescript-make-for-more-perfo...

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 types from typescript (designed for programmers) are not always inline with V8 internal representation of objects?) Or what if people push typescript through V8 with compile time errors? (The compiler should have prevented this from happening - but you can pump whatever you want into V8, including things considered broken by typescript).

You only really get any improvement in runtime if your compiler guarantees anything (and bakes it into whatever it is compiling). As of now there are little guarantees with the javascript language (which is what comes out of your typescript compiler). AFAIK typescript is designed to help programmers find common bugs.

Not saying it's not possible, but more work is needed into bridging the two.

Re: Why the New V8 Is So Damn Fast

#108

Post by enitihas »

askmike wrote: post #107
mwsherman wrote: post #97

I speculated recently that TypeScript might _de facto_ help V8 optimizations, and the post seems to confirm that. https://clipperhouse.com/does-typescript-make-for-more-perfo...

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…

Wouldn't it be good if JavaScript also starts supporting python like type annotations (completely optional, but unlike python used to guide the optimizer. Given that some non trivial amount of JS is already generated after type checking (typescript, flow, and all the statically typed languages compiling to JS), all this compile time type info could be made available to the optimizer.

Re: Why the New V8 Is So Damn Fast

#109

Post by FridgeSeal »

stcredzero wrote: post #69
pseudocook wrote: post #63

Earlier quoted context omitted.

I used to be a Smalltalk developer on Windows 3.1 for a brief time in the early 90's. When I found out that internally, Smalltalk was compiled into a sort of intermediate assembly language, and run on a virtual machine, I wondered why couldn't we just distribute the assembly language part over the Internet, where it could be run on any kind of machine with an interepreter. Everyone told me I was crazy, it was impract…

I used to work for a Smalltalk vendor. It was even better than that. For awhile we had the hottest JIT virtual machine. Smalltalks that followed the original design ran bit identically across multiple platforms. At one point, Squeak Smalltalk was running bit identically across 50 combinations of CPU and OS, and Squeak and its descendants probably can run bit identically across several times that number of environment…

Wow that sounds super, super cool!

As you say, I really wish tech had followed that route, think of all the cool things we'd have.

Re: Why the New V8 Is So Damn Fast

#110

Post by jahewson »

askmike wrote: post #107
mwsherman wrote: post #97

I speculated recently that TypeScript might _de facto_ help V8 optimizations, and the post seems to confirm that. https://clipperhouse.com/does-typescript-make-for-more-perfo...

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.

Post reply on HN