Newhouse: Because you need the ****ysis p*** and interpreting IR.
Mollo: Gajus: it’s possible with ES6 modules
Trucchi: Yamasaki: I’m genuinely curious, what’s your argument citations aside that Java would be faster than C++?
Standen: It’s not possible with CommonJS ones
Pelchat: I want it to stretch to window height but go offscreen
Trucchi: Because all else being equal, C++ tends to be faster though there are always specific use-cases where one thing wins over the other
Buchheit: Dekok: Right. That ***umes that all of the code is using ES6 modules down the dependency chain
Mischke: Granted, PyPy is written in PyPy itself. It’s a self hosted JIT. It’s quite neat
Marek: Ie. lodash should be using that too
Walters: Gajus: import only works with ES6 modules.
Litzau: And since npm packages are being distributed with ES5 code in /dist/ which is different from /src/ that wouldn’t work.
Krites: Anything else is a deviation of the spec
Fisher: Java can be faster than c++, for unoptimized c++ or java, and ***uming you’ve spent the time tuning the vm and gc parameters to your wo***oad, and that your code doesn’t hit an edge case in the vm. etc.
Yamasaki: Trucchi: Well, isn’t javscript making the same claim, because it has a trace-jit, it produces much faster code than any static compiler could do. the compiler cannot predict the hotspots, hence the optimizations are more generic and not really focused on what gets executed the most
Trucchi: Eh? but the C++ compiler does focus on what gets executed the most in some situations
Pennacchio: Yamasaki: you can do PGO
Yamasaki: But then it seems strange that these vms and jits are not written in their own language for performance reasons, like they are e.g in Lisp
Trucchi: Yamasaki: anyway, this isn’t necessarily a hypothetical – you can compare nashorn written in Java and v8
Mulkins: This channel is amazing
Schirpke: But, you actually have control over the performance in c++, and hand optimized c++ can hit, or come very close to the limits of the machine in many cases
Rowand: And PGO doesn’t have the problem of being limited in time, like most JITs do.
Trucchi: Though nashorn is still being worked on and is a newer product
Trucchi: I think whether you want a vm/jit written in its own language very much depends on the language and what your needs are
Raitt: Yamasaki: the amount of work you’d need for writing a self-hosted JIT is quite a lot. For JS, you’d need to come up with a restricted subset, just like PyPy uses RPython
Prutt: Because full JS is too dynamic
Trucchi: In theory you could do something like that with WASM or ASM.js
Chevas: WASM still needs to support platform-independent JIT’ing for that to be efficient though
Mcgath: Yamasaki: the thing about c++ is that you have very little or no runtime overhead essentially none if you turn off rtti and exceptions, and can use compiler intrinsics or even inline ***embly to ensure the code you want is executed.
Yamasaki: Trucchi: vtune from intel did also hotspot ****ysis/tracing, but clang/gcc do not. they judge just from the code what to optimize and from the programmers hints. e.g. Linux uses unlikely to tell the compiler what it should ***ume about the likelihood of branching. a tracing jit will find that out by itself
Trucchi: Which is the ability to do native extensions and integrations
Trucchi: Oh, you’re talking about JIT on the C++ code, not on the JS code being compiled