Comment by smallstepforman | Hacker News Reader

Comment by smallstepforman | Hacker News Reader

Parent Full thread

smallstepforman

Yet again another threading implementation which ignores the Actor programming model. This must be a systemic failure in both academia for not teaching students about Actors, and the industry for barely talking about Actors. It’s like the old saying, those that dont understand Unix are doomed to reimplement it, poorly.

For those readers that haven’t encountered Actors, its more than just a threading model. It allows messaging (important for interaction). An Actor is essentially a class with a std::vector<std::function void(…)> member, and a public messaging function which pushes the message with variable arguments to the queue. The message invokes the scheduler, which sequentially invokes the queued function. It eliminates locks for the client, which is the key benefit. It keeps Actors on a specific thread to use hot caches, unless work stealing moves the Actor to a free thread. The Actor abstraction is higher level than threads.

I’m sure the author will come to realise the benefits of Actors once he has a decade more experience under his belt, after which just like me he’ll be disappointed at academia and the industry for not talking about the benefits of the Actor programming model.

Shameless plug : my own Actor implementation, used in real world 24h/365 embedded projects: https://github.com/smallstepforman/Medo/tree/main/Actor

Actor's are fantastic and ideal for many situations.

However, this thread pool is specifically for _high performance_ computing which generally means working with shared memory. The actor paradigm generally assumes no shared memory and communications using message passing. It's harder to optimize performance and is an impedance mismatch for HPC.

Another important difference from the actor model is that the library uses a future interface with blocking wait to get the results. With actors there is no wait as the results are posted to the message queue of the caller.

But waiting makes the usage more similar to sequential computing code. When there is an opportunity the code starts several jobs to work on presumably independent data sets, then waits for their results in a shared memory and then process them sequentially until there is another opportunity for parallel computation.

Coming from the Scala world this comment confuses me.

We know actors very well and we've had a popular and solid implementation in Akka for years.

But that hasn't mean that every other concurrency model has gone away. If anything with the advent of libraries like ZIO (http://zio.dev) we see concurrency being a hot space for interesting new takes and approaches. I feel like maybe I am missing something if it can be used as a one-stop solution for all concurrency needs.

Chromium uses actor model extensively. Yet in Safari Apple moves into the direction of multiple fine-grain locks for performance reasons I presume. So it unclear which model will dominate the industry. Locks allow for better performance, but the code becomes much harder to maintain and reason about, although even in C++ with the right API and proper discipline the situation is not that bad.

Also it is interesting that Go does not use the actor model with its strictly one polymorphic message queue per sequence or green thread. Rather it is based on CSP or concurrent sequential processes with green threads with multiple typed message queues or channels per thread. In my limited experience with Go I would rather use a third-party actor model implementation rather than native CSP as the programming model is simpler.

That is the most C-like C++ I think I've ever seen.

Reply on news.ycombinator.com