Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Message Passing and the Actor Model

dist-prog-book.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: Message Passing and the Actor Model

#61

Post by zmmmmm »

ramchip wrote: post #58
zmmmmm wrote: post #54

From a quick skim of it I don't see any mention of the real difficulty I have encountered with the Actor model in practice: managing imbalanced actor workloads. If you consider a simple chain of actors that do some work and then send on a result to a next actor that then does some more work: A -> B -> C -> D Suppose something (anything) happens that make messages to B take slightly longer to process than the rate at…

There’s a lot of literature on this in the Erlang world. This post is a very thorough summary of the various solutions available: https://ferd.ca/handling-overload.html I don’t find that kind of fully async processing pipeline very idiomatic TBH, at least in Erlang - more typically, every request would be its own actor, and do blocking requests to other actors that own shared resources.

Thank you for the insightful comments. That link looks perfect (down to the point of having a diagram with a->b->c->d just like mine!).

The idea of each request being its own actor being more idiomatic is intriguing. Naively though does it really solve the problem? Don't you just end up with an overflow of actors now instead of an overflow of one actor's inbox?

Re: Message Passing and the Actor Model

#62

Post by lliamander »

zmmmmm wrote: post #61
ramchip wrote: post #58

Earlier quoted context omitted.

There’s a lot of literature on this in the Erlang world. This post is a very thorough summary of the various solutions available: https://ferd.ca/handling-overload.html I don’t find that kind of fully async processing pipeline very idiomatic TBH, at least in Erlang - more typically, every request would be its own actor, and do blocking requests to other actors that own shared resources.

Thank you for the insightful comments. That link looks perfect (down to the point of having a diagram with a->b->c->d just like mine!). The idea of each request being its own actor being more idiomatic is intriguing. Naively though does it really solve the problem? Don't you just end up with an overflow of actors now instead of an overflow of one actor's inbox?

In Erlang the actors are lightweight processes are much smaller than OS threads. I wouldn't worry.

Re: Message Passing and the Actor Model

#63

Post by the_af »

Latty wrote: post #47
always_good wrote: post #20

I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day. I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunders…

I've played with this a bit, professionally and personally (Scala/Akka specifically). The way it makes you think about your model and the boundaries it introduces seem good. I really love the way it forces you to model the communication between parts of your code as a data structure - it feels like a much less costly version of the "everything as a micro-service" dream. Scala seems like the ideal language for it - yo…

> Akka was still struggling with type loss in the system the last time I used it, which really felt like a pain, and where I feel it adds the boundary that makes it harder to understand.

I don't know if this is what you are referring to, but: I don't understand the mix of Akka actors and Scala. Scala is a statically typed language -- in fact, that's the whole point of it -- and using Akka actors feels a bit like programming in Smalltalk. So you turn a statically typed language into a dynamically typed language with message passing. Honest question: why would you use Scala for that?

Back when I took Coursera's "Reactive Programming in Scala" course, some years ago, I asked Ronald Kuhn & Martin Odersky precisely this question, and they didn't have a convincing answer. Kuhn's answer was "good point, we're also considering Typed Actors". It's my impression Scala never did go with Typed Actors (I might be mistaken; I certainly don't use them), so I wonder what's their current answer to this question.

Re: Message Passing and the Actor Model

#64

Post by Hop_Gracer »

Message Passing along with "shared nothing" is going to be very important as all programming moves to multi-processor devices and distributed architectures. Erlang, which takes the message-passing concepts from SmallTalk with the pattern matching and error handling of Prolog, solves a lot of problems for us.

Re: Message Passing and the Actor Model

#65

Post by zmmmmm »

lliamander wrote: post #62
zmmmmm wrote: post #61

Earlier quoted context omitted.

Thank you for the insightful comments. That link looks perfect (down to the point of having a diagram with a->b->c->d just like mine!). The idea of each request being its own actor being more idiomatic is intriguing. Naively though does it really solve the problem? Don't you just end up with an overflow of actors now instead of an overflow of one actor's inbox?

In Erlang the actors are lightweight processes are much smaller than OS threads. I wouldn't worry.

