www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Photon v0.12.1 with 50% faster eventloop

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
So big news is that on Linux (and soon on other platforms) 
eventloop was rewritten to run faster especially in chatty apps 
that do lots of smallish send/recv ping pong. The end result is 
50% faster end-to-end memcached benchmark for my up and coming 
hedgehog[1] server. It's now actually 15-20% faster than stock 
memcached on memtier benchmark and about 50% faster on memcslap 
tests I carried out, this is far from extensive benchmarking and 
hedgehog is not even that optimized yet(!)

Of other notable additions is support for AArach64 on Linux. I 
basically spun up virtual machine on my Mac and to my dismay 
AArch64 was not supported yet so I fixed it making the code more 
portable going forward.

All in all I find that fibers can deliver as long as we are not 
going into millions of connections.

1. https://github.com/DmitryOlshansky/hedgehog


--
Dmitry Olshansky
CEO   Glowlabs
https://olshansky.me
Jul 28
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 28 July 2025 at 19:57:41 UTC, Dmitry Olshansky wrote:

 So big news is that on Linux (and soon on other platforms) 
 eventloop was rewritten to run faster especially in chatty apps 
 that do lots of smallish send/recv ping pong. The end result is 
 50% faster end-to-end memcached benchmark for my up and coming 
 hedgehog[1] server. It's now actually 15-20% faster than stock 
 memcached on memtier benchmark and about 50% faster on memcslap 
 tests I carried out, this is far from extensive benchmarking 
 and hedgehog is not even that optimized yet(!)

 [...]


And ofc I forgot the obligatory link:

https://github.com/DmitryOlshansky/photon
Jul 28
parent reply Salih Dincer <salihdb hotmail.com> writes:
On Monday, 28 July 2025 at 20:02:41 UTC, Dmitry Olshansky wrote:

 And ofc I forgot the obligatory link:

 https://github.com/DmitryOlshansky/photon


Undoubtedly, Photon is a good piece of software, because the 
passing years have taught us a lot. Especially when you mentioned 
its nature, you said that Photon’s nature is dual. I sense that 
you have an interest in physics, and therefore in science, and I 
feel the names were not chosen by coincidence.

We (my colleagues and I) use loops in electronics as well. After 
all, isn’t life itself a loop? I’d like to benefit from Photon 
for microcontrollers too. Let me give an example: when branching 
from the main loop to a subroutine—which can even be another 
microcontroller on a separate PCB—you momentarily step away from 
other tasks, forced by me to do so. In a way, when one 
microcontroller sleeps, the other wakes up and practically takes 
over the operations. It strongly resembles a relay race. You also 
seem to be doing things similar to what we do in electronics. 
After all, threads are almost like independent circuits.

Wishing you success...

SDB 79
Aug 01
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Saturday, 2 August 2025 at 05:27:04 UTC, Salih Dincer wrote:

 On Monday, 28 July 2025 at 20:02:41 UTC, Dmitry Olshansky wrote:

 And ofc I forgot the obligatory link:

 https://github.com/DmitryOlshansky/photon


 Undoubtedly, Photon is a good piece of software, because the 
 passing years have taught us a lot. Especially when you 
 mentioned its nature, you said that Photon’s nature is dual. I 
 sense that you have an interest in physics, and therefore in 
 science, and I feel the names were not chosen by coincidence.


I have BSc in applied math and physics. Indeed the name was 
chosen very specifically. Unfortunately Ali Baba written their 
own fiber scheduling runtime called photon. I’m not sure if I was 
the first but ofc now living in the shadow of the big tech.


 We (my colleagues and I) use loops in electronics as well. 
 After all, isn’t life itself a loop? I’d like to benefit from 
 Photon for microcontrollers too. Let me give an example: when 
 branching from the main loop to a subroutine—which can even be 
 another microcontroller on a separate PCB—you momentarily step 
 away from other tasks, forced by me to do so. In a way, when 
 one microcontroller sleeps, the other wakes up and practically 
 takes over the operations. It strongly resembles a relay race. 
 You also seem to be doing things similar to what we do in 
 electronics. After all, threads are almost like independent 
 circuits.


Cooperative multitasking could be indeed spread across a fleet of 
MCUs, it is tricky but could provide the benefit of simple mental 
model while programming such a board.


 Wishing you success...


There is a lot to tackle still.


 SDB 79
Aug 02
prev sibling next sibling parent reply IchorDev <zxinsworld gmail.com> writes:
On Monday, 28 July 2025 at 19:57:41 UTC, Dmitry Olshansky wrote:

 So big news is that on Linux (and soon on other platforms) 
 eventloop was rewritten to run faster especially in chatty apps 
 that do lots of smallish send/recv ping pong. The end result is 
 50% faster end-to-end memcached benchmark for my up and coming 
 hedgehog[1] server. It's now actually 15-20% faster than stock 
 memcached on memtier benchmark and about 50% faster on memcslap 
 tests I carried out, this is far from extensive benchmarking 
 and hedgehog is not even that optimized yet(!)

 Of other notable additions is support for AArach64 on Linux. I 
 basically spun up virtual machine on my Mac and to my dismay 
 AArch64 was not supported yet so I fixed it making the code 
 more portable going forward.

 All in all I find that fibers can deliver as long as we are not 
 going into millions of connections.


