wtf is Fletch?

[George Moschovitis]

Hi there, 

I am wondering if someone on the Dart team can share some concrete details on what exactly Fletch is.

It looks like an interesting project, yet the README file is  rather cryptic (at least to me).

-g.

[Kasper Lund]

Hi George,

You're not the first to ask, so you may find a bit of context here:

   https://plus.google.com/114943499066504644906/posts/aJEX5yRi3WN

Fletch is an attempt to get experience with different concurrency mechanisms for languages like Dart. We're experimenting with light-weight user-level threading and synchronous operations to get a feel for how that scales and whether or not it simplifies the programming model compared to more traditional asynchronous approaches. There's a bit more information about the approach we're taking on our GitHub Wiki pages:

   https://github.com/dart-lang/fletch/wiki.

If you've got feedback for us, feel free to submit issues to our GitHub issue tracker. If nothing else maybe you can tell us what we need to do to make our README less cryptic :)

Cheers,

Kasper

--
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 email to misc+uns...@dartlang.org.

[Greg Lusk]

I'm assuming that Fletch is for server-side use?

[Greg Lowe]

It looks like they're implementing a concurrency model based on Hoare's Communicating Sequential Processes, similar to the model used in Erlang and go.

https://github.com/dart-lang/fletch/wiki/Coroutines-and-Threads

https://github.com/dart-lang/fletch/wiki/Processes-and-Isolates

http://en.wikipedia.org/wiki/Communicating_sequential_processes

The go FAQ has a couple of simple explanations:

http://golang.org/doc/faq#csp

Why build concurrency on the ideas of CSP?

Concurrency and multi-threaded programming have a reputation for difficulty. We believe this is due partly to complex designs such as pthreads and partly to overemphasis on low-level details such as mutexes, condition variables, and memory barriers. Higher-level interfaces enable much simpler code, even if there are still mutexes and such under the covers.

One of the most successful models for providing high-level linguistic support for concurrency comes from Hoare's Communicating Sequential Processes, or CSP. Occam and Erlang are two well known languages that stem from CSP. Go's concurrency primitives derive from a different part of the family tree whose main contribution is the powerful notion of channels as first class objects. Experience with several earlier languages has shown that the CSP model fits well into a procedural language framework.

Why goroutines instead of threads?

Goroutines are part of making concurrency easy to use. The idea, which has been around for a while, is to multiplex independently executing functions—coroutines—onto a set of threads. When a coroutine blocks, such as by calling a blocking system call, the run-time automatically moves other coroutines on the same operating system thread to a different, runnable thread so they won't be blocked. The programmer sees none of this, which is the point. The result, which we call goroutines, can be very cheap: they have little overhead beyond the memory for the stack, which is just a few kilobytes.

To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly minted goroutine is given a few kilobytes, which is almost always enough. When it isn't, the run-time grows (and shrinks) the memory for storing the stack automatically, allowing many goroutines to live in a modest amount of memory. The CPU overhead averages about three cheap instructions per function call. It is practical to create hundreds of thousands of goroutines in the same address space. If goroutines were just threads, system resources would run out at a much smaller number.

[Bob Nystrom]

On Tue, Jan 27, 2015 at 11:33 AM, Greg Lowe <greg...@gmail.com> wrote:

similar to the model used in Erlang and go.

Erlang and Go actually have quite different models. They both support lots of lightweight concurrent "things", but the similarity pretty much ends there.

Erlang is based around the actor model, which means the concurrent process itself is the focus. Processes are first-class in Erlang (or, at least, their pid is). Each process has a single built-in communication channel—its mailbox.

Go places the emphasis on channels. A goroutine is not first class and doesn't by default include any communication. To talk to it, you have to have access to a channel it's also using on. A single goroutine may communicate along multiple channels.

