1 / 24

The Best of Both Worlds: Collaborating between Industry and Academia

The Best of Both Worlds: Collaborating between Industry and Academia. Kim Hazelwood May 10, 2007. About Me. “Seven of Nine” Virginia, Florida , South Carolina, North Carolina, California, Massachusetts, New York Met Matt Cettei in 1998, married in 2001

alice-rivas
Download Presentation

The Best of Both Worlds: Collaborating between Industry and Academia

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Best of Both Worlds: Collaborating between Industry and Academia Kim Hazelwood May 10, 2007

  2. About Me • “Seven of Nine” • Virginia, Florida, South Carolina, North Carolina, California, Massachusetts, New York • Met Matt Cettei in 1998, married in 2001 • Ph.D. from Harvard in 2004 (under Mike Smith) • Started at UVa in 2005 (after Intel post-doc) • Other interests • Marathons (and other extreme sports) • Reality television • Travel

  3. Why Build New Infrastructure? • You almost never have the infrastructure you need to do your research • Not enough detail or wrong abstraction level • Wrong platform (ISA, OS) • Robustness issues (“We do not include eon because our infrastructure couldn’t execute it”) • Proprietary • Your options • Build your own • Extend an existing system • Spend a summer in industry and use their proprietary system (pray for a SC agreement)

  4. 1) Building Your Own Infrastructure • Benefits: • Huge potential payoff if your infrastructure fills a much-needed void (e.g., David Brooks--Wattch) • You’re in control • Drawbacks: • Could be 2-4 year investment • A lot of time handling uninteresting corner cases • 2-4 year delay in investigating your real ideas • Often tempts us to hoard our infrastructure (Resist!) • Supporting users • Most are lazy, cryptic, and just plain mean • “Can you tell me how to use your system?” • “When do you plan to fix the eon bug?” • “When will you port this to PowerPC?” • Unwilling to help you extend/modernize your system (even if open source) Example: Wattch

  5. 2) Extending Existing Infrastructure • Level of pain depends on the base infrastructure • Possible outcomes: • Quick way to explore your real ideas • Infrastructure could have very steep learning curve • Could get bogged down fixing bugs • Notes: • Won’t make you (as) famous • Don’t expect it to be bug free • Don’t expect it to be well documented • Don’t expect much help from the original author (see previous slide) • Reputation will also be tied to the base system

  6. 3) Use Proprietary Infrastructure • Spend a summer/semester/year in industry • Benefits • Tools are already robust, validated • Drawbacks • Often have steep learning curve • Others have to “trust” your results • Tools could disappear at any time • Hope for a source agreement, but have a solid Plan B

  7. What’s In This For Industry? • A long-term investment (in you) • You will be up to speed on their tools • You will be pre-screened • You will remember that company when you (or your students) graduate • Some short-term benefits • Free promotion of their tools/products/company • Publications • Note: Research groups are more likely to “invest”

  8. A Great Example: Intel and {UVa, …} • Pin Dynamic Instrumentation System • Allows user-defined code to be injected into a running program • Why? You name it! Profiling, bug detection, security, reliability, optimization, translation, … Application Plug-In Transform Profile Code Cache Execute

  9. Dynamic Instrumentation Demo • Pin • Four architectures – IA-32, Intel64, IA-64, XScale • Four OSes – Linux, FreeBSD, MacOS, Windows • http://rogue.colorado.edu/pin/

  10. The Reality • A long and winding quest for the “perfect” thesis infrastructure • My Story …

  11. My Experience • 1999 – CarbonFIRE – Dynamic optimization for IA-64 CarbonFIRE is proprietary This is cool! I want to do research on dynamic optimizations HP We don’t have IA-64 machines Me Advisor

  12. To Build or Not to Build? Building a dynamic optimizer will take too long I should chat with the Dynamo team

  13. Take Two: Dynamo • 2000 – HP Labs Porting Dynamo to IA32 HP Labs We’re initiating the process of university licensing Dynamo-x86 runs Hello World! You can’t publish with Hello World Advisor

  14. Take Three: DELI • 2001 – HP Labs - Implementing Dynamic Optimizations in DELI HP Labs Still working on that university license Things get interesting for embedded systems We don’t have any LX hardware Advisor

  15. 2001 – An Interesting Year • And then… • HP Labs Cambridge – Closes • Dynamo and DELI projects – Cancelled • Vas and Evelyn – Moved to IBM Please sign this source code agreement MIT Legal SURE! HP Legal NEVAH! Harvard Legal

  16. Take Four: Jikes RVM • 2002 – IBM Research and Jikes RVM – Online Inlining IBM Jikes RVM is open source! Online inlining is great! But I have more ideas for traces and efficient code caches What infrastructure do you want to use?

  17. Take Five: DynamoRIO • 2003 – The DynamoRIO collaboration (between HP Labs and MIT) Please sign this source code agreement SURE! MIT Legal NEVAH! Me HP Legal Harvard Legal

  18. Our Solution? • Kim becomes a “visiting scholar” at MIT Kendall/MIT Harvard Central Porter

  19. 2003 – More Interesting Events • Saman and Derek form Determina • Determina buys DynamoRIO source • This (and next year’s 10-year HS reunion) prompts my mad rush to finish my dissertation ?

  20. Finished! • May 2004 • Code Cache Management in Dynamic Optimization Systems • Oops … Matt still has a year in his MBA program

  21. And Then Finally: Pin is Created! • 2004 – Post-Doc with Intel Pin team • My assignment – Pin (anything) • My selections • Design the code cache algorithms • Add a code cache API • Explore embedded implementation (XScale) • Work on multithreading issues • Help develop SuperPin • Public relations – tutorials, talks, promotional tour

  22. Academic Research • 2005 – Joined UVa – Pin source code agreement • Started exploring applications of Pin • Collaborative HW/SW designs • Tortola project: ISA virtualization • Hardware and OS support for Pin et al. • Multicore scheduling • Power optimizations – di/dt • VEEs for embedded systems • Continued researching internal design decisions • Code caches • Self-modifying code • Indirect branches

  23. Advice • Be sure to balance development with research • Publish along the way • Don’t reinvent the wheel • If what you need already exists, use it! If not… Share your infrastructure • No need to be competitive or territorial • BUT … your own research should take precedent over tech support • Set up a mailing list so that your users can help each other • The Jikes RVM 48-hour rule

  24. The Best of Both Worlds: Collaborating between Industry and Academia Kim Hazelwood May 10, 2007

More Related