On reddit:

http://www.reddit.com/r/programming/comments/1fkr5s/dconf_2013_day_2_talk_4_web_development_in_d_by/

On hackernews:

https://news.ycombinator.com/item?id=5812723

On facebook:

https://www.facebook.com/dlang.org/posts/650767074936977

On twitter:

https://twitter.com/D_Programming/status/341527862815367168


Andrei

On Monday, 3 June 2013 at 12:14:48 UTC, Andrei Alexandrescu wrote:
> On reddit:
>
> http://www.reddit.com/r/programming/comments/1fkr5s/dconf_2013_day_2_talk_4_web_development_in_d_by/
>
> On hackernews:
>
> https://news.ycombinator.com/item?id=5812723
>
> On facebook:
>
> https://www.facebook.com/dlang.org/posts/650767074936977
>
> On twitter:
>
> https://twitter.com/D_Programming/status/341527862815367168
>
>
> Andrei

http://dconf.org/2013/talks/panteleev.pdf
404 error

Andrei Alexandrescu:

> http://www.reddit.com/r/programming/comments/1fkr5s/dconf_2013_day_2_talk_4_web_development_in_d_by/

On Reddit they seem to suggest the idea of good stack traces for fibers...

Bye,
bearophile

On Monday, 3 June 2013 at 12:14:48 UTC, Andrei Alexandrescu wrote:
> On reddit:
>
> http://www.reddit.com/r/programming/comments/1fkr5s/dconf_2013_day_2_talk_4_web_development_in_d_by/
>
> On hackernews:
>
> https://news.ycombinator.com/item?id=5812723
>
> On facebook:
>
> https://www.facebook.com/dlang.org/posts/650767074936977
>
> On twitter:
>
> https://twitter.com/D_Programming/status/341527862815367168
>
>
> Andrei

Great talk! Would love to see the improvements to phobos suggested.

An idea for the virtual address space problem on 32-bit:
- Assuming each stack has a marker page at the end to prevent overflow, by simply exchanging the stack memory with a separate block of memory you can reduce the number of marker pages saving up to one page per fiber
- Could use some fast compression method to save a not recently used stack in memory
- As a last resort can save stack to a file and read it in again when it is required. Since events are queued the event loop can easily peek ahead in the queue and start loading in a stack early so that it is ready by the time that event gets to the front.

On Monday, 3 June 2013 at 18:07:57 UTC, Diggory wrote:
> Great talk! Would love to see the improvements to phobos suggested.
>
> An idea for the virtual address space problem on 32-bit:
> - Assuming each stack has a marker page at the end to prevent overflow, by simply exchanging the stack memory with a separate block of memory you can reduce the number of marker pages saving up to one page per fiber
> - Could use some fast compression method to save a not recently used stack in memory
> - As a last resort can save stack to a file and read it in again when it is required. Since events are queued the event loop can easily peek ahead in the queue and start loading in a stack early so that it is ready by the time that event gets to the front.

Thanks!

One of the main advantages of fibers over threads is the low overhead for switching - basically you save registers and change ESP. By comparison, switching to another thread requires an OS kernel system call. Copying entire stacks might negate this performance benefit. It's worth noting that it looks like the average stack size will grow for D programs in the future, as the push is made to minimize heap allocations throughout Phobos and use the stack more.

vibe.d really puts cgi.d to shame when it comes to scalability. With 100 concurrent connections, cgi.d (especially in embedded_http and fastcgi modes, scgi and cgi are a little behind) can hold its own. Not great, I got 5000 requests per second on my box, the same ballpark as C# in the video, but not too bad.

In the question section though he started to talk about event loops. I've been thinking about that too. It isn't tied into cgi.d yet, but I've written a linux loop built on epoll:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/eventloop.d

It uses a pipe back to itself for the injection of arbitrary events. Works something like this:

// this helps listening on file descriptors
FileEventDispatcher dispatcher;

// args are fd, on read ready, on write ready, on error
dispatcher.addFile(0, (int fd) {
    ubyte[100] buffer;
    auto got = unix.read(fd, buffer.ptr, buffer.length);
    if(got == -1)
         throw new Exception("wtf");
    if(got == 0)
       exit;
    else
        writeln(fd, " sent ", cast(string) buffer[0 .. got]);
}, null, null);

