vibe.d-lite v0.1.0 powered by photon

[Dmitry Olshansky]

I have been building Photon[1] scheduler library with the aim to 
build high performance servers but since we are already have 
vibe.d and everybody is using it might as well try to speed it 
up. Thus vibe.d-light idea was born - port vibe.d framework on 
top of photon.

So in the last couple of weeks I've been porting vibe-core, 
vibe-stream, vibe-inet and vibe-http to:
a) work with Photon instead of eventcore
b) speed things up as I go, since I like fast things

The end result is that running bench-http-server from vibe-http 
examples I get 1.6M rps with my version vs 243k rps on vanila 
running on 48 rather weak cores.

Ofc I want people to try it and see how it works in terms of 
correctness and speed on more complex projects:

https://code.dlang.org/packages/vibe-d-light

https://github.com/DmitryOlshansky/vibe.d

Though most of work goes on in deps:
https://github.com/DmitryOlshansky/vibe-http
https://github.com/DmitryOlshansky/vibe-core

See also Photon the machinery behind it all:
https://github.com/DmitryOlshansky/photon

Warning - this is likely Linux only at the moment, though I 
expect MacOS to also work.

Key differences so far:

1. photon powered *-light versions always run multi-threaded 
utilizing whatever number of cores you gave them with e.g. 
taskset or all of them by default. No need to muck around with 
setting up multiple event loops and if you did - don't worry 
it'll still do the right thing.
2. There is no Interruptible* mutexes, condvars or anything 
photon doesn't support the notion and code that relies on 
interrupt needs to be rethought (including some part of vibe.d 
itself).
3. UDP is stubbed out, because I do not have much of sensible 
examples utilizing UDP and felt wrong to port it only to leave it 
untested. Anyone using UDP with vibe.d is welcome to give me good 
examples preferably with multicast.
4. Timers... Photon has timer related functionality in particular 
sleeps but not quite what vibe.d wants so at this point timers 
are stubbed out.
5. Fibers are scheduled roughly to the least loaded cores so all 
of LocalThis LocalThat are in fact SharedThis and SharedThat, 
simplifying the whole thing and making it easier to scale.
6. Processes and process management is stubbed out until I find a 
way to implement them in Photon.
7. Files work but may block the thread in some cases, still need 
a little bit more support in Photon.
8. Worker threads - there is none at the moment, all is scheduled 
on the same pool. Practically speaking this should only affect 
CPU intensive tasks, the rest already avoids blocking on syscall 
so the primary need for workers is nil.
9. Maybe something else I forgot in the midst of it all.

So closing thoughts - is anyone willing to help me iron out the 
inevitable bugs and improve things beyond this proof of concept? 
What the community thinks of the idea in general?