We continued our discussion of parallelism.
Functional languages offer nice opportunities for parallel evaluation of subexpressions, since there are few if any side effects that might create unexpected dependencies between subexpressions.
Today we introduced costs graphs as a tool for analyzing the work and span of functional programs. We mentioned Brent's Theorem, which describes the possible parallel speed-up of a program in terms of the program's work and span and the available processors.
Cost graphs also provide a tool for scheduling processors to expression evaluation. Scheduling is often a tricky problem. In some instances, a programmer may wish to schedule processors directly. Alternatively, in a high-level functional language it is convenient to let a compiler do the scheduling, with the programmer focusing instead on developing algorithms and data-structures that have potential for parallelism, in particular by writing code with low span complexity.
Lists are inherently sequential, thus making it difficult for a programmer to write parallel-friendly code. As an alternative, we introduced sequences as a new datastructure, with functions that look very similar to list functions but support parallel implementations behind the scenes.