This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Why AsyncFP? Does Scala really need another type of actor? (slides)

11 replies
Bill La Forge
Joined: 2011-07-13,
User offline. Last seen 42 years 45 weeks ago.
Had fun writing these slides. Hopefully they will not be too controversial.

https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BxfwYLnRiLVIZGZhNmYzN2EtNmFlMi00YWY3LWEyODYtNWEyNWFjNzMzYWJl&hl=en_US

Feel free to knock holes in what I've said here. I'd consider it a blessing.

Thanks!

Bill La Forge
kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 17 hours ago.
Re: Why AsyncFP? Does Scala really need another type of actor?

"Computers are getting fatter, not faster."

OK, that is the most concise definition of the issue I have seen yet.
Well done!

"Passing data between threads is slow!"

Not sure what you are getting at as both hardware and software threads
share the same process VM and passing data can be very fast. Is what you
meant to say: "Scala Actors passing data between threads is slow!"?

"Threads use lots of RAM which limits scalability."

Other than the stack - no - not really - the heap is shared. Presumably
what you mean is "Scala Actors use of threads use lots of RAM which
limits scalability."??

"Messages pass between mailboxes are blocked for added throughput."

I would recommend "Messages pass between mailboxes are batched (or
coalesced) for added throughput." The word 'blocked' is too overloaded.

If I get the gist of what you are saying would this be correct: Scala
needs another type of actor that is higher performance for certain
applications by making more optimal use of hardware, operating system
and JVM resources.

I am in agreement with that - it is always good to have alternate
implementations of an API or feature for more specific purposes - after
all, why else does Java have so many garbage collectors.

Cheers, Eric

On 2011-10-13 11:56 PM, William la Forge wrote:
> Had fun writing these slides. Hopefully they will not be too
> controversial.
>
> https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BxfwY...
>
>
> Feel free to knock holes in what I've said here. I'd consider it a
> blessing.
>
> Thanks!
>
> Bill La Forge

Razvan Cojocaru 3
Joined: 2010-07-28,
User offline. Last seen 42 years 45 weeks ago.
RE: Why AsyncFP? Does Scala really need another type of actor?

Well – I’m not clear what it is that it’s suggesting… to address all the evils there J

 

Anyhow – having spent some time to read it, I have some notes below

 

I like “computers are getting fatter not faster”.

 

I don’t want to start a holy war, but I don’t agree with this anymore: “code that uses all that hardware is difficult to write”: Welcome to J2EE – there’s MDBs and web sessions and EJB sessions and other sessions in there…

Now – if your logic is made of dinky 3 line pieces of code that take 2 nanoseconds to run and for some reason may need asynchronicity, you may have a point but I’m not sure what helps there other than specialized parallel transputing things… like OCCAM whatnot.

 

Slide 5 – never seen that suggested… May be better to not mention that idea J

Slide 6 – “thread waits on DB”, but Slide 7 – “actors do not tie up threads unless you use I/O” so what makes them better than threads?

Slide 7 – actors are heavyweight ???

never thought of it that way. I mean if actors are much lighter than threads which are much lighter than processes… what’s lighter than an actor? Feathers? J

By the way, then comes slide 8 saying “actors are lightweight”. Confused now.

Same slide 8 – if it’s all synchronous, why bother doing anything? Are you thinking to replace the |> symbol or what exactly?

 

Anywhoo – personal opinion, highly discard-able, except maybe for writing SETI or LHC algorithms, code mostly needs to interact with storage and correlate sessions/messages. Having actors-lighter-than-threads already, I would focus on caching as the “hard” part of taking advantage of what’s obviously going to be deployed in a “cloud” i.e. distributed. NIO maybe the only trick required up one’s sleeve…

 

Get an expensive level-7 hardware switch to front a cluster and get out for an early lunch J. It is over-simplifying it, but it rarely is complicated…

 

Cheers,

Razie

 

