Closed datdinhquoc closed 4 years ago
v8 does amazing things in optimising JavaScript. It will always do a better job of optimising JavaScript than almost everyone would do trying to do that themselves. It is a lot more than just trying to "translate" JavaScript (or TypeScript) to op codes, you have to provide all the expectations of a JavaScript runtime, like a GC system, etc.
We are very unlikely to ever not use v8.
@kitsonk I'm wondering if it would be possible to optimize V8 thanks to the insights given by the types (for inline caching), and other code optimizations that could be done by the JS/SWC compiler. Do you think that this would be possible in the long term future?
The Chromium team experimented with this a while back (strong mode R.I.P. 2015-2016) and it didn't and so they dropped it.
@pirix-gh As an aside, if you're interested in compiling JavaScript to standalone binaries, you should check out QuickJS. It lends itself well to embedding.
As for V8... I echo @kitsonk's answer above. I doubt V8 would ever be suitable for compiling standalone binaries (size-efficient ones, at least). You've got the Ignition interpreter, lazy compilation, bytecode flushing, all sorts of memory-juggling techniques, and numerous other factors relevant in a VM-like environment, but not a precompiled binary.
Though it'd probably be fun to screw around with TurboFan by marking every function as hot, eagerly compiling everything, and treating deoptimised code as a compilation error. 😁 It'd make the worst Clang replacement ever.
Closing in favor of https://github.com/denoland/deno/issues/986
@Alhadis QuickJS is order of magnitudes slower than V8. It maybe suitable for some embeddable workloads where there is tight control over the JavaScript it runs, but isn't suitable for Deno which needs to run general performance JavaScript.
@kitsonk I was bringing up QuickJS in case it was of interest to the OP. Read my response a bit closer:
As an aside, if you're interested in compiling JavaScript to standalone binaries
At no point did I imply anything about engine performance.
@Alhadis you mentioned someone who was not the OP. The person you mentioned questioned if performance could be improved by using types. So maybe read the questions a bit closer?
Right, so I copy+pasted the wrong username when writing that. My mistake.
Regardless, it should have been obvious that my reply was tangential to the conversation.
Well the OP said:
As in the diagram above, Deno is still based on V8 Engine which is JavaScript, and JS is non-typed, this will make the run-time execution slow.
Your suggestion would make runtime execution even slower... So in any context your thoughts were tangential to the conversation. 🤷
Jesus fucking Christ, I said it was an aside.
I regret posting. You're a fair dinkum gronk.
I was expecting that deno would be possible to compile to binary, I'm a big fan of a single binary format (inspired by Go) which offers simplicity on fast scaling experience and small deployment file size (k8s)
As in the diagram above, Deno is still based on V8 Engine which is JavaScript, and JS is non-typed, this will make the run-time execution slow.
Is it possible to compile Deno to native binary for performance, coz Deno runs TypeScript that is typed? For example, compile through LLVM?