Right, but in my scenario (and I appreciate perhaps this means I'm "doing it wrong"), the messages themselves have a fairly heavy payload (around 800 bytes). Given that, whether I'm spinning up an actor or a message, if it can't be processed quickly it's consuming a non trivial chunk of memory.

Re: Message Passing and the Actor Model

#66

Post by nickpsecurity »

Latty wrote: post #47
always_good wrote: post #20

I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day. I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunders…

I've played with this a bit, professionally and personally (Scala/Akka specifically). The way it makes you think about your model and the boundaries it introduces seem good. I really love the way it forces you to model the communication between parts of your code as a data structure - it feels like a much less costly version of the "everything as a micro-service" dream. Scala seems like the ideal language for it - yo…

Those of you discussing Scala Actors might like the details in this paper on that I coincidentally submitted to Lobste.rs this morning:

https://infoscience.epfl.ch/record/151999/files/EPFL_TH4874....

Re: Message Passing and the Actor Model

#67

Post by javadocmd »

zmmmmm wrote: post #54

From a quick skim of it I don't see any mention of the real difficulty I have encountered with the Actor model in practice: managing imbalanced actor workloads. If you consider a simple chain of actors that do some work and then send on a result to a next actor that then does some more work: A -> B -> C -> D Suppose something (anything) happens that make messages to B take slightly longer to process than the rate at…

It is a non-trivial problem, but one common enough that I would suggest any Actor library worth its salt would include mechanisms to tackle it. (Here's Akka talking about back-pressure support in Streams, for example. https://doc.akka.io/docs/akka/2.5.11/stream/stream-flows-and...) Akka also provides infrastructure for actor pooling and routing.

I don't see the manifestation of this problem as forfeiting the point. You could on the opposite extreme write one monolithic application that does everything: web interface, application logic, and data storage. It's readily apparent that for most use-cases, the benefits of separating, say, your web and database software will more than outweigh the added complexity cost of running two applications and routing requests between them. (And we don't anymore balk at running pools of web servers in front of our databases.) Continue to chop your application into smaller segments and of course you'll see diminishing returns. The application just has to be complex enough to raise the expectation of benefit from segmentation.

Re: Message Passing and the Actor Model

#68

Post by eslaught »

polskibus wrote: post #37
eslaught wrote: post #27

Earlier quoted context omitted.

It's worth mentioning that this isn't the only way to do distributed programming. Dataflow programming works quite well, and the newest state of the art systems are exploring ways to generate dataflow parallelism implicitly from sequential programs. See e.g. Legion from Stanford: http://legion.stanford.edu/ In my personal opinion, message passing is going to be considered an evolutionary dead-end in the long term, an…

I checked the tutorials section on Legion's site, they don't seem to be very inviting for a stranger. Is there a better site that would help me grasp basic ideas about Legion and show its strengths in comparison to other paradigms?

First, I'll say: if you have any suggestions for how to improve the tutorials and documentation in general, we'd be happy to hear them. Even years into the project, we're still learning how to teach Legion. We're an open source project and would be happy to accept contributions, but even a set of first impressions would help.

As for what resources exist today:

If a video format would help, the bootcamp [1] has a more gentle on-ramp (despite the name).

If you'd prefer text, there is also a language called Regent. The ideas are all the same, but the code does a much better job of expressing those core concepts. You could study Regent, but write all your code in C++ if you want. Even if you never write code in it, we've found Regent can be a better way to learn. And Regent has a tutorial [2].

[1]: http://legion.stanford.edu/bootcamp2017/

[2]: http://regent-lang.org/tutorial/

Re: Message Passing and the Actor Model

#69

Post by eslaught »

mmjaa wrote: post #28
eslaught wrote: post #27

Earlier quoted context omitted.

It's worth mentioning that this isn't the only way to do distributed programming. Dataflow programming works quite well, and the newest state of the art systems are exploring ways to generate dataflow parallelism implicitly from sequential programs. See e.g. Legion from Stanford: http://legion.stanford.edu/ In my personal opinion, message passing is going to be considered an evolutionary dead-end in the long term, an…

>It's worth mentioning that this isn't the only way to do distributed programming. Its not the only way, but it is one of the oldest that is still in production. If you take a train anywhere in the Western world, your life is being protected by best x-of-x systems based around the actor model. Just sayin' ..

I absolutely agree that message passing and actor models are the way things are done now. I just don't agree that it'll be the best we can do in the future.

As a programming languages person, message passing doesn't seem very satisfying. A lot of errors that you can get in parallel codes (e.g. deadlocks) aren't prevented by message passing. There are entirely new kinds of errors that are added (mismatched sends/receives). And there are errors that are nominally fixed, but really aren't: strictly speaking, in a shared-nothing distributed system, there can't be such a thing as a data race. And yet, two messages can absolutely race, and so you end up with the same problems just at a higher level of abstraction. Fundamentally, actor models are giant balls of mutable state interacting concurrently.... I'm sorry, yuck.

The siren's call of implicit parallelism is the idea that you can generate a parallel execution automatically from sequential code. This was the objective of e.g. the auto-parallelizing compilers of the 80s and 90s. And that of course turns out to be an intractable problem. The difference today is that people are (a) more willing to work with new languages and abstractions, and (b) are willing to use dynamic analysis to cover the gaps where the static compile-time analyses fail. And at least in HPC people are willing to consider this because the next-generation machines are getting scary-complicated and it's not obvious how mere mortals are expected to program them under the traditional approach.

Post reply on HN