Will Akka actors replace Scala actors in the standard Scala distro?

Hi Ken,
first off: Akka actors _are_ part of the Typesafe stack ;-)
But to answer your main question, yes, Akka actors will replace the current scala.actor package in the distribution at some point. There will be a smooth transition, though, meaning that for at least one major Scala release both implementations will be offered in parallel, probably in separate jars to keep IDEs from offering conflicting content assist options. Looking at it from the scala.actor perspective there are three main differences to consider:
- actor encapsulation: Akka does not make the Actor object visible to the outside, it is hidden behind ActorRef- mailbox model: Akka requires strict in-order processing while scala.actor offers Erlang style behavior changes- threads as target: Akka users do not have to concern themselves with java.lang.Thread, sending messages to it is not supported
The first difference is crucial for a reliable actor model (i.e. disallow bypassing the mailbox) and also for distributed actor systems (remote, clustering), which means it cannot be bridged in a source-compatible way.
The second difference concerns options on how to formulate the behavior of your actors internally, and we will provide an emulation layer for Erlang style “receive” (and scala.actor’s “react”) on top of Akka’s Actor.
The third difference might not be all that important as no-one is using it anyway; … hey, you, don’t look away, if there’s something I should know please tell me! ;-)
So, if there’s something big I have overlooked, please holler!
Regards,
Roland
On Sep 18, 2011, at 06:59 , Ken McDonald wrote:

It would make sense to me from a software maintainability point of view, plus the fact that from what little I know Akka actors seem better than Scala actors--but all I've heard concretely is that the Akka actors will be part of the Typesafe stack.
Thanks,Ken

Roland KuhnTypesafe – Enterprise-Grade Scala from the Expertstwitter: @rolandkuhn

This is the first time I have ever heard of Akka, so I looked it up.

I was wondering how actors (in general) would work in the context of Fork/Join API in Java 7. I was reading the Akka tutorial for Java, calculating pi, and it seemed similar to what you could do with Fork/Join, but fork join gives you a lot of other functionality like work stealing. Or would it be the case you just implement Fork/Join on top of Actors?

Cheers, Eric

On 2011-09-17 11:06 PM, Roland Kuhn wrote:

AFF40125-B7B1-4F66-BAD0-837D150E5F37 [at] rkuhn [dot] info" type="cite">Hi Ken,
first off: Akka actors _are_ part of the Typesafe stack ;-)
But to answer your main question, yes, Akka actors will replace the current scala.actor package in the distribution at some point. There will be a smooth transition, though, meaning that for at least one major Scala release both implementations will be offered in parallel, probably in separate jars to keep IDEs from offering conflicting content assist options. Looking at it from the scala.actor perspective there are three main differences to consider:
- actor encapsulation: Akka does not make the Actor object visible to the outside, it is hidden behind ActorRef - mailbox model: Akka requires strict in-order processing while scala.actor offers Erlang style behavior changes - threads as target: Akka users do not have to concern themselves with java.lang.Thread, sending messages to it is not supported
The first difference is crucial for a reliable actor model (i.e. disallow bypassing the mailbox) and also for distributed actor systems (remote, clustering), which means it cannot be bridged in a source-compatible way.
The second difference concerns options on how to formulate the behavior of your actors internally, and we will provide an emulation layer for Erlang style “receive” (and scala.actor’s “react”) on top of Akka’s Actor.
The third difference might not be all that important as no-one is using it anyway; … hey, you, don’t look away, if there’s something I should know please tell me! ;-)
So, if there’s something big I have overlooked, please holler!
Regards,
Roland
On Sep 18, 2011, at 06:59 , Ken McDonald wrote:

It would make sense to me from a software maintainability point of view, plus the fact that from what little I know Akka actors seem better than Scala actors--but all I've heard concretely is that the Akka actors will be part of the Typesafe stack.
Thanks, Ken

Roland Kuhn Typesafe – Enterprise-Grade Scala from the Experts twitter: @rolandkuhn

Eric,Scala Actors use a modified version of the ForkJoinPool contained in Java 7 by default, so they benefit from work stealing and such (at a thread level, not an actor level).  They also suffer from the weaknesses as well.
http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_1_final/src/f...
I don't know if Akka supports using the ForkJoinPool out-of-the-box, but I imagine setting it up to do so would be trivial.
-Erik

Hi Eric,
On Sep 18, 2011, at 16:37 , Eric Kolotyluk wrote:

This is the first time I have ever heard of Akka, so I looked it up.

Good! :-)

