[dart-misc] Web Assembly, revisted

[Warren]

This comment on HN: https://news.ycombinator.com/item?id=10536851


indicates that GC and ES6 module integration is coming to Web Assembly in
the not-too-distant-future.


Does this change the story for Dart at all? I.e. does Web Assembly become a
viable target for the VM?

[Joao Pedrosa]

Hi,

I think that Dart's future on the browser may take a better advantage of
the Strong Mode that they seem to have been working on for JavaScript. With
Strong Mode they would have already have access to GC, DOM etc.

I was recently checking out what happened to the Oilpan project and it
seems to have finally reached a mature level to be activated by default for
most things on Chrome. Oilpan was the GC project that promised to make it
possible to also integrate the Dart VM into Chrome. But perhaps they would
take the opportunity to integrate it with Web Assembly instead. Even with
Oilpan though, they still seem to have a tiered approach to GC that they
can use for other kinds of optimizations. They've apparently come up with
one such optimization that removed a ton of code at the same time.

As for how to utilize Web Assembly from Dart, one could hope that the way
that they have started precompiling stuff for the mobile phones that it
could be used for a Web Assembly step. The question is why would that be
something that they would want to. Because Dart already works on the
browser without depending on Web Assembly. Mostly though they don't care
about using Dart for, say, creating web games. Most developers are fine
with Dart being used for CRUD stuff on the browser instead. And for that
Web Assembly would not be needed.

As for Flutter on Web Assembly, that could one day be useful. That could be
part of a paradigm shift because then one would care a little less about
interoperability with the DOM. Then it would be more about reusing good
code that is already targeting mobile devices.

Things like Fletch could find their way into Web Assembly instead. But it
would not necessarily beat the performance of JIT.

It is more likely that languages like Swift would have an easier time
targeting Web Assembly with their lower requirement for GC and already good
ties to the LLVM toolsets as used by Web Assembly.

Cheers,
Joao

Post by Warren
This comment on HN: https://news.ycombinator.com/item?id=10536851
indicates that GC and ES6 module integration is coming to Web Assembly in
the not-too-distant-future.
Does this change the story for Dart at all? I.e. does Web Assembly become
a viable target for the VM?
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[lihui]

no,dart was dead.
the cause of death: compile time type information can not used for
optimization. all types are (semi-)boxed
kotlin and even java are better .

圚 2015幎11月10日星期二 UTC+8䞊午11:17:56Warren写道

Post by Warren
This comment on HN: https://news.ycombinator.com/item?id=10536851
indicates that GC and ES6 module integration is coming to Web Assembly in
the not-too-distant-future.
Does this change the story for Dart at all? I.e. does Web Assembly become
a viable target for the VM?

[Gen]

I do not know how the performance of Dart will evolve in the next months.
I do not know the impact of boxed numbers and arbitrary size integers.
With regard to memory consumption, this might help:
https://api.dartlang.org/1.12.2/dart-typed_data/dart-typed_data-library.html
Anyway, I doubt that performance is the main reason why developers and
especially web developers would not use Dart.

Post by lihui
no,dart was dead.
the cause of death: compile time type information can not used for
optimization. all types are (semi-)boxed
kotlin and even java are better .
圚 2015幎11月10日星期二 UTC+8䞊午11:17:56Warren写道

Post by Warren
This comment on HN: https://news.ycombinator.com/item?id=10536851
indicates that GC and ES6 module integration is coming to Web Assembly in
the not-too-distant-future.
Does this change the story for Dart at all? I.e. does Web Assembly become
a viable target for the VM?

[lihui]

optimization for dynamic type system is hard. it contribute big problems
to every new application area.

for targeting to js, dart compile output cannot be as clean as kotlin,
java or typescript.
dart is harder to compile to web assembly as it is static typed. to fill
gap between dynamic and static semantic without performance degrade , the
whole JIT optimization work in dartvm must be included,which is terrible
for web application.
dart is also hard to run on IOS with AOT approach.


圚 2015幎11月10日星期二 UTC+8䞋午5:00:40Gen写道

Post by Gen
I do not know how the performance of Dart will evolve in the next months.
I do not know the impact of boxed numbers and arbitrary size integers.
https://api.dartlang.org/1.12.2/dart-typed_data/dart-typed_data-library.html
Anyway, I doubt that performance is the main reason why developers and
especially web developers would not use Dart.

