60 likes | 188 Views
Implications of Emerging Hardware. Tom Wenisch (University of Michigan) Nikos Hardavellas (Northwestern University) Sangyeun Cho (University of Pittsburgh) Kirk Pruhs (University of Pittsburgh) Phillip Gibbons (Intel Labs) Stavros Harizopoulos (HP Labs)
E N D
Implications of Emerging Hardware Tom Wenisch (University of Michigan) Nikos Hardavellas (Northwestern University) Sangyeun Cho (University of Pittsburgh) Kirk Pruhs (University of Pittsburgh) Phillip Gibbons (Intel Labs) Stavros Harizopoulos (HP Labs) Spiros Papadimitriou (Google Research) Ashwin Kumar Kayyoor (University of Maryland) Xiaorui Wang (University of Tennessee)
Emerging Memory Technologies • Observation • Existing buffer pool and storage mgmt optimized for slow disk / volatile DRAM • Emerging memories change power/energy/reliability trade-offs • e.g., access latency, energy per access, access granularity, wearout, non-volatility • Action: Rethink data management to exploit these devices • e.g., new index structures (access granularity) • e.g., new recovery mechanisms (non-volatility) • e.g., jointly optimize for energy & performance (energy/access) • e.g., new query processing strategies (access latency)
Data Placement • Observation: “Not all memory addresses are created equal” • Memory/storage is major/growing piece of power breakdown • Devices and power modes create heterogeneity • Power management is exposed to software • However, current practice is oblivious to hardware power knobs • Where data is placed within and across nodes impacts efficiency • Action: Proactively place data to optimize for energy • e.g., consider moving computation to the data • e.g., cluster data with similar locality to enable power down • e.g., consider trading compute for storage (compression)
Specialization • Observation • Hardware specialization provides greatest leverage for efficiency • Hardware is moving towards specialization • In the chip (dark silicon) • In the system (e.g., GPUs) • In the cluster (e.g., wimpy nodes) • More examples: mobile CPUs, embedded cores, GPUs, SIMD engines, vector units, reconfigurable hardware, wimpy nodes, etc. • Action: Software should influence how hardware specializes • Identify important specializations (in particular for energy) • Action: Software should embrace specialized hardware • Devise techniques to map/migrate/schedule tasks at correct grain
QoS Resiliency • Observation • Data processing tasks have variable QoS demands • with respect to latency / throughput • with respect to data quality • Hardware knobs can trade QoS for energy efficiency • However, these knobs are susceptible to QoS and efficiency cliffs • Action: Carefully trade QoS for energy • Need to design interfaces to express QoS objectives • Optimizers must tune HW knobs to lowest power that meets QoS • However, algorithms must provide robust QoS in the face of unexpectedly & rapidly changing demand
Energy-Constrained Data Mgmt • Observation • Proliferation of high-capability energy-constrained devices (smart phones) • Local computation & communication cost energy • Action: Find energy-minimal client + cloud solutions • Partition data storage & processing between “client” and “cloud”