Well done! Are there any plans to integrate this project into 
vibe.d's eventcore?
Jul 31
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Thursday, 31 July 2025 at 12:48:18 UTC, IchorDev wrote:

 On Monday, 28 July 2025 at 19:57:41 UTC, Dmitry Olshansky wrote:

 All in all I find that fibers can deliver as long as we are 
 not going into millions of connections.


 Well done! Are there any plans to integrate this project into 
 vibe.d's eventcore?


Eventcore is too low-level interface to meaningfully improve 
upon. I’m cautiously optimistic about vibe.d core fork working on 
top of photon. It would then integrate with the rest of the 
vibe.d. To be honest it seems like vibe.d core is too high level, 
while eventcore is too low level, photon is somewhere in between.

—
Dmitry Olshansky
CEO   Glowlabs
https://olshansky.me
Aug 01
parent IchorDev <zxinsworld gmail.com> writes:
On Friday, 1 August 2025 at 08:35:49 UTC, Dmitry Olshansky wrote:

 On Thursday, 31 July 2025 at 12:48:18 UTC, IchorDev wrote:

 Well done! Are there any plans to integrate this project into 
 vibe.d's eventcore?


 Eventcore is too low-level interface to meaningfully improve 
 upon. I’m cautiously optimistic about vibe.d core fork working 
 on top of photon. It would then integrate with the rest of the 
 vibe.d. To be honest it seems like vibe.d core is too high 
 level, while eventcore is too low level, photon is somewhere in 
 between.


Well, good luck then!
Aug 05
prev sibling parent reply GL <gleb.tsk gmail.com> writes:
On Monday, 28 July 2025 at 19:57:41 UTC, Dmitry Olshansky wrote:



 All in all I find that fibers can deliver as long as we are not 
 going into millions of connections.


Cool, really cool!
Thank you.

But unfortunately, Photon is not compatible with zmq (zmqd). So 
pity...
Aug 11
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Monday, 11 August 2025 at 17:44:23 UTC, GL wrote:

 On Monday, 28 July 2025 at 19:57:41 UTC, Dmitry Olshansky wrote:



 All in all I find that fibers can deliver as long as we are 
 not going into millions of connections.


 Cool, really cool!
 Thank you.



 But unfortunately, Photon is not compatible with zmq (zmqd). So 
 pity...


That would be something I could look into. I think it should be 
easily fixable. Do you have some examples that fail?

—
Dmitry Olshansky
CEO   GlowLabs
https://olshansky.me
Aug 12
parent reply GL <gleb.tsk gmail.com> writes:
On Tuesday, 12 August 2025 at 14:14:04 UTC, Dmitry Olshansky 
wrote:

 That would be something I could look into. I think it should be 
 easily fixable. Do you have some examples that fail?


Hello!
Shure:

import zmqd;

    zmqd.Context context;
    zmqd.Socket rec;

    context = Context();
    rec = Socket(context, SocketType.pull);

----------

Invalid argument (src/poll.cpp:159)
Error Program exited with code -6
Aug 13
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Wednesday, 13 August 2025 at 09:46:07 UTC, GL wrote:

 On Tuesday, 12 August 2025 at 14:14:04 UTC, Dmitry Olshansky 
 wrote:

 That would be something I could look into. I think it should 
 be easily fixable. Do you have some examples that fail?


 Hello!
 Shure:

 import zmqd;

    zmqd.Context context;
    zmqd.Socket rec;

    context = Context();
    rec = Socket(context, SocketType.pull);

 ----------

 Invalid argument (src/poll.cpp:159)
 Error Program exited with code -6


Cool, so it dies on poll. Since poll is intercepted by photon, 
there is something I failed to account for. Let's see if I can 
get it fixed.
Aug 13
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Wednesday, 13 August 2025 at 10:08:17 UTC, Dmitry Olshansky 
wrote:

 On Wednesday, 13 August 2025 at 09:46:07 UTC, GL wrote:

 On Tuesday, 12 August 2025 at 14:14:04 UTC, Dmitry Olshansky 
 wrote:

 That would be something I could look into. I think it should 
 be easily fixable. Do you have some examples that fail?


 Hello!
 Shure:

 import zmqd;

    zmqd.Context context;
    zmqd.Socket rec;

    context = Context();
    rec = Socket(context, SocketType.pull);

 ----------

 Invalid argument (src/poll.cpp:159)
 Error Program exited with code -6




So that was trivial mistake in handling -1 argument to poll.

Some more digging around and I've got the following to work:

import std.stdio;
import zmqd;
import photon;
import core.thread;

void main()
{
	startloop();
	shared bool terminated = false;
	go({
     	//  Socket to talk to clients
		auto responder = Socket(SocketType.rep);
		writeln("Got socket");
		responder.bind("tcp://*:5555");
		writeln("Binded socket");

		while (!terminated) {
			ubyte[10] buffer;
			responder.receive(buffer);
			writefln("Received: \"%s\"", cast(string)buffer);
			Thread.sleep(1.seconds);
			responder.send("World");
		}
	});
	go({
		writeln ("Connecting to hello world server...");
		auto requester = Socket(SocketType.req);
		requester.connect("tcp://localhost:5555");

		foreach (int requestNbr; 0..10)
		{
			ubyte[10] buffer;

			if (requestNbr == 9) terminated = true;
			requester.send("Hello");
			requester.receive(buffer);

		}
	});
	runFibers();
}

I need to think a little more about it but I would likely ship it 
in the next release. Soonish :)
Aug 13