I was wondering how actors (in general) would work in the context of Fork/Join API in Java 7. I was reading the Akka tutorial for Java, calculating pi, and it seemed similar to what you could do with Fork/Join, but fork join gives you a lot of other functionality like work stealing. Or would it be the case you just implement Fork/Join on top of Actors?

Fork/Join and actors live at different levels of abstraction, hence putting one in the context of the other may not be meaningful. F/J is a specific solution for managing threads when you want something parallelized which can be broken down recursively, which is why it is used by the parallel collections framework. The actor model—on the other hand—is a completely different approach to distributed computing, where the elementary cell contains well-protected private state and is accessible only via messages which are queued in its mailbox.
It would of course be possible to implement F/J on a set of “dumb” stateless actors, which just perform some passed-in computation, which is what the π example does. However, this does not exercise all the strengths of encapsulation and fault-tolerance which are provided by the actor model. The main issue is that “thinking in actors” is really different from the traditional OO and functional approaches; one way to look at it is that actors are actually the most radical implementation of OO, being fully encapsulated.
On the other side, I know that Viktor has looked into perhaps writing an Akka dispatcher based on Java’s F/J framework. Without using F/J, Akka already has wicked fast event-based scheduling with and without work-donating, so he would have to comment on the potential up- and down-sides of this.
One more thing to consider is this: in an Akka application you get full control how many threads to allocate to each group of actors, including growing and shrinking policies, so that you can for example dedicate some cores to the low-latency paths (actors using PinnedDispatcher) while scaling out the rest. This flexibility and control is not possible with F/J, especially if there are multiple users of it in the same JVM.
Hope that helps. In case you have more questions, I’m happy to answer them either on the scala or akka lists.
Regards,
Roland

Cheers, Eric

On 2011-09-17 11:06 PM, Roland Kuhn wrote:

AFF40125-B7B1-4F66-BAD0-837D150E5F37 [at] rkuhn [dot] info" type="cite">Hi Ken,
first off: Akka actors _are_ part of the Typesafe stack ;-)
But to answer your main question, yes, Akka actors will replace the current scala.actor package in the distribution at some point. There will be a smooth transition, though, meaning that for at least one major Scala release both implementations will be offered in parallel, probably in separate jars to keep IDEs from offering conflicting content assist options. Looking at it from the scala.actor perspective there are three main differences to consider:
- actor encapsulation: Akka does not make the Actor object visible to the outside, it is hidden behind ActorRef - mailbox model: Akka requires strict in-order processing while scala.actor offers Erlang style behavior changes - threads as target: Akka users do not have to concern themselves with java.lang.Thread, sending messages to it is not supported
The first difference is crucial for a reliable actor model (i.e. disallow bypassing the mailbox) and also for distributed actor systems (remote, clustering), which means it cannot be bridged in a source-compatible way.
The second difference concerns options on how to formulate the behavior of your actors internally, and we will provide an emulation layer for Erlang style “receive” (and scala.actor’s “react”) on top of Akka’s Actor.
The third difference might not be all that important as no-one is using it anyway; … hey, you, don’t look away, if there’s something I should know please tell me! ;-)
So, if there’s something big I have overlooked, please holler!
Regards,
Roland
On Sep 18, 2011, at 06:59 , Ken McDonald wrote:

It would make sense to me from a software maintainability point of view, plus the fact that from what little I know Akka actors seem better than Scala actors--but all I've heard concretely is that the Akka actors will be part of the Typesafe stack.
Thanks, Ken

Roland Kuhn Typesafe – Enterprise-Grade Scala from the Experts twitter: @rolandkuhn

Roland KuhnTypesafe – Enterprise-Grade Scala from the Expertstwitter: @rolandkuhn

Erik, What 'weaknesses' were you thinking about?

I am developing applications in Space Based Architecture, using SQL
Spaces. One of the application uses MatLab, but each MatLab instance is
a single thread, consequently you have to run multiple instances in
separate processes. In effect, each instance becomes a worker that can
be on the same multi-core system, or on somewhere else on the network,
and the space binds them altogether. It is convenient that you can use
Java RMI to communicate with the MatLab instances.

I was originally considering trying ForkJoinPool as a way to decompose
the computations and manage the workers, but since reading about Akka
I'm wondering if it might be better going down that route.

In some cases computations can take hours using a single MatLab
instance, so we are motivated to reduce this as the individual
computations are completely independent of each other.

As much as I would prefer to use Scala, I am the only one on the team
who understands Scala. Using the Java version of Akka seems like an
alternative to ForkJoinPool, so I was curious as to how much of an
alternative it might be, and what the pros and cons are.

Cheers, Eric

