Thread overview
AST to AST JIT Backend
Sep 01, 2020
James Lu
Sep 01, 2020
kinke
Sep 01, 2020
Araq
Sep 01, 2020
Francesco Mecca
Sep 01, 2020
James Lu
Sep 03, 2020
Atila Neves
September 01, 2020
I have an idea, one way we can get faster compiles for Dlang is by compiling to an existing JITted language, which could be easier to build a proof of concept for than a full optimizing JIT compiler.

Perhaps we could compile Dlang to Lua, targeting LuaJIT or JavaScript, targeting V8.

I personally know to write highly performant JavaScript very well. Combined with Dlang's natural type information, it could result in fast machine code, fast. Backends for the Nim language tend to output poor (slow) JavaScript code.

In an earlier thread, I showed that the V8 JavaScript engine could generate decent quality machine code much faster than LLVM D Compiler.
September 01, 2020
On Tuesday, 1 September 2020 at 00:15:24 UTC, James Lu wrote:
> Perhaps we could compile Dlang to Lua, targeting LuaJIT or JavaScript, targeting V8.

There has been some talk about MIR as well (the JIT project, not Ilya's numerical libraries): https://developers.redhat.com/blog/2020/01/20/mir-a-lightweight-jit-compiler-project/
September 01, 2020
On Tuesday, 1 September 2020 at 00:15:24 UTC, James Lu wrote:
> Backends for the Nim language tend to output poor (slow) JavaScript code.

It's the first time I read this complaint and it hasn't been my experience at all. It was good enough to win "virtual DOM" benchmarks a couple of years ago.
September 01, 2020
On Tuesday, 1 September 2020 at 00:15:24 UTC, James Lu wrote:
> I have an idea, one way we can get faster compiles for Dlang is by compiling to an existing JITted language, which could be easier to build a proof of concept for than a full optimizing JIT compiler.
>
> Perhaps we could compile Dlang to Lua, targeting LuaJIT or JavaScript, targeting V8.
>
> I personally know to write highly performant JavaScript very well. Combined with Dlang's natural type information, it could result in fast machine code, fast. Backends for the Nim language tend to output poor (slow) JavaScript code.
>
> In an earlier thread, I showed that the V8 JavaScript engine could generate decent quality machine code much faster than LLVM D Compiler.

Over the years I have made some experiments in ast-to-ast conversions for luajit, there is even a nice tool to do that easily here:
https://github.com/franko/luajit-lang-toolkit

The results weren't always satisfying because most of the time the luajit optimizer expects idiomatic lua code.
To be more precise, luajit is so powerful because it is optimized for the kind of ast that is emitted from idiomatic lua code when compiled.
It is very difficult to reproduce that for non trivial snippets of code.

I suggest you to try that yourself.

September 01, 2020
On Tuesday, 1 September 2020 at 21:36:13 UTC, Francesco Mecca wrote:
> On Tuesday, 1 September 2020 at 00:15:24 UTC, James Lu wrote:
>> I have an idea, one way we can get faster compiles for Dlang is by compiling to an existing JITted language, which could be easier to build a proof of concept for than a full optimizing JIT compiler.
>>
>> Perhaps we could compile Dlang to Lua, targeting LuaJIT or JavaScript, targeting V8.
>>
>> I personally know to write highly performant JavaScript very well. Combined with Dlang's natural type information, it could result in fast machine code, fast. Backends for the Nim language tend to output poor (slow) JavaScript code.
>>
>> In an earlier thread, I showed that the V8 JavaScript engine could generate decent quality machine code much faster than LLVM D Compiler.
>
> Over the years I have made some experiments in ast-to-ast conversions for luajit, there is even a nice tool to do that easily here:
> https://github.com/franko/luajit-lang-toolkit
>
> The results weren't always satisfying because most of the time the luajit optimizer expects idiomatic lua code.
> To be more precise, luajit is so powerful because it is optimized for the kind of ast that is emitted from idiomatic lua code when compiled.
> It is very difficult to reproduce that for non trivial snippets of code.

I have experience writing high-performance JavaScript code, because I've microbenchmarked lots of JavaScript and understand engine internals. Care to link me to what idiomatically fast Lua looks like? Or, should we, as you suggest, try microbenchmarking myself? And should we base AST to AST translation off your work? (I presume to use Lua or JavaScript as a fast JIT intermediate language, one needs to de-abstract the AST a bit to get something easier to translate into a faster Lua/JS AST.)
September 03, 2020
On Tuesday, 1 September 2020 at 00:15:24 UTC, James Lu wrote:
> I have an idea, one way we can get faster compiles for Dlang is by compiling to an existing JITted language, which could be easier to build a proof of concept for than a full optimizing JIT compiler.
>
> Perhaps we could compile Dlang to Lua, targeting LuaJIT or JavaScript, targeting V8.
>
> I personally know to write highly performant JavaScript very well. Combined with Dlang's natural type information, it could result in fast machine code, fast. Backends for the Nim language tend to output poor (slow) JavaScript code.
>
> In an earlier thread, I showed that the V8 JavaScript engine could generate decent quality machine code much faster than LLVM D Compiler.

What you're talking about is exactly what I've wanted to do for about a year now, with the addition of a focus on running unit tests. My goal is to experiment and find out what is the fastest way to get results from tests, which is tricky since it's a balancing act between interpreting/compiling/executing. I'm fed up of paying the linker tax.

I wish I had the time.
September 03, 2020
On Thursday, 3 September 2020 at 16:29:50 UTC, Atila Neves wrote:
> tests. My goal is to experiment and find out what is the fastest way to get results from tests, which is tricky since it's a balancing act between interpreting/compiling/executing. I'm fed up of paying the linker tax.

Maybe it is possible to come up with some kind of plugin-like load/unload approach.

So that the testing framework is executed once and then does hot reload/fork (whatever the OS provides an efficient solution for).