A testing framework for Scala actors: please try it!

Dear Samira,

I've developed an alternate actor system and I'd very much appreciate it if you reviewed it. It is a high performance system, so it is a little harder to code to, but it includes support for functional programming. It also does replies without recourse to future.

It works a bit like the language E, decoupling actors from mailboxes. This allows actors which share the same mailbox, for example, all actors created to process the same user request, to interoperate synchronously. The performance gain then is between 11000% and 13000%.

Now because of the use of both replies and functional programming facilities like fold, find, exists, map, filter and flatmap, I also contend that the code you write is easier to read--which too much actor code is not.

Do let me know what you think about it, and of course I'd be delighted to answer any questions. Here's the links:

wiki - https://github.com/laforge49/Asynchronous-Functional-Programming/wiki
source - https://github.com/laforge49/Asynchronous-Functional-Programming

I am also most interested in working with any early adopters. :-)

Sincerely,

Bill La Forge
laforge49@gmail.com


On Mon, Jul 18, 2011 at 9:42 AM, Samira Tasharofi <samira.tasharofi@gmail.com> wrote:

Hi all,

We (a group at UIUC) have created a testing framework for Scala
actors, named
"Setac" (http://mir.cs.illinois.edu/setac/) .
It is presented as a paper in Scala days 2011 (http://days2011.scala-
lang.org/). The idea is that it allows the users to control the
schedule of the test execution and check the assertions at
appropriate
times. Please try the tool and give me your feedback.

My goal is to port Setac for Akka actors as well. In order to improve
the
framework, I need some actor programs so that I can see which
features
are required to be included in an actor testing framework. I would be
happy to help with any of you to test your actor programs and also
look into the test cases you wrote for testing your programs.
Please let me know if you have written any actor program or you know
about some actor systems/test suites that might help me.


Thanks,
Samira

Hi Bill,

Thanks for letting me know about your actor system. I just wonder what
is the application of your actor system? what did make you motivated
to create such system with actors that share mail boxes? Do you have
any evaluation of the performance you will achieve by such system?

I'll take a look into your code and let you know about my opinion. I
am kinda busy now; but I'll do that as soon as I can.

Regards,
Samira

On Jul 17, 9:49 pm, William la Forge wrote:
> Dear Samira,
>
> I've developed an alternate actor system and I'd very much appreciate it if
> you reviewed it. It is a high performance system, so it is a little harder
> to code to, but it includes support for functional programming. It also does
> replies without recourse to future.
>
> It works a bit like the language E, decoupling actors from mailboxes. This
> allows actors which share the same mailbox, for example, all actors created
> to process the same user request, to interoperate synchronously. The
> performance gain then is between 11000% and 13000%.
>
> Now because of the use of both replies and functional programming facilities
> like fold, find, exists, map, filter and flatmap, I also contend that the
> code you write is easier to read--which too much actor code is not.
>
> Do let me know what you think about it, and of course I'd be delighted to
> answer any questions. Here's the links:
>
> wiki -https://github.com/laforge49/Asynchronous-Functional-Programming/wiki
> source -https://github.com/laforge49/Asynchronous-Functional-Programming
>
> I am also most interested in working with any early adopters. :-)
>
> Sincerely,
>
> Bill La Forge
> laforg...@gmail.com
>
> On Mon, Jul 18, 2011 at 9:42 AM, Samira Tasharofi <
>
>
>
>
>
>
>
> samira.tashar...@gmail.com> wrote:
> > Hi all,
>
> > We (a group at UIUC) have created a testing framework for Scala
> > actors, named
> > "Setac" (http://mir.cs.illinois.edu/setac/) .
> > It is presented as a paper in Scala days 2011 (http://days2011.scala-
> > lang.org/). The idea is that it allows the users to control the
> > schedule of the test execution and check the assertions at
> > appropriate
> > times. Please try the tool and give me your feedback.
>
> > My goal is to port Setac for Akka actors as well. In order to improve
> > the
> > framework, I need some actor programs so that I can see which
> > features
> > are required to be included in an actor testing framework. I would be
> > happy to help with any of you to test your actor programs and also
> > look into the test cases you wrote for testing your programs.
> > Please let me know if you have written any actor program or you know
> > about some actor systems/test suites that might help me.
>
> > Thanks,
> > Samira

Hi Samira!

I've been working on a versioning graphical database for almost 10 years now and my focus of late has been scalability and performance. The higher layers are implemented using actors and I realized that, while there are gains to be made by implementing the lower layers as actors, the actors themselves would soon become the bottleneck.

A big part of the problem is that once your bottom layer code is written in actors, then everything works best using actors. It is just easier if actors are fine grained and you can use them for everything--that kind of uniformity is important for keeping the code base and test suite manageable.

After experimenting with various approaches for a year, I came up with the idea finally of using callbacks in place of return values and writing the application code so that it worked when everything was on the same thread as well as when interactions spanned threads. Then to increase the chances of things interacting on the same thread, I decoupled actors from their mailboxes and allowed mailboxes to be shared. That gave me a speedup of 2 orders of magnitude. Here's the timing test-- https://github.com/laforge49/Asynchronous-Functional-Programming/blob/master/Blip/src/test/scala/org/agilewiki/blip/TimingTest.scala --but you will need to put back the zero's I commented out.

I've also been thinking lately that asynchronous interactions can be sped up by blocking outgoing messages until the inbox is empty. But from previous experiments, I don't think the results will be so dramatic, likely less than an order of magnitude.

Looking forward to hearing more from you later. I well understand that everyone worth knowing has little time to spare.

Thanks for the questions. :-)