Post by lihui
no,dart was dead.
the cause of death: compile time type information can not used for
optimization. all types are (semi-)boxed
kotlin and even java are better .
圚 2015幎11月10日星期二 UTC+8䞊午11:17:56Warren写道

Post by Warren
This comment on HN: https://news.ycombinator.com/item?id=10536851
indicates that GC and ES6 module integration is coming to Web Assembly
in the not-too-distant-future.
Does this change the story for Dart at all? I.e. does Web Assembly
become a viable target for the VM?

[Gen]

I see no particular reason why a Dart program on the Dart VM (or on the JVM
if a port would exist) should be slower than the equivalent Java program on
the JVM.
Except that the JVM might be better than the Dart VM.
AOT compilation is a new strategy for Dart.
I hope someone of the Dart team will make the effort to explain how it
works and what to expect.

Post by lihui
optimization for dynamic type system is hard. it contribute big problems
to every new application area.
for targeting to js, dart compile output cannot be as clean as kotlin,
java or typescript.
dart is harder to compile to web assembly as it is static typed. to fill
gap between dynamic and static semantic without performance degrade , the
whole JIT optimization work in dartvm must be included,which is terrible
for web application.
dart is also hard to run on IOS with AOT approach.
圚 2015幎11月10日星期二 UTC+8䞋午5:00:40Gen写道

Post by Gen
I do not know how the performance of Dart will evolve in the next months.
I do not know the impact of boxed numbers and arbitrary size integers.
https://api.dartlang.org/1.12.2/dart-typed_data/dart-typed_data-library.html
Anyway, I doubt that performance is the main reason why developers and
especially web developers would not use Dart.

Post by lihui
no,dart was dead.
the cause of death: compile time type information can not used for
optimization. all types are (semi-)boxed
kotlin and even java are better .
圚 2015幎11月10日星期二 UTC+8䞊午11:17:56Warren写道

Post by Warren
This comment on HN: https://news.ycombinator.com/item?id=10536851
indicates that GC and ES6 module integration is coming to Web Assembly
in the not-too-distant-future.
Does this change the story for Dart at all? I.e. does Web Assembly
become a viable target for the VM?

[lihui]

on the contrary, i think the guys behind dartvm are more smarter than ones
behind JVM and golang now. but they are more idealism.
the performance gap between them is related to language semantic, not
implementation .

圚 2015幎11月10日星期二 UTC+8䞋午5:54:20Gen写道

Post by Gen
I see no particular reason why a Dart program on the Dart VM (or on the
JVM if a port would exist) should be slower than the equivalent Java
program on the JVM.
Except that the JVM might be better than the Dart VM.
AOT compilation is a new strategy for Dart.
I hope someone of the Dart team will make the effort to explain how it
works and what to expect.

Post by lihui
optimization for dynamic type system is hard. it contribute big problems
to every new application area.
for targeting to js, dart compile output cannot be as clean as kotlin,
java or typescript.
dart is harder to compile to web assembly as it is static typed. to
fill gap between dynamic and static semantic without performance degrade ,
the whole JIT optimization work in dartvm must be included,which is
terrible for web application.
dart is also hard to run on IOS with AOT approach.
圚 2015幎11月10日星期二 UTC+8䞋午5:00:40Gen写道

Post by Gen
I do not know how the performance of Dart will evolve in the next months.
I do not know the impact of boxed numbers and arbitrary size integers.
https://api.dartlang.org/1.12.2/dart-typed_data/dart-typed_data-library.html
Anyway, I doubt that performance is the main reason why developers and
especially web developers would not use Dart.

Post by lihui
no,dart was dead.
the cause of death: compile time type information can not used for
optimization. all types are (semi-)boxed
kotlin and even java are better .
圚 2015幎11月10日星期二 UTC+8䞊午11:17:56Warren写道

Post by Warren
This comment on HN: https://news.ycombinator.com/item?id=10536851
indicates that GC and ES6 module integration is coming to Web Assembly
in the not-too-distant-future.
Does this change the story for Dart at all? I.e. does Web Assembly
become a viable target for the VM?