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!
Why the New V8 Is So Damn Fast
151–160 of 237 posts
Re: Why the New V8 Is So Damn Fast
#152Earlier 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.
Re: Why the New V8 Is So Damn Fast
#153Earlier 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 ;)
Re: Why the New V8 Is So Damn Fast
#154Why hasn't node replaced PHP yet?
Re: Why the New V8 Is So Damn Fast
#155I 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.
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
#156Why 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.
https://richardartoul.github.io/jekyll/update/2015/04/26/hid...
Re: Why the New V8 Is So Damn Fast
#157Why 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…
function vec3 (x, y, z) { return {x, y, z} }Re: Why the New V8 Is So Damn Fast
#158Earlier 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.
Re: Why the New V8 Is So Damn Fast
#159I 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…
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
#160I 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 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.