mraleph

Dart VM is written primarily in C++.

There is bytecode, but the story here is kinda complicated - there are actually 2 different versions: one is called DBC and is used during development of Flutter applications on iOS, there is another called KBC - that one is more like a classical bytecode, it is currently in development.

> And is there a place where more details are available?

You can get some high level information at https://mrale.ph/dartvm

Let me know if you want to know something special.

> Is it possible to work with Flutter using Typescript, or is it Dart only?

You might be thinking that Flutter underneath is using JavaScript - to which Dart compiles. However this is not how Flutter works, there is no JavaScript involved anywhere in the stack.

Dart is its own language - and it can run natively, unlike TypeScript - which is just a type system over JavaScript and needs to be compiled to JavaScript to actually run.

So no, you can't use TypeScript with Flutter.

Yes, your intuition is correct. The way it works in Dart VM is like so:

Each loop has an interruption point somewhere (e.g. in the header). If a very hot loop is found VM would enter runtime at that interruption point, where it would synchronously initiate compilation of an optimized version of the function for OSR at this particular interruption point.

After unoptimized IL is contsructed it is "shaken": a matching interruption point is found in the graph and everything not reachable from it is shaken (which drops all code before the loop).

After then the graph is transformed a bit - for each local variable alive at the interrupt point we introduce artificial parameter - so that we could simply treat OSR substitution kinda like a call.

Then graph is optimized and compiled.

Finally when we return back to the original unoptimized code we would do a tail call to the new optimized version.

(I will cover this in the "Introduction to Dart VM" in more details and with some drawings, when I reach this).

That is fairly classical thing to do - a lot of VMs, including JVM and JS VMs do OSR.

Non-nullability is actually being actively worked on[1]. Currently language team is working on specifying the feature and figuring out the path towards it.

[1] https://github.com/dart-lang/language/issues/110

There is the "static immutability" proposal[1] which is related to concurrency. However it is correct that there is no single issue that just says "Make Concurrency Awesome".

I believe that we already have necessary building blocks (isolates), we just need to make concurrency via isolates efficient and ergonomic.

However it is still very early, so I don't have much else to share.

[1]: https://github.com/dart-lang/language/blob/master/working/01...

I am not a language designer myself, but I think "avoid overwhelming" was an explicit idea behind initial design of Dart. Yes, this led to a language that some might consider boring, but it also led to a language that a lot of people can easily pick up and use (with little surprise and reasonable amount of fun).

There are few things that I would like to have in Dart (ADT and pattern matching for example), but otherwise I actually think its a fun language to program in.

> And the worst part is what i feel was the first environment outside erlang to get real actor-like concurrency is now barely mentionning actors in its documentation.

Dart went through a lot of turmoil in the past few years, but now that this turmoil is over we hope to explore concurrency story again.

Dartino (which was a dialect of Dart targeting IOT devices) had really fun concurrency story centered around lean isolates, coroutines and fast message passing based on deeply immutable data and we think there might be something here that we could incorporate into Dart proper.

When you say "JIT compilers are notoriously tricky to implement" what, I think, you actually mean is "optimizations for dynamically typed languages are notoriously tricky to implement".

If the language you need to compile is Lua - then it does matter whether you are trying to compile it just-in-time or ahead-of-time. Both would be hard to implement if you care about performance (and implementing an AOT compiler that produces fast code would probably be even harder than JIT).

Similarly if your language is like Pallene - which reminds me of Oberon-2 of all things, then you can implement both AOT and JIT with much less effort.

That does not however mean that AOT is trivial to write - as you increase the expressivity of the language and add more ways to write abstract code so does the complexity of optimizing away the cost of those abstractions (eliminating indirections and allocations, resolving polymorphic calls statically, etc)

Finally at some point, even a language like Pallene might benefit from a JIT - because of JITs' ability to see the execution and focus on actually taken execution paths, rather then looking at the program as whole and not knowing which paths would actually be taken.

That's because compiling non-C++/Rust-like language to WASM is unpleasant and associated with completely unneccessary overheads.

Dart does not use LLVM anywhere in its toolchain.

> dropped their custom runtime

Dart VM is very much alive, nobody dropped it - it's used by Flutter to run Dart code, used by all Dart CLI tools (and Flutter CLI tools too) and on server side underneath pub.dartlang.org (and used on server by some other companies too).

Is C# statically typed?

> I have personally gone through and fixed hundreds of these runtime failures.

An interesting question here would be how many of those hundreds of failures were actual bugs and how many were just were just side effect of changing "dynamic is both top and bottom" rule.

So far I have not encountered a single actual issue when migrating users' code to Dart 2 - I encountered "unsoundly" typed code, but it actually worked and did not contain bugs.

Works just fine in Safari and Firefox Nightly for me. Consider reporting your browser configuration to the author? [1]

[also notice that it is in no way affiliated with Flutter and done by somebody in the community]

[1] I can't find any way to contact the author, but here is his blog post about the Studio https://medium.com/@pmutisya/flutter-studio-version-2-41cce1...

but I am not talking about the percentage increase I am talking about increase "by a factor of X" that is X = B/A.

See: https://ell.stackexchange.com/a/52747

Maybe my problem is that I am missing "by".

