New releases of JActor and JID

[Bill La Forge]

JActor

JActor is a high-performance Java Actor implementation that can send 1
billion messages per second, making it one of the fastest Actor
implementation in any language.

Release 3.0.0 Final: JActor is now faster and lighter. Message passing
now runs at 1.2 billion per second. The API has been simplified. And
you can now create 1 billion actors per second.

https://github.com/laforge49/JActor#readme

JID

JID is a system that can deserialize, update, and reserialize a map of
10,000 actors in 4 milliseconds on an i5 at 2.53 GHz. Serialization/
reserialization timings are independent of the size and complexity of
the table entries. Incremental serialization/deserialization is used
to achieve high performance.

Release 1.0.0 RC1: While an initial release, this project is a
reimplementation of the AsyncFP Scala project.

https://github.com/laforge49/JID#readme

Bill La Forge
@laforge49

[Paul Tarvydas]

Hi Bill

I haven't actually read your code, but I did browse some of your commentary.

You "commandeer" messages when receiving actors are idle, instead of spinning up new processes (threads).

Good idea.

Why do you do anything *but* commandeer messages? I.E. only one thread (per core) which commandeers every message.

In my experience, this works and does away with all context switching overhead. I would expect it to be even faster.

pt

[William la Forge]

Paul,

Yes, you describe the ideal case, which I suspects happens often enough. The performance is about 10 times slower than synchronous messaging (same mailbox)--about 100 million messages--because of the overhead of atomic references.

But when eventually you do send a message between threads, you've got to add the message to a queue because the target mailbox has already been commandeered.

Also, some actors should not be commandeered because they are either too slow (big calculation) or block for I/O. If you were to commandeer them, then all the commandeered mailboxes/actors would block. The async mailboxes inhibit commandeering for just this reason.

Bill