http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html

enjoy!

Great talk!


Sean

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!

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.

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

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.

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

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.

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