On 2011-09-18 8:02 AM, Erik Engbrecht wrote:
> Eric,
> Scala Actors use a modified version of the ForkJoinPool contained in
> Java 7 by default, so they benefit from work stealing and such (at a
> thread level, not an actor level). They also suffer from the
> weaknesses as well.
>
> http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_1_final/src/f...
>
> I don't know if Akka supports using the ForkJoinPool out-of-the-box,
> but I imagine setting it up to do so would be trivial.
>
> -Erik

Actually I am fairly familiar with Actors having used the SR Programming Language back in the 90's, and a couple of years ago I wrote a prime numbers program in Scala using Actors as a way to play with my home/hobby computer with 8 cores and 16 threads :-)  -- it was cool watching all 16 threads running at 90%.

The application I have in mind is using MatLab, which is single threaded. However, you can run multiple instances in separate processes, and use RMI to communicate with each instance.

I was imagining you could create one actor for each MatLab instance (representing that well protected private state you mentioned), but I was looking for something more effective than what is used in the pi tutorial, like ForkJoinPool, which I would imagine might sit on top of the actors level. On the other hand, perhaps f/j is overkill for what I am trying to do.

This application lives in a Space Based Architecture, so workers can be coordinated via the space. The specific application is we have a list of colors, and we need to compute a recipe for each color, and each computation for a recipe is completely independent of any other recipe. In a trivial mindless approach you just throw all the work requests for each recipe into the space and workers do the work and return the results to the space, but I am worried about the overhead of the space communications being too dominate. The next best approach seem to decompose the computation into chunks, and have each worker do one chunk. In reality there are issues of MatLab instances having different contexts for different types of computations, and then competition for which worker is running which context, and if more than one person is doing computations with different contexts, how do you distribute the work fairly as switching contexts in MatLab is also an overhead.

One of the things that intrigued me about Akka was the fault-tolerance nature of things - in particular how to handle some worker failing somewhere if the system it is on goes down. Obviously I need to read further...

Cheers, Eric

On 2011-09-18 8:32 AM, Roland Kuhn wrote:

EF266916-780D-4DB2-B569-AEAB86611073 [at] rkuhn [dot] info" type="cite">Hi Eric,
On Sep 18, 2011, at 16:37 , Eric Kolotyluk wrote:

This is the first time I have ever heard of Akka, so I looked it up.

Good! :-)

I was wondering how actors (in general) would work in the context of Fork/Join API in Java 7. I was reading the Akka tutorial for Java, calculating pi, and it seemed similar to what you could do with Fork/Join, but fork join gives you a lot of other functionality like work stealing. Or would it be the case you just implement Fork/Join on top of Actors?

Fork/Join and actors live at different levels of abstraction, hence putting one in the context of the other may not be meaningful. F/J is a specific solution for managing threads when you want something parallelized which can be broken down recursively, which is why it is used by the parallel collections framework. The actor model—on the other hand—is a completely different approach to distributed computing, where the elementary cell contains well-protected private state and is accessible only via messages which are queued in its mailbox.
It would of course be possible to implement F/J on a set of “dumb” stateless actors, which just perform some passed-in computation, which is what the π example does. However, this does not exercise all the strengths of encapsulation and fault-tolerance which are provided by the actor model. The main issue is that “thinking in actors” is really different from the traditional OO and functional approaches; one way to look at it is that actors are actually the most radical implementation of OO, being fully encapsulated.
On the other side, I know that Viktor has looked into perhaps writing an Akka dispatcher based on Java’s F/J framework. Without using F/J, Akka already has wicked fast event-based scheduling with and without work-donating, so he would have to comment on the potential up- and down-sides of this.
One more thing to consider is this: in an Akka application you get full control how many threads to allocate to each group of actors, including growing and shrinking policies, so that you can for example dedicate some cores to the low-latency paths (actors using PinnedDispatcher) while scaling out the rest. This flexibility and control is not possible with F/J, especially if there are multiple users of it in the same JVM.
Hope that helps. In case you have more questions, I’m happy to answer them either on the scala or akka lists.
Regards,
Roland

Cheers, Eric

On 2011-09-17 11:06 PM, Roland Kuhn wrote:

