improving programs through source code transformations
play

IMPROVING PROGRAMS THROUGH SOURCE CODE TRANSFORMATIONS - PowerPoint PPT Presentation

IMPROVING PROGRAMS THROUGH SOURCE CODE TRANSFORMATIONS Disserta(on Proposal Jonathan Dorn April 19, 2016 Beyond Functional Correctness So9ware development


  1. IMPROVING ¡PROGRAMS ¡ THROUGH ¡SOURCE ¡CODE ¡ TRANSFORMATIONS ¡ Disserta(on ¡Proposal ¡ Jonathan ¡Dorn ¡ April ¡19, ¡2016 ¡

  2. Beyond ¡Functional ¡Correctness ¡ • So9ware ¡development ¡involves ¡ tradeoffs . ¡ • “Fast, ¡good, ¡or ¡cheap. ¡Pick ¡any ¡two.” ¡ • Time ¡vs. ¡memory. ¡ • Maintainability ¡vs. ¡efficiency. ¡ • … ¡ 2 ¡

  3. 3 ¡

  4. 4 ¡

  5. 5 ¡

  6. 6 ¡

  7. Non-­‑Functional ¡Properties ¡ • “ How ¡good ” ¡instead ¡of ¡“ what ” ¡[Paech ¡2004]. ¡ • “More” ¡or ¡“less;” ¡“higher” ¡or ¡“lower.” ¡ • Difficult ¡to ¡reason ¡about ¡(e.g., ¡security). ¡ • Characterize ¡implementa(ons ¡by ¡how ¡much ¡of ¡ a ¡property ¡they ¡possess. ¡ 7 ¡

  8. Non-­‑Functional ¡Tradeoffs ¡ Visual ¡Error ¡ Run3me ¡ 8 ¡

  9. Non-­‑Functional ¡Tradeoffs ¡ Visual ¡Error ¡ Run3me ¡ 9 ¡

  10. Quantifying ¡Non-­‑Functionality ¡ • Different ¡metrics ¡for ¡different ¡proper(es. ¡ • Image ¡quality : ¡RGB ¡distance ¡(e.g., ¡L 2 ), ¡SSIM, ¡EMD. ¡ • Run3me : ¡seconds, ¡speedup/slowdown. ¡ • Energy ¡efficiency : ¡joules, ¡wa_s. ¡ • Maintainability : ¡bug ¡fix ¡(me, ¡defect ¡density. ¡ • Correctness : ¡% ¡error, ¡accuracy, ¡precision, ¡PSNR. ¡ 10 ¡

  11. Local ¡Changes ¡ • Small ¡changes ¡can ¡have ¡ large ¡effects. ¡ • E.g., ¡ bubble_sort(a) ¡ à ¡ quick_sort(a) . ¡ • Op(on ¡of ¡ fine-­‑grained ¡control. ¡ • Program ¡lines, ¡statements, ¡AST ¡nodes. ¡ 11 ¡

  12. Proposal ¡Thesis ¡ By ¡applying ¡ local ¡so6ware ¡transforma8ons , ¡we ¡ can ¡select ¡be_er ¡tradeoffs ¡between ¡ non-­‑ func8onal ¡proper8es ¡ of ¡exis(ng ¡so9ware ¡ ar(facts. ¡ 12 ¡

  13. The ¡rest ¡of ¡this ¡proposal ¡ • Overview ¡of ¡the ¡proposed ¡research ¡thrusts ¡ • Visual ¡error ¡and ¡run(me ¡performance ¡ • Energy ¡usage ¡ • Coding ¡style ¡ • Proposed ¡research ¡(meline ¡ • Conclusion ¡ 13 ¡

  14. The ¡rest ¡of ¡this ¡proposal ¡ • Overview ¡of ¡the ¡proposed ¡research ¡thrusts ¡ • Visual ¡error ¡and ¡run(me ¡performance ¡ • Energy ¡usage ¡ • Coding ¡style ¡ • Proposed ¡research ¡(meline ¡ • Conclusion ¡ 14 ¡

  15. Computer ¡Generated ¡Imagery ¡ • 11% ¡of ¡all ¡(ckets ¡in ¡2015 ¡ went ¡to ¡computer ¡ animated ¡movies.* ¡ • Does ¡not ¡include ¡live ¡ movies ¡with ¡CGI. ¡ • Video ¡games ¡topped ¡ $90B ¡in ¡2015.** ¡ ¡* ¡h_p://www.boxofficemojo.com/ ¡ ¡** ¡h_p://www.gamesindustry.biz/ar(cles/2015-­‑04-­‑22-­‑gaming-­‑will-­‑hit-­‑usd91-­‑5-­‑billion-­‑this-­‑year-­‑newzoo ¡ 15 ¡

  16. Visual ¡Error ¡and ¡Runtime ¡Performance ¡ Visual ¡Error ¡ Original ¡Program ¡ Desired ¡Program ¡ Exis(ng ¡Technique ¡ Run3me ¡ 16 ¡

  17. Hypothesis ¡ • We ¡can ¡apply ¡local ¡changes ¡to ¡the ¡abstract ¡ syntax ¡tree ¡of ¡a ¡graphics ¡program ¡to ¡produce ¡ an ¡approxima(on ¡that ¡is: ¡ • Visually ¡faithful ¡ to ¡the ¡original ¡and ¡ • Efficient ¡to ¡compute. ¡ • Evaluate ¡both ¡image ¡quality ¡and ¡run(me. ¡ 17 ¡

  18. Simple ¡Example ¡ return (color) - floor floor + p.x p.x 0.5 18 ¡

  19. Simple ¡Example ¡ return (color) - floor floor + p.x p.x 0.5 19 ¡

  20. Simple ¡Example ¡ Before ¡ A9er ¡ return (color) - floor floor + p.x p.x 0.5 20 ¡

  21. Approach ¡ • Transforma(on: ¡Replace ¡node ¡N ¡with ¡N’. ¡ • Determine ¡replacements ¡offline ¡(manual). ¡ • Gene(c ¡search ¡to ¡select ¡nodes ¡to ¡replace. ¡ • Use ¡image ¡quality ¡as ¡fitness ¡func(on. ¡ 21 ¡

  22. Experimental ¡Setup ¡ • Benchmarks ¡chosen ¡from ¡previous ¡work. ¡ • Record ¡ run8me ¡and ¡ image ¡quality . ¡ • Three ¡data ¡points ¡for ¡each ¡benchmark: ¡ 1. Original ¡program. ¡ 2. Baseline ¡“slower ¡but ¡less ¡error” ¡approach. ¡ 3. Best ¡transformed ¡variant ¡from ¡our ¡search. ¡ 22 ¡

  23. Runtime ¡Results ¡ Baseline ¡ Our ¡Approach ¡ 20 ¡ Normalized ¡Run3me ¡ 15 ¡ 10 ¡ 5 ¡ 0 ¡ 23 ¡

  24. Image ¡Quality ¡Results ¡ Baseline ¡ Our ¡Approach ¡ 1 ¡ Normalized ¡Error ¡ 0.5 ¡ 0 ¡ 24 ¡

  25. Summary ¡ • We ¡can ¡apply ¡local ¡changes ¡to ¡produce ¡ programs ¡that: ¡ • Are ¡significantly ¡ faster ¡than ¡the ¡baseline ¡approach, ¡ • Have ¡ less ¡error ¡ than ¡the ¡original ¡program, ¡and ¡ • O9en ¡have ¡ less ¡error ¡ than ¡the ¡baseline. ¡ 25 ¡

  26. Outline ¡ • Overview ¡of ¡the ¡proposed ¡research ¡thrusts ¡ • Visual ¡error ¡and ¡run(me ¡performance ¡ • Energy ¡usage ¡ • Coding ¡style ¡ • Proposed ¡research ¡(meline ¡ • Conclusion ¡ 26 ¡

  27. Data ¡Center ¡Energy ¡Use ¡ 100 ¡ Percentages ¡of ¡ 2.0% ¡ 80 ¡ (billion ¡kWh/year) ¡ Infrastructure ¡ US ¡electricity ¡use ¡ Electricity ¡Use ¡ in ¡a ¡given ¡year ¡ 1.5% ¡ Communica(ons ¡ 60 ¡ Storage ¡ 40 ¡ High-­‑end ¡servers ¡ 0.8% ¡ Mid-­‑range ¡servers ¡ 20 ¡ Volume ¡servers ¡ 0 ¡ 2000 ¡ 2005 ¡ 2010 ¡ Reproduced ¡from ¡J. ¡Koomey. ¡ Growth ¡in ¡data ¡center ¡electricity ¡use ¡2005 ¡to ¡2010 . ¡ Analy(cs ¡Press, ¡Oakland, ¡CA, ¡2011. ¡ ¡ 27 ¡

  28. Genetic ¡Optimization ¡Algorithm ¡ blackscholes ¡ • Local ¡changes ¡to ¡ bodytrack ¡ ferret ¡ assembly ¡code. ¡ fluidanimate ¡ freqmine ¡ • Tradeoff ¡between ¡ swap(ons ¡ reduced ¡energy ¡ and ¡ vips ¡ x264 ¡ relaxed ¡seman8cs . ¡ average ¡ • Validated ¡with ¡test ¡suite. ¡ 0 ¡ 25 ¡ 50 ¡ 75 ¡ 100 ¡ Energy ¡Reduc3on ¡(%) ¡ 28 ¡

  29. Genetic ¡Optimization ¡Algorithm ¡ blackscholes ¡ • Local ¡changes ¡to ¡ bodytrack ¡ ferret ¡ assembly ¡code. ¡ fluidanimate ¡ freqmine ¡ • Tradeoff ¡between ¡ swap(ons ¡ reduced ¡energy ¡ and ¡ vips ¡ x264 ¡ relaxed ¡seman8cs . ¡ average ¡ • Validated ¡with ¡test ¡suite. ¡ 0 ¡ 25 ¡ 50 ¡ 75 ¡ 100 ¡ Energy ¡Reduc3on ¡(%) ¡ 29 ¡

  30. Scaling ¡to ¡Larger ¡Programs ¡ 100 ¡ Energy ¡Reduc3on ¡(%) ¡ 80 ¡ 60 ¡ 40 ¡ 20 ¡ 0 ¡ 0 ¡ 200000 ¡ 400000 ¡ 600000 ¡ 800000 ¡ 1000000 ¡ Lines ¡of ¡Code ¡(Assembly) ¡ 30 ¡

  31. Hypothesis ¡ By ¡direc(ng ¡the ¡gene(c ¡search ¡more ¡effec(vely ¡ and ¡ reducing ¡the ¡search ¡space, ¡we ¡can ¡achieve ¡ larger ¡energy ¡op(miza(ons ¡ faster . ¡ Evaluate ¡both ¡magnitude ¡of ¡op(miza(on ¡and ¡ search ¡(me. ¡ 31 ¡

  32. Intuition ¡ • Op(miza(ons ¡on ¡different ¡paths ¡through ¡the ¡ program ¡are ¡likely ¡to ¡be ¡independent. ¡ • Combine ¡ op(miza(ons ¡from ¡separate ¡searches. ¡ • Op(miza(ons ¡on ¡frequently ¡executed ¡paths ¡ are ¡likely ¡to ¡have ¡larger ¡impact. ¡ • Profile ¡the ¡program ¡to ¡target ¡hot ¡paths. ¡ 32 ¡

  33. Algorithm ¡Overview ¡ E VALUATE ¡F ITNESS ¡ I NPUT ¡ Eject ¡ Report ¡ O UTPUT ¡ M UTATE ¡ 33 ¡

  34. Optimizing ¡Two ¡Workloads ¡ E VALUATE ¡F ITNESS ¡ E VALUATE ¡F ITNESS ¡ I NPUT ¡ I NPUT ¡ Eject ¡ Eject ¡ Report ¡ Report ¡ O UTPUT ¡ O UTPUT ¡ M UTATE ¡ M UTATE ¡ 34 ¡

  35. Option ¡1: ¡Share ¡Variants ¡During ¡Search ¡ E VALUATE ¡F ITNESS ¡ E VALUATE ¡F ITNESS ¡ I NPUT ¡ I NPUT ¡ Eject ¡ Eject ¡ Report ¡ Report ¡ O UTPUT ¡ O UTPUT ¡ M UTATE ¡ M UTATE ¡ 35 ¡

  36. Option ¡2: ¡Combine ¡Best ¡After ¡Search ¡ E VALUATE ¡F ITNESS ¡ E VALUATE ¡F ITNESS ¡ I NPUT ¡ I NPUT ¡ Eject ¡ Eject ¡ Report ¡ Report ¡ O UTPUT ¡ O UTPUT ¡ M UTATE ¡ M UTATE ¡ 36 ¡

  37. Experimental ¡Setup ¡ Benchmarks ¡ Baseline: ¡GOA ¡search ¡ • Collect ¡HPC ¡and ¡data ¡ 1. Only ¡one ¡workload. ¡ center ¡benchmarks. ¡ 2. All ¡workloads ¡in ¡single ¡ • Collect ¡mul(ple ¡ fitness ¡func(on. ¡ workloads ¡for ¡each ¡ benchmark. ¡ 37 ¡

Recommend


More recommend