4 ms·

3 is true because Actors are implemented on top of a language and runtime that hasn't decided to implement actors and ONLY actors. Just like Haskell, you can in

3 is true because Actors are implemented on top of a language and runtime that hasn't decided to implement actors and ONLY actors. Just like Haskell, you can in fact mix paradigms of concurrency. This is generally regarded to be a positive thing! But of course it does mean you need to understand how the semantics interact. But it's weird to call out actors oversubscribing to threads in Akka as a bad thing when that's exactly what Erlang's runtime does! And by the way, it's not difficult for even C to match the classic "quarter million execution threads" claim. Java certainly can with competitive memory overheads.

phamilton 12y ago
The problem with Akka oversubscribing is that it doesn't actually have control over execution. It can't pause an actor in order to guarantee fair scheduling. It's similar to Node and the event loop in that regard. That's a big deal in my book. Competitive memory overhead in the Erlang world for a quarter million processes is 700MB (just sleeping). You can't do that with POSIX threads, where the default pthreads stack size on Linux is 2MB. Java adds more overhead on top of POSIX threads. As far as tuning PTHREAD_STACK_MIN on x86 is generally 16K, which is quite a bit bigger. So either you aren't in the same ballpark (factor of >5) or you have basically built a scheduler yourself (which is what Akka did).
- KirinDave 12y ago
  > The problem with Akka oversubscribing is that it doesn't actually have control over execution. It can't pause an actor in order to guarantee fair scheduling. It's similar to Node and the event loop in that regard. That's a big deal in my book. I mean it can if you use their libraries. You just suggest that because calling out to a different I/O library is possible that we should only evaluate it in that context. This is basically a condemnation of ALL languages that host multiple abstractions. > or you have basically built a scheduler yourself (which is what Akka did). Riiiiiiight.. so... what's the problem there? Someone did what the erlang folks did on the JVM. Why is that used as a refutation here? > As far as tuning PTHREAD_STACK_MIN on x86 is generally 16K, which is quite a bit bigger. So either you aren't in the same ballpark (factor of >5) My comment was in regards to building a scheduler yourself (erlang doesn't have that many threads of parallel execution either) or using a technique with less demanding semantics like Fork-Join. A lot of people have mixed up a lot of concepts here in the attempt to discuss why they like Erlang, but the truth is that it can't be nearly so efficient at scheduling and executing parallel computation as the average Java program appealing to java.util.concurrent, but is tuned for greater concurrency. It's also true that for some classes of computation Erlang's strategy works great, and for others it'd require substantial engine improvements to make competitive. The impression given on this thread is that Elixir is the answer. I don't like that impression being left for people new to the discipline, because it's not how most people who are good at distributed systems or massively parallel AND concurrent programming think about the problem.
  - phamilton 12y ago
    By not having preemptive scheduling, there are a whole lot of hoops that have to be jumped through. Spray.io is a disaster in usability in my opinion, for example. I've yet to find my code simpler and easier to maintain and debug when I use callback based async techniques. That is, however my opinion and personal taste. Others may disagree.
    - KirinDave 12y ago
      You won't find me carrying a lot of water for any Node library. I just think it's not wise to try and represent the use cases that actor based excels at as primary for our industry or even somehow privileged.
grogers 12y ago
The difference is the scheduling. In erlang, processes are preemptively scheduled, in akka they aren't. Erlang goes to great lengths to avoid one process from starving another. With akka you have to go to some lengths yourself to prevent starvation (e.g. preventing blocking calls in your event handlers).

phamilton 12y ago

The problem with Akka oversubscribing is that it doesn't actually have control over execution. It can't pause an actor in order to guarantee fair scheduling. It's similar to Node and the event loop in that regard. That's a big deal in my book. Competitive memory overhead in the Erlang world for a quarter million processes is 700MB (just sleeping). You can't do that with POSIX threads, where the default pthreads stack size on Linux is 2MB. Java adds more overhead on top of POSIX threads. As far as tuning PTHREAD_STACK_MIN on x86 is generally 16K, which is quite a bit bigger. So either you aren't in the same ballpark (factor of >5) or you have basically built a scheduler yourself (which is what Akka did).

KirinDave 12y ago
> The problem with Akka oversubscribing is that it doesn't actually have control over execution. It can't pause an actor in order to guarantee fair scheduling. It's similar to Node and the event loop in that regard. That's a big deal in my book. I mean it can if you use their libraries. You just suggest that because calling out to a different I/O library is possible that we should only evaluate it in that context. This is basically a condemnation of ALL languages that host multiple abstractions. > or you have basically built a scheduler yourself (which is what Akka did). Riiiiiiight.. so... what's the problem there? Someone did what the erlang folks did on the JVM. Why is that used as a refutation here? > As far as tuning PTHREAD_STACK_MIN on x86 is generally 16K, which is quite a bit bigger. So either you aren't in the same ballpark (factor of >5) My comment was in regards to building a scheduler yourself (erlang doesn't have that many threads of parallel execution either) or using a technique with less demanding semantics like Fork-Join. A lot of people have mixed up a lot of concepts here in the attempt to discuss why they like Erlang, but the truth is that it can't be nearly so efficient at scheduling and executing parallel computation as the average Java program appealing to java.util.concurrent, but is tuned for greater concurrency. It's also true that for some classes of computation Erlang's strategy works great, and for others it'd require substantial engine improvements to make competitive. The impression given on this thread is that Elixir is the answer. I don't like that impression being left for people new to the discipline, because it's not how most people who are good at distributed systems or massively parallel AND concurrent programming think about the problem.
- phamilton 12y ago
  By not having preemptive scheduling, there are a whole lot of hoops that have to be jumped through. Spray.io is a disaster in usability in my opinion, for example. I've yet to find my code simpler and easier to maintain and debug when I use callback based async techniques. That is, however my opinion and personal taste. Others may disagree.
  - KirinDave 12y ago
    You won't find me carrying a lot of water for any Node library. I just think it's not wise to try and represent the use cases that actor based excels at as primary for our industry or even somehow privileged.

grogers 12y ago

The difference is the scheduling. In erlang, processes are preemptively scheduled, in akka they aren't. Erlang goes to great lengths to avoid one process from starving another. With akka you have to go to some lengths yourself to prevent starvation (e.g. preventing blocking calls in your event handlers).