Practice meeting, Aug. 20th

[Lyle Kopnicky]

We'll discuss Chapter 3, "Evaluation Strategies", of Parallel and Concurrent Programming in Haskell. Please read it beforehand. You may wish to try running the code examples from the book. At the meeting anyone will be able to present and contribute to the discussion.

Location:

Collective Agency

511 SW 10th Ave

Portland, OR

Date:

August 20th, 2018

Time:

6:30pm - 8:30pm

We'll be in the 12th floor conference room, not in the Collective Agency suite. Take the elevator to the 12th floor and walk around to the rear of the floor. It's behind the glass door with the sign that says "Fire Escape".

RSVP at:

https://www.meetup.com/Portland-Functional-Programming-Study-Group/events/jlvlvpyxlbbc/

[Lyle Kopnicky]

Thanks to everyone for their contributions and participation tonight! We went over Chapter 3, got through the sequential section on K-means, but didn't get into parallelizing it yet.

I took us on a bit of a detour because I questioned the point of something in the book. Specifically where he defines

rdeepseq x = rseq (force x)

and then defines

parPair sa sb = evalPair (rparWith sa) (rparWith sb)

and then calls

parPair rdeepseq rdeepseq

I thought, why are we wrapping the force with rseq, instead of rpar, only to later add the parallelism? So we tried an experiment in the meeting. We defined

rdeeppar x = rpar (force x)

and then instead of calling parPair, we wrote

evalPair rdeeppar rdeeppar

This seemed to produce the same results - even the threadscope output looked the same.

It turns out that rseq doesn't really do anything. It doesn't create a spark, whereas rpar does. So wrapping an rseq around the (force x) is just so that we get a strategy. Then you can always decide later that you want to run it in parallel, by wrapping rparWith around your strategy. So, rparWith rseq is the same as rpar.

We'll follow up with the rest of Chapter 3 next time, on September 3rd.

- Lyle