From: scala-user [at] googlegroups [dot] com [mailto:scala-user [at] googlegroups [dot] com] On Behalf Of William la Forge
Sent: October-14-11 2:56 AM
To: scala-user
Subject: [scala-user] Why AsyncFP? Does Scala really need another type of actor? (slides)

 

Had fun writing these slides. Hopefully they will not be too controversial.

https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BxfwYLnRiLVIZGZhNmYzN2EtNmFlMi00YWY3LWEyODYtNWEyNWFjNzMzYWJl&hl=en_US

Feel free to knock holes in what I've said here. I'd consider it a blessing.

Thanks!

Bill La Forge

Peter 2
Joined: 2011-02-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Why AsyncFP? Does Scala really need another type of actor? (

Hi Bill,

I very much appritiate that you are undertaking this initiative to
evaluate the pros and cons of AsynchFP versus Scala Actors/Akka.

On Page "Solution 3: Use Scala Actors!" you state: "Actors pass
messages across threads, so if you use a lot of actors response time
suffers."

As opposed to this, "Programming in Scala" introduces the "react"
method which conserves the thread and allows to host all actors on a
single thread.

So I am confused about the above statement. Could you please elaborate
on this? As an Actor-newby I'd be also very pleased to get input from
Actors/Akka users about AsynchFP.

Thanks a lot
Peter

Raoul Duke
Joined: 2009-01-05,
User offline. Last seen 42 years 45 weeks ago.
Re: Why AsyncFP? Does Scala really need another type of actor?

On Fri, Oct 14, 2011 at 10:33 AM, Eric Kolotyluk
wrote:
> "Passing data between threads is slow!"
>
> Not sure what you are getting at as both hardware and software threads share
> the same process VM and passing data can be very fast. Is what you meant to
> say: "Scala Actors passing data between threads is slow!"?

it all depends on semantics.

passing messages in erjang is not slow.

Bill La Forge
Joined: 2011-07-13,
User offline. Last seen 42 years 45 weeks ago.
Re: Why AsyncFP? Does Scala really need another type of actor?
Eric, Razvan, Peter and Raoul,

Many thanks to each of you for your review. Very helpful.

I do need to add one important clarification immediately. Scala actors are not slow. There has been a lot of work done on Scala actors and I've heard it said that they are faster than most other implementations. Indeed, AsyncFP mailboxes add a layer of complexity on top of Scala reactors and, for the equivalent operation, are much slower. An AsyncFP actor is only faster than a Scala actor when the AsyncFP actors share the same mailbox--then they're about 100 times faster. But of course 100 times faster is pretty meaningless if your application logic is more than 1 or 2 lines.

Thanks again guys!

Bill
Bill La Forge
Joined: 2011-07-13,
User offline. Last seen 42 years 45 weeks ago.
Re: Why AsyncFP? Does Scala really need another type of actor?
New version uploaded at the same link: http://www.pearltrees.com/#/N-p=26930425&N-play=1&N-u=1_389370&N-fa=3451453&N-s=1_3451540&N-f=1_3451540

Hopefully less controversial now. I've tightened up the language a bit. I also added a new slide at the end which touches very lightly on the pros and cons of AsyncFP.

Thanks again guys!

Bill

On Sat, Oct 15, 2011 at 6:20 AM, William la Forge <laforge49 [at] gmail [dot] com> wrote:
Eric, Razvan, Peter and Raoul,

Many thanks to each of you for your review. Very helpful.

I do need to add one important clarification immediately. Scala actors are not slow. There has been a lot of work done on Scala actors and I've heard it said that they are faster than most other implementations. Indeed, AsyncFP mailboxes add a layer of complexity on top of Scala reactors and, for the equivalent operation, are much slower. An AsyncFP actor is only faster than a Scala actor when the AsyncFP actors share the same mailbox--then they're about 100 times faster. But of course 100 times faster is pretty meaningless if your application logic is more than 1 or 2 lines.

Thanks again guys!

Bill

kolotyluk
Joined: 2010-06-04,
User offline. Last seen 5 weeks 17 hours ago.
Re: Why AsyncFP? Does Scala really need another type of actor?
Looks better. It might be nice to see a code example or problem example the highlights where AsyncFP really shines. I always like a concrete example so I can grok things.

Cheers, Eric

On 2011-10-14 8:52 PM, William la Forge wrote:
CAGwFecZPo5_L-PcsZZ3WM2iOLN2HXQMQmcaJ-hbLPj-X+hS7eg [at] mail [dot] gmail [dot] com" type="cite">New version uploaded at the same link: http://www.pearltrees.com/#/N-p=26930425&N-play=1&N-u=1_389370&N-fa=3451453&N-s=1_3451540&N-f=1_3451540

Hopefully less controversial now. I've tightened up the language a bit. I also added a new slide at the end which touches very lightly on the pros and cons of AsyncFP.

Thanks again guys!

Bill

On Sat, Oct 15, 2011 at 6:20 AM, William la Forge <laforge49 [at] gmail [dot] com" rel="nofollow">laforge49 [at] gmail [dot] com> wrote:
Eric, Razvan, Peter and Raoul,

Many thanks to each of you for your review. Very helpful.

I do need to add one important clarification immediately. Scala actors are not slow. There has been a lot of work done on Scala actors and I've heard it said that they are faster than most other implementations. Indeed, AsyncFP mailboxes add a layer of complexity on top of Scala reactors and, for the equivalent operation, are much slower. An AsyncFP actor is only faster than a Scala actor when the AsyncFP actors share the same mailbox--then they're about 100 times faster. But of course 100 times faster is pretty meaningless if your application logic is more than 1 or 2 lines.

Thanks again guys!

Bill

Bill La Forge
Joined: 2011-07-13,
User offline. Last seen 42 years 45 weeks ago.
Re: Why AsyncFP? Does Scala really need another type of actor?
Oh yes, I don't think I mentioned. Some more slides, this time on managing data integrity, Scala vs AsyncFP actors.
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BxfwYLnRiLVINWI5NTZhNjUtODJmZC00ZjZhLTkzOTctYjA1Y2Y0N2M2Zjcw&hl=en_US

Bill

On Sat, Oct 15, 2011 at 8:01 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
Looks better. It might be nice to see a code example or problem example the highlights where AsyncFP really shines. I always like a concrete example so I can grok things.

Cheers, Eric

On 2011-10-14 8:52 PM, William la Forge wrote:
New version uploaded at the same link: http://www.pearltrees.com/#/N-p=26930425&N-play=1&N-u=1_389370&N-fa=3451453&N-s=1_3451540&N-f=1_3451540

Hopefully less controversial now. I've tightened up the language a bit. I also added a new slide at the end which touches very lightly on the pros and cons of AsyncFP.

Thanks again guys!

Bill

On Sat, Oct 15, 2011 at 6:20 AM, William la Forge <laforge49 [at] gmail [dot] com> wrote:
Eric, Razvan, Peter and Raoul,

Many thanks to each of you for your review. Very helpful.

I do need to add one important clarification immediately. Scala actors are not slow. There has been a lot of work done on Scala actors and I've heard it said that they are faster than most other implementations. Indeed, AsyncFP mailboxes add a layer of complexity on top of Scala reactors and, for the equivalent operation, are much slower. An AsyncFP actor is only faster than a Scala actor when the AsyncFP actors share the same mailbox--then they're about 100 times faster. But of course 100 times faster is pretty meaningless if your application logic is more than 1 or 2 lines.

Thanks again guys!

Bill


Bill La Forge
Joined: 2011-07-13,
User offline. Last seen 42 years 45 weeks ago.
Re: Why AsyncFP? Does Scala really need another type of actor?
I agree! But good examples are always hard to come by. :D

I think the main thing is granularity. I.E. Smaller actors handling many more messages. But aside from doing some slides, my next programming project will likely be speeding up the transaction rate of the database implemented using AsyncFP. My goal is 50K tps, but I don't know how realistic that is. The only bottleneck will be that I need to flush the log file after every transaction--anything else would be cheating!

Bill

On Sat, Oct 15, 2011 at 8:01 PM, Eric Kolotyluk <eric [dot] kolotyluk [at] gmail [dot] com> wrote:
Looks better. It might be nice to see a code example or problem example the highlights where AsyncFP really shines. I always like a concrete example so I can grok things.

Cheers, Eric

On 2011-10-14 8:52 PM, William la Forge wrote:
New version uploaded at the same link: http://www.pearltrees.com/#/N-p=26930425&N-play=1&N-u=1_389370&N-fa=3451453&N-s=1_3451540&N-f=1_3451540

Hopefully less controversial now. I've tightened up the language a bit. I also added a new slide at the end which touches very lightly on the pros and cons of AsyncFP.

Thanks again guys!

Bill

On Sat, Oct 15, 2011 at 6:20 AM, William la Forge <laforge49 [at] gmail [dot] com> wrote:
Eric, Razvan, Peter and Raoul,

Many thanks to each of you for your review. Very helpful.

I do need to add one important clarification immediately. Scala actors are not slow. There has been a lot of work done on Scala actors and I've heard it said that they are faster than most other implementations. Indeed, AsyncFP mailboxes add a layer of complexity on top of Scala reactors and, for the equivalent operation, are much slower. An AsyncFP actor is only faster than a Scala actor when the AsyncFP actors share the same mailbox--then they're about 100 times faster. But of course 100 times faster is pretty meaningless if your application logic is more than 1 or 2 lines.

Thanks again guys!

Bill


Ittay Dror 2
Joined: 2010-05-05,
User offline. Last seen 42 years 45 weeks ago.
Re: Why AsyncFP? Does Scala really need another type of actor?

On Saturday, October 15, 2011 6:25:32 PM UTC+2, Bill La Forge wrote:
Oh yes, I don't think I mentioned. Some more slides, this time on managing data integrity, Scala vs AsyncFP actors.
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BxfwYLnRiLVINWI5NTZhNjUtODJmZC00ZjZhLTkzOTctYjA1Y2Y0N2M2Zjcw&hl=en_US

On slide 3 you write the way to wait for replies in Scala actors blocks the thread. This is not true:
   otherActor ! Request
   react {
      case Reply => ...
   }

will wait for a reply without blocking the thread.

In slide 4, you show a code overriding messageHandler method. This is not how Scala actors work. Instead, you define the 'act' method and use react. react statements can be nested, to simulate state machines:

def act = loop {
  react {
    case msg: LockMsg => lock(msg)
              react {
                   case msg: UnlockMsg => unlock(msg)
                   case msg if !msg.instanceOf[LockMsg] => unexpectedMsg(msg)
              }
   case _ => unexpectedMsg(msg)
}

Ittay  

Bill

On Sat, Oct 15, 2011 at 8:01 PM, Eric Kolotyluk <eric [dot] ko [dot] [dot] [dot] [at] gmail [dot] com> wrote:
Looks better. It might be nice to see a code example or problem example the highlights where AsyncFP really shines. I always like a concrete example so I can grok things.

Cheers, Eric

On 2011-10-14 8:52 PM, William la Forge wrote:
New version uploaded at the same link: http://www.pearltrees.com/#/N-p=26930425&N-play=1&N-u=1_389370&N-fa=3451453&N-s=1_3451540&N-f=1_3451540

Hopefully less controversial now. I've tightened up the language a bit. I also added a new slide at the end which touches very lightly on the pros and cons of AsyncFP.

Thanks again guys!

Bill

On Sat, Oct 15, 2011 at 6:20 AM, William la Forge <lafo [dot] [dot] [dot] [at] gmail [dot] com> wrote:
Eric, Razvan, Peter and Raoul,

Many thanks to each of you for your review. Very helpful.

I do need to add one important clarification immediately. Scala actors are not slow. There has been a lot of work done on Scala actors and I've heard it said that they are faster than most other implementations. Indeed, AsyncFP mailboxes add a layer of complexity on top of Scala reactors and, for the equivalent operation, are much slower. An AsyncFP actor is only faster than a Scala actor when the AsyncFP actors share the same mailbox--then they're about 100 times faster. But of course 100 times faster is pretty meaningless if your application logic is more than 1 or 2 lines.

Thanks again guys!

Bill


Bill La Forge
Joined: 2011-07-13,
User offline. Last seen 42 years 45 weeks ago.
Re: Why AsyncFP? Does Scala really need another type of actor?
Thanks Ittay. I was sure replies required a future. I'll dig into both of these issues further. But what you are saying makes a lot of sense.

I was also under the impression that nested react's were deprecated or something in favor of message guards.

Bill

On Sun, Oct 16, 2011 at 6:28 PM, Ittay Dror <ittay [dot] dror [at] gmail [dot] com> wrote:

On Saturday, October 15, 2011 6:25:32 PM UTC+2, Bill La Forge wrote:
Oh yes, I don't think I mentioned. Some more slides, this time on managing data integrity, Scala vs AsyncFP actors.
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BxfwYLnRiLVINWI5NTZhNjUtODJmZC00ZjZhLTkzOTctYjA1Y2Y0N2M2Zjcw&hl=en_US

On slide 3 you write the way to wait for replies in Scala actors blocks the thread. This is not true:
   otherActor ! Request
   react {
      case Reply => ...
   }

will wait for a reply without blocking the thread.

In slide 4, you show a code overriding messageHandler method. This is not how Scala actors work. Instead, you define the 'act' method and use react. react statements can be nested, to simulate state machines:

def act = loop {
  react {
    case msg: LockMsg => lock(msg)
              react {
                   case msg: UnlockMsg => unlock(msg)
                   case msg if !msg.instanceOf[LockMsg] => unexpectedMsg(msg)
              }
   case _ => unexpectedMsg(msg)
}

Ittay  

Bill

On Sat, Oct 15, 2011 at 8:01 PM, Eric Kolotyluk <eric [dot] ko [dot] [dot] [dot] [at] gmail [dot] com> wrote:
Looks better. It might be nice to see a code example or problem example the highlights where AsyncFP really shines. I always like a concrete example so I can grok things.

Cheers, Eric

On 2011-10-14 8:52 PM, William la Forge wrote:
New version uploaded at the same link: http://www.pearltrees.com/#/N-p=26930425&N-play=1&N-u=1_389370&N-fa=3451453&N-s=1_3451540&N-f=1_3451540

Hopefully less controversial now. I've tightened up the language a bit. I also added a new slide at the end which touches very lightly on the pros and cons of AsyncFP.

Thanks again guys!

Bill

On Sat, Oct 15, 2011 at 6:20 AM, William la Forge <lafo [dot] [dot] [dot] [at] gmail [dot] com> wrote:
Eric, Razvan, Peter and Raoul,

Many thanks to each of you for your review. Very helpful.

I do need to add one important clarification immediately. Scala actors are not slow. There has been a lot of work done on Scala actors and I've heard it said that they are faster than most other implementations. Indeed, AsyncFP mailboxes add a layer of complexity on top of Scala reactors and, for the equivalent operation, are much slower. An AsyncFP actor is only faster than a Scala actor when the AsyncFP actors share the same mailbox--then they're about 100 times faster. But of course 100 times faster is pretty meaningless if your application logic is more than 1 or 2 lines.

Thanks again guys!

Bill



Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland