As an internet user, I really enjoy reading about all these performance improvements in V8 / javascript. As a ruby developer, I'm insanely jealous.
And here I am just happy I don't have to touch js.
I'm being downvoted because I can't be happy?
Why the New V8 Is So Damn Fast
161–170 of 237 posts
Re: Why the New V8 Is So Damn Fast
#162Earlier quoted context omitted.
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?
> respect Not much respect, but more acceptance as a unavoidable language to use that thanks of millons of $$$$/human-hours of effort to polish it... is ok-ish.
You don’t achieve acceptance without a level of respect that comes from being useful. JS is really one of the most useful languages today.
You can argue whether everything moving to web apps (and I may be using the term web apps wrong, but I’m speaking about anything that runs in a browser) is such a good idea, it’s probably not, but it’s whats happening because it’s really fucking awesome in terms of getting things to actually work across multiple devices.
JS does something none of the other tech stacks does, in that it integrates really well with your current stack. I work in enterprise, we operate more than 500 different it systems, and most of them run on windows. So natural,y our operations ninjas are really great at Microsoft tech. Operating ruby, PHP, python and so on can certainly be done within the windows environment, but we’ve naturally been doing .net since it fits in better.
JS fits into this infrastructure perfectly. A lot of it is thanks to MS, but we haven’t had to spend money on retraining staff to integrate modern JS into our stack.
The language itself offers a lot of freedom, which includes risk, but I don’t personally think it’s worsening that regard than python.
Re: Why the New V8 Is So Damn Fast
#163Why 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? 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-international.org/ecma-262/7.0/index.html#s...
[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: Why the New V8 Is So Damn Fast
#164Why hasn't node replaced PHP yet?
Hasn’t it? It’s the most utilized language on the web.
If you’re asking why PHP hasn’t died...Well, because it’s still useful. In the real world you don’t change your tech just because something better comes along because it’s tremendously expensive to do so.
That’s why cobol is still around, and if you want an example of something even worse, it’s also why you still find companies using classic ASP and so on.
And PHP isn’t really that bad. Parable is tremendously productive.
Re: Why the New V8 Is So Damn Fast
#165Earlier 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.
But go has an imprecise GC (in reference implementation) or stack maps (in gccgo), so the GC overhead is rather huge. It also lacks of compaction, so cache misses are not that good too.
Re: Why the New V8 Is So Damn Fast
#166Earlier 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.
.NET is another example of value types in a garbage collected language. It’s also somewhat unique afaik in doing so within a VM.
Re: Why the New V8 Is So Damn Fast
#167You have social icons floating over he text.
Re: Why the New V8 Is So Damn Fast
#168Earlier 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.
The compiler can also perform optimizations that are impossible for a JIT because they're too expensive. JITs have to balance execution speed with compilation time. It's not so clear cut which approach in theoretically superior. I also don't know any languages where a JIT and an AOT compiler have gotten equivalent amounts of engineering hours so that we could have a fair comparison.
Graal can run in dynamic and aot compilation mode. If you feed profiles into aot from a test run you can get pretty close to dynamic compilation peak performance.
Re: Why the New V8 Is So Damn Fast
#169Why 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.
I agree that this is unexpected for most of us, but if you read this section in my v8-perf repo ( https://github.com/thlorenz/v8-perf/blob/master/data-types.m... ) you'll understand better why that is. However it doesn't necessarily cause a large slowdown, just makes your function polymorphic and the resulting optimized code larger and a bit slower. To avoid this entirely I recommend using a JavaScript `class` when p…
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}?
Re: Why the New V8 Is So Damn Fast
#170Earlier quoted context omitted.
> 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 h…
You make some interesting points about cases where JS will always be difficult to be optimized automatically. I wonder if compiler hints can help in that regard? For example, if performance is important then you could annotate the 'x+=x' line to tell the compiler to not check for overflow.
Another option would be that the compiler deduces when exactly the statement x+=x would need to switch from integer to double. That's more difficult, and impossible in general, but not impossible in specific cases.