OCR Introspection EDT Characterization & Profiling Infrastructure Intel TG Team

Overview Background Approach Current Methodology Initial Results Implementation & Interfaces Next Steps

Background Can we benefit from any ‘predictable behavior’ of EDTs ? –Code or data placement choices based on EDTs’ resource requirements –Programmer productivity tool (datablock partitioning, EDT functionality) Characterizing EDT behavior Exploiting this information at runtime

Approach Express EDT metrics as a function of size of data operated upon by EDT Use the above function at runtime to quickly estimate EDT’s resource requirements

Current Methodology Several simplifying assumptions –EDT behavior is consistent –Metrics can be expressed as polynomials –Sum of sizes of datablocks used as a proxy for size of data operated upon by EDT OCR App Raw EDT Metrics -Instruction Count -Floating Point Ops -Reads & Writes - Datablock sizes EDT Metrics Represented as polynomial function on sum of sizes of all datablocks used by an EDT Profiling header “edt1”, {polynomial coeffs}, “edt2”, {polynomial coeffs}, “edt3”, {polynomial coeffs}, Runtime Can use the projections to inform its heuristics LLVM Pass, Statistics Summarize, Best-fit Generate header Rebuild #include struct _profileStruct gProfilingTable[] = { {"mainEdt", 1, 1, 1, 1, 0.0, 0.0, 0.0, 0.0, (double []){229,}, (double []){16,}, (double []){2068,}, (double []){2632,}, 0, }, {"node_110_body", 2, 2, 2, 2, 0.0, 0.0, 0.0, 0.0, (double []){77620,25,}, (double []){0,0,}, (double []){14052,0,}, (double []){13432,1,}, 0, }, {"node_210_body", 2, 2, 3, 2, 0.0, 0.0, 0.0, 0.0, (double []){63115,0,}, (double []){0,0,}, (double []){ , , e-05,}, (double []){28000, e-12,}, 0, }, {"node_220_body", 3, 3, 4, 2, 0.0, 0.0, 0.0, 0.0, (double []){113716, , e-07,}, (double []){ , , e-08,}, (double []){ , , e- 07, e-12,}, (double []){ , ,}, 0, }, }; OCR: LLVM Pass, Statistics credit: Romain Cledat FP Ops = y = 0.33x^ x , x = sum(size_of(DB[i]))

Initial Results OCR Apps credit: Chih-Chieh Yang, Adam Smith (NAS), Roger Golliver (LULESH), Jamie Arteaga (SCF) Two phases Three modes

Implementation & Interfaces Profiling –On x86, LLVM-pass + OCR statistics hooks added by Romain –On FSim, hardware counters Data analysis –Offline tools for summarizing & best fit –Making them online will add to runtime overhead (how much?) Projections –Optional “profile.h” #include’d by OCR app Lists function name corresponding to each EDT with the polynomial coefficients of its metrics –Runtime picks it up during template creation –Runtime can use them when EDT is ready to run

Next Steps Cleanup the post-processing tools & integrate with OCR Using the projections –Code/data placement decisions –Reacting to temperature, failures Better projections –Polynomial functions not always accurate –Datablock reads vs. writes & stack accesses –Quantifying other metrics