Coroutines, in turn, are a third, different model. They're similar to actors in that the coroutine is usually a first-class object and has an implicit single communication channel. But they're different in that coroutines don't generally run "on their own". You directly control which coroutine is active by deciding which one to resume.

I believe, but I'm not positive, that any one of the models can be implemented in terms of the others.

Cheers!

- bob

[George Moschovitis]

So, the plan is to create an alternative VM optimized for non-browser use? (e.g. server side, command line, embedded, android?)

Or are you planning to merge the good parts back to the existing Dart VM?

-g.

[Kasper Lund]

The plan is to experiment with alternative concurrency mechanisms with the goal of gaining insights that may (or may not) feed into Dart proper at some point. We feel that without the experiments it is hard to conclude that the current asynchronous model is the best we can do.

We are also interested in getting a better understanding on how to deploy and run applications (partly?) written in the Dart language on various mobile platforms. Some of those platforms do not allow just-in-time compilation, so in context of Fletch we're experimenting with fast interpretation instead.

Cheers,

Kasper

[Rich Eakin]

On Wed, Jan 28, 2015 at 8:34 AM, 'Kasper Lund' via Dart Misc <mi...@dartlang.org> wrote:

The plan is to experiment with alternative concurrency mechanisms with the goal of gaining insights that may (or may not) feed into Dart proper at some point. We feel that without the experiments it is hard to conclude that the current asynchronous model is the best we can do.

We are also interested in getting a better understanding on how to deploy and run applications (partly?) written in the Dart language on various mobile platforms. Some of those platforms do not allow just-in-time compilation, so in context of Fletch we're experimenting with fast interpretation instead.

Wow, that's big.  Thanks for sharing the process!

[George Moschovitis]

Great, thanks for the info...

[Jesse Riggins]

Yes thanks for the info.  

Sounds interesting.  I admittedly don't know a lot about this myself, so please bear with me, but is this a project for which the LMAX Disruptor would be a candidate?

On Wednesday, January 28, 2015 at 4:23:14 AM UTC-6, George Moschovitis wrote:

Great, thanks for the info...

[Peter Jakobs]

So like a dartVM that has no jit and could run on ios/winrt just in interpreted mode?

[kc]

Seems like Lua. Byte code with coroutines. Like Bob's Wren language.

[Si Robertson]

Goroutine-like things in Dart would be utterly brilliant as long as a similar minimal API approach is used, Dart's isolates are ugly and really need to be replaced with something else. Goroutines are by far the easiest (and dare I say cleanest) form of concurrency I have used.

Just my humble opinion.

[Kasper Lund]

Si,

We'd love feedback on our coroutine / thread / process design in Fletch, so if you've got time I encourage you to take a look at these Wiki pages:

  https://github.com/dart-lang/fletch/wiki/Coroutines-and-Threads

  https://github.com/dart-lang/fletch/wiki/Processes-and-Isolates

and ask questions on our mailing list: https://groups.google.com/forum/#!forum/fletch.

Cheers,

Kasper

[Filipe Morgado]

I find awesome that the Dart team is experimenting with different concurrency models.

But what exactly is the goal of the experiment?

I use Dart exclusively on the server (currently), so this is all good news.

But ... how would a blocking model work when compiled to JS? I don't think it's currently possible.

Is the plan to propose new models to the JS ECMA group before anything can be pushed to Dart?

Also, is there a distinction being made between concurrency and parallelism, in the experimental model?

Thank you :)

[Peter Jakobs]

Well Mozilla and Intel are cooking something up in that direction, its called river trail...

But event if that would be fitting, if dart would require something like that, dart would not be usable anymore with dart2js.

[Joao Pedrosa]

Hi Filipe,

I'd love to know the goals they have for Fletch too. Until then, we could try to speculate what they have in mind.

I think Fletch could be seen as the "node.js" of Dart. Dart is a language and a VM. Fletch is a VM and a way to give Dart some features that are not exactly meant to be cross-platform with dart2js and so on.

