Why the New V8 Is So Damn Fast

Post by pjmlp » Tue, Jul 31, 2018, 6:20 AM UTC

josephg wrote: post #106

ux-app wrote: post #87

Earlier quoted context omitted.

>For games I’ve heard of people making a per-frame arena allocation pools Games are a special case where each ms counts. Globally, the number of LOC written for consumer or business software dwarfs that of game code and for these kinds of applications JS is well within the realm of performant enough. That assumes you're not doing your presentation layer using the DOM though which is still garbage wrt performance. Luc…

Yes I think we all agree. As I said in my post above: >> Thanks to V8 you can definitely achieve good enough performance with JavaScript for most applications The point I argued above isn’t that JS is slow. It’s that JS will probably always be slower than well written C code. I still write far more JS than C, because my time is usually more valuable than the computer’s. That said, games are far from the only place wh…

Post by pjmlp » Tue, Jul 31, 2018, 6:24 AM UTC

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.

Post by pjmlp » Tue, Jul 31, 2018, 6:27 AM UTC

weberc2 wrote: post #115

mynegation wrote: post #81

Earlier quoted context omitted.

This is exactly it: dynamic languages give you OK ish performance and fast development speed. Fast C++ code requires a lot of expertise, this kind of expertise is expensive and there are diminishing returns too. I don’t know anything about expertise of your colleague in C++ but given that their first optimization was to eliminate some redundant copying, I suspect there is some more room for improvement. After unneces…

I don’t think this is a property of dynamic languages. This groovy example is almost certainly the best case for the JVM (arithmetic, few allocations or polymorphism, etc). In other words, probably not taking advantage of the dynamism. Dynamic languages can be fast by being well designed and simple (Wren) or highly optimized (JS) or both (LuaJIT). There’s also the experimental GraalVM, but this is definitely the exce…

Post by mingabunga » Tue, Jul 31, 2018, 6:38 AM UTC

hatcherdogg wrote: post #72

For some reason I was expecting an internal combustion engine.

Post by bazza451 » Tue, Jul 31, 2018, 6:49 AM UTC

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