denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
97.29k stars 5.36k forks source link

Feature request: Deno, compile to native binary #5512

Closed datdinhquoc closed 4 years ago

datdinhquoc commented 4 years ago

image 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?

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

millsp commented 4 years ago

@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?

kitsonk commented 4 years ago

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.

Alhadis commented 4 years ago

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

bartlomieju commented 4 years ago

Closing in favor of https://github.com/denoland/deno/issues/986

kitsonk commented 4 years ago

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

Alhadis commented 4 years ago

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

kitsonk commented 4 years ago

@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?

Alhadis commented 4 years ago

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.

kitsonk commented 4 years ago

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

Alhadis commented 4 years ago

Jesus fucking Christ, I said it was an aside.

I regret posting. You're a fair dinkum gronk.

slaveofcode commented 4 years ago

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)