AFF40125-B7B1-4F66-BAD0-837D150E5F37 [at] rkuhn [dot] info" type="cite">Hi Ken,
first off: Akka actors _are_ part of the Typesafe stack ;-)
But to answer your main question, yes, Akka actors will replace the current scala.actor package in the distribution at some point. There will be a smooth transition, though, meaning that for at least one major Scala release both implementations will be offered in parallel, probably in separate jars to keep IDEs from offering conflicting content assist options. Looking at it from the scala.actor perspective there are three main differences to consider:
- actor encapsulation: Akka does not make the Actor object visible to the outside, it is hidden behind ActorRef - mailbox model: Akka requires strict in-order processing while scala.actor offers Erlang style behavior changes - threads as target: Akka users do not have to concern themselves with java.lang.Thread, sending messages to it is not supported
The first difference is crucial for a reliable actor model (i.e. disallow bypassing the mailbox) and also for distributed actor systems (remote, clustering), which means it cannot be bridged in a source-compatible way.
The second difference concerns options on how to formulate the behavior of your actors internally, and we will provide an emulation layer for Erlang style “receive” (and scala.actor’s “react”) on top of Akka’s Actor.
The third difference might not be all that important as no-one is using it anyway; … hey, you, don’t look away, if there’s something I should know please tell me! ;-)
So, if there’s something big I have overlooked, please holler!
Regards,
Roland
On Sep 18, 2011, at 06:59 , Ken McDonald wrote:

It would make sense to me from a software maintainability point of view, plus the fact that from what little I know Akka actors seem better than Scala actors--but all I've heard concretely is that the Akka actors will be part of the Typesafe stack.
Thanks, Ken

Roland Kuhn Typesafe – Enterprise-Grade Scala from the Experts twitter: @rolandkuhn

Roland Kuhn Typesafe – Enterprise-Grade Scala from the Experts twitter: @rolandkuhn

Hi Eric,
you might want to consider using (remote) actors instead of RMI, simply because of the asynchronous nature of your problem. And with what the Akka 2.x series will offer, things are looking even brighter; more on that from Jonas in a short while.
Wrapping each MatLab instance in one actor would be exactly the approach I would have suggested. That way you retain full control over how to scale out your application.
Regards,
Roland
On Sep 18, 2011, at 18:27 , Eric Kolotyluk wrote:

Actually I am fairly familiar with Actors having used the SR Programming Language back in the 90's, and a couple of years ago I wrote a prime numbers program in Scala using Actors as a way to play with my home/hobby computer with 8 cores and 16 threads :-)  -- it was cool watching all 16 threads running at 90%.

The application I have in mind is using MatLab, which is single threaded. However, you can run multiple instances in separate processes, and use RMI to communicate with each instance.

I was imagining you could create one actor for each MatLab instance (representing that well protected private state you mentioned), but I was looking for something more effective than what is used in the pi tutorial, like ForkJoinPool, which I would imagine might sit on top of the actors level. On the other hand, perhaps f/j is overkill for what I am trying to do.

This application lives in a Space Based Architecture, so workers can be coordinated via the space. The specific application is we have a list of colors, and we need to compute a recipe for each color, and each computation for a recipe is completely independent of any other recipe. In a trivial mindless approach you just throw all the work requests for each recipe into the space and workers do the work and return the results to the space, but I am worried about the overhead of the space communications being too dominate. The next best approach seem to decompose the computation into chunks, and have each worker do one chunk. In reality there are issues of MatLab instances having different contexts for different types of computations, and then competition for which worker is running which context, and if more than one person is doing computations with different contexts, how do you distribute the work fairly as switching contexts in MatLab is also an overhead.

One of the things that intrigued me about Akka was the fault-tolerance nature of things - in particular how to handle some worker failing somewhere if the system it is on goes down. Obviously I need to read further...

Cheers, Eric

On 2011-09-18 8:32 AM, Roland Kuhn wrote:

EF266916-780D-4DB2-B569-AEAB86611073 [at] rkuhn [dot] info" type="cite">Hi Eric,
On Sep 18, 2011, at 16:37 , Eric Kolotyluk wrote:

This is the first time I have ever heard of Akka, so I looked it up.

Good! :-)

I was wondering how actors (in general) would work in the context of Fork/Join API in Java 7. I was reading the Akka tutorial for Java, calculating pi, and it seemed similar to what you could do with Fork/Join, but fork join gives you a lot of other functionality like work stealing. Or would it be the case you just implement Fork/Join on top of Actors?

