190 likes | 308 Vues
In the evolving landscape of computer architecture, it's crucial to debunk misconceptions about what computer architects really do. Rather than merely designing instruction sets and microarchitectures, architects must adapt to a dynamic environment where their role encompasses broader system design responsibilities. Modern challenges include power constraints, reliability, and the increasing complexity of systems serving billions of users. This presentation underscores the importance of innovation, addressing real-world problems, and the future direction of computer architecture amidst rapidly changing technological demands.
E N D
“Or should.” What Computer Architects Really Do Bob Colwell E-M Talk ISCA ‘05
But First, I’d Like to Thank • Ron Hoelzeman (Pitt), Doug Jensen, Dan Siewiorek (CMU), George Cox, Kevin Kahn • Paul Rodman, Dave Papworth, Rich Lethin, Josh Fisher & amazing Multiflow team • Incredible P6 team, esp. Randy Steck, Glenn Hinton, Mike Fetterman, Andy Glew, Dave Papworth, Gurbir Singh • My parents, Ellen, Kelly, Ken, Kristen • Joe Malingowski • Yale Patt, Wen-mei Hwu, Guri Sohi, Tom Conte, Computer Arch community
A Misconception About What Computer Architects Do EE Times May 23, 2005 “Is the day of the architect over?” “Microprocessor architects managed to re-create almost the whole history of the mainframe computer industry…they used all the tricks, from microprogramming and stripped-down pipelines with load-store architectures to speculative execution and branch prediction. Best of all, hardly anyone was unkind enough to comment that all this ground had been covered already, just at a lesser level of integration.”
What would we have done… Had we been born 300 years ago Same IQ’s but no computers, no electronics Power source = waterwheels and oxen Same brains as today but different challenges Likewise with computer pioneers Issue isn’t “why were they so innovative & why aren’t we” They did what we do: whatever is necessary • Those things change over time
Intellectual Giant Theory Intellectual giants did walk the earth in the ’60’s • Eckert, Mauchly, von N, Conway, Cocke, Brooks, Flynn, Tomasulo… • we should honor pioneering contributions • but today’s designers are not leeches living off that legacy Intellectual giants did walk the earth in the ’60’s. They still do.
system CPU CPU-Mesmerization. Root cause? Profits. Design today: more complex 1960’s complexity • Poor tools, interaction of electronics, packaging & ISA Today’s complexity • Today’s complexity from speed, hyper-aggressive uArch’s, power limits, SW compatibility, number of usage models, CPU-Mesmerization
CPU architect IA32+64-bit exts IA32 64-bit extensions to IA32
Multicore $100B industry Compilers Apps Multicore Vendors
Design today: scarier • No-recalls much harder than design-for-minimal-field-service • Pioneers designed for 1,000 users • Design errors? Charge ‘em for service calls • Today we design for 1,000,000,000 users • Design errors? Pray…
What architects really do • Insidious error: thinking architects design instruction sets & uArch mechanisms • We have, and do, but that misses the point • Architects start out as generals, moonlight as Special Forces • Range freely, identify needs, apply appropriate force • Ensure that biggest risks are attacked first • Make sure project goals are clear & focussed • Seek odd viewing angles to drive out problems • Supply judgment calls where data is lacking • And judgment as to when data should be collected
CPU architects must evolve into system designers Recent arch history • For past two decades an architect’s point of highest leverage has been microarchitecture • Re-use what works • Pipelining, caches, shared buses, superscalar • Invent where necessary • Microdataflow/OOO, trace caches, speculative branch predictors, cache coherency • With some major ISA work on RISCs • But this is changing. Right now.
System Designers todo list “Whatever needs doing” has become… • Products, not CPUs • Power-constrained system design • Multicore (gotta pay the bills, too) • Reliable systems from unreliable components No longer “what I’d like to sell you” but designing what buyers want
$$$ 2004 “killer products” “killer apps” + PC’s iPOD desired delivered Time “PC era” Ubiq. comp. Products Not CPUs Cell phones Ray tracing Portable computing “Speed at any price” “What’s in it for me?” -buyer
Power-constrained design • “fast as possible at max power” will yield to “fast enough, no faster” • Lesson from the embedded space • Thermal variability vs. guaranteed real-time • Throw in wireless links for good measure • Battery life, not just cooling cost • Global warming, energy crisis looms • It ain’t just cars and oil prices • Be synchronized to public taste or lose
Multicore • “Here I come, ready or not…” • We can build ‘em. Can we… • Compile to them? • Feed them? (bandwidth) • Cool them? (power) • Write apps for them? • Clear and present challenge • There are pots of gold associated w/ this
Reliable Systems from Unreliable Components • N-mod redundancy too expensive • Transient errors, manufacturing defects, design errors • Must survive them all • Solution can’t drive power up • Still want guaranteed performance for real-time • Intel’s Shekhar Borkar says we have at most 10 years to figure this out
Adjurations • Computer revolution is only getting started • Role of architects is changing • If we don’t do it who will? • Your grandchildren will thank you • And wonder if they’re as smart as you were