I think async programming has been full of headaches and it may not ultimately solve the problem of taking all advantage from multiple CPUs and so on. For example, some of the discussions about Oilpan showed that they didn't find that parallel GC was a win necessarily, so they dropped it. Just going parallel for parallelism's sake isn't always a win, necessarily. One should try to mix&match as they go in that direction and try to extract more advantages from the platform as a whole.

Dart may be committed to isolates, zones and async programming. Fletch may be a way to explore different ways to do the same thing, while trying to simplify the programming model and still get more advantage out of the deal. :-)

Dart is full a promises. Committing this early to a programming model was too much to ask. The language will still be about the same. But where they can take the platform is something for the future to decide.

Cheers,

Joao

--

[kc]

Also, is there any relationship between fletch and chromium mojo?

And what's the code in docs/scheduler.md?

[kc]

Correct link:

https://github.com/dart-lang/fletch/blob/master/docs/scheduler.md

[Kasper Lund]

The scheduler doc is a description of some of the internal datastructures we use in Fletch to efficiently schedule lots of processes / isolates on top of a smaller number of OS-level threads. We're looking into using static verification techniques to prove some interesting properties, so having pseudo-code helps us communicate the ideas better.

Cheers,

Kasper

On Wed Feb 04 2015 at 11:10:52 AM kc <kevin...@gmail.com> wrote:

Correct link:

 https://github.com/dart-lang/fletch/blob/master/docs/scheduler.md

[kc]

Thanks.

Is Fletch related to:
http://www.chromium.org/developers/design-documents/mojo

And is it envisaged that Fletch concepts will be available client side in JS and Dart VM? Or mainly serverside?

[Kasper Lund]

Fletch is unrelated to Mojo -- and at this point we're mostly interested in understanding the feasibility of different concurrency mechanisms. It's a little bit too early to form a reasonable vision of where Fletch fits in long-term.

Where do you see it fitting in? Any opinions?

Cheers,

Kasper

[kc]

Concurrency baked into the runtime is very attractive. Maybe simpler than the event/callback/future model even with async/await sugar.

Is the idea that with Fletch 'await' gets mapped to a concurrent 'yield to'?

Also attractive would be value objects and (deep) immutability build into the runtime - with some supporting syntax. 

Concurrency and immutability could also play well with the emerging react/react native approach.

K.

[Si Robertson]

Goroutine-like things (and Channels) in the Dart VM both client-side and server-side... now that would be attractive :)

[Peter Jakobs]

https://codereview.chromium.org/909223002/

Fletch bytecode with dart2js, what is this about?

[Joao Pedrosa]

Hi Peter,

Now I see how they tie together. I think Peter Ahé had been working on incremental compilation for dart2js. I also noticed him committing to Fletch. And now your link shows that it kind of makes sense. :-)

Maybe the bytecodes would help with the incremental compilation process.

I support the incremental compilation idea  :-)

Dart has features that are supposed to help the development tools. It's great when the users get features that are supposed to help them more directly. :-)

We should just build Fletch and play with it a little.

Cheers,

Joao

On Tue, Feb 10, 2015 at 9:15 PM, Peter Jakobs <p4j...@gmail.com> wrote:

https://codereview.chromium.org/909223002/

Fletch bytecode with dart2js, what is this about?

--

[Joao Pedrosa]

Hi,

Alright. I have taken it for a spin on Linux. My impression so far is that Fletch starts much quicker. Like twice as quick as the DartVM that comes with the Dart Editor for me. On the other hand, Fletch runs slower on straight out code.

Here's a sample run:

$ time /home/dewd/apps/dart/dart-sdk/bin/dart count_me.dart 

Hello 2500000000

Elapsed: 4 ms

real 0m0.079s

user 0m0.073s

sys 0m0.008s

$ time /home/dewd/dice/fletch_dart/fletch/out/ReleaseX64/fletch count_me.dart 

Hello 2500000000

