[racket] thread size and creation time

By "very long process", I had in mind "years", but there could be a
shorter path.

The current Racket implementation internally has a construct for
"lightweight continuations" that are used to implement futures. Those
continuations can be lightweight because they are used only as long as
the future stays simple (i.e., stays in the subset of Racket that
allows futures to run in parallel). It should work to similarly use a
lightweight continuation for a thread, as long as the thread stays
simple enough.

How easily we can get from here to there depends on which primitives
you imagine using in the threads.

At Mon, 13 May 2013 13:43:37 +0200, Berthold Bäuml wrote:
> Thanks for the clarification. Indeed, I had a system design in mind which is 
> typical for Erlang with very many actors which are cheap at runtime as well as 
> during creation and destruction. When you say "very long process", does this 
> mean that you even can not make a rough prediction when it will be there?
> 
> Best,
> Berthold
> 
> 
> On 11.05.2013, at 17:27, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> 
> > Racket threads are indeed heavier than in Gambit or Erlang, while being
> > much lighter than threads in Java or pthreads.
> > 
> > The difference between Racket and Gambit is mostly in the
> > representation of continuations. The Racket implementation of
> > continuations is tangled up with the C stack in a way that creates
> > trouble and inefficiency.
> > 
> > Tangling with the C stack is related Racket's origins, where we wanted
> > to allow callback paths through C and have those paths captured in
> > continuations and swapped among threads. That approach was a good way
> > of getting started quickly, but not a great choice in the long run. We
> > are moving the implementation in a direction that will let us fix the
> > problem, but it's a very long process.
> > 
> > At Sat, 11 May 2013 12:17:28 +0200, Berthold Bäuml wrote:
> >> Hi,
> >> 
> >> what is the reason that threads in Racket are so much bigger than in Gambit 
> >> Scheme and take so much longer to create them? Is there possibly a way to 
> come 
> >> closer to Gambit performance or have threads in Gambit less functionality? 
> In 
> >> my little Racket test program below I get about 10kB per thread on my 
> MacBook 
> >> and creation takes about 100us per thread (Gambit claims to fit "millions 
> of 
> >> active threads in ~1GB and a creation time of 0.5us).
> >> 
> >> Marc Freely states in a talk from 2010 about Gambit 
> >> http://www.iro.umontreal.ca/~gambit/Gambit-inside-out.pdf
> >> 
> >> Green threads
> >> Preemptive scheduler with priorities
> >> Very lightweight and scalable
> >> Thread = descriptor (324 bytes) + continuation 
> >> Thread creation/synchronization ~ 0.5 μs 
> >> O(log N) enqueue/dequeue operations 
> >> Supports millions of active threads (in ~ 1GB)
> >> 
> >> 
> >> Best,
> >> Berthold
> >> 
> >> -- 
> >> -----------------------------------------------------------------------
> >> Berthold Bäuml -- Head of Autonomous Learning Robots Lab
> >> DLR, Robotics and Mechatronics Center (RMC)
> >> Münchner Str. 20, D-82234 Wessling
> >> Phone +49 8153 282489
> >> http://www.robotic.de/Berthold.Baeuml
> >> 
> >> 
> >> 
> >> ____________________
> >>  Racket Users list:
> >>  http://lists.racket-lang.org/users
> 
> -- 
> -----------------------------------------------------------------------
> Berthold Bäuml -- Head of Autonomous Learning Robots Lab
> DLR, Robotics and Mechatronics Center (RMC)
> Münchner Str. 20, D-82234 Wessling
> Phone +49 8153 282489
> http://www.robotic.de/Berthold.Baeuml
>