Following my previous post about new opportunities for D with ASM.js, I've caught up with a lot of reading about Dart after seeing the seriousness of the project and a virtual machine being integrated to chrome directly. The benchmarks are already very promising[1]

My position has changed, and I now think D would be in a better position if it ran in the Dart VM. In other words, ASM.js has become the Dart language - the solution is to introduce a D to Dart compiler[2]. This compiler would be written in D with Pegged, the same way I'm writing this ASN.1 compiler[3]

This would require the interfaces from the Dart libraries (front-end DOM objects) to be built into a D library. Of course, the D=>Dart compiler would need to handle druntime and phobos as well for complete integration. I don't think this task is half as complicated as it would have been to go the D=>LLVM=>ASM.js route.

The best part of it all is this: you can compile the back-end (server-side) code to a binary executable using vibe.d and achieve immense performance improvements vs what runs in the Dart VM, and send the front-end code to Dart. This obviously seems like a durable and promising opportunity.

Comments?

[1] https://www.dartlang.org/performance/
[2] https://www.dartlang.org/articles/why-not-bytecode/#compiling-to-source
[3] https://github.com/globecsys/asn1.d

Etienne:

> the solution is to introduce a D to Dart compiler[2]. This compiler would be written in D with Pegged,

How much RAM is this going to use?

Bye,
bearophile

On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:
> My position has changed, and I now think D would be in a better position if it ran in the Dart VM. In other words, ASM.js has become the Dart language - the solution is to introduce a D to Dart compiler[2].

Chrome runs pnacl which is a lot more efficient than Dart, but a D to Dart converter would be interesting for sharing code.

> Of course, the D=>Dart compiler would need to handle druntime and phobos as well for complete integration.

That sounds like a bad idea. No sane person would write Dart code in D. The main benfit would be in sharing datastructures/RPC-like functionality.

On 2014-05-15 4:48 PM, bearophile wrote:
> Etienne:
>
>> the solution is to introduce a D to Dart compiler[2]. This compiler
>> would be written in D with Pegged,
>
> How much RAM is this going to use?
>
> Bye,
> bearophile

Good question, I'd be aiming for a 64 bit compiler with ~4 GB max memory usage, the ASN.1 compiler I made with pegged stayed well below 2 GB with 1000 lines of BNF->PEG rules unless I had 700+ lines of code to parse (which check every OR possibility at 3 levels deep for the longest matching solution).

It's very efficient when you generate the grammar in a separate D file and make good use the garbage collector rather than mixin the grammar directly. https://github.com/globecsys/asn1.d/blob/master/asn1/parser/parser.d#L1022

On 2014-05-15 4:58 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>
> That sounds like a bad idea. No sane person would write Dart code in D.
> The main benfit would be in sharing datastructures/RPC-like functionality.

The Phobos and druntime would most likely be type-resolved and inlined when converted to Dart code. It's mostly to stay in D. This compiler wouldn't really generate Dart code for... you know.. being "used". It would mostly allow to use the power of templates/alias/ctfe/contracts/auto/etc for browser-executed code (going through Dart is a side-effect)

On Thursday, 15 May 2014 at 21:05:12 UTC, Etienne wrote:
> On 2014-05-15 4:58 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> The Phobos and druntime would most likely be type-resolved and inlined when converted to Dart code. It's mostly to stay in D. This compiler wouldn't really generate Dart code for... you know.. being "used". It would mostly allow to use the power of templates/alias/ctfe/contracts/auto/etc for browser-executed code (going through Dart is a side-effect)

Ok, as a Dart developer I would never use this:
1a. The files will be too big.
1b. Compiling from D to Dart to JS will lead to insanely big files.
2. The dart IDE has browser integrated debugging.
3. What is the benefit, it will be wiped out once PNaCl is available as a D backend?

On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:
> This compiler would be written in D with Pegged, the same way I'm writing this ASN.1 compiler[3]

A lexer, parser, and set of AST classes for D already exists. You may want to use them instead.

https://github.com/Hackerpilot/Dscanner/tree/master/std/d

