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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
CS 194 Research Proposal Exploring Latency Constraints of Co-Processing Boards Grant Jenks UCLA
Outline • Problem • Approach • Methodology • Summary
Problem • Description • Little research has considered what a general co-processing board with its own memory may be able to do. • Many questions regarding the latency tolerance of classes of programs have yet to be answered.
Problem Continued • Importance • A lot of aging hardware does not allow for upgrading to a multiprocessor machine. • Research answers fundamental questions about the capacity for co-processing within a computer. • Research explores the OS interaction with co-processing boards that contain their own processors and memories.
Problem Continued • Challenges • Precisely analyzing the tolerance of latencies between the main board and a co-processing board. • Accurately identifying and testing the future demands on computers with co-processing boards.
Approach • Previous Work • Chris J. Thompson, Sangyun Hahn, and Mark Oskin. Using Modern Graphics Architectures for General-Purpose Computing: A Framework and Analysis International Symposium on Microarchitecture (MICRO), Turkey, Nov. 2002 • AGEIA PhysX PCI Card • Designed to enhance game realism. • Currently supported by only a handful of games. • Highly optimized for relevant physics calculations.
Approach Continued • My Research • Further previous work in a generalized setting. • Analysis • As the latencies between processors and memories are increased within a computer, what effects does this have on different classes of programs? • Synthesis • Based on the analysis, could a board be implemented which would assist the computer according to the analysis? • Generalized approach not yet investigated.
Methodology • Plan of Attack • Finish the analysis by checkpoint. • Implement a synthesized solution based on analysis by end of project.
Methodology Continued • Analysis Goals • 4th Week: Setup simulation environment and develop application classes. • 5th-10th Week: Test each application class against specific latency constraints. • Each week will test a different level of latency constraints. • Data collected will be categorized and charted.
Methodology Continued • Synthesis Goals • Determine the “sweet spot” from the analysis for hardware constraints. • Results of analysis lead in many directions. • Case 1: Current hardware supports needs. • Develop practical implementation of problem on existing hardware. • Test implementation and compare with simulated analysis. • Case 2: Current hardware is too specialized. • Attempt to develop implementation of problem on FPGA board. • Test FPGA design and compare with analysis. • Case 3: No hardware meets requirements. • Further explore why no current hardware meets requirements. • Detail what would need to happen in order for a general co-processing board to be feasible.
Summary • Problem • Tolerable latencies for applications are unknown for general co-processing boards. • Approach • Simulate the generalized co-processor at different latencies and with different applications and attempt to synthesize a testable implementation. • Methodology • Analyze then synthesize. • Questions