www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Fibers talk by Mikola Lysenko

reply Peter Modzelewski <peter.modzelewski gmail.com> writes:
http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html

enjoy!
Oct 03 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Great talk!


Sean
Oct 03 2008
prev sibling parent reply Mikola Lysenko <mikolalysenko gmail.com> writes:
I'm looking forward to hearing what everyone else thinks of it.  I don't think
the slides came through very well on the video, so if anyone is interested it
might be a good idea to download the slides separately: 
http://team0xf.com/conference/fibers.pdf

One thing I took away from the conference is that I need to get on IRC more
often.  (Though I've been so busy with homework/sleeping the last few days that
I haven't had much time.)

-Mik

Peter Modzelewski Wrote:


 http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html
 
 enjoy!
Oct 03 2008
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 03 Oct 2008 19:39:29 -0400, Mikola Lysenko  
<mikolalysenko gmail.com> wrote:

 I'm looking forward to hearing what everyone else thinks of it.


I really liked it (And thanks for putting the slides online). I've been  
slowly reading up on CSP/Occam/Cilk/Futures/User Threads/etc and this  
really clarified some things. Specifically, how Tango fibers are a lower  
level primitive (aka a coroutine) than a Win32 Fiber (aka a user-land  
thread). By the way, while 'fiber' is a very good name, I had thought that  
Tango's fibers were just a portable version of Win32 fibers. And while I  
had heard about coroutines before, this really helped me understand their  
usage and advantages.
Oct 03 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Mikola Lysenko:

 http://team0xf.com/conference/fibers.pdf


Very nice, few simple comments:
- In Python you have yield, but it can also take parameters, so the two
coroutines can send messages to each other all the time. I presume this is
possible with those fibers too.
- It's good to not have to change the language to implement them. But if you
can change the language a little, what kind of syntactic sugar can you find
useful for them?
- A few benchmarks to compare the performance of fibers compared to normal
plain subroutines (and opApply) can be useful.
- If programmers start using fibers often, then can it become positive for the
compiler to be aware of them, to optimize code better? (especially when they
are used where they aren't necessary).

Bye,
bearophile
Oct 04 2008
next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sat, Oct 4, 2008 at 8:14 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Mikola Lysenko:

 http://team0xf.com/conference/fibers.pdf


 Very nice, few simple comments:
 - In Python you have yield, but it can also take parameters, so the two
coroutines can send messages to each other all the time. I presume this is
possible with those fibers too.


It's a matter of subclassing Fiber and adding whatever capabilities to
it that you want.  I think Daniel Keep did something along these lines
but I can't find any code..


 - A few benchmarks to compare the performance of fibers compared to normal
plain subroutines (and opApply) can be useful.


They're fast.  Very fast.  But you're obsessed with benchmarks so
that's probably not enough for you.


 - If programmers start using fibers often, then can it become positive for the
compiler to be aware of them, to optimize code better? (especially when they
are used where they aren't necessary).


Yes, this was discussed.  If the compiler becomes aware of fiber
switches, it can generate more efficient code as it knows which
registers have to be saved or not.  It can also get rid of them
entirely if possible.
Oct 04 2008
parent reply downs <default_357-line yahoo.de> writes:
Jarrett Billingsley wrote:

 On Sat, Oct 4, 2008 at 8:14 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Mikola Lysenko:

 http://team0xf.com/conference/fibers.pdf


 Very nice, few simple comments:
 - In Python you have yield, but it can also take parameters, so the two
coroutines can send messages to each other all the time. I presume this is
possible with those fibers too.


 
 It's a matter of subclassing Fiber and adding whatever capabilities to
 it that you want.  I think Daniel Keep did something along these lines
 but I can't find any code..
 

 - A few benchmarks to compare the performance of fibers compared to normal
plain subroutines (and opApply) can be useful.


 
 They're fast.  Very fast.  But you're obsessed with benchmarks so
 that's probably not enough for you.
 

 - If programmers start using fibers often, then can it become positive for the
compiler to be aware of them, to optimize code better? (especially when they
are used where they aren't necessary).


 
 Yes, this was discussed.  If the compiler becomes aware of fiber
 switches, it can generate more efficient code as it knows which
 registers have to be saved or not.  It can also get rid of them
 entirely if possible.


I'm not sure how fast Tango's fibers are.

Tools' fibers are a few milliseconds per context switch on an unpatched phobos.

On a patched phobos, that goes down to a few hundred processor cycles. :)

 --downs
Oct 05 2008
parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Oct 5, 2008 at 8:25 AM, downs <default_357-line yahoo.de> wrote:

 Jarrett Billingsley wrote:

 On Sat, Oct 4, 2008 at 8:14 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Mikola Lysenko:

 http://team0xf.com/conference/fibers.pdf


 Very nice, few simple comments:
 - In Python you have yield, but it can also take parameters, so the two
coroutines can send messages to each other all the time. I presume this is
possible with those fibers too.


 It's a matter of subclassing Fiber and adding whatever capabilities to
 it that you want.  I think Daniel Keep did something along these lines
 but I can't find any code..


 - A few benchmarks to compare the performance of fibers compared to normal
plain subroutines (and opApply) can be useful.


 They're fast.  Very fast.  But you're obsessed with benchmarks so
 that's probably not enough for you.


 - If programmers start using fibers often, then can it become positive for the
compiler to be aware of them, to optimize code better? (especially when they
are used where they aren't necessary).


 Yes, this was discussed.  If the compiler becomes aware of fiber
 switches, it can generate more efficient code as it knows which
 registers have to be saved or not.  It can also get rid of them
 entirely if possible.


 I'm not sure how fast Tango's fibers are.

 Tools' fibers are a few milliseconds per context switch on an unpatched phobos.

 On a patched phobos, that goes down to a few hundred processor cycles. :)


Tango's fiber switches are on the same order.
Oct 05 2008
prev sibling parent Mikola Lysenko <mikolalysenko gmail.com> writes:
In short: Yes.



bearophile Wrote:


 - In Python you have yield, but it can also take parameters, so the two
coroutines can send messages to each other all the time. I presume this is
possible with those fibers too.


Daniel Keep did this long ago using StackThreads.  The general idea behind
Fibers is to provide a low-level, low-overhead mechanism for getting
implementing more complex behaviors.  As a consequence, it was deemed
unnecessary to put this kind of feature in the core runtime.


 - It's good to not have to change the language to implement them. But if you
can change the language a little, what kind of syntactic sugar can you find
useful for them?


I'd basically add a yield statement and a way to automatically wrap parameters.
 This would let you do something like the following:

int delegate(int) dg = cocreate (int x) { yield x + 2; yield x +5; }
print(dg(1));
print(dg(2));

//Prints out:
// 3
// 7


 - A few benchmarks to compare the performance of fibers compared to normal
plain subroutines (and opApply) can be useful.


I have some older benchmarks from stackthreads, but I lost them when I changed
web hosts.  I am currently planning on building a profiling suite for tuning
performance on various systems.

In theory, it would be very difficult to get much faster as the cost per switch
is on the order of 10 cpu instructions.  In practice, you will sill pay
something due to cache misses.


 - If programmers start using fibers often, then can it become positive for the
compiler to be aware of them, to optimize code better? (especially when they
are used where they aren't necessary).


A compiler implementation could avoid unnecessary register saves, inline
context switching and make parameter passing automatic.



Regards,
-Mik
Oct 05 2008