I am not a native speaker, so I was always under impression that "factor of K larger" means something was X and became K * X (e.g. the multiplicative factor was 1 and became X). Can I read somewhere about the correct usage?

> completely neglected code maintainability

Where did I neglect maintainability as a factor? The only optimization that potentially affects maintainability is manually allocating Mapping-s in the typed array. And there I openly acknowledged that it affects readability and makes the code error prone. All other optimizations are not in any way affecting maintainability.

Even typed array optimization is purely confined in the library internals... On the other hand WASM spills out of the library by requiring users to explicitly destroy SourceMapConsumer.

Flutter has the builtin ability to mimic platform conventions (Android on Android, iOS on iOS), which includes scrolling, animations, fonts, etc.

If you have an Android phone you can download Flutter Gallery app from Play Store, go to the menu and flip behavior from Android to iOS. Suddenly you have an app that behaves like an iOS app. Here is a demo like that from the early days: https://youtu.be/Mx-AllVZ1VY?t=11m23s

It's a mobile UI framework for creating Android and iOS applications from the same code base.

Here is a good introductory video: https://www.youtube.com/watch?v=fq4N0hgOWzU

I don't think you can avoid JavaScript even with WASM - and WASM in it's current form is, for some languages, a worse compilation target than JavaScript.

Not irrelevant. Question for you, is this more legible:

https://twitter.com/mraleph/status/965686742614462466

I can update CSS if that helps.

UPD. Updated CSS to use non monospace fonts for the body.

The math is not that obvious because Rust implementation does not match 1-1 what baseline JS version was doing (e.g. it sorts only generatedMappings and not originalMappings).

I will do measurements later to compare and update the post.

FWIW, quick look at Rust code actually reveals that that implementation is also different algorithmically from what I was optimizing, e.g. it only sorts generatedMappings array.

In reality it means that performance of my code should not be that far from what WASM is showing because sorting of originalMappings (which I do eagerly and WASM version does lazily) is one third to one half of the overall runtime.

I will try to measure and update the post tomorrow or Wednesday.

I should mention in the post that source-map version that relies on WASM actually requires you to manually manage lifetime of SourceMapConsumer object[1], which my change does not actually require because the memory object is encapsulated within SourceMapConsumer itself.

I do agree that the way I manage mappings is hardly ergonomic. As mentioned in the post I would prefer to use Typed Objects to access the packed array of mappings, but alas that proposal is stalled.

[1] https://github.com/mozilla/source-map#sourcemapconsumerproto...

[Thank you for reading the post! I am glad you enjoyed it]

All optimizations in the post can mostly be divided into three large groups:

1) algorithmic improvements; 2) workarounds for implementation independent, but potentially language dependent issues; 3) workarounds for V8 specific issues;

You need to think about algorithms no matter which language you write in, so we don't need to talk much about the first group. In the post it is represented by sorting improvements (sorting subsequences rather than the whole array) and by discussions of caching benefits (or lack of them there-off).

The second group is represented by a monomorphisation trick: the fact that the performance suffers due to polymorphism is not really a V8 specific issue and it is not even JS specific issue. You can apply this approach across implementations and even languages. Some languages apply it in some form for you under the hood.

The last group is represented by argument adaptation stuff.

Finally an optimization I did to mappings representation (using typed array instead of an object) is an optimization that spans all three groups. It's about understanding limitations and costs of a GCed system as whole.

Now... Why did I choose the title? That's because I think group #3 represents the issue that should and would be mostly fixed over time. While groups 1 and 2 represent universal knowledge that spans across implementations and languages.

Obviously it is up to each developer and each team to choose between spending N rigorous hours profiling and reading and thinking about their JavaScript code, or to spend N hours rewriting their stuff in a language X. What I want is:

a) that everybody was fully aware that the choice even exists; b) language designers and implementors worked together on making this choice less and less obvious - which means working on language features and tools and reducing the need in group #3 optimizations.

> but isn't expressive enough for a modern language.

What do you miss?

> Scripts for GC languages wouldn't be compiled directly for WebAssembly -- their runtimes would

It is not a walk in the park to compile runtime into WebAssembly (unless you are just compiling an interpreter).

Performant runtimes usually include machine specific backends and/or hand written assembly code. You'll need to port that all to target WASM too.

You can still do

    d8 --trace-turbo                        \
       --trace-deopt                        \
       --code-comments                      \
       --redirect-code-traces               \
       --redirect-code-traces-to=code.asm   \
       --print-opt-code                     \
       your-file.js

and load resulting turbo.cfg and code.asm into IRHydra.

However most of the important features (like source and deopt-to-ir mapping) are broken.

I used to repair things in my free time - but I don't think I want to do it anymore.

> is like IRHydra

It does 'IR' part of the IRHydra, but it does not give you another important feature - ability to see how your function evolved over time and figure out reasons for it. Loading files one by one in search for the right version is pretty cumbersome.

I was always hoping that V8 will eventually get proper Dev Tools integration for compiler / runtime internals - and I think things have finally started happening in that area.

Yes and no. "Yes" because JS decorators are indeed very local - they apply to what they decorate. "No" because JS decorators are still imperative. Essentially when you write

    @D class A { }

this simply means something along the lines of:

    class A { }
    D(A)

where D is an arbitrary function doing arbitrary things to A. There is nothing declarative here.