On 2014-05-15 5:10 PM, "Ola Fosheim Grøstad"
> Ok, as a Dart developer I would never use this:
> 1a. The files will be too big.

There's really no issue with big files, because dart minify, tree shaking and the general VM caching opportunities & further optimizations can take care of it.

> 1b. Compiling from D to Dart to JS will lead to insanely big files.

This compiler would be a bet that the VM can offer more and better optimizations. Tree shaking and minification can provide good advantages and refactoring opportunities for the time being, it's nothing we've never seen with the current JS libraries.

> 2. The dart IDE has browser integrated debugging.

The dart code generated by D=>Dart compiler would be pretty-printed and suitable debugging through the dart IDE

> 3. What is the benefit, it will be wiped out once PNaCl is available as
> a D backend?

The idea so far has been that the Dart VM will run on source code rather than bytecode like PNaCl, and it will be faster for it.

First, you can further optimize the script if you're flexible on the data types. It's impossible to fit 2 longs into an int with PNaCl, but the Dart VM will do it if that could be something the source code allows.

Second, you can keep doing "tree shaking" even during the program execution. Haven't used a part of the code for a while? Fine, lets just take it out of the memory and serialize the data for later.

Finally, you keep the debug info with you in the browser. I don't know what the complexity of debugging bytecode in the browser would be, it's hard to come accross a good visual GDB debugger and we all know how long that's been around.

So, this is mostly a bet that minified files pushed in a Dart VM will be better off than bytecode in most cases

On Thursday, 15 May 2014 at 21:33:24 UTC, Etienne wrote:
> There's really no issue with big files, because dart minify, tree shaking and the general VM caching opportunities & further optimizations can take care of it.

It can do some tree shaking if you turn off metainfo. But D templates is bound to lead to bloat. Dart is a dynamic language and does not benefit much from templates. The power of Dart is in closures, but are you sure that D closures are compatible?

>> 1b. Compiling from D to Dart to JS will lead to insanely big files.
>
> This compiler would be a bet that the VM can offer more and better optimizations. Tree shaking and minification can provide good advantages and refactoring opportunities for the time being, it's nothing we've never seen with the current JS libraries.

Dart2js produce large files, acceptable performance, but big.

> The idea so far has been that the Dart VM will run on source code rather than bytecode like PNaCl, and it will be faster for it.

Never. PNaCl will stay faster, it is IR based and multi threaded. Dart is a dynamic language designed to be JS compatible. The advantage with dart source distribution is in download size and future proof compatibility, not speed.

On 2014-05-15 6:04 PM, "Ola Fosheim Grøstad"
> It can do some tree shaking if you turn off metainfo. But D templates is
> bound to lead to bloat. Dart is a dynamic language and does not benefit
> much from templates. The power of Dart is in closures, but are you sure
> that D closures are compatible?

Templates are compile-time, a D compiler always takes care of all its compile-time duties =)

> Dart2js produce large files, acceptable performance, but big.

That's a temporary issue, I'm looking at years from now when/if Dart is more mature and implemented in more browsers as an alternative to javascript

Also, I talked about caching in the VM

http://1.bp.blogspot.com/-W1p7BELpIDE/UH42kXZeFsI/AAAAAAAANLA/kZGulTfNjQg/s1600/Screen+Shot+2012-10-16+at+9.39.29+PM.png


> Never. PNaCl will stay faster, it is IR based and multi threaded. Dart
> is a dynamic language designed to be JS compatible. The advantage with
> dart source distribution is in download size and future proof
> compatibility, not speed.

There's a lot of advantages to a source-code VM vs a bytecode VM.

Javascript is compiled into a source-code VM, sure it'll never exceed the power of a byte-code VM because without more type information the optimization opportunities are limited

See these benchmarks over time as an example:
http://iq12.com/files/v8/v8_score.png

Dart is still very young and does not benefit from as many optimizations for the moment.

This same team (the V8 team) decided that a VM based on dynamic typing in a type-safe language would be better than pure bytecode because of adaptive and profile-guided optimizations. To me that's truly groundbreaking, and based on these charts - I'd trust them!