digitalmars.D - AST to AST JIT Backend
- James Lu (13/13) Aug 31 2020 I have an idea, one way we can get faster compiles for Dlang is
- kinke (4/6) Aug 31 2020 There has been some talk about MIR as well (the JIT project, not
- Araq (4/6) Aug 31 2020 It's the first time I read this complaint and it hasn't been my
- Francesco Mecca (13/26) Sep 01 2020 Over the years I have made some experiments in ast-to-ast
- James Lu (10/38) Sep 01 2020 I have experience writing high-performance JavaScript code,
- Atila Neves (8/21) Sep 03 2020 What you're talking about is exactly what I've wanted to do for
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (5/9) Sep 03 2020 Maybe it is possible to come up with some kind of plugin-like
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.
Aug 31 2020
kinke <noone nowhere.com> 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/
Aug 31 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.
Aug 31 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.
Sep 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 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.)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.
Sep 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.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.
Sep 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).
Sep 03 2020