Tooling for profiling of parallel code

[toddaaro]

A big goal when writing parallel code is that ... things run in parallel and go faster. But sometimes it is hard to tell whether or not the desired parallelism is occuring, and if it is not, it can be difficult to tell why it isn't there. Some sort of profiling tooling should exist to help programmers with this problem. An example of such a system is Haskell's ThreadScope, which provides a wealth of profiling information in a pleasing GUI interface. This is a very high bar for the long term, but in the short term there is stuff we can do.

The most basic useful output would be to allow a user to "watch" certain tasks, and receive an output of what times the tasks are active and on what threads. This could then be analyzed in another tool to see "how parallel" the code was. An example API would be to wrap "watched code" in a macro that expands to two debug print statements wrapping the code, with those debug statements printing scheduler id, timestamps, and a user-specified identifier to a log file.

I don't think much more should be planned for the short term, but awareness of a ThreadScope-like goal could influence scheduler design in minor ways.

http://www.haskell.org/haskellwiki/ThreadScope

[mstewartgallus]

You may find some of the following pseudo-crates for logging useful. These could also be used as a basis for better facilities.

• ::rt::mem Memory management
• ::rt::comm Messaging and task communication
• ::rt::task Task management
• ::rt::dom Task scheduling
• ::rt::trace Unused
• ::rt::cache Type descriptor cache
• ::rt::upcall Compiler-generated runtime calls
• ::rt::timer The scheduler timer
• ::rt::gc Garbage collection
• ::rt::stdlib Functions used directly by the standard library
• ::rt::kern The runtime kernel
• ::rt::backtrace Log a backtrace on task failure
• ::rt::callback Unused

[nikomatsakis]

One simple way to achieve this is to provide decent debug info, which will enable us to integrate with advanced tools like vtune etc. Of course this won't be language specific.

[thestinger]

Rust has decent debug info so existing profiling tools work fine with native threads. #17325 means that supporting profiling for green threads is out-of-scope of the standard libraries. #10302 is the only major missing piece of the puzzle and it would now be very easy to implement.