Closed listepo-alterpost closed 6 months ago
For the moment and as long as there is no direct Dart compilation to WASM, we can use as an alternative to make modules in Rust which is Multiplatform and through Dart's FFI make calls from Dart / Flutter.
@mraleph thank you for the very comprehensive reply!
Given your previous comments on JS being a good target based on available built-in GC, it makes perfect sense about WASM.
And thank you for the extra info about the other LLVM experiments, happy to hear that current AOT compileris competitive or better than LLVM and I guess given it already supports x64 and arm,I guess adding WASM generation would not be that prohibitive.
My main request for if/when Dart to WASM support is worked on would be: that there be a way of choosing to have a "minimal" runtime. Going by your previous answer to my asking about the VM runtime, I hope that excluding dart:io support, icu and WASM having builtin GC, it could mean that the Dart VM runtime could be quite small for a WASM target.
Dart is already compiled to JavaScript. So why not compile it to AssemblyScript (WebAssembly using Typescript) too! AssemblyScript has already implemented GC, WASM interop (via as-bind), generates small binaries, and it has already solved many of the issues.
https://www.assemblyscript.org/
You just need to add a few more things to the current Dart to JavaScript compiler like passing the types.
For example, this project already implements a Dart to TypeScript. https://github.com/polymer-dart/dart2ts https://github.com/polymer-dart
I haven't tried it yet, but with the help of this and AssemblyScript, wasm is already in the hands of Dart developers! These just need some attention from the core team.
Side benefit: If this is solved, Dart can also be used for targeting TypeScript!
You just need to add a few more things to the current Dart to JavaScript compiler like passing the types.
If you try to add these "few more things" yourself you will discover that JavaScript and AssemblyScript are two very different targets despite some syntactic similarities that latter has to TypeScript.
this project already implements a Dart to TypeScript.
This project implements subset of Dart to TypeScript, and a single pass AST conversion is not something you want to be doing really doing - the devil is in the details. That's why dart2js is hundred of thousands of lines of code.
You just need to add a few more things to the current Dart to JavaScript compiler like passing the types.
If you try to add these "few more things" yourself you will discover that JavaScript and AssemblyScript are two very different targets despite some syntactic similarities that latter has to TypeScript.
this project already implements a Dart to TypeScript.
This project implements subset of Dart to TypeScript, and a single pass AST conversion is not something you want to be doing really doing - the devil is in the details. That's why dart2js is hundred of thousands of lines of code.
Well writing a wasm compiler from ground up is much harder. That's why this issue has not had much progress since 2018.
I am trying to suggest a faster path to the target. The end users will certainly appreciate "a little more" progress on this even if it is based on a compiler that supports a subset of Dart. The quality can be increased over time if there is something that works partially.
The end users will certainly appreciate "a little more" progress on this even if it is based on a compiler that supports a subset of Dart.
Unfortunately we are not interested in a compiler that supports subset of Dart. We are interested in a compiler that can run actual Dart applications (which are usually thousands of lines of Dart code using most of its language features).
That however should not discourage you from building a compiler that supports subset and satisfies your particular use case. e.g. similar to how somebody built that dart2ts compiler you are linking to - which is far from something that we would ever consider doing ourselves.
You can't compile all the Dart applications to WebAssembly because WASM currently does not have WebIDL bindings (or if you use JavaScript interop, it will have a low performance like how Blazer tries to do so).
To fully compile all Dart applications, you need to wait for this issue to be resolved and then appear in the browsers. That seems like "a few years" from now. https://github.com/WebAssembly/proposals/issues/8 https://github.com/WebAssembly/interface-types
The problem is that Wasm isn't targetable as it does not integrate a solution for garbage collection... Thus which limits Webassembly to low level languages being C / C++ / C# / Go / Rust and some others.
With Wasm 2.0 next generation languages like Python / Dart / D / Java could be used. You can contribute to the proposal here https://github.com/WebAssembly/gc
The problem is that Wasm isn't targetable as it does not integrate a solution for garbage collection
I don't think that's actually correct. Rather it means the full DartVM along with it's GC needs to be included in the WASM which of course significantly increases the size.
Rather it means the full DartVM along with it's GC needs to be included in the WASM which of course significantly increases the size.
That's true. GC is just an algorithm that can be implemented in the wasm binary. The GC will take some space, but for example, AssemblyScript does that and it has one the smallest generated wasm binaries among the others.
https://github.com/dart-lang/sdk/issues/32894#issuecomment-684808186
That's true. GC is just an algorithm that can be implemented in the wasm binary. The GC will take some space, but for example, AssemblyScript does that and it has one the smallest generated wasm binaries among the others.
You may start a Dart-to-AssemblyScript compiler project if you want, but remember that AssemblyScript is not a standard as Dart, WebAssembly, JavaScript, TypeScript and EcmaScript are!
I am calling the official AssemblyScript documentation here:
Also, both can make use of compiler infrastructure that has been created by many individuals and corporations over years. In contrast, AssemblyScript is a relatively young project with limited resources that strives to create a viable alternative from another perspective.
@StEvUgnIn
I am calling the official AssemblyScript documentation here:
Since the scope of your request is clearly different I think your feature request should be in a separate issue, rather than trying to hijack this one
Any public comments about the work going on here?
Any public comments about the work going on here?
Long story short: over the last 3 months we have hosted an intern who worked on targeting WASM+GC. He got some preliminary results: managed to implement enough of a backend working to translate a simple merge-sort benchmark. Unfortunately internship time has just run out. We are interested in driving this further, but right now we have no concrete plans, things are in discussion.
/cc @mkustermann
Glad to see Dart can be compiled into WASM~ +1 The browser as the desktop environment seems will happen very soon. Dart to WASM (but not rely on another scripting language: javascript) seems more wisdom because javascript is not designed for big programs(at least that's why they now have typescript).
Another use case: I'd like to compile Dart to Wasm so I can write canisters that run on DFINITY's Internet Computer. Only languages that compiles to Wasm are viable, so Dart can not be used to create canisters for the Internet Computer until this support is added.
Another use case: I'd like to compile Dart to Wasm so I can write canisters that run on DFINITY's Internet Computer. Only languages that compiles to Wasm are viable, so Dart can not be used to create canisters for the Internet Computer until this support is added.
Dart is a very good standard but I invite you to use TypeScript. The syntax is very closed and you might as well find similarities (Futures, class, typing, access level, etc.).
You may start a Dart-to-AssemblyScript compiler project if you want, but remember that AssemblyScript is not a standard as Dart, WebAssembly, JavaScript, TypeScript and EcmaScript are!
Since when were JavaScript and EcmaScript different standards? And when did TypeScript get a standard? Dart is approved by the ECMA standard under ECMA-408, unlike TS.
We have dart2native, which supposably can compile Dart code to natively executable code, without dependencies, although, it does add some code for type checking and GC, why can't the same be done for Wasm? A large, inefficient Wasm binary is a start, it's not a great start, but a start nonetheless.
I was looking at a use case for using wasm as a module on the server. CNCFs Open Policy Agent project ships in three varieties
Right now my only option is the number two which seems to introduce a lot of additional overhead. I think WASM could make sense as a target for a lot of server side application components and the ability to handle them natively in Dart would be a huge improvement for developer experience and interoperability.
There is a package that uses c ffi on pub dev that I'd like to use. Unfortunately that means I wouldn't be able to use it on the web.
Would wasm support mean I could in fact use it on the web by compiling that C into wasm ? This is a bit unclear to me.
@cedvdb
Would wasm support mean I could in fact use it on the web by compiling that C into wasm ? This is a bit unclear to me.
No, this is an orthogonal problem. What you want is dart:ffi
implementation on the Web using WASM.
Note that if you have a library that compiles to WASM you can already use it on the Web - it's just that you need to write bindings twice (once using dart:ffi
and once using something like dart:js
/package:js
).
We have discussed possibility of providing Web version of dart:ffi
- but so far we did not have resources to do that.
The Motoko Language, built for webassembly is becoming open source next week, it has built in garbage collection and compiles to wasm maybe dart can use the garbage collecter from the Motoko project for the wasm.?
https://sdk.dfinity.org/docs/language-guide/motoko.html https://stackoverflow.blog/2020/08/24/motoko-the-language-that-turns-the-web-into-a-computer/
The Motoko Language, built for webassembly is becoming open source next week, it has built in garbage collection and compiles to wasm maybe dart can use the garbage collecter from the Motoko project for the wasm.?
https://sdk.dfinity.org/docs/language-guide/motoko.html https://stackoverflow.blog/2020/08/24/motoko-the-language-that-turns-the-web-into-a-computer/
I didn't develop Dart, but I'm still fairly certain that the GCs would be incompatible.
As explained before: compiling Dart to linear memory Wasm and implementing GC on top of linear memory is not really a problem - if we had infinite resources and nothing else to do then we would most certainly have already done it. However with the current set of resource constraints and priorities we are not really interested in targeting it - because it is not going to solve any problems that we are facing.
Nevertheless, we do see Wasm GC as a really interesting target for Dart-for-Web deployments, with a potential to achieve better startup / efficiency than what is possible with dart2js
. We are currently engaging with Wasm GC effort and are building a compilation toolchain capable of compiling some meaningful benchmarks. Once we have some more concrete results we will share them.
Waiting for Wasm GC makes total of sense. But Wasm target is not just meaningful to browsers. There are also interesting upcoming server-side Wasm runtimes like https://github.com/lunatic-solutions/lunatic . It tries to build Erlang type of cheap isolated processes and reliability top of Wasm. Then there is https://github.com/faasm/faasm a high-performance stateful serverless runtime. I bet in future we see Wasm targeted lot more in server side solutions where publish your server-side app as Wasm instead of running your app in containers or as raw executable.
@wanton7 Do note that Wasm GC is a Wasm feature, not a browser feature, server-side Wasm engines are allowed to support the GC extension too. This means that Dart compiled to Wasm could still be executed outside of a browser.
@CrimsonCodes0 Yes I know ;) I thought from your comment Dart-for-Web deployments
meant just browsers. I just wanted to mention Wasm in future won't be browser only target.
Nevertheless, we do see Wasm GC as a really interesting target for Dart-for-Web deployments, with a potential to achieve better startup / efficiency than what is possible with
dart2js
.
dart->wasm compile can get rid of the platform(dartvm,dart2js,..)-differences like the flutter-web int: 2^53 and dartvm int: 2^64 and the incompatibility of the BigInt cross platforms... .
We're certainly excited about the potential here and engaged with the WASM GC effort. But, just to be clear, there is a long road ahead still: https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md
@vsmenon does Dart really need WASM GC? Why must we wait on WASM GC?
Would it be possible for a dart app to declare how much memory it needs at build time? And from here memory gets preallocated/managed in the app? Using this memory pool, if needed, other virtual memory could be simulated, via a remote storage interface and some sort of paging?
@unicomp21 see https://github.com/dart-lang/sdk/issues/32894#issuecomment-831774883 - Dart could in fact target WASM MVP (aka WASM with linear memory), but we are not interested in pursuing such translation at the moment.
@mraleph are the "problems" enumerated somewhere?
@mraleph are the "problems" enumerated somewhere?
Small download size and high efficiency.
Waiting for an alpha version and SIMD support! 😎
@gmpassos I'm looking forward to that too, and I think to use SIMD efficiently in dart would be a language construct like "unsafe context" that I've proposed here https://github.com/dart-lang/language/issues/1758#issuecomment-887669522
I have tested this dart2wasm prototype and it is very promising. https://github.com/askeksa-google/sdk/blob/wasm_prototype/dart2wasm.md
D:\MyDartProjects\dart-sdk\sdk>v8\d8.exe fibonacci.js 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987 Execution time: 4.5390000000000015 ms
D:\MyDartProjects\dart-sdk\sdk>dart fibonacci.dart 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987 Execution time: 0:00:00.002000
D:\MyDartProjects\dart-sdk\sdk>v8\d8.exe --experimental-wasm-gc pkg/dart2wasm/bin/run_wasm.js -- fibonacci.wasm 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987 Execution time: 0:00:00.003000
Execution time: 0:00:00.002000
is it 2ms?
Interaction with the browser and the DOM?
Definitely see the issues with lack of WASM GC, but figured I'd add another use case here that has nothing to do with web.
At @tidbyt we have a connected hardware product with a companion app. The companion app for the hardware is written in Flutter so the team is familiar with Dart. The firmware for the hardware is written in C/C++, which runs on a microcontroller.
Ideally we'd like to write parts of the firmware in a higher-level language than C/C++. We'd also want these parts to be easily portable to other microcontrollers and architectures. As a proof-of-concept, I've added a WASM runtime to our firmware and compiled experiments in a couple of different languages to WASM. These languages have different levels of maturity and learning curves, and I'm still evaluating what would work best.
If Dart compiled to WASM, we could use a language our team already knows and share code for some features between our Flutter app and our embedded device.
Of course this would also be contingent on having reasonably-sized WASM binaries that fit in the embedded environment. It's possible we could achieve something similar by embedding a JS interpreter and using dart2js
, but that might also run into resource constraints. Either way we probably only have space for either a WASM runtime or a JS runtime on an embedded device.
I have a similar use case to @rohansingh in wanting to use WASM on small devices and microcontrollers and at the moment I have to use eg. Assemblyscript, but would much rather use Dart. Yes I realise Dartino was abandoned, but I really do think there is a nice usecase for using Dart on devices as @rohansingh mentioned for teams and developers that are already doing companion apps for the devices in Flutter.
Given this usecase, I would be writing Dart code in a similar style to that in AS and taking care of memory management myself, so I tried to find if there was a existing way in Dart to aot compile with GC disabled. I haven't been able to see anything to do this or perhaps I am missing something?
I guess what I'd like to do is what the dart2wasm prototype does but with GC removed - @mraleph is that likely to be possible or am I missing something fundamental here?
I guess what I'd like to do is what the dart2wasm prototype does but with GC removed - @mraleph is that likely to be possible or am I missing something fundamental here?
I don't think that would ever be possible, Dart is fundamentally a GC managed language. There are allocations hidden from the user in the core library and there are allocations that you don't even think about as a programmer (e.g. you evaluate a sum of two integers and put the result into a List
- that can trigger an allocation of a box).
You could build a dialect of Dart which eliminates hidden allocations and allows you to manage memory manually - but that's not something we ever plan to do ourselves.
My use case for WASM support in Dart is to use this library here, https://github.com/mfcc64/showcqt-js/blob/master/showcqt.js, which is an FFMpeg Audio Spectrum Visualizer that has been converted to WASM. Would be great to use the WASM port so I can do the web app too.
Update: Oh, I misunderstood this thread title. I not only want to export to WASM but also include existing WASM libs.
Update 2: Oh, I see a way to import WASM into Dart now, https://pub.dev/packages/wasm. However, if it cannot export WASM then I am not sure how it can export a web target. Guess I should just try it out.
@ElijahLynn please do try it out, and let us know how it goes!
Are there any ways to export WASM from Dart, like pyodide, running Dart inside browswer?
We also plan to expand Dart's compilation toolchain to support compiling to Wasm, contingent on the timely standardisation of WasmGC.
from 2022 roadmap
+1
I found this page, https://github.com/dart-lang/sdk/blob/main/pkg/dart2wasm/dart2wasm.md.
You don't need to build the Dart SDK to run dart2wasm, as long as you have a Dart SDK installed.
To compile a Dart file to Wasm, run:
dart --enable-asserts pkg/dart2wasm/bin/dart2wasm.dart options infile.dart outfile.wasm
How can I run dart --enable-asserts pkg/dart2wasm/bin/dart2wasm.dart ...
I always got Error when reading 'pkg/dart2wasm/bin/dart2wasm.dart': No such file or directory.
errors.
And I could not find dart2wasm.dart
in my dart sdk directory either.
@liudonghua123
Dart SDK version: 2.19.0-374.1.beta (beta)
dartaotruntime path-to-sdk/bin/snapshots/dart2wasm_product.snapshot -h
It would be very cool to add support for the WebAssembly
Admin comment: For current status, see https://dart.dev/web/wasm