Elapsed: 24 ms

real 0m0.045s

user 0m0.041s

sys 0m0.004s

$ cat count_me.dart 

main() {

var i = 0;

var j = 0;

var sw = new Stopwatch();

sw.start();

for (i = 0; i < 100000; i++) {

  if (i % 2 == 0) {

    j += i;

  } else {

    j += 1;

  }

}

sw.stop();

print("Hello $j");

print("Elapsed: ${sw.elapsedMilliseconds} ms");

}

Fletch could be pretty good for short-lived processing like in CGI or command-line tools. Seeing "Thread" in some sample code was a pretty nice throw-back as well. Loved it. It reminded me of Ruby for a moment.

Building Fletch was not too difficult. I did get scared seeing that it would never stop. But the reason it seemed busier than expected was because it was building many different binaries for comparison/benchmarking purposes.

I ran the tests alright. I tested it on Ubuntu 14.10.

Thanks!

Cheers,

Joao

[Kasper Lund]

Joao,

When you're running Fletch like this:

   $ time out/ReleaseX64/fletch count_me.dart

you're also paying the price for compiling the program to bytecodes (it actually happens in a separate program). Both the Dart VM and Fletch have the option to compile to snapshots, so you might like running this instead:

   $ time out/ReleaseX64/fletch count_me.dart --out=count_me.snap

   $ time out/ReleaseX64/fletch count_me.snap

Be aware that the IA32 of Fletch version is somewhat faster than the X64 version, because we've optimized the bytecode interpreter by writing it in assembly code for that architecture.

We're not done making Fletch fast yet, and we're focused on making it cheap to spawn lots of processes (read: isolates) and send lots of messages. As an example of this we're trying to make it feasible (and really, really fast) to spawn a new process as part of accepting client connections in a simple server:

  https://github.com/dart-lang/fletch/blob/master/benchmarks/socket/SocketBase.dart#L43

We're also trying to stick to synchronous I/O, which you can see in our socket code:

  https://github.com/dart-lang/fletch/blob/master/lib/io/socket.dart#L86

