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

[Mike Rettig]

Bill,

I guess you were posting this to the jetlang message list to get some
feedback, so I will oblige.

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

"Message passing between actors mostly uses 2-way messages (request /
response)."

I consider 2 way messaging with actors an anti-pattern. A well
designed jetlang application will consist of simple, testable,
synchronous method calls on each fiber and a few asynchronous messages
over channels.

Communication with another actor should not be a blocking operation.
If it is a blocking call, then simple same thread method calls should
be used instead of the added complexity of trying to use actors.

Mike

> --
> You received this message because you are subscribed to the Google Groups "jetlang-dev" group.
> To post to this group, send email to jetla...@googlegroups.com.
> To unsubscribe from this group, send email to jetlang-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jetlang-dev?hl=en.
>

[William la Forge]

Mike,

Can we discuss?

2-way messaging does not necessarily mean blocking. JActor makes extensive use of continuations, when necessary.

I actually consider excessive use of 1-way messaging to be the anti-pattern, one that is even more common with actors than the exception anti-pattern is with Java. I find 1-way messaging important for sending notifications in the middle of synchronous code, but 2-way messaging opens the doors for lots of optimazations in the framework... to say nothing about the importance of flow control.

I've seen a lot of bad actor designs by programmers who aren't good protocol designers. And with 1-way messages you really need to think about protocol design. And too often a bad protocol means out-of-memory exceptions when trying to run a benchmark or poor performance when a system is under load--not things that newbies would come up against early in their development efforts.

I know my views on actors are radical. Dissatisfaction with scala actor performance led me to work on my own actor system and the optimizations I discovered along the way opened my eyes to a different way of thinking.

Bill

[Mike Rettig]

If you were dissatisfied with scala actor performance, then my guess
is that the actors were too fined grained. Most people approach actors
as if they are replacements for objects. They create a lot of tiny
little actors and send messages for everything. The better approach is
to create a few coarse grained actors and write simple, synchronous
methods for the domain logic on each fiber.

Mike

[William la Forge]

Mike,

You are 100% correct. My interest is in very fine-grained actors. Being able to send a billion messages per second or to create a billion actors per second is important to me. In the JID project I've developed a high-performance incremental serialization system for actors. In a simple latency test I can deserialize, modify and then reserialize a table with 10,000 entries--that's 400 nanoseconds per entry--and the time to deserialize/reserialize is largely independent of the size/complexity of the table entries. (And those table entries are all actors.)

Bill