Use queues for actors about robots HOT 4 CLOSED

Ah nvm, the InnerActorSystem uses channels, which kind of fulfill the same role.

from robots.

So can i do anything ? (real question, I am more than open to any amelioration idea :) )

PS: thanks for taking the time for reading the code despite the awful documentation :/

from robots.

Nah, the code is using channels, which for multi-producer, single-consumer scenarios like actors, seems to be the best alternative (according to @aturon's Crossbeam paper at https://aturon.github.io/blog/2015/08/27/epoch/, seems to be the best-performing alternative).

There is excessive locking, as you can see a message could be taking as little as 50ns or so (compared to 4,000,000 or so that it's currently taking), but I don't know how to improve the design substantially and keep your goal to have a similar API to Akka's (I'm a pretty big fan of akka even though it has it's rough edges if your use-case is not out of the box).

from robots.

@hexsel, the 4.000.000ns on the benches are for 1_000 messages, that is indeed very slow but not as slow as what you thought :)

That's about 200.000 msg/seconds which is pretty low, but it'as also due to the fact that the system in this way does not take advantage of the parallelism since there is a single consumer actor, and that it cannot be run on multiple thread at the same time (for obvious concurrency reasons), an i3 would be as performant as an i7 or a xeon in this case.

I tried to shave some ns, but the only thing I could think about was to code my own primitives for my use case and use a fair amount of unsafe (there currently is no unsafe code at all, even though that should change pretty soon, but you get the idea). Indeed callgrind showed me no obvious bottleneck, it's more about having a lot of locks and reference counting.

The bench overall are on the same order as Erlang, so I was satisfied enough with that, but if this becomes critical I'm willing to start shaving nanoseconds.

Thanks for the paper it's a great read :)

from robots.