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

61–70 of 237 posts

Re: Why the New V8 Is So Damn Fast

#61

Post by 0xcde4c3db »

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…

Keep in mind that a lot of performance differences come out of the snowball effect of popularity driving product development. X86 being faster than MIPS today has nothing to do with the relative merits of the ISAs and everything to do with the millions of people who wanted to run X86 code really fast for the past 25 years. JavaScript's foray into this scale of popularity is pretty recent, with the widespread adoption of "Web 2.0" and AJAX only dating back to about 2005 (both are older, but spent a while in the throes of obscurity and incompatibility).

Re: Why the New V8 Is So Damn Fast

#62

Post by drb91 »

gsnedders wrote: post #30
Avshalom wrote: post #21

Earlier quoted context omitted.

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)

The ES spec doesn't require it, but every implementation does insertion order (and insertion order was a deliberate decision by Brendan in the original implementation, IIRC), and the web very much relies on it. The "new" generation of JS VMs (V8, Chakra, Carakan) all dropped insertion order for array index properties (that is properties whose name is a uint32), but kept it for everything else; that broke about as muc…

Building a browser sometimes feels like building a language where the only guarantee is the worst features will be used and maintained.

I mean this not as a slight on the ecmascript creators/maintainers but rather as an observation of how difficult the problem is.

Re: Why the New V8 Is So Damn Fast

#63

Post by pseudocook »

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 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 impractical, it would never work.

Re: Why the New V8 Is So Damn Fast

#64

Post by ams6110 »

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?

Re: Why the New V8 Is So Damn Fast

#65

Post by josephg »

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 humans are better at writing C code than we are at writing clever compilers.

It’s many of the exact ergonomics which make JavaScript useful and easy to use that also make it much harder to optimise. For example, what code should V8 generate for `x+=x` ? The optimiser might find that x is always a positive integer, but every time it gets doubled, it might cross the magic overflow point where it needs it’s representation swapped for a double. The generated code must check for this every time. Or consider memory management - For games I’ve heard of people making a per-frame arena allocation pools for values with a lifetime that won’t cross frame boundaries. This basically makes these allocations free and improves cache coherency. I’m happy that the JS GC is multithreaded now, but there’s no way a GC can compete with that. And unlike C, there’s no way in JS to override the allocation behaviour.

There are a million paper cuts like this which lower the ceiling of how fast optimised JS can run. I’m glad V8 will keep improving, but for my money the future of really fast JavaScript is Webassembly.

Re: Why the New V8 Is So Damn Fast

#66

Post by ioquatix »

pseudocook wrote: post #63
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 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…

You are crazy, it is impractical, it will never work. /s

Re: Why the New V8 Is So Damn Fast

#67

Post by AzzieElbab »

2trill2spill wrote: post #44
AzzieElbab wrote: post #34

Why hasn't node replaced PHP yet?

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

Re: Why the New V8 Is So Damn Fast

#68

Post by nicoburns »

gunn wrote: post #55
sbjs wrote: post #12

Earlier quoted context omitted.

Does that mean there's still room in the JS ecosystem for a Rails-alike? Maybe one that could become very popular? Because I am looking for a major open source project to create and spearhead, something that could get hundreds of thousands of active users and a thriving subcommunity, but I've been holding off until I find just the right project.

Definitely. And using these technologies, there are some cool possibilities beyond what rails is capable of. For instance if you used typescript (still allows devs to use plain JS), you could use types to check that forms send all the required params. For example, a login page might require: interface LoginParams { username: string; password: string; rememberMe?: boolean; } Having the typescript compiler check for in…

Unfortunately TypeScript doesn't do runtime checks like this. It assumes that incoming data conforms to the type spec! However, you might be interested in the Rocket framework (written in Rust), which does do exactly that:

https://rocket.rs/

Re: Why the New V8 Is So Damn Fast

#69

Post by stcredzero »

pseudocook wrote: post #63
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 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 environments now.

But it gets even crazier. (Non-Smalltalk) In the 90's, there was an OS entirely written in a virtual Instruction Set (TAOS) which was JIT assembled into real machine code as fast as it could be read off of disk and ran at 80-90% of native speeds. This OS could be ported by simply porting the assembler, which typically took about 3 days.

Back to Smalltalk craziness. There were also in-house research versions of Smalltalk that could prune their images as small as 45k, and were suitable for creating command line tool executables. As it was, VisualWorks, if you turned off things like the splash screen, actually could start faster than the Perl runtime in the late 90's, though you'd be hard pressed to create an image below 500kB. (Even getting it below a megabyte was an incredible feat.)

The tech industry could be way ahead of where it is now, if only everyone were like early adopters. The thing is, most people are quite different.

Re: Why the New V8 Is So Damn Fast

#70

Post by MikeHolman »

fasquoika wrote: post #42
chii wrote: post #35

Earlier quoted context omitted.

> If you're wrong you can deoptimise and fix-up to the same base-line performance. but how do you know it's wrong (if the iteration order of a .keys() call isnt the same)?

The original code didn't have a call to .keys(), and that's the case where this should be optimized. If you do the unordered optimization, then encounter an operation that needs an ordered iteration, you'd have to fall back to an ordered representation (which could be slower than not doing the optimization at all)

That requires extra bookkeeping for ordering, but it isn't really that common where people will have object literals with the same properties initialized in a different order.

But a much more common case is that properties added after object creating will be added in an inconsistent order, for example:

o = {}; o.x = 1; o.y = 2; o.z = 3;

p = {}; p.y = 4; p.x = 5; p.z = 6;

When executing p.y = 4 you don't know that the object will eventually evolve to have the same properties as o.

Post reply on HN