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

121–130 of 237 posts

Re: Why the New V8 Is So Damn Fast

#121

Post by weberc2 »

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.

> 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 of the decades of optimizations that went into the JVM; the same investment in an AOT compiler would close the gap to within the margin of error. Anyway, sorry for my compulsive nitpicking; hopefully it was interesting.

Re: Why the New V8 Is So Damn Fast

#122

Post by yxhuvud »

askaboutit wrote: post #50
nielsbot wrote: post #13

Earlier quoted context omitted.

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."

I researched this yesterday against Crystal. Seems people won’t touch it because of oracle. Which is a real shame. Truffle is a 9x improvement in speed over Ruby. But because Oracle is a patent nightmare and a dying organization. People aren’t interested.

Uh, how is oracle a dying organization?

Re: Why the New V8 Is So Damn Fast

#124

Post by tlrobinson »

lovelle wrote: post #15
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.

I would insanely choose ruby rather than javascript for the major advantages that has to offer. Performance in most of cases is not a real needed over consistency. Also Ruby 2.6 has jit, would be great to see some bench tests. :P

Out of curiosity, what are the major advantages Ruby has to offer over JavaScript?

Re: Why the New V8 Is So Damn Fast

#125

Post by lucb1e »

AzzieElbab wrote: post #34

Why hasn't node replaced PHP yet?

I don't like Javascript as a language. Everything from OOP to imports feel hacked in rather than having been supported by the language itself. One can't even add 0.1 and 0.2 together and get what you'd expect. Variable definitions are global scoped by default, semicolons can randomly be omitted, etc. There are just so many things about the language that feel hacky or unpolished.

So it's fast these days... great? There's more that I seek for in a language than just speed. PHP7 and Pypy also do a pretty good job, and one can always offload the heavy lifting to some compiled code if it's really that important to squeeze the last few percent of performance out.

The only thing unique to JS (afaik) that I really like is addressing dictionary keys as object properties (`a={'test':512}; console.log(a.test);` instead of having to do `console.log(a['test']);`). I'm not sure why that is so oddly satisfying, but it is.

Re: Why the New V8 Is So Damn Fast

#126

Post by yxhuvud »

weberc2 wrote: post #111
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…

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.

Regarding your last point, Crystal has the same features as go in that regard, while at the same time being vastly more expressive. This mostly due to the standard library in Crystal being so nice for work with collections (which perhaps isn't surprising as the APIs are heavily influenced by Ruby). Blocks being overhead free is another necessary part for this to work well.

Re: Why the New V8 Is So Damn Fast

#127

Post by ken »

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.

Not surprising. HP did this with PA-RISC binaries, back in the 1990's: http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html

They found that most programs ran slightly faster in the JIT. I'm still not sure why this technique didn't catch on.

Re: Why the New V8 Is So Damn Fast

#128

Post by readittwice »

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

I don't think so: TypeScript/JavaScript-Types are too coarse-grained for optimizations: For example number is a double in JS. For generating good machine code you really need to know whether the number is int or double. The same for string: Depending on the JS engine there are actually a lot of different string types.

Even if we consider that good enough or somehow solved, understanding type annotations only helps you reaching peak performance faster. It doesn't really make peak performance faster.

Also there are the PyPy and Dart devs that in theory could use type annotations, but both don't. For PyPy they even have an entry in the FAQ: http://doc.pypy.org/en/latest/faq.html#would-type-annotation...

Re: Why the New V8 Is So Damn Fast

#129

Post by eropple »

sbjs wrote: post #77
nicoburns wrote: post #68

Earlier quoted context omitted.

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/

TypeScript can do runtime checks like this! Granted it uses a TypeScript framework (similar to AJV) that both does the runtime checks and preserves type information for your IDE and type checker. I wrote about it here: https://medium.com/@stevenbradleyconsulting/from-0-to-type-s...

Aw, man - I'd hoped you'd found something to make this less of a stone-cold pain to do. Instead, it's io-ts again. Which is...interesting...but it really sucks to actually use when you have to manually define every in/out yourself. It's 2018. There's no good reason TypeScript can't emit the type information to just build these (and I don't really mean decorator metadata).

Re: Why the New V8 Is So Damn Fast

#130

Post by tlrobinson »

vinceguidry wrote: post #54
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.

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

Apparently Steve Yegge ported much of Rails to JavaScript (on Rhino, at the time) back in 2007 at Google, but it was never open sourced AFAIK: https://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html

For comparison, (according to `find . -name "*.rb" | xargs wc -l`) Rails back then was about 66K LOC (plus 38K LOC of tests) and is now 137K LOC (plus 216K LOC of tests).

However, Steve says he only ported "essentially all of ActionView, ActionController and Railties, plus a teeny bit of ActiveRecord", so maybe half of the total.

Post reply on HN