4 ms·

Do you mean co-routines / user threads / green threads? I tend to agree it can have a serious performance boost in some cases. Not sure why you were down voted

Do you mean co-routines / user threads / green threads? I tend to agree it can have a serious performance boost in some cases. Not sure why you were down voted. There is actually a library for java that adds it via byte code instrumentation (quasar or something) although not sure it will work for scala. But saying that actor model is bad practice, I'm not sure that I accept it. Maybe on a single muticore but once you start talking distributed computing (e.g. Spark which is Akka based) then all this "avoid crossing to the kernel" optimization is becoming a drop in the ocean.

jamii 12y ago
> all this "avoid crossing to the kernel" optimization is becoming a drop in the ocean Here is an example of a small single threaded program beating out a number of distributed graph frameworks running on 128 cores, with a 128 billion edge dataset. http://www.frankmcsherry.org/graph/scalability/cost/2015/02/04/COST2.html http://www.frankmcsherry.org/graph/scalability/cost/2015/02/... Performance matters because it enables simplicity. If your language forces you to pull in multiple machines to solve your problem then its turned a simple program into a distributed system and life gets complicated fast. Just throwing more cores at a program without understanding why its slow will just get you into trouble. Multithreaded programs and distributed programs should be a scary last resort after making absolutely sure you can't get away with the simple solution.
- eranation 12y ago
  Yes I saw this, and got a little disillusioned at first, but after looking carefully this is not big data, their entire dataset fits in RAM. When your dataset can't fit in RAM - this is where the last resort comes into play. Sadly most companies, I agree, don't know when data is really big data. Most of the time it's just medium data. And I agree about the overhead costs.
  - jamii 12y ago
    > their entire dataset fits in RAM 128 billion edges. 1 TB of data just to list edges as pairs of integers. 154 GB after cleverly encoding edges as variable length offsets in a Hilbert curve. Do you have a bigger dataset?
    - eranation 12y ago
      Oh, I was referring to the original posts. Will take a look. Thanks!
pron 12y ago
> Do you mean co-routines / user threads / green threads? I tend to agree it can have a serious performance boost in some cases. Yes, but in this context, they provide the same performance benefits as the asynchronous techniques mentioned in the article, without all the drawbacks of the cumbersome asynchronous style. > But saying that actor model is bad practice The actor model is a general technique for fault-tolerance, and it's great. How it handles concurrency, though, is an orthogonal concern. Akka has asynchronous (callback based) actors, and callbacks are an anti-pattern. Erlang has synchronous (blocking) actors, which are so much simpler, and don't have all the complications associated with asynchronous code.
- noelwelsh 12y ago
  Erlang has asynchronous message passing by default, on which synchronous message passing can be built.
  - Matthias247 12y ago
    I would agree that in both Akka and Erlang message passing works in an asynchronous way. For me the difference is more that Akka has a push-style approach to message processing in the receiver (the receive message is automatically called) whereas Erlang and also e.g. the F# Mailboxprocessor use a pull-style appproach (you call receive to fetch a message). I like the latter approach better, because it allows one to start also different asynchronous operations which won't be interrupted by the reception of a new message.
  - pron 12y ago
    That's not what I meant. Message receive in Erlang is blocking (synchronous), just like it is in Go and Quasar. Meaning, it's basically a blocking queue rather than the asynchronous/push-style/callback approach used in Akka.

jamii 12y ago

> all this "avoid crossing to the kernel" optimization is becoming a drop in the ocean Here is an example of a small single threaded program beating out a number of distributed graph frameworks running on 128 cores, with a 128 billion edge dataset. http://www.frankmcsherry.org/graph/scalability/cost/2015/02/04/COST2.html http://www.frankmcsherry.org/graph/scalability/cost/2015/02/... Performance matters because it enables simplicity. If your language forces you to pull in multiple machines to solve your problem then its turned a simple program into a distributed system and life gets complicated fast. Just throwing more cores at a program without understanding why its slow will just get you into trouble. Multithreaded programs and distributed programs should be a scary last resort after making absolutely sure you can't get away with the simple solution.

eranation 12y ago
Yes I saw this, and got a little disillusioned at first, but after looking carefully this is not big data, their entire dataset fits in RAM. When your dataset can't fit in RAM - this is where the last resort comes into play. Sadly most companies, I agree, don't know when data is really big data. Most of the time it's just medium data. And I agree about the overhead costs.
- jamii 12y ago
  > their entire dataset fits in RAM 128 billion edges. 1 TB of data just to list edges as pairs of integers. 154 GB after cleverly encoding edges as variable length offsets in a Hilbert curve. Do you have a bigger dataset?
  - eranation 12y ago
    Oh, I was referring to the original posts. Will take a look. Thanks!

pron 12y ago

> Do you mean co-routines / user threads / green threads? I tend to agree it can have a serious performance boost in some cases. Yes, but in this context, they provide the same performance benefits as the asynchronous techniques mentioned in the article, without all the drawbacks of the cumbersome asynchronous style. > But saying that actor model is bad practice The actor model is a general technique for fault-tolerance, and it's great. How it handles concurrency, though, is an orthogonal concern. Akka has asynchronous (callback based) actors, and callbacks are an anti-pattern. Erlang has synchronous (blocking) actors, which are so much simpler, and don't have all the complications associated with asynchronous code.

noelwelsh 12y ago
Erlang has asynchronous message passing by default, on which synchronous message passing can be built.
- Matthias247 12y ago
  I would agree that in both Akka and Erlang message passing works in an asynchronous way. For me the difference is more that Akka has a push-style approach to message processing in the receiver (the receive message is automatically called) whereas Erlang and also e.g. the F# Mailboxprocessor use a pull-style appproach (you call receive to fetch a message). I like the latter approach better, because it allows one to start also different asynchronous operations which won't be interrupted by the reception of a new message.
- pron 12y ago
  That's not what I meant. Message receive in Erlang is blocking (synchronous), just like it is in Go and Quasar. Meaning, it's basically a blocking queue rather than the asynchronous/push-style/callback approach used in Akka.