Bill

On Wed, Jul 20, 2011 at 9:32 AM, Samira Tasharofi <samira.tasharofi@gmail.com> wrote:

Hi Bill,

Thanks for letting me know about your actor system. I just wonder what
is the application of your actor system? what did make you motivated
to create such system with actors that share mail boxes? Do you have
any evaluation of the performance you will achieve by such system?

I'll take a look into your code and let you know about my opinion. I
am kinda busy now; but I'll do that as soon as I can.

Regards,
Samira

On Jul 17, 9:49 pm, William la Forge <laforg...@gmail.com> wrote:
> Dear Samira,
>
> I've developed an alternate actor system and I'd very much appreciate it if
> you reviewed it. It is a high performance system, so it is a little harder
> to code to, but it includes support for functional programming. It also does
> replies without recourse to future.
>
> It works a bit like the language E, decoupling actors from mailboxes. This
> allows actors which share the same mailbox, for example, all actors created
> to process the same user request, to interoperate synchronously. The
> performance gain then is between 11000% and 13000%.
>
> Now because of the use of both replies and functional programming facilities
> like fold, find, exists, map, filter and flatmap, I also contend that the
> code you write is easier to read--which too much actor code is not.
>
> Do let me know what you think about it, and of course I'd be delighted to
> answer any questions. Here's the links:
>
> wiki -https://github.com/laforge49/Asynchronous-Functional-Programming/wiki
> source -https://github.com/laforge49/Asynchronous-Functional-Programming
>
> I am also most interested in working with any early adopters. :-)
>
> Sincerely,
>
> Bill La Forge
> laforg...@gmail.com
>
> On Mon, Jul 18, 2011 at 9:42 AM, Samira Tasharofi <
>
>
>
>
>
>
>
> samira.tashar...@gmail.com> wrote:
> > Hi all,
>
> > We (a group at UIUC) have created a testing framework for Scala
> > actors, named
> > "Setac" (http://mir.cs.illinois.edu/setac/) .
> > It is presented as a paper in Scala days 2011 (http://days2011.scala-
> > lang.org/). The idea is that it allows the users to control the
> > schedule of the test execution and check the assertions at
> > appropriate
> > times. Please try the tool and give me your feedback.
>
> > My goal is to port Setac for Akka actors as well. In order to improve
> > the
> > framework, I need some actor programs so that I can see which
> > features
> > are required to be included in an actor testing framework. I would be
> > happy to help with any of you to test your actor programs and also
> > look into the test cases you wrote for testing your programs.
> > Please let me know if you have written any actor program or you know
> > about some actor systems/test suites that might help me.
>
> > Thanks,
> > Samira

Oh, I also wanted to add that I really got tired of writing spaghetti code. Being able to do things like fold is a godsend!

https://github.com/laforge49/Asynchronous-Functional-Programming/wiki/Fold

Bill

On Wed, Jul 20, 2011 at 11:59 AM, William la Forge <laforge49@gmail.com> wrote:

Hi Samira!

I've been working on a versioning graphical database for almost 10 years now and my focus of late has been scalability and performance. The higher layers are implemented using actors and I realized that, while there are gains to be made by implementing the lower layers as actors, the actors themselves would soon become the bottleneck.

A big part of the problem is that once your bottom layer code is written in actors, then everything works best using actors. It is just easier if actors are fine grained and you can use them for everything--that kind of uniformity is important for keeping the code base and test suite manageable.

After experimenting with various approaches for a year, I came up with the idea finally of using callbacks in place of return values and writing the application code so that it worked when everything was on the same thread as well as when interactions spanned threads. Then to increase the chances of things interacting on the same thread, I decoupled actors from their mailboxes and allowed mailboxes to be shared. That gave me a speedup of 2 orders of magnitude. Here's the timing test-- https://github.com/laforge49/Asynchronous-Functional-Programming/blob/master/Blip/src/test/scala/org/agilewiki/blip/TimingTest.scala --but you will need to put back the zero's I commented out.

I've also been thinking lately that asynchronous interactions can be sped up by blocking outgoing messages until the inbox is empty. But from previous experiments, I don't think the results will be so dramatic, likely less than an order of magnitude.

Looking forward to hearing more from you later. I well understand that everyone worth knowing has little time to spare.

Thanks for the questions. :-)

