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 next 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 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

- 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
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
prev sibling next sibling parent "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
prev sibling 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

- 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