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

191–200 of 237 posts

Re: Why the New V8 Is So Damn Fast

#191

Post by wruza »

readittwice wrote: post #128
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 yo…

>For generating good machine code you really need to know whether the number is int or double

Do you? I remember reading that LJ is able to infer ints for e.g. loops with no specific effort (neither performance hit).

Re: Why the New V8 Is So Damn Fast

#192

Post by austincheney »

zawerf wrote: post #6

Why can't V8 deduce that the order of keys doesn't matter? It's pretty nuts that just rearranging the keys from { x, y, z } to { y, x, z } would cause a slowdown.

Keys are written to objects in the order to which they are assigned. Why would want to modify that order since it is irrespective of key access?

Re: Why the New V8 Is So Damn Fast

#193

Post by elyobo »

brianmurphy wrote: post #89
AzzieElbab wrote: post #34

Why hasn't node replaced PHP yet?

Speaking for myself, I have 20 years of C like language experience and I can't stand the scoping rules or functional nature of javascript. This is why I like PHP. It comes natural when switching between C, bourne shell, perl and PHP. Throw in the ever changing frameworks a casual user encounters and I want to avoid javascript at all costs.

Mmmm, I have a similar background (the C was long ago, the PHP not so long) but love the scoping rules and functional nature. I think that the C background (declaring variables up the top of a function) helped avoid some of the JS pitfalls, and I find the block scoping in JS to be convenient at times, whereas PHP's leaks things in ways that can bite you sometimes (e.g. a for loop in PHP would leak both the iterator variables and variables defined within it, while they wouldn't in JS).

The functional stuff was weird for a while but just keeps growing on me.

Re: Why the New V8 Is So Damn Fast

#194

Post by mort96 »

_0w8t wrote: post #174
axilmar wrote: post #169

Earlier quoted context omitted.

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}

AFAIK, that's not true; the spec doesn't guarantee that it iterates in insertion order, it's just how it's commonly implemented in browsers.

Re: Why the New V8 Is So Damn Fast

#195

Post by jashmatthews »

abhorrence wrote: post #23
lovelle wrote: post #15

Earlier quoted context omitted.

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

2.6’s JIT is entirely at the method level currently, and unfortunately for certain types of workloads (e.g. Rails) this means the performance benefit is largely outweighed by the call counters and deoptimization checks on every method invocation. There’s definitely room for improvement, and the inclusion of JIT infrastructure is awesome, it’s just not making much of a performance impact. Yet.

The overheads from the call counters and deoptimization checks are tiny. The real problem is that right now MJIT doesn't allow much optimization beyond generating native code equivalent to simply executing the instructions. It's ridiculously simple compared to V8.

Re: Why the New V8 Is So Damn Fast

#196

Post by mxkxkucikf »

the_duke wrote: post #173
solidr53 wrote: post #137

Earlier quoted context omitted.

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.

Typescript being a superset of javascript does allow optional type annotations. RTFM.

Re: Why the New V8 Is So Damn Fast

#197

Post by lucb1e »

b2ccb2 wrote: post #163
lucb1e wrote: post #125

Earlier quoted context omitted.

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? Ther…

> One can't even add 0.1 and 0.2 together and get what you'd expect. That's floating point math, and persists in many languages [1]. > Variable definitions are global scoped by default, semicolons can randomly be omitted, etc. Nothing random about it, automatic semicolon insertion is well defined/documented [2]. Also let [3] is your scoping friend. [1] https://0.30000000000000004.com/ [2] https://www.ecma-internation…

> Nothing random about it, automatic semicolon insertion is well defined/documented

Figured someone would say that. Yes, of course it's not random: it's a computer, it follows the same instructions every time.

What I meant, of course, is that it isn't logical. You can't guess it without having to check the spec. In bash you know that a newline is as good as a semicolon, in C you know you always need a semicolon, and in Python you know you never need it. In JS it's somewhere in between. Reading that spec, it's when the next line would have syntax that is illegal if it were a continuation... so you have to do JS simulation in your head to check if your code could, perhaps, make sense as a line continuation. So I guess you just always have to do it. I'm not saying it's a major issue and this is the one reason I don't use it, but similar to how people criticize PHP for having inconsistent function names (which is also not a bug or broken), it would have been nice if it weren't the case.

> let [3] is your scoping friend

It's not about it being possible, it's that global scoped default is just asking for abuse of the global scope. Even PHP doesn't do that, and PHP is really made for quick and dirty web development (or at least it used to be, so it supports many things that make that possible).

Re: Why the New V8 Is So Damn Fast

#198

Post by eksemplar »

konart wrote: post #161
konart wrote: post #144

Earlier quoted context omitted.

And here I am just happy I don't have to touch js.

I'm being downvoted because I can't be happy?

You’re probably being downvoted because your comment doesn’t contribute anything to the thread. And rightly so, unless you want HN to be as useless as /r/programming.

Your comment is also borderline rude, as it implies that anyone using JavaScript are unfortunate. I mean, what did you really want to achieve by posting that comment?

Re: Why the New V8 Is So Damn Fast

#199

Post by syspec »

mxkxkucikf wrote: post #196
the_duke wrote: post #173

Earlier quoted context omitted.

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

Typescript being a superset of javascript does allow optional type annotations. RTFM.

i think they mean, make it into the JS spec.

Re: Why the New V8 Is So Damn Fast

#200

Post by beagle3 »

blattimwind wrote: post #190
beagle3 wrote: post #183

Earlier quoted context omitted.

Yes, it seems Graal might finally deliver on the "JIT is better because it is better informed" promise after 20 years. I'm holding my fingers crossed, but I think we need a little more experience with it before victory can be declared.

What about luajit?

luajit is a great triumph for dynamic compilations and jits; and the fact that it compares favorably to C code (about 70-85% in some of my experiments) is utterly amazing. Especially given that it's essentially the work of one person.

And yet, regardless of how much typing info you give it, it loses out to good AOT compilers, for a similarly implemented algorithm.

GraalVM is unique in that it seems to do better than AOT in some cases. I'd wait a couple more years before declaring JIT victory, though.

The belief is that JITs have information, such as variable values and memory access patterns, that an AOT does not. Well, so far hardly any JIT uses that info, and AOTs do have them from through profile feedback; And also, JITs have to amortize compilation effort and runtime saving, whereas AOT doesn't. So the "JIT is obviously >= AOT" is not foregone conclusion.

Post reply on HN