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

51–60 of 237 posts

Re: Why the New V8 Is So Damn Fast

#51

Post by lovelle »

wolf550e wrote: post #16
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…

Welcome to 1995 and the wonderful world of Java. Except in Java you can use threads to use multiprocessing, so you can have efficient shared data structures but also hard to debug bugs.

I would argue that in 95 was recently the first jdk 1.0 release, it was until 2004 which came java 5 with java.util.concurrent which was such huge improvement for that time, since then is easier to write concurrent software, and since java 8 is a wonderful experience!

Re: Why the New V8 Is So Damn Fast

#52

Post by zzzcpan »

chrisseaton wrote: post #18
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…

In my group at Oracle we're experimenting with running C using the same just-in-time compilation techniques that JavaScript uses, and sometimes we see it running faster than ahead-of-time native compilation, due to the effects of things like inline caching and profiling.

> sometimes we see it running faster than ahead-of-time native compilation

Edge cases. But obviously it's not comparable to something ahead-of-time compiled and hand profiled with PGO and stuff. Although in theory you could put that through JIT too, but it would probably just add overhead and only slow things down.

Re: Why the New V8 Is So Damn Fast

#53

Post by mpweiher »

chrisseaton wrote: post #18
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…

In my group at Oracle we're experimenting with running C using the same just-in-time compilation techniques that JavaScript uses, and sometimes we see it running faster than ahead-of-time native compilation, due to the effects of things like inline caching and profiling.

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. Performance was a huge issue that to the best of my knowledge they never fully resolved.

More in my article "Jitterdämmerung": http://blog.metaobject.com/2015/10/jitterdammerung.html

Re: Why the New V8 Is So Damn Fast

#54

Post by vinceguidry »

sbjs wrote: post #12
out_of_protocol wrote: post #5

Earlier quoted context omitted.

Not true unfortunately. Rails quality unreachable for current js frameworks. Well, i hope situation will change in the future

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.

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 is re-implementing Rails, you're already setting yourself up for failure. Sequelize has tried to be ActiveRecord for how long? The only thing it makes me do is want to go back to Ruby and Rails.

No, what you have to figure out if you want to do a JavaScript web framework is how to get me to actually want to use JavaScript to program a website. How can prototypical inheritance actually contribute to a workflow as opposed to a more conventional inheritance scheme.

But honestly, quite frankly, I can't tell what anyone would want to use JavaScript on the server at all for.

Re: Why the New V8 Is So Damn Fast

#55

Post by gunn »

sbjs wrote: post #12
out_of_protocol wrote: post #5

Earlier quoted context omitted.

Not true unfortunately. Rails quality unreachable for current js frameworks. Well, i hope situation will change in the future

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 inconsistencies with form data would save a lot of the troubles I've seen in rails apps.

Re: Why the New V8 Is So Damn Fast

#56

Post by Twirrim »

nielsbot wrote: post #13
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.

You might be interested in TruffleRuby: https://github.com/oracle/truffleruby "A high performance implementation of the Ruby programming language. Built on the GraalVM by Oracle Labs."

There's also JRuby, Ruby running on the JVM. Which can be insanely fast for anything longer running than your typical CLI use case.

Re: Why the New V8 Is So Damn Fast

#57

Post by zzzcpan »

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…

> take advantage of SIMD, hyperthreading, multicore, large caches... without knowing if they're available ahead of time

You can't with Javascript. You need concurrency-friendly programming model and code structure for compiler to be able to do anything that fancy.

Re: Why the New V8 Is So Damn Fast

#58

Post by delinka »

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…

A couple of the replies here seem to read that you've said something like "JIT magically makes single-threaded code multi-threaded." I'm a little mystified by the reading comprehension on HN...

You can write a multi-threaded optimizer that works on single-threaded code. Using multiple threads on multiple cores to optimize single-threaded code ... is pretty darn cool, but barbegal never said it made the single- into multi- ...

Re: Why the New V8 Is So Damn Fast

#59

Post by emp »

wolf550e wrote: post #16
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…

Welcome to 1995 and the wonderful world of Java. Except in Java you can use threads to use multiprocessing, so you can have efficient shared data structures but also hard to debug bugs.

Don’t forget 1987 and the Self language from which Java got Hotspot. Fascinating language and runtime: http://www.selflanguage.org

Re: Why the New V8 Is So Damn Fast

#60

Post by MikeHolman »

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 reason most of the features of the JIT are needed is due to the lack of static typing in javascript. The most important thing the JIT does is figure out what types of things you are using and optimize for them.

There will always be some cost here, because at runtime you need to check if your assumptions still hold. Some of the time you can pull these checks out of loops, but sometimes you can't, and they can be costly.

There are a few things a JIT can theoretically do better. Inlining is the biggest one. For example, a JIT knows not to inline a function that never gets called, and it can also do inlining for indirect calls based on profile data. A JIT could also theoretically move unexecuted blocks out of line for better instruction cache locality. It could also check for aliasing at run time (with a bailout) and then optimize a loop assuming no aliasing.

Unfortunately for JITs, AOT compilers can do a pretty good simulation of most of these things with PGO, that is running a scenario with an instrumented binary and re-optimizing using profile data.

Still can't bailout if an assumption is wrong, so it doesn't work for dynamic languages, but you don't really need bailout for much in static languages.

Post reply on HN