Fork/Join and actors live at different levels of abstraction, hence putting one in the context of the other may not be meaningful. F/J is a specific solution for managing threads when you want something parallelized which can be broken down recursively, which is why it is used by the parallel collections framework. The actor model—on the other hand—is a completely different approach to distributed computing, where the elementary cell contains well-protected private state and is accessible only via messages which are queued in its mailbox.
It would of course be possible to implement F/J on a set of “dumb” stateless actors, which just perform some passed-in computation, which is what the π example does. However, this does not exercise all the strengths of encapsulation and fault-tolerance which are provided by the actor model. The main issue is that “thinking in actors” is really different from the traditional OO and functional approaches; one way to look at it is that actors are actually the most radical implementation of OO, being fully encapsulated.
On the other side, I know that Viktor has looked into perhaps writing an Akka dispatcher based on Java’s F/J framework. Without using F/J, Akka already has wicked fast event-based scheduling with and without work-donating, so he would have to comment on the potential up- and down-sides of this.
One more thing to consider is this: in an Akka application you get full control how many threads to allocate to each group of actors, including growing and shrinking policies, so that you can for example dedicate some cores to the low-latency paths (actors using PinnedDispatcher) while scaling out the rest. This flexibility and control is not possible with F/J, especially if there are multiple users of it in the same JVM.
Hope that helps. In case you have more questions, I’m happy to answer them either on the scala or akka lists.
Regards,
Roland

Cheers, Eric

On 2011-09-17 11:06 PM, Roland Kuhn wrote:

AFF40125-B7B1-4F66-BAD0-837D150E5F37 [at] rkuhn [dot] info" type="cite">Hi Ken,
first off: Akka actors _are_ part of the Typesafe stack ;-)
But to answer your main question, yes, Akka actors will replace the current scala.actor package in the distribution at some point. There will be a smooth transition, though, meaning that for at least one major Scala release both implementations will be offered in parallel, probably in separate jars to keep IDEs from offering conflicting content assist options. Looking at it from the scala.actor perspective there are three main differences to consider:
- actor encapsulation: Akka does not make the Actor object visible to the outside, it is hidden behind ActorRef - mailbox model: Akka requires strict in-order processing while scala.actor offers Erlang style behavior changes - threads as target: Akka users do not have to concern themselves with java.lang.Thread, sending messages to it is not supported
The first difference is crucial for a reliable actor model (i.e. disallow bypassing the mailbox) and also for distributed actor systems (remote, clustering), which means it cannot be bridged in a source-compatible way.
The second difference concerns options on how to formulate the behavior of your actors internally, and we will provide an emulation layer for Erlang style “receive” (and scala.actor’s “react”) on top of Akka’s Actor.
The third difference might not be all that important as no-one is using it anyway; … hey, you, don’t look away, if there’s something I should know please tell me! ;-)
So, if there’s something big I have overlooked, please holler!
Regards,
Roland
On Sep 18, 2011, at 06:59 , Ken McDonald wrote:

It would make sense to me from a software maintainability point of view, plus the fact that from what little I know Akka actors seem better than Scala actors--but all I've heard concretely is that the Akka actors will be part of the Typesafe stack.
Thanks, Ken

Roland Kuhn Typesafe – Enterprise-Grade Scala from the Experts twitter: @rolandkuhn

Roland Kuhn Typesafe – Enterprise-Grade Scala from the Experts twitter: @rolandkuhn

Roland KuhnTypesafe – Enterprise-Grade Scala from the Expertstwitter: @rolandkuhn

Eric,See:http://artisans-serverintellect-com.si-eioswww6.com/default.asp?W9

Specifically the second paragraph under purpose.  More generally along these lines, any FJ task that either blocks in an unmanaged way or runs continuously can cause starvation.  If you have the FJ pool configured such that worker threads process their local dequeues in a LIFO manner you can also get surprising behavior.
Basically the FJ pool is optimized for short, non-blocking computations, so you can decompose a task into lots of smaller tasks without worrying too much about the overhead of doing so.
If you have long, blocking tasks you'd probably be better off using a different backing thread pool.  I don't think Akka uses FJ by default, so if you use Akka you are probably good.  If you use Scala Actors there's a flag you can set so it will use a ThreadPoolExecutor (I think) instead of the FJ pool.
-Erik

