ThreadScope Tour/Spark2

Objectives

Use spark events and the spark size viewer to diagnose a spark granularity issue

Steps

Sparks too small (parlist1)

1. Build and run the somewhat the parlist1 example from the previous Spark visualisation module

    ./parlist1 +RTS -N2 -lf
    threadscope parlist1.eventlog

   Previously we modified a program (parlist0) that was flooding the spark pool by creating sparks far more quickly than they could be converted. Parlist1 is the result of our improvements.

2. Scroll down to the spark creation/conversion for the revised parlist1.

   

   We are now creating and converting sparks throughout the life of the program, which is an improvement.

   But dig a little a deeper, and notice the colours in the log above. Where is all this fizzle (grey), and garbage collection (orange) coming from? Sparks fizzle if something else has evaluated their task before them.

   In this case, the competition comes from the main thread which is trying to consume our list in sum xs. It walks down, evaluating values from the list. The ideal is for the values have already been evaluated by one of the sparks, but since we are getting a lot of fizzle; our main thread must often be getting to these values before the sparks are.

3. Switch to the spark size view in the bottom drawer.

   

   Notice how most of the sparks being evaluated are rather short lived, around the 4µs range. Maybe we need coarser-grained work so that we don't find ourselves with work that's faster to do than spark off. TODO: provisionally understanding this as a problem of overheads

Tweaking spark granularity (parlist2)

4. Build the parlist2 example and ThreadScope it. This version explores the idea of doing coarser grained work. It feeds bigger inputs to fib, which changes what we're trying to compute (so not a solution for the real world!), but a useful way to explore the possibility of larger sparks.

    ./parlist2 +RTS -N2 -lf
    threadscope parlist2.eventlog

5. Have a look first at the activity

   

   Now we're talking! We're nearly maxing our two cores

6. Switch to the spark size view

   

   Notice that our sparks are now running for 250 to 500 times longer. Upping the granularity ensures that if the main thread is working on something, it'll be working on something long enough to get started on some of the sparks.

7. Enable the spark traces and scroll down.

   

   Green everywhere. No more fizzle.

Exercises

1. parlist2 does not compute the same thing as parlist1 because we increased the size of the work to get bigger sparks. Can you think of a way to get the same effect while doing the same task? Validate with ThreadScope.