Live data from Hacker News

Why the New V8 Is So Damn Fast

nodesource.com

151–160 of 237 posts

Re: Why the New V8 Is So Damn Fast

#151

As an internet user, I really enjoy reading about all these performance improvements in V8 / javascript. As a ruby developer, I'm insanely jealous.

You say "Ruby developer" as if you were born like that and stuck with it. There's an entire world out there!

If the alternative is JavaScript, I think most Ruby programmers are fine where they are ;)

Re: Why the New V8 Is So Damn Fast

#152
post #12

Earlier quoted context omitted.

Not true unfortunately. Rails quality unreachable for current js frameworks. Well, i hope situation will change in the future

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.

It sounds like you're looking for Ember. https://www.emberjs.com

Re: Why the New V8 Is So Damn Fast

#153
post #151

Earlier quoted context omitted.

You say "Ruby developer" as if you were born like that and stuck with it. There's an entire world out there!

If the alternative is JavaScript, I think most Ruby programmers are fine where they are ;)

I don't know. I'd say that both Ruby and JavaScript are pretty awesome these days.

Re: Why the New V8 Is So Damn Fast

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

From the late 90s until 2006, I believed in the sufficiently smart JIT. There were a few benchmarks showing corner cases of Java out-performing C/C++. I followed the research. I was particularly excited by Michael Franz's SafeTSA research on more JIT-optimized program representations. Surely we were just a few years from Java generally out-performing C/C++! I worked on the most popular Java desktop app.

Then I moved to Google, working on the indexing system and properly learned C++. I've since worked on several projects for several companies where the annual cost for compute time is easily 200 times my salary. These are systems where it pays to extensively profile both CPU and I/O and retain C++ optimization experts.

I still see the appeal of platform-independent binaries and dynamic optimization, but you really need the startup time and optimization cost advantages of ahead-of-time compilation. Hopefully the platform independence and dynamic optimization features would also be decoupled from the garbage collector.

HP Research had project dynamo that was basically a tracing JIT emulator for PARisc CPUs that ran on PARisc. It showed that binaries compiled with -O2 could get performace comparable to -O4 through dynamic recompilation.

Ideally, we'd distribute programs in a compact and compressed CPU-independent SSA representation similar to SafeTSA or LLVM bitcode. Installation would AoT-compile the binaries and keep around the SSA form for use by an HP Dynamo-like runtime optimizer. The AoT could compile functions and methods to lists strait-line extended basic blocks with a call to a trampoline loop or other techniques for lightweight instrumentation/tracing of native code. The dynamic optimizer wouldn't need to work with arbitrary machine code, only AoT compiler output. Also, it would never have to disassemble native code, but could always start by gluing together the SSA for each extended basic block in the trace.

A few CPU features could make native tracing and dynamic recompilation extremely light weight. Unfortunately, Intel and ARM are disincentivised to do so, as it would make it easier to migrate off of their intellectual property.

Re: Why the New V8 Is So Damn Fast

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

Because it uses hidden classes to get read in O(1) for an object property access. The slowdown comes from the inline cache as explained in below article.

https://richardartoul.github.io/jekyll/update/2015/04/26/hid...

Re: Why the New V8 Is So Damn Fast

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

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…

A factory function will also give the objects it returns the same hidden class, resulting in monomorphic code that can be optimized.

    function vec3 (x, y, z) { return {x, y, z} }

Re: Why the New V8 Is So Damn Fast

#158
post #151

Earlier quoted context omitted.

If the alternative is JavaScript, I think most Ruby programmers are fine where they are ;)

I don't know. I'd say that both Ruby and JavaScript are pretty awesome these days.

It certainly is a lot better than it was. Though every time I'm allowed back at the backend, Ruby is just such a breath of fresh air.

Re: Why the New V8 Is So Damn Fast

#159

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…

An int64 type is being added to Javascript in the near future, I believe.

Of course it will take a while to be supported everywhere, but they are taking steps in that direction at least.

Re: Why the New V8 Is So Damn Fast

#160

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…

I think the type annotations themselves don't do anything, but the typing strongly pushes developers towards monomorphic (or at least non-megamorphic) calls sites; and having proper-ish data types may also encourages consistent order of initialisation.

I don't really know about the details fo Pypy, but from what I gathered from performance talks about V8 between the hidden classes and inline caching it would strongly benefit from these behavioural changes.

Basically, it doesn't preclude the runtime from having to do its analysis, but it makes the analysis & optimisations "hit" at higher rates than they would otherwise do.

Post reply on HN