(→Sparks too small (parlist1): tidy up)
m (→Tweaking spark granularity (parlist2))
Revision as of 16:31, 7 December 2011
Use spark events and the spark size viewer to diagnose a spark granularity issue
2.1 Sparks too small (parlist1)
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.
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.
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
2.2 Tweaking spark granularity (parlist2)
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
Have a look first at the activity
Now we're talking! We're nearly maxing our two cores
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.
Enable the spark traces and scroll down.
Green everywhere. No more fizzle.
- 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.