// you can also listen to events identified by type

addListener(delegate void(int a) { writeln("got ", a); });
addListener(delegate void(File a) { writeln("got ", a); });
send(20); // calls the listener above
send(stdin); // works with fancier types too

loop(); // enters the loop
}


I really like the idea of dispatching things based on type, it is so convenient and lets you plug anything in.

The FileEventDispatcher is different because all file descriptors are the same type, and we might want to differentiate it based on descriptor number. But you could also do addListener(FdReady) or something like that, i havent used this for a while.



Anyway my goal here is to prove that we can have one generic event loop that all libraries can use. My implementation probably isn't phobos bound, I'm settling for "works for me" and "proves it can work" but maybe the experience or some code will help when it is time to do a standard one.


I've plugged in my terminal.d to it (optionally, use -version=with_eventloop)) but that's it so far. Eventually I'll probably put simpledisplay and cgi.d in there as well and really see how it is coming together. If all goes well, we can have one program, one event loop, and all those various inputs handled.

03-Jun-2013 22:07, Diggory пишет:
> On Monday, 3 June 2013 at 12:14:48 UTC, Andrei Alexandrescu wrote:
>> On reddit:
>>
>> http://www.reddit.com/r/programming/comments/1fkr5s/dconf_2013_day_2_talk_4_web_development_in_d_by/
>>
>>
>> On hackernews:
>>
>> https://news.ycombinator.com/item?id=5812723
>>
>> On facebook:
>>
>> https://www.facebook.com/dlang.org/posts/650767074936977
>>
>> On twitter:
>>
>> https://twitter.com/D_Programming/status/341527862815367168
>>
>>
>> Andrei
>
> Great talk! Would love to see the improvements to phobos suggested.

Indeed.

>
> An idea for the virtual address space problem on 32-bit:
> - Assuming each stack has a marker page at the end to prevent overflow,
> by simply exchanging the stack memory with a separate block of memory
> you can reduce the number of marker pages saving up to one page per fiber
> - Could use some fast compression method to save a not recently used
> stack in memory
> - As a last resort can save stack to a file and read it in again when it
> is required. Since events are queued the event loop can easily peek
> ahead in the queue and start loading in a stack early so that it is
> ready by the time that event gets to the front.


Copying to disk is certainly strange and rising the cost of context switch by on-the-fly compression is even more so. So is copying memory.

Since we know there is plenty RAM but limited address space we can go for MM file and have some say 512M of it mapped at any given time (to have multiple smaller windows). Think of memory window as a slot for fiber - i.e. any fiber is mapped to one of X fixed addresses. Then the only requirement that when it wakes up it's mapped to the same address it was born with. It's sort of hash-table where fixed addresses are slots (collision chains) and items are fiber context that got mapped there.

The amount of pages actually used would be fairly low and thus it may never have to pull them off the disk. In fact the moment it starts paging it turns into your idea of writing context to disk.

Now the question is relative latency of MapViewOfFile in this setting.
It's definitely something to measure if it's fast enough we are done here basically.

If not (and I guess not, at least it's a sys call) it makes sense to manage placement of Fibers with some kind of good strategy. Ideally ones that wait on the same resource (say updated index.html to read off disk) should wake up together and thus they better be in the same window (so you can map a pack of them at once).

-- 
Dmitry Olshansky

On Monday, 3 June 2013 at 19:27:02 UTC, Adam D. Ruppe wrote:
> vibe.d really puts cgi.d to shame when it comes to scalability. With 100 concurrent connections [...]

I forgot to finish this thought! But you read that right, at puny 100 concurrent connections it holds its own, but if you go up to 1000 or 5000 like the vibe.d benchmarks, my code starts dropping connections fast.

My view has always been "I'll cross that bridge when I come to it" though. The sites I work on do ok, but they don't have that kind of traffic!

On Monday, 3 June 2013 at 18:51:45 UTC, Vladimir Panteleev wrote:
>> An idea for the virtual address space problem on 32-bit:

[snip]

Another problem is passing objects on the stack across fibers. This might even be implicit (e.g. due to delegates).

Torrents and links: http://semitwist.com/download/misc/dconf2013/