parallel

Joe Armstrong: Grow software apps by adding small communicating objects

We should grow things (software applications) by adding more small communicating objects, rather than making larger and larger non-communicating objects.

Concentrating on the communication provides a higher level of abstraction than concentrating on the function APIs used within the system. Black-box equivalence says that two systems are equivalent if they cannot be distinguished by observing their communication patterns. Two black-boxes are equivalent if they have identical input/output behavior.

When we connect black boxes together we don't care what programming languages have been used inside the black boxes, we don't care how the code inside the black boxes has been organized, we just have to obey the communication protocols.

Erlang programs are the exception. Erlang programs are intentionally structured as communicating processes — they are the ultimate micro-services.

Large Erlang applications have a flat “bus like” structure. They are structured as independent parallel applications hanging off a common communication bus. This leads to architectures that are easy to understand and debug and collaborations which are easy to program.

~ From this post by Joe Armstrong, author of the book Programming Erlang: Software for a Concurrent World

Amdahl’s Law - Theoretical speedup of programs using parallel programming

Strictly speaking, Amdahl’s Law isn’t only about speeding up serial programs by using parallel processing techniques, but in practice that’s often the case. Here’s a description from Wikipedia:

“Amdahl's law is often used in parallel computing to predict the theoretical speedup when using multiple processors. For example, if a program needs 20 hours using a single processor core, and a particular part of the program which takes one hour to execute cannot be parallelized, while the remaining 19 hours (p = 0.95) of execution time can be parallelized, then regardless of how many processors are devoted to a parallelized execution of this program, the minimum execution time cannot be less than that critical one hour. Hence, the theoretical speedup is limited to at most 20 times (1/(1 − p) = 20). For this reason parallel computing is relevant only for a low number of processors and very parallelizable programs.”

The image comes from this Wikipedia page. I just looked up that information after starting to watch this YouTube video about Amdahl’s Law, Ruby, and Scala, at Twitter.

The Case for Message-Driven (Understanding Async, Non-Blocking, Concurrent, Parallel and More) alvin August 18, 2015 - 4:16pm

How to create a Twitter client in Scala

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 15.10, “How to create a Twitter client in Scala.”

Problem

You want to create a client to connect to Twitter to access the information you want, such as showing timelines and trends.

Examples of how to use parallel collections in Scala

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 13.12, “Examples of how to use parallel collections in Scala.”

Back to top

Problem

You want to improve the performance of algorithms by using parallel collections.

Back to top

Solution

When creating a collection, use one of the Scala’s parallel collection classes, or convert an existing collection to a parallel collection. In either case, test your algorithm to make sure you see the benefit you’re expecting.

Table of Contents

  1. Problem
  2. Solution
Back to top

Simple concurrency with Scala Futures (Futures tutorial)

Table of Contents1 - Problem2 - Solution3 - Run one task, but block4 - Run one thing, but don’t block, use callback5 - The onSuccess and onFailure callback methods6 - Creating a method to return a Future[T]7 - How to use multiple Futures in a for loop8 - Discussion9 - A future and ExecutionContext10 - Callback methods11 - For-comprehensions (combinators: map, flatMap, filter, foreach, recoverWith, fallbackTo, andThen)12 - See Also13 - The Scala Cookbook

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 13.9, “Simple concurrency with Scala Futures.”

Back to top

Problem

You want a simple way to run one or more tasks concurrently in a Scala application, including a way to handle their results when the tasks finish. For instance, you may want to make several web service calls in parallel, and then work with their results after they all return.

Back to top

Solution

A Future gives you a simple way to run an algorithm concurrently. A future starts running concurrently when you create it and returns a result at some point, well, in the future. In Scala, it’s said that a future returns “eventually.”

One way that functional programming helps with concurrency

I’ve read a lot of irrational claims about how functional programming helps with concurrency, but if a compiler can do what this says, at least it’s a clear, rational example of how FP can help with concurrency. It’s taken from an article titled, Functional programming for the rest of us.