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
