-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compile Dart to Wasm #32894
Comments
Yes it would. This is something we are looking at. Thank you. |
What, is the effort of webassembly and is there a timeline, for implementation? |
There is no timeline and no work is happening on this at the moment. |
@mraleph thanks for answer, but how can I know that already happening? |
@listepo-alterpost I am not sure I understand the question. Nothing is happening on this at the moment. |
Using this in flutter apps would be a great usecase. |
@b-strauss using it in what way? |
I guess like Blazor alternative(Hummingbird) |
WebAssembly is a cross platform format. If the DartVM had support for it, we could use the same WASM files on mobile Flutter apps as on web Flutter apps (with Hummingbird via calls to the JS WASM API). |
@b-strauss There is definitely no plans to support running WASM binaries on Dart VM. You can run native code on mobile platforms - which means you can run anything you want and you don't need to compile to WASM first. |
@mraleph You're right of course. But seeing that the target platforms for flutter will grow in the future (Web, Windows, macOS, fuchsia), having a single binary would make targeting these definitely easier. But I'm aware the cost for that would be high. ;) |
Any news on this? |
No news. In general if you are interested in WASM support I recommend including rationale (e.g. "I am interested in WASM because ..."). Knowing use cases that people consider would help us to prioritise things. Thanks. |
I am interested in WASM because ..
TLDR: code sharing of packages between client-side web & flutter. |
@Schonhoffer You can already do this in multiple ways:
As you can see neither of these options requires any sort of WASM support from Dart. |
Dart Sass is also very interested in WebAssembly. Our biggest user base runs Dart Sass on Node.js, but we consistently hear from our users that the performance of the compiled JS output is not up to par. Our users are comparing the performance of our dart2js output to Node Sass, which is a wrapper around a C++ library. Dart Sass via dart2js is 2x slower than Node Sass in the very best cases, and almost 6x slower when compiling some real-world libraries. On the other hand, the main reason anyone uses Dart Sass over Node Sass is that it's vastly easier to install a library that doesn't require native compilation. So users have a choice: they can have an easy installation experience or fast compilation, and whichever they choose also comes with a bunch of subtle incompatibilities. It's not a great experience. WebAssembly would give us the best of both worlds. It would almost certainly represent a major performance boost over dart2js because we don't have to deal with the overhead of JavaScript, and it's just as portable (and thus easy to install) as plain JS. Even if it the WASM binary had to ship with a full garbage collector until WASM supported it, it would make a huge difference to me and my users. As an aside, can we re-open this issue, since the proposal is still under consideration? |
For all of you: |
"Sorry, this survey is not active" |
@mraleph The point is about easy interoperability. I can compile Rust/C/C++ to native, but having a to deal with this for every platform is cumbersome and unecessary on early versions of my app. Do this makes any sense? |
That and "it already compiles to JavaScript" is not really a big comfort because one of the main perks of using wasm instead of transpiling to JS is the incredible speed increase. |
I am reopening the issue to indicate that this is something we are considering, even though we currently have no immediate plans to work on this.
WASM is not some pixie dust that makes your code magically faster. I actually have some serious doubts that compiling Dart to WASM would bring any speed increase, and in fact expect worse performance due to the lack of dynamic optimizations, insulation from underlying native architecture and inability to rely on builtin optimised primitives and standard library. The only performance characteristic that can potentially be improved by targeting WASM is startup latency. Additionally you will get somewhat predictable performance - but again, I actually doubt it would be better than peak performance you will get from good dart2js code. |
@mraleph Are you talking about running WASM binaries on Dart VM, or compiling Dart to WASM? |
@b-strauss renamed issue to make it clear. |
@mraleph Is running WASM on the Dart VM also something that is considered? Should there be a separate issue for that? |
This developer @NachoBrito actually shows that Dart needs to focus on Webassembly instead of JavaScript. JS Interop needs work to support the new HTML5 APIs: |
Will dart webassembly support using the upcoming tail call support? My reason for asking. Looking at the "out of order execution" supported by modern cpu's, will tail call's essentially allow us to await cache line misses? And run something else in the meantime where the cache lines have been loaded? |
|
The tail call instructions are just fused call-and-return instructions that pop the caller's stack frame before pushing the callee's stack frame. While this is a useful primitive in some coroutine implementations, the tail call instructions do not by themselves confer any capability to suspend and resume the execution of a function body. Such capabilities are being discussed as part of the Stack Switching Proposal. Dart has the |
@askeksa-google I'm confused. Why are the leaningtech guys realizing large performance boosts by having tail calls? https://leaningtech.com/extreme-webassembly-2-the-sad-state-of-webassembly-tail-calls/ |
Maybe I misunderstood what you wanted to do with the tail calls. It's certainly feasible to add an option to emit tail calls whenever the result of a call is directly returned. This will make stack traces different from what would be expected from the Dart source, but this is already the case for other optimizations, such as inlining. It may indeed improve performance in some cases. I don't see what it has to do with hiding cache misses, though. |
@askeksa-google In talking w/ some of the redpanda engineers, my understanding is c++ co_await essentially makes cache line misses "await'able". Another strand/coroutine can be resumed where the cache line has been loaded. Per Gor, tail calls are required in order to support co_await in webassembly. I'm wondering if dart await can perform as efficiently as c++ co_await, in webassembly? |
flutter 3.10 and dart 3.0 is released with some wasm support, how can I compile dart code to wasm in 2023? I also noticed https://pub.dev/packages/wasm, but it is about loading wasm module in dart, not compile dart code to wasm module. |
@liudonghua123 we're not ready to release things beyond preview. Keep in mind, all of the runtime support for WasmGC is also in preview. https://flutter.dev/wasm has the latest details |
Thanks, I also found some docs on https://github.com/dart-lang/sdk/tree/main/pkg/dart2wasm. |
@kevmoo |
@iapicca – "final" is tricky to define. We'll certainly need a runtime that supports WasmGC. It's possible we may make our first release require a JS runtime as well, since we're VERY focused on the Flutter+Browser scenario. Our support will certainly evolve, though. I'd love to think we'd run on most Wasm runtimes (as long as they support GC), but that's not our focus now or in the near future. |
I'm also extremely interested in a more portable WASM output. Requiring GC is totally understandable, but it's very important for our use-cases that we be able to integrate with as many WASM runtimes as possible—even if it means using a much lower-level API to communicate out. |
@kevmoo I was attempting to make a dart package to use fermyon spin, |
We've now landed new support in the
I have a small example of how this can be used for a Dart web app here: Note that this is still within our initial focus of using WasmGC in the context of web apps (whether Flutter web apps or general ones). Over time we'd like to support more general WasmGC execution -- this issue tracks some of the additional work required for that: #53884 |
It seems I can compile dart to wasm with dart 3.4.0.
But I can't run it with wasmer or wasmedge.
|
@liudonghua123 |
Wen dart to wasm runtime?? --2024.05.23 |
This feature is now considered done. There are some planned improvements outside the core though. For current status, please see https://dart.dev/web/wasm |
For those looking for future things
|
…sm` and make `dart compile --help` show the wasm subcommand Bug: #32894 Change-Id: Ia0d57385879630c9c4c289465c797b84444c36fc Cherry-pick: https://dart-review.googlesource.com/c/sdk/+/368307 Cherry-pick-request: #55857 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/368420 Reviewed-by: Ömer Ağacan <[email protected]> Commit-Queue: Martin Kustermann <[email protected]>
It would be very cool to add support for the WebAssembly
Admin comment: For current status, see https://dart.dev/web/wasm
The text was updated successfully, but these errors were encountered: