www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D talk at Silicon Valley ACCU

reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Wednesday, May 13, 2015 - "Multitasking in D" by Ali Çehreli

   http://www.meetup.com/SFBay-Association-of-C-C-Users/events/218992449/

Ali
May 11 2015
parent reply "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> writes:
On Tuesday, 12 May 2015 at 00:42:28 UTC, Ali Çehreli wrote:

 http://www.meetup.com/SFBay-Association-of-C-C-Users/events/218992449/


When will the video be available online?
May 18 2015
parent reply "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> writes:
On Monday, 18 May 2015 at 08:44:30 UTC, Per Nordlöw wrote:

 On Tuesday, 12 May 2015 at 00:42:28 UTC, Ali Çehreli wrote:

 http://www.meetup.com/SFBay-Association-of-C-C-Users/events/218992449/


 When will the video be available online?


A key follow-up question:

Is there any significant space- and time-overhead in being lazy 
and choosing a fiber-based solution to convert a function to a 
range instead of converting it to a standard D range?
May 18 2015
parent reply "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> writes:
On Monday, 18 May 2015 at 09:12:50 UTC, Per Nordlöw wrote:

 On Monday, 18 May 2015 at 08:44:30 UTC, Per Nordlöw wrote:

 On Tuesday, 12 May 2015 at 00:42:28 UTC, Ali Çehreli wrote:

 http://www.meetup.com/SFBay-Association-of-C-C-Users/events/218992449/


 When will the video be available online?


 A key follow-up question:

 Is there any significant space- and time-overhead in being lazy 
 and choosing a fiber-based solution to convert a function to a 
 range instead of converting it to a standard D range?


One caveat with D fiber implementation is that in the following 
example

import std.stdio;

import std.concurrency: yield;

void fibonacciSeries()
{
     int current = 0; // <-- Not a parameter anymore
     int next = 1;
     while (true)
     {
         current.yield; // return
         const nextNext = current + next;
         current = next;
         next = nextNext;
     }
}

unittest
{
     import std.concurrency: yield, Generator;
     auto series = new Generator!int(&fibonacciSeries);
     import std.range: take;
     writefln("%(%s, %)", series.take(10));
}

the type of `current` and template argument to `Generator` must 
manually match. Isn't it possible to design a D api that matches 
these at compile-time?

Otherwise we risk getting run-time exceptions such as

object.Exception /home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/
oncurrency.d(1694): 
yield(T) called with no active generator for the supplied type

Could yet another function qualifier (or extended attribute) do 
the job of checking this at compile time?
May 18 2015
next sibling parent "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> writes:
On Monday, 18 May 2015 at 11:57:29 UTC, Per Nordlöw wrote:

 Could yet another function qualifier (or extended attribute) do 
 the job of checking this at compile time?


For comparison here's how M$ has solved it in their proposal 
under include <experimental/generator>

http://blogs.msdn.com/b/vcblog/archive/2014/11/12/resumable-functions-in-c.aspx

They specify yielded type a function header instead of at caller 
as

     generator<int> fib()

which is probably a bit less error prone.
May 18 2015
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/18/2015 04:57 AM, "Per =?UTF-8?B?Tm9yZGzDtnci?= 
<per.nordlow gmail.com>" wrote:


 On Monday, 18 May 2015 at 09:12:50 UTC, Per Nordlöw wrote:

 On Monday, 18 May 2015 at 08:44:30 UTC, Per Nordlöw wrote:

 On Tuesday, 12 May 2015 at 00:42:28 UTC, Ali Çehreli wrote:

 http://www.meetup.com/SFBay-Association-of-C-C-Users/events/218992449/


 When will the video be available online?






Unfortunately, this presentation was not recorded. To be honest, it was 
a little too rushed for my liking. However, the discussions by the 
audience were high quality and there were good questions.


 Is there any significant space- and time-overhead in being lazy and
 choosing a fiber-based solution to convert a function to a range
 instead of converting it to a standard D range?




A fiber's stack is allocated from the heap. That's one overhead. The 
rest of the CPU register manipulations are comparable to a function call.

 
https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L3584

I am not aware of any compiler tricks that can see through fibers either.

So, for simple tasks like Fibonacci series, there is no need to use a 
fiber and it may be hurtful.


 void fibonacciSeries()
 {
      int current = 0; // <-- Not a parameter anymore
      int next = 1;
      while (true)
      {
          current.yield; // return


Yeah, that yields an int...


          const nextNext = current + next;
          current = next;
          next = nextNext;
      }
 }

 unittest
 {
      import std.concurrency: yield, Generator;
      auto series = new Generator!int(&fibonacciSeries);


... which we had to spell out up there.


 Could yet another function qualifier (or extended attribute) do the job
 of checking this at compile time?


Yeah, there is nothing that can be done at language level because yield 
is not a keyword. However, as you say, a UDA can make it a little 
better. Here is a rough version:

struct Yields
{
     string type;
}

 Yields("int") // <-- SPECIFIED HERE
void fibonacciSeries()
{
     // ...
}

auto generator(alias func)()
{
     import std.format : format;

     foreach (attr; __traits(getAttributes, func)) {
         import std.traits : isInstanceOf;

         static if (is (typeof(attr) == Yields)) {
             mixin (format("alias YieldedType = %s;", attr.type));

             import std.concurrency: Generator;
             return new Generator!YieldedType(&func);
         }
     }

     assert(false, format("%s does not have a Yields attribute",
                          func.stringof));
}

unittest
{
     import std.stdio;
     import std.range: take;
     auto series = generator!fibonacciSeries; // <-- THIS TIME, NO 'int'
     writefln("%(%s, %)", series.take(10));
}

It needs to be cleaned up. At least, the assert should be converted to a 
static assert. Still though, there is no guarantee that "int" matches 
what is yielded.

Ali
May 18 2015
parent "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> writes:
On Monday, 18 May 2015 at 18:35:04 UTC, Ali Çehreli wrote:

 converted to a static assert. Still though, there is no 
 guarantee that "int" matches what is yielded.


Couldn't `yield()` capture CT-attributes of the calling function, 
in this case `fibonacciSeries`, and propagate them via default 
values of template arguments like is done in, for instance,

void contextual_writeln(string file = __FILE__,
                         uint line = __LINE__,
                         string fun = __FUNCTION__, T...)(T t)
{
     import std.stdio: writeln;
     try { writeln(file, ":",line, ":"/* , ": in ",fun */, " 
debug: ", t); }
     catch (Exception) { }
}

and use them to match the type of the argument to yield at 
compile-time? AFAIK everything visible by the compiler such UDA 
of functions could be put in a template argument either as a 
template alias or string parameter.

If not, isn't it time for a specific keyword for spawning threads 
and/or fibers? Contentenders could be `yield`, `go`, `co`, 
`spawn`. I'm aware of the problem with new keywords conflicting 
with existing symbols but that could be solved with deprecation 
phase so people can fix their code.
May 18 2015
prev sibling parent Rory McGuire via Digitalmars-d-announce writes:
On Mon, May 18, 2015 at 1:57 PM, via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:


 void fibonacciSeries()


void fibonacciSeries(T)() if (isIntegral!T) {...}



 unittest
 {
     import std.concurrency: yield, Generator;
     auto series = new Generator!int(&fibonacciSeries);


auto series = new Generator!int(&fibonacciSeries!int);


     import std.range: take;
     writefln("%(%s, %)", series.take(10));
 }


Surely you shouldn't have int in your fibonacci function?
May 19 2015