1 / 6

Saving Power through Explicit Mechanisms

Explore how to build a machine that balances adequate performance and low power mode through switching functional units as needed. Learn about optimizing cache usage, speculative issue logic, and compiler decisions for efficient results. Follow an execution plan involving testing, refining, and automating optimizations using tools like SyCHOSis and MIPS ISA simulator.

dukesm
Download Presentation

Saving Power through Explicit Mechanisms

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. Saving Power through Explicit Mechanisms Dave Maze, Edwin Olson 6.893, Fall 2000

  2. The Power/Performance Dilemma • Mainstream architectures focusing on high performance • Some applications require low power • Usage patterns of some devices call for short periods of high performance and long periods of low-power performance.

  3. Our Solution • Build a machine which can yield adequate performance, but can switch to a low power mode. • Turn functional units and capabilities on or off depending on performance/power needs. • Have the compiler make as many decisions as possible (minimize hardware profiling required) • Explicit instructions for coarse granularity, extra bits in instructions for fine granularity.

  4. Areas that can be optimized • Turn off sections of cache to reflect size of “working set” • Put functional units into a “coma” mode • Turn on/off out-of-order/speculative issue logic (resulting in an in-order microprocessor)

  5. Things to worry about… • Existing work exists. Try not to duplicate. Try to do something novel. • Code density – perhaps we’ll ignore code density for this phase of research. • Compiler hacking – perhaps we can sidestep the issue by doing some assembly hacking to get approximate results.

  6. Execution Plan • Begin by testing ideas/profiling benchmarks to determine effectiveness of particular ideas. • Select an idea, hack together an approach, and measure results. (Checkpoint 1, Oct. 19) • Refine, extend, automate optimization (Checkpoint 2, Nov. 9) • Tools: SyCHOSis, MIPS ISA simulator

More Related