It's important to note that we're not blocking native threads for this (it's still based on epoll / kqueue underneath) so we believe we can avoid sacrificing scalability even though the programming model is nice and simple.

Cheers,

Kasper

[Kasper Lund]

On Wed Feb 11 2015 at 12:15:06 AM Peter Jakobs <p4j...@gmail.com> wrote:

https://codereview.chromium.org/909223002/

Fletch bytecode with dart2js, what is this about?

Up until now, Fletch has had it's own somewhat hacky Dart-to-bytecode compiler written in C++ (called fletchc). Even though it's nice and fast, it doesn't implement the full Dart language and it doesn't produce very friendly error messages, so we think using the dart2js frontend code is a better choice long term. 

The dart2js frontend also support incremental analysis so it will be a good basis for exploring "live programming" in a Fletch context.

Cheers,

Kasper

[Paul Brauner]

It's important to note that we're not blocking native threads for this (it's still based on epoll / kqueue underneath) so we believe we can avoid sacrificing scalability even though the programming model is nice and simple.

That's how the Haskell and Go runtime work as far as I understand, and programming concurrent applications with them has been a much better experience than dealing with futures and streams in Dart so far, from my point of view at least. I can't wait to see where this project goes!

[kc]

Any experiments in the area of value objects/immutability/structs?

K.

[Si Robertson]

I agree. The issue of transferring data between threads/coroutines without serialization (i.e. zero-copy) also needs to be addressed, that is massive development brick wall for me where Dart's isolates are concerned at the moment. The ability to at least zero-copy buffers (bytes) would be very much appreciated.

[Peter Jakobs]

From G+

Me:

 

Personally I would like to have shared memory, or at least somewhat shared: Only one thread can write it, the others can only read it.
Or just plain pthreads like what they want to do in javascript... https://gist.github.com/dherman/5463054

Kasper:

We'd like to experiment with something like that. We are imagining building up some state in an isolate and then spawning a high number of isolates with the same state but with only read access to it. Once all the spawned isolates are done we can merge their heaps (the state they've built up) into the original spawner isolate. More to come. 

[kc]

Some struct code in fletch:

https://github.com/dart-lang/fletch/blob/master/tools/servicec/lib/src/struct_layout.dart

Just for ipc?

K.

[Tristan Caron]

Dart is already attractive.

Goroutine with Channel:

package main

import (
   "fmt"
)

func main() {
   channel := make(chan int)

   go func() {
      for i := 0; i < 10; i++ {
         channel <- i
      }
      close(channel)
   }()

   for {
      if value, ok := <-channel; ok {
         fmt.Println(value)
      } else {
         break
      }
   }
}

Future with Stream:

library main;

import "dart:async";

Future main() async {
  var channel = new StreamController();

  channel.stream.listen((int i) {
    print(i);
  });

  new Future(() {
    for (int i = 0; i < 10; i++) {
      channel.add(i);
    }
    channel.close();
  });

  await channel.done;
}

Waiting for async* <3

[Joao Pedrosa]

Hi,

I have added a simple socket sample that uses Fletch here:

https://github.com/jpedrosa/arpoador/blob/master/direct_test/simplest_http_response/serve_pages.dart

I just wanted to see how it would work under some stress. So I ran the "ab" command on it like this:

$ ab -n 10000 -c 30 http://127.0.0.1:8777/

The response was like this:

[snip]

Concurrency Level:      30

Time taken for tests:   0.429 seconds

Complete requests:      10000

Failed requests:        0

Total transferred:      840000 bytes

HTML transferred:       240000 bytes

Requests per second:    23283.37 [#/sec] (mean)

Time per request:       1.288 [ms] (mean)

Time per request:       0.043 [ms] (mean, across all concurrent requests)

Transfer rate:          1909.96 [Kbytes/sec] received

[snip]

I also watched the Fletch process using the system monitor. It looked good. Using the CPU at 80%+ under stress and not a lot of memory to begin with.

It's a very simple test as I'm not even using any HTTP parser. :-)

Like Kasper said, Fletch doesn't implement a lot of the Dart language yet. And error reporting is very cryptic/non-existent at the moment.

Using Kasper's hint that I could compile it to bytecodes for an even faster startup, I found that it did improve by a lot. In a simple test that I did, it started almost as quickly as Perl which is a beast at starting up.

Cheers,

Joao

K.

[Kasper Lund]

We're experimenting with letting Dart code provide "services" to programs written in C++, Objective-C and Java. The idea is fairly simple and we only allow exchanging simple binary-encoded structured messages between the language runtimes. The formats of the structured messages are described by IDL and we generate stub code for all the involved languages.

As a very contrived example you can take a look at:

https://github.com/dart-lang/fletch/blob/master/tests/service_tests/person/person_counter.idl

Cheers,

Kasper

[Jim Trainor]

A clean service interface to other languages would be great.

In my own project I treat my dart code as a service layer that sits beneath a much smaller layer of javascript.  If that same service layer could be executed as the bottom end of a C++, Objective-C, or Java program it would make sense insofar as my own application's architecture is concerned.  The top layer of Javascript/C++/Objective-C/Java/whatever becomes (hopefully) just a thin layer of platform adaptation on top of a thicker layer of platform independent Dart code.

 

--

[kc]

Fletch services and idl look very similar to mojo and mojo's idl mojom.

K.

[Alex Tatumizer]

> Fletch services and idl look very similar to mojo and mojo's idl mojom. 

CORBA, is it you? Long time no see! Where have you been for the last, like, 15 years?

BTW, are we talking only about idl, or the entire thing wholesale? 

[kc]

Is Fletch related to gRPC:

https://github.com/grpc/grpc/blob/master/README.md

K.