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

111–120 of 237 posts

Re: Why the New V8 Is So Damn Fast

#111

Post by weberc2 »

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…

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.

Re: Why the New V8 Is So Damn Fast

#112

Post by askmike »

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.

For speed purposes? This post is for example already talking about how fast JS is getting without types.

I'd say it would be a lot easier to simply focus on the WebAssembly format, you can write your code in a number of (typed) languages and compile into wasm which is designed to be fast.

Javascript already comes with a few decades of bagage, and things are already changing really fast (ES6 and newer versions). Not everyone likes types and the people who do can use typescript (or flow). And the people who need insane performance (games, etc) can use WebAssembly.

Re: Why the New V8 Is So Damn Fast

#113

Post by zmmmmm »

shub wrote: post #98
physguy1123 wrote: post #88

Earlier quoted context omitted.

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…

In addition, a lot of the techniques used to write high-performance Java boil down to "write it like C". Avoid interfaces, avoid polymorphic virtual calls (as you can't avoid virtuals entirely), avoid complex object graphs, avoid allocating as much as possible...it's not nearly as nice as naive Java. Still nicer than C IMO. If your process segfaults you can know for certain that it's a platform bug.

The other thing that makes Java nicer than C is the ease and depth with which you can profile it to discover where the bottlenecks actually are. While it's certainly possible to profile in both cases, the runtime reflective and instrumentation capabilities of the JVM really add a lot of power to it.

Re: Why the New V8 Is So Damn Fast

#114

Post by askmike »

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.

I very much agree with you!

> You only really get any improvement in runtime if your compiler guarantees anything (and bakes it into whatever it is compiling).

I meant this in reference to runtime speed optimisations coming from types. V8 is improving every day!

Re: Why the New V8 Is So Damn Fast

#115

Post by weberc2 »

mynegation wrote: post #81
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…

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

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 exception and not the rule.

Writing performant C++ is actually not hard if you have rudimentary C++ knowledge. That said, rudimentary C++ knowledge is a lot more expensive than rudimentary knowledge of other languages. But the options aren’t just dynamic languages vs C++; there’s a ton of middle ground with VM languages like Java and C# and native languages like Go. The first two aren’t much harder than dynamic languages and I find Go easier than any dynamic language I’ve used to date (I’m a professional python developer). But all of these languages are on the order of half of C’s performance and 100X the speed of CPython or Ruby and 10X of JS.

Re: Why the New V8 Is So Damn Fast

#116

Post by wongma »

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.

Don't be too jealous. My main concern with Node and its ecosystem is maturity and security. It loses hands down on both those points compared Ruby / Rails especially in the area of dependencies.

This keeps me happily in Rubyland.

Re: Why the New V8 Is So Damn Fast

#117

Post by weberc2 »

Negitivefrags wrote: post #39
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 difference in speed has a lot more to do with memory layout. Javascript will never be as fast for this reason. You could make a JIT language as fast as C so long as it supported value types properly. Most programs in the "slow" languages spend most of their time chasing pointers around.

To elaborate on your point, its not just chasing pointers, it’s that those pointers point into random heap locations, each of which needs to be allocated individually and garbage collected. Also, because of the haphazard locations of these objects in the heap, you have way more cache misses than you would with value types.

Re: Why the New V8 Is So Damn Fast

#118

Post by enitihas »

askmike wrote: post #112
enitihas wrote: post #108

Earlier quoted context omitted.

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.

For speed purposes? This post is for example already talking about how fast JS is getting without types. I'd say it would be a lot easier to simply focus on the WebAssembly format, you can write your code in a number of (typed) languages and compile into wasm which is designed to be fast. Javascript already comes with a few decades of bagage, and things are already changing really fast (ES6 and newer versions). Not e…

Yes for speed purposes. And yes some people may not like types, that's why I said completely optional. Anyways the optimizer tries to figure out the types on it's own, so give it a non blank slate to start with. You are correct in noting that js is already fast enough, but the problem is the sort of performance gotchas(order of keys in objects) as mentioned in the post aren't really obvious during development time. Types may help level the unpredictability.

Re: Why the New V8 Is So Damn Fast

#119

Post by AzzieElbab »

notamy wrote: post #90
AzzieElbab wrote: post #67

Earlier quoted context omitted.

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.

Oh sure, and the only reason one would do this is to keep Aws bills up to Amazon shareholders expectations

Re: Why the New V8 Is So Damn Fast

#120

Post by swsieber »

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 admit the performance is improving.

But it's not c level performance. Throwing multiple cores at js to get c level performance glossession over an important detail: in C, those cores are free to do other things.

Post reply on HN