Active Harmony’s Plug-in Interface A World of Possibilities Ray S.

Active Harmony’s Plug-in Interface A World of Possibilities Ray S. Chen [email protected] Jeffrey K. Hollingsworth [email protected] Paradyn/Dyninst Week 2013 April 30, 2013

Overview and Motivation Auto-tuning has a broad range of applications o Optimization of run-time, throughput, energy, etc. Supporting new features increasingly difficult due to monolithic internals o o 10 years of non-structured development Core search logic implemented in Tcl Reorganization produced a generalized autotuning framework o o Á la componentization of Dyninst API Eases integration with other projects 2

Auto-tuning Basics Empirically test configurations for performance o Searches a set of valid configurations for optimal Valid configurations defined by tuning variables o o Variables can be integer, real, or enumerated strings Each variable bound by minimum, maximum, and step Set of tuning variables define a parameter space o o N variables create an N-dimensional space Cartesian coordinates represent unique configurations 3

Parameter Space Example o o o o Name: Tile Min: 2 Max: 16 Step: 2 Variable 2 o o o o Name: Unroll Min: 0 Max: 10 Step: 1 Unroll Variable 1 10 9 8 7 6 5 4 3 2 1 0 2 4 6 8 10 12 14 Tile 4 16

Auto-Tuning Feedback Loop Evaluated Performance 5.1 Client Application Auto Search Strategy Tuner Candidate Points 5

Search Strategies Drives the feedback loop Pluggable module with two major interfaces o o Fetch: Generates a new point for client Report: Accepts a point/performance pair from client Four strategies included in Active Harmony o o o o Brute Force Random Nelder-Mead Parallel Rank Order (PRO) 6

Generalized Auto-Tuning Evaluated Performance REPORT 3 2 1 Client Application Active Search 321 Harmony Strategy FETCH Candidate Points 7

Onion Model Workflow REPORT 3 2 1 Search Strategy FETCH Allows for paired functionality, but either hook is optional. Fetch hooks executed in ascending order. Report hooks executed in descending order. Point values cannot be modified (directly). 8

Plug-in Workflow: ACCEPT 3 2 1 Search Strategy Indicates successful processing at this level. Plug-in relinquishes control of the point to entity below. 9

Plug-in Workflow: RETURN 3 2 1 Search Strategy Allows a short-circuit in the feedback loop. Plug-in must provide the performance value. Processing resumes at the same level from the report workflow. 10

Plug-in Workflow: REJECT 3 2 1 Search Strategy Allows modification of the search indirectly. Plug-in must provide an alternate valid point. o Search strategy is not obligated to use it. Processing jumps directly back to search strategy. 11

Plug-in Example: Point Logger logger init() logger init() {{ outfd outfd open(“performance.log”); open(“performance.log”); }} logger report(flow t logger report(flow t *flow, *flow, point t point t *pt, *pt, double double perf) perf) {{ fprintf(outfd, fprintf(outfd, “%s “%s - - %lf\n”, %lf\n”, string(pt), string(pt), perf); perf); flow- type flow- type ACCEPT; ACCEPT; }} logger fini() logger fini() {{ close(outfd); close(outfd); }} 12

Plug-in Workflow: WAIT 3 2 1 External Process Search Strategy Allows asynchronous point processing Plug-in sends point to external process Other points processed in the mean time Processing resumes at the same level upon return 13

Plug-in Example: Code Server cs init() cs init() {{ sockfd sockfd tcp connect(CODE SERVER); tcp connect(CODE SERVER); register fetch callback(sockfd, register fetch callback(sockfd, code ready); code ready); }} cs fetch(flow t cs fetch(flow t *flow, *flow, hpoint t hpoint t *pt) *pt) {{ send point(sockfd, send point(sockfd, pt); pt); flow- type flow- type WAIT; WAIT; }} code ready(flow t code ready(flow t *flow, *flow, hpoint t hpoint t *pt list[]) *pt list[]) {{ recv completed id(sockfd, recv completed id(sockfd, id); id); flow- point flow- point find point in list(pt list, find point in list(pt list, id); id); flow- type flow- type ACCEPT; ACCEPT; 14 }}

Plug-in Example: Constraints Support for non-rectangular parameter spaces. o Implemented as plug-in #2 using REJECT workflow. 𝑦 3 2 1 Search Strategy 𝑥 15

Plug-in Example: TAUdb Integration with TAU via TAUdb. o Tuning and Analysis Utilities Search data stored in persistent database Adds parameter analysis to any tuning session. Can potentially be used as result cache 16

Specifying Plug-ins Pluggable modules read from configuration o Unstructured key/value pair system queried at launch cat cat harmony.cfg harmony.cfg SESSION STRATEGY pro.so SESSION STRATEGY pro.so SESSION PLUGIN LIST logger.so:taudb.so SESSION PLUGIN LIST logger.so:taudb.so Directly from the command-line o o Tuna to accept in-line configuration directives Syntax to be determined 17

Availability Current release is Active Harmony 4.0 o Includes Tuna and preliminary plug-in interface Upcoming release to include o o o Improved plug-in interface Library of basic strategies and plug-ins No more Tcl code! 18

Summary and Next Steps Generalized auto-tuning framework presented o o Variety of systems possible with minimal coding Functionality encapsulated to simplify development Next steps o Develop library of search strategies and plug-ins o o o Hierarchical search? We could use your help! Investigation of further abstractions o Parameter spaces 19