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

231–237 of 237 posts

Re: Why the New V8 Is So Damn Fast

#231

Post by konart »

eksemplar wrote: post #198
konart wrote: post #161

Earlier quoted context omitted.

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?

How my comment is different from this one - https://news.ycombinator.com/item?id=17650823 for example?

>Your comment is also borderline rude, as it implies that anyone using JavaScript are unfortunate

No, it does not, that's just your interpretation. I never used word 'fortunate' or anything similar. I'm happy not to work with it as in "I'm happy not to use public transport today, because I like walking". Surely this can't be rude to anyone except those people who see everything as way to offence them somehow. Inferiority complex maybe? No idea.

> I mean, what did you really want to achieve by posting that comment?

Just wanted to express myself. As it turns out that's a wrong thing to do unless you have some sort of clear goal in mind. Noted.

Re: Why the New V8 Is So Damn Fast

#232

Post by kwood »

vinceguidry wrote: post #206
vimslayer wrote: post #205

Earlier quoted context omitted.

Indeed, JS does not have classical inheritance. IMO introducing a class syntax that looks so much like the classes from other languages and yet behaves differently was a mistake. The rest of your comment sounds a bit misinformed to me. You seem to have decided that prototypical inheritance is somehow inherently worse than classical inheritance, but don't mention why that would be. I have found very little practical d…

I didn't intend to argue that prototypal inheritance was bad, just that I didn't relish the prospect of building something in it, in the context of a discussion about reinventing Rails in Javascript. The argument is that with the amount of time and effort that went into Rails, the new framework has to offer something a lot more unique than just "Rails in JS" if it wants to be relevant, because you'll never even get r…

From what I remember, object spread came a year later and is ES7 (in case you need a starting point for research)

Re: Why the New V8 Is So Damn Fast

#233

Post by eropple »

sbjs wrote: post #211
eropple wrote: post #129

Earlier quoted context omitted.

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

You can add another build step right after the `tsc -w` compilation phase, which takes your .ts files, parses them to find our your types, and emits runtime code that checks your types. That's what you're describing that TypeScript should be doing on its own. But I don't see why you'd want to do this instead of using io-ts? This is more complicated overall.

Runtime type information is important. TypeScript is in the best place to provide it. So...it should. Boilerplating our way through io-ts is a waste of my time and yours.

Re: Why the New V8 Is So Damn Fast

#234

Post by physguy1123 »

repolfx wrote: post #184
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…

There's this classic paper from Google that runs an optimisation competition on the same program written in C++, Java, Scala and Go: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...

This is great benchmark of the fundamental problems with say Java - the code itself is fairly simple and the JITs probably generate optimal code given their constraints, but the performance problems clearly show that the GC and pointer chasing really hinder your performance.

If you add in cases where simd, software prefetching, or memory access batching help, the difference will only grow.

Re: Why the New V8 Is So Damn Fast

#235

Post by cztomsik »

lucb1e wrote: post #197
b2ccb2 wrote: post #163

Earlier quoted context omitted.

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

You're totally safe unless you start line with parentheses, bracket or operator so it's not that hard - https://standardjs.com/rules.html#semicolons

const/let is the way of doing javascript, setting global will raise an error (click "run with js" http://jsbin.com/hogegikipo/edit?html,console,output). This is true for ES5 strict mode, ES2015 modules and anything you will transpile from ES2015 modules.

Re: Why the New V8 Is So Damn Fast

#236

Post by Twirrim »

askaboutit wrote: post #85
Twirrim wrote: post #56

Earlier quoted context omitted.

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

I believe Truffle was 3-4x+ faster than Jruby. This is what Ruby needs. But Oracle will ruin it.

It's open source, the community can always fork it and move forwards if they dislike what Oracle does with it.

Re: Why the New V8 Is So Damn Fast

#237

Post by simiones »

zzzcpan wrote: post #203
jahewson wrote: post #110

Earlier quoted context omitted.

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.

> because the JIT can perform optimisations which are impossible for the compiler Is there an example of at least one such optimization? As JIT is not magic, it also compiles things ahead of time, but a little bit ahead of time and it is very constrained on how much time and resources it can waste. It also can't afford to slow down interpreter too much, can't do excessive profiling, can't do big changes to the code t…

One such example is dynamic re-compilation in Java, with e.g. inlining or uninlining based on recent profiling. This would handle the case where a certain (large-ish) function is on a branch that's often taken for some stable amount of time (where inlining gets rid of method call overhead), then often not taken for other periods of time (where un-inlining gets rid of the instruction cache bloat).

Artificial example:

    while (true) {
        if (timeOfDay
Post reply on HN