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

171–180 of 237 posts

Re: Why the New V8 Is So Damn Fast

#171

Post by conceptme »

enitihas wrote: post #108
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…

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.

Python totally ignores them at runtime, PHP has this but it actually slows down the code a bit. It does make catching bugs easier.

Re: Why the New V8 Is So Damn Fast

#172

Post by stefs »

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.

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

Re: Why the New V8 Is So Damn Fast

#173

Post by the_duke »

solidr53 wrote: post #137
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...

Yeah, I've always wondered this too. It would be cool to be able to extract typings in a separate file, like source maps, and send over the wire along with the JavaScript bundle (for compatibility). It would definitely help moving sections of the code up the tier ladder, not unlike Web Assembly. I even predict that future typescript versions would include stricter typings optimized for an browser to solve problems li…

I'd much prefer that optional type annotations make it into the spec, like they did for Python and PHP.

Re: Why the New V8 Is So Damn Fast

#174

Post by _0w8t »

axilmar wrote: post #169
thlorenz wrote: post #11

Earlier quoted context omitted.

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

Why does it have to be that the order of members matters? shouldn't both {x,y,z} and {z,x,y} compile down to {x,y,z}?

In JS for-in loop enumerates keys in the insert order. So {x,y,z} is different from {z,x,y}

Re: Why the New V8 Is So Damn Fast

#175

Post by repolfx »

grashalm01 wrote: post #168
adrianN wrote: post #138

Earlier quoted context omitted.

The compiler can also perform optimizations that are impossible for a JIT because they're too expensive. JITs have to balance execution speed with compilation time. It's not so clear cut which approach in theoretically superior. I also don't know any languages where a JIT and an AOT compiler have gotten equivalent amounts of engineering hours so that we could have a fair comparison.

Graal can run in dynamic and aot compilation mode. If you feed profiles into aot from a test run you can get pretty close to dynamic compilation peak performance.

And if you don't the gap is about 20% iirc.

Re: Why the New V8 Is So Damn Fast

#176

Post by repolfx »

weberc2 wrote: post #121
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.

> 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. I can’t help myself, but the JVM performs at par with managed AOT languages (Go, Haskell, OCaml, etc) and strictly slower than the unmanaged AOT languages (C, C++, Rust). The JVM does outperform various AOT Java compilers, but that’s probably an artifact o…

Lots of people believe this but it's false.

JVM vs C++ depends very much on the code shapes and what the code is doing. C++ that's very heavy on virtual function calls can be faster written as Java. On the other hand if you use a lot of SIMD intrinsics and things like that, C++ can be a lot faster.

W.R.T. AOT vs JIT, as others are pointing out, Graal is a compiler that can execute in both modes, i.e. it's a comparable compiler. JITC is about a 20% win for relatively static languages like Java and can be massively larger (like 4000%+) for other languages like JavaScript or Ruby. In fact the nature of very dynamic languages like Ruby or Python or JavaScript mean there's little point trying to AOT compile them at all because there'd be almost no optimisations you could safely do ahead of time.

Re: Why the New V8 Is So Damn Fast

#177

Post by imtringued »

azhenley wrote: post #84
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…

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.

We have that already. It's called asm.js and it's successor is WebAssembly.

Re: Why the New V8 Is So Damn Fast

#178

Post by repolfx »

willio58 wrote: post #139
yxhuvud wrote: post #122

Earlier quoted context omitted.

Uh, how is oracle a dying organization?

I went to go look for evidence of oracle dying and actually came up empty handed. I was also under this impression. I think it has waned significantly in popularity in the developer community over the years, but their stock isn’t bad at all and they seem to have diversified quite a bit in the time they’ve existed.

Oracle doesn't even seem that patent happy these days. They seem to have got burned by their experience with the Java patents (all useless, case revolves now around copyright).

Financially Oracle is doing very well indeed.

Re: Why the New V8 Is So Damn Fast

#179

Post by repolfx »

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.

Well, JRuby runs on the JVM which is developed by Oracle. Basically, if you're a ruby user who wants good performance there's not many other places to turn.

But you know Oracle acquired Java long ago and other than Google, I'm unaware of Oracle causing problems for any other users. And Google is a rather special case - they reimplemented an incompatible version of Java without licensing it. You're not going to be doing that.

Re: Why the New V8 Is So Damn Fast

#180

Post by weberc2 »

pjmlp wrote: post #145
weberc2 wrote: post #115

Earlier quoted context omitted.

I don’t think this is a property of dynamic languages. This groovy example is almost certainly the best case for the JVM (arithmetic, few allocations or polymorphism, etc). In other words, probably not taking advantage of the dynamism. Dynamic languages can be fast by being well designed and simple (Wren) or highly optimized (JS) or both (LuaJIT). There’s also the experimental GraalVM, but this is definitely the exce…

> VM languages like Java and C# and native languages like Go. Oh well this VM meme is getting old, https://www.ptc.com/en/products/developer-tools/perc https://www.excelsiorjet.com/ https://docs.microsoft.com/en-us/dotnet/framework/net-native... https://docs.microsoft.com/en-us/xamarin/mac/internals/aot https://docs.unity3d.com/Manual/IL2CPP-HowItWorks.html

I don’t think I’m following your point. That C# isn’t a VM language because there exist AOT compilers? That’s fine; my point is unrelated to the VM/interpreter/AOT taxonomy—just that dynamic languages aren’t particularly performant. I’m happy to concede the “C# is/isn’t a VM (even though 99% of production deployments are VMs)” point if it matters to you.
Post reply on HN