Roland,I think Eric is shooting for something along these lines.
Given N nodes with M cores each:1. There are N "Akka" processes, one per node2. Each "Akka" process contains M actors, each of which talk to Matlab via RMI (I'm guessing using the MatlabControl library)3. Each node runs up to M Matlab processes4. Each "Akka" process runs a supervisor actor that distributes work to the others, and restarts them if they die5. Nodes can farm out work to one another by sending jobs to the supervisor for that node
Alternatively each Matlab process could run an actor in its own local JVM, and then the Matlab processes could talk to each other using remote actors.  The problem is Matlab ships with it's own JRE, which is likely to be behind the times (especially if you are running an older version of Matlab).  Matlab might also do funny things to its local JVM...I don't know.  But anyway, since you can only have one Matlab engine per process, and each Matlab engine is for the most part single threaded, so if you want to take advantage of multiple cores you need multiple processes.
-Erik

Hi Erik,
On Sep 18, 2011, at 19:13 , Erik Engbrecht wrote:

Roland,I think Eric is shooting for something along these lines.
Given N nodes with M cores each:1. There are N "Akka" processes, one per node2. Each "Akka" process contains M actors, each of which talk to Matlab via RMI (I'm guessing using the MatlabControl library)3. Each node runs up to M Matlab processes4. Each "Akka" process runs a supervisor actor that distributes work to the others, and restarts them if they die5. Nodes can farm out work to one another by sending jobs to the supervisor for that node

Yes, this matches my intention.

Alternatively each Matlab process could run an actor in its own local JVM, and then the Matlab processes could talk to each other using remote actors.  The problem is Matlab ships with it's own JRE, which is likely to be behind the times (especially if you are running an older version of Matlab).  Matlab might also do funny things to its local JVM...I don't know.  But anyway, since you can only have one Matlab engine per process, and each Matlab engine is for the most part single threaded, so if you want to take advantage of multiple cores you need multiple processes.

Thanks for explaining a bit deeper, this clears up the confusion in my previous mail.
Regards,
Roland KuhnTypesafe – Enterprise-Grade Scala from the Expertstwitter: @rolandkuhn

Some more information...

While you can run Java code within a MatLab instance, the instance is
single threaded, so far as I know you cannot start other Java threads.

Currently we use a Socket to communicate between the Java UI application
and the MatLab instance doing the work.

What the MatLab people do for web applications is launch one or more
MatLab processes, and the servlet communicates to the MatLab processes
via RMI, which is more elegant than what we do over a Socket.

Presumably one could run Akka code in the MatLab process, as long as it
is single threaded, or Just as easily the Akka process can use RMI to
get the MatLab processes to do work, with one Actor managing on MatLab
process.

In our new architecture there will be a service process running on each
node, that could contain the Akka based supervisor supporting all the
worker Actors. Initially we will be supporting only one node, but in the
future there will be multiple nodes. The Java UI application will post
work requests in the space, and the masters would watch the space, take
the request and coordinate the computations, then merge the results and
return the result to the space.

However, each node only needs to start and stop the MatLab processes,
once they are running, you could have a central master with all the
worker actors talking exclusively to each MatLab instance via RMI. If we
can run the Akka library in MatLab we could also implement the worker
actor in the MatLab process if that is better somehow.

Ultimately I am looking for the most simple architecture that is
efficient and reliable, and it is a space-based architecture.

Cheers, Eric

On 2011-09-18 10:13 AM, Erik Engbrecht wrote:
> Roland,
> I think Eric is shooting for something along these lines.
>
> Given N nodes with M cores each:
> 1. There are N "Akka" processes, one per node
> 2. Each "Akka" process contains M actors, each of which talk to Matlab
> via RMI (I'm guessing using the MatlabControl library)
> 3. Each node runs up to M Matlab processes
> 4. Each "Akka" process runs a supervisor actor that distributes work
> to the others, and restarts them if they die
> 5. Nodes can farm out work to one another by sending jobs to the
> supervisor for that node
>
> Alternatively each Matlab process could run an actor in its own local
> JVM, and then the Matlab processes could talk to each other using
> remote actors. The problem is Matlab ships with it's own JRE, which
> is likely to be behind the times (especially if you are running an
> older version of Matlab). Matlab might also do funny things to its
> local JVM...I don't know. But anyway, since you can only have one
> Matlab engine per process, and each Matlab engine is for the most part
> single threaded, so if you want to take advantage of multiple cores
> you need multiple processes.
>
> -Erik
>

While you can run Java code within a MatLab instance, the instance is single threaded, so far as I know you cannot start other Java threads.

Yes, you can start other Java threads in Matlab, as long as they are doing Java-y things. However, the Matlab engine itself is single threaded and will prevent other threads from using it concurrently. See http://www.mathworks.com/matlabcentral/newsreader/view_thread/148991  --
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining [at] gmail [dot] com

Thanks Brian, that clears up a year long argument we have been having at work.

Now I see both sides were right and wrong - it was not being explained clearly.

We have no trouble accessing the MatLab engine from a single thread.

So, is it better to run the remote actor in the MatLab engine then instead of using RMI?

It looks like Akka uses a web stack for communications. Isn't that a lot heavier weight that using RMI?

Cheers, Eric

On 2011-09-18 12:50 PM, Brian Schlining wrote:

CAH2-wOP3r1DREiJA2f3eqoGbAoEWnsaK95b-Oz3LR_830kRwiw [at] mail [dot] gmail [dot] com" type="cite">

While you can run Java code within a MatLab instance, the instance is single threaded, so far as I know you cannot start other Java threads.

Yes, you can start other Java threads in Matlab, as long as they are doing Java-y things. However, the Matlab engine itself is single threaded and will prevent other threads from using it concurrently. See http://www.mathworks.com/matlabcentral/newsreader/view_thread/148991   --
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining [at] gmail [dot] com" rel="nofollow">bschlining [at] gmail [dot] com

Akka remote message sends use Netty with Protobuf serialization, though other serializers may be specified for user-defined message classes; I’d think that RMI cannot possibly be cheaper. Which web stack are you referring to?
Regards,
Roland
On Sep 18, 2011, at 22:19 , Eric Kolotyluk wrote:

Thanks Brian, that clears up a year long argument we have been having at work.

Now I see both sides were right and wrong - it was not being explained clearly.

We have no trouble accessing the MatLab engine from a single thread.

So, is it better to run the remote actor in the MatLab engine then instead of using RMI?

It looks like Akka uses a web stack for communications. Isn't that a lot heavier weight that using RMI?

Cheers, Eric

On 2011-09-18 12:50 PM, Brian Schlining wrote:

CAH2-wOP3r1DREiJA2f3eqoGbAoEWnsaK95b-Oz3LR_830kRwiw [at] mail [dot] gmail [dot] com" type="cite">

While you can run Java code within a MatLab instance, the instance is single threaded, so far as I know you cannot start other Java threads.

Yes, you can start other Java threads in Matlab, as long as they are doing Java-y things. However, the Matlab engine itself is single threaded and will prevent other threads from using it concurrently. See http://www.mathworks.com/matlabcentral/newsreader/view_thread/148991   --
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining [at] gmail [dot] com" rel="nofollow">bschlining [at] gmail [dot] com

Roland KuhnTypesafe – Enterprise-Grade Scala from the Expertstwitter: @rolandkuhn

I'm an idiot - I read "Jetty" instead of "Netty" %-)

Cheers, Eric

On 2011-09-18 1:44 PM, Roland Kuhn wrote:

02EF4DDB-1158-45F6-BE64-32F146400DFF [at] rkuhn [dot] info" type="cite"> Akka remote message sends use Netty with Protobuf serialization, though other serializers may be specified for user-defined message classes; I’d think that RMI cannot possibly be cheaper. Which web stack are you referring to?
Regards,
Roland
On Sep 18, 2011, at 22:19 , Eric Kolotyluk wrote:

Thanks Brian, that clears up a year long argument we have been having at work.

Now I see both sides were right and wrong - it was not being explained clearly.

We have no trouble accessing the MatLab engine from a single thread.

So, is it better to run the remote actor in the MatLab engine then instead of using RMI?

It looks like Akka uses a web stack for communications. Isn't that a lot heavier weight that using RMI?

Cheers, Eric

On 2011-09-18 12:50 PM, Brian Schlining wrote:

CAH2-wOP3r1DREiJA2f3eqoGbAoEWnsaK95b-Oz3LR_830kRwiw [at] mail [dot] gmail [dot] com" type="cite">

While you can run Java code within a MatLab instance, the instance is single threaded, so far as I know you cannot start other Java threads.

Yes, you can start other Java threads in Matlab, as long as they are doing Java-y things. However, the Matlab engine itself is single threaded and will prevent other threads from using it concurrently. See http://www.mathworks.com/matlabcentral/newsreader/view_thread/148991   --
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining [at] gmail [dot] com" rel="nofollow">bschlining [at] gmail [dot] com

Roland Kuhn Typesafe – Enterprise-Grade Scala from the Experts twitter: @rolandkuhn

On Sun, Sep 18, 2011 at 11:37, Eric Kolotyluk wrote:
> This is the first time I have ever heard of Akka, so I looked it up.
>
> I was wondering how actors (in general) would work in the context of
> Fork/Join API in Java 7. I was reading the Akka tutorial for Java,
> calculating pi, and it seemed similar to what you could do with Fork/Join,
> but fork join gives you a lot of other functionality like work stealing. Or
> would it be the case you just implement Fork/Join on top of Actors?

I find it curious that Roland didn't mention this, but you can
actually select the Executor for a group of actors. The default is
just an event-based, but there is a *work-stealing* event based
executor as well:

http://akka.io/api/akka/1.1.3/#akka.dispatch.ExecutorBasedEventDrivenWor...

I guess you'd probably use that with this:
http://akka.io/api/akka/1.1.3/#akka.routing.LoadBalancer. That way,
you send message to one actor who distributes it to others in a load
balancing fashion (this one is round-robin, but you can have more
sophisticated dispatchers), and these other actors having been
assigned a work stealing executor.

On Sep 19, 2011, at 03:43 , Daniel Sobral wrote:

> On Sun, Sep 18, 2011 at 11:37, Eric Kolotyluk wrote:
>> This is the first time I have ever heard of Akka, so I looked it up.
>>
>> I was wondering how actors (in general) would work in the context of
>> Fork/Join API in Java 7. I was reading the Akka tutorial for Java,
>> calculating pi, and it seemed similar to what you could do with Fork/Join,
>> but fork join gives you a lot of other functionality like work stealing. Or
>> would it be the case you just implement Fork/Join on top of Actors?
>
> I find it curious that Roland didn't mention this, but you can
> actually select the Executor for a group of actors. The default is
> just an event-based, but there is a *work-stealing* event based
> executor as well:
>
> http://akka.io/api/akka/1.1.3/#akka.dispatch.ExecutorBasedEventDrivenWor...
>
Actually, while not giving this precise path, I hinted at it: I just called it “work-donating” dispatcher out of some weird reflex (because that term would be less imprecise from a technical standpoint, as I’m told by Viktor). More information on all choices here: http://akka.io/docs/akka/1.2-RC6/scala/dispatchers.html

> I guess you'd probably use that with this:
> http://akka.io/api/akka/1.1.3/#akka.routing.LoadBalancer. That way,
> you send message to one actor who distributes it to others in a load
> balancing fashion (this one is round-robin, but you can have more
> sophisticated dispatchers), and these other actors having been
> assigned a work stealing executor.
>

Yes, that’s the idea. And in 2.0 you will get all of this without having to think about it beforehand: just take your sufficiently state-less actor and outfit it with a pool, a router and a suitable dispatcher by adding this deployment to your configuration file.

Roland Kuhn
Typesafe – Enterprise-Grade Scala from the Experts
twitter: @rolandkuhn

I implemented a dispatcher based on FJ but after discussing it with Doug I decided to drop it (it had worse performance than the default dispatcher).
The reason is that it is, as the name states, designed for fork/join problems. With actors however, there is no join phase. It also doesn't seem to be dong work-stealing unless it's quiescing (sp?).

Now, the only remaining SPOBN of the default impl is the task queue of the thread pool executor, what would be interesting would be to stripe multiple and then rotate workers around, as there is no need for ordering of which mailboxes to execute, as long as there is low risk of starvation.

Cheers,
V

On Sep 19, 2011 8:24 AM, "Roland Kuhn" <google [at] rkuhn [dot] info> wrote:
>
> On Sep 19, 2011, at 03:43 , Daniel Sobral wrote:
>
>> On Sun, Sep 18, 2011 at 11:37, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
>>> This is the first time I have ever heard of Akka, so I looked it up.
>>>
>>> I was wondering how actors (in general) would work in the context of
>>> Fork/Join API in Java 7. I was reading the Akka tutorial for Java,
>>> calculating pi, and it seemed similar to what you could do with Fork/Join,
>>> but fork join gives you a lot of other functionality like work stealing. Or
>>> would it be the case you just implement Fork/Join on top of Actors?
>>
>> I find it curious that Roland didn't mention this, but you can
>> actually select the Executor for a group of actors. The default is
>> just an event-based, but there is a *work-stealing* event based
>> executor as well:
>>
>> http://akka.io/api/akka/1.1.3/#akka.dispatch.ExecutorBasedEventDrivenWorkStealingDispatcher
>>
> Actually, while not giving this precise path, I hinted at it: I just called it “work-donating” dispatcher out of some weird reflex (because that term would be less imprecise from a technical standpoint, as I’m told by Viktor). More information on all choices here: http://akka.io/docs/akka/1.2-RC6/scala/dispatchers.html
>
>> I guess you'd probably use that with this:
>> http://akka.io/api/akka/1.1.3/#akka.routing.LoadBalancer. That way,
>> you send message to one actor who distributes it to others in a load
>> balancing fashion (this one is round-robin, but you can have more
>> sophisticated dispatchers), and these other actors having been
>> assigned a work stealing executor.
>>
>
> Yes, that’s the idea. And in 2.0 you will get all of this without having to think about it beforehand: just take your sufficiently state-less actor and outfit it with a pool, a router and a suitable dispatcher by adding this deployment to your configuration file.
>
> Roland Kuhn
> Typesafe – Enterprise-Grade Scala from the Experts
> twitter: @rolandkuhn
>

On Monday, September 19, 2011 3:57:42 AM UTC-5, √iktor Klang wrote:

... unless it's quiescing (sp?).

quiescent :-)
Ken