DConf 2013 Day 2 Talk 4: Web Development in D by Vladimir Panteleev

[Dmitry Olshansky]

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