Bill

On Wed, Jul 20, 2011 at 9:32 AM, Samira Tasharofi <samira.tasharofi@gmail.com> wrote:

Hi Bill,

Thanks for letting me know about your actor system. I just wonder what
is the application of your actor system? what did make you motivated
to create such system with actors that share mail boxes? Do you have
any evaluation of the performance you will achieve by such system?

I'll take a look into your code and let you know about my opinion. I
am kinda busy now; but I'll do that as soon as I can.

Regards,
Samira

On Jul 17, 9:49 pm, William la Forge <laforg...@gmail.com> wrote:
> Dear Samira,
>
> I've developed an alternate actor system and I'd very much appreciate it if
> you reviewed it. It is a high performance system, so it is a little harder
> to code to, but it includes support for functional programming. It also does
> replies without recourse to future.
>
> It works a bit like the language E, decoupling actors from mailboxes. This
> allows actors which share the same mailbox, for example, all actors created
> to process the same user request, to interoperate synchronously. The
> performance gain then is between 11000% and 13000%.
>
> Now because of the use of both replies and functional programming facilities
> like fold, find, exists, map, filter and flatmap, I also contend that the
> code you write is easier to read--which too much actor code is not.
>
> Do let me know what you think about it, and of course I'd be delighted to
> answer any questions. Here's the links:
>
> wiki -https://github.com/laforge49/Asynchronous-Functional-Programming/wiki
> source -https://github.com/laforge49/Asynchronous-Functional-Programming
>
> I am also most interested in working with any early adopters. :-)
>
> Sincerely,
>
> Bill La Forge
> laforg...@gmail.com
>
> On Mon, Jul 18, 2011 at 9:42 AM, Samira Tasharofi <
>
>
>
>
>
>
>
> samira.tashar...@gmail.com> wrote:
> > Hi all,
>
> > We (a group at UIUC) have created a testing framework for Scala
> > actors, named
> > "Setac" (http://mir.cs.illinois.edu/setac/) .
> > It is presented as a paper in Scala days 2011 (http://days2011.scala-
> > lang.org/). The idea is that it allows the users to control the
> > schedule of the test execution and check the assertions at
> > appropriate
> > times. Please try the tool and give me your feedback.
>
> > My goal is to port Setac for Akka actors as well. In order to improve
> > the
> > framework, I need some actor programs so that I can see which
> > features
> > are required to be included in an actor testing framework. I would be
> > happy to help with any of you to test your actor programs and also
> > look into the test cases you wrote for testing your programs.
> > Please let me know if you have written any actor program or you know
> > about some actor systems/test suites that might help me.
>
> > Thanks,
> > Samira