SlideShare uma empresa Scribd logo
1 de 17
Baixar para ler offline
Brought to you by
Rust, Wright's Law, and the
Future of Low-Latency
Systems
Bryan Cantrill
CTO, Oxide Computer Company
OXIDE
The Arbiter of Systems Performance
• If it needs to be said: software must execute within the confines of
hardware — and the hardware is the ultimate arbiter of performance
• The history of improving systems performance consists broadly of:
○ Process revolutions that propelled all designs
○ Architectural revolutions that optimized for certain use cases
○ Software revolutions that allowed us to better utilize hardware
• All of these revolutions must live within the confines of economics!
OXIDE
Process Revolution: Moore’s Law
• In his 1965 paper, Gordon Moore did not actually coin a law per se —
he just a bunch of incredibly astute and prescient observations
• The term “Moore’s Law” would be coined by Carver Mead in 1971 as
part of his work on determining ultimate physical limits
• Moore updated the law in 1975 to be a doubling of transistor density
every two years (Denard scaling would be outlined in detail in 1974)
• For many years, Moore’s Law could be inferred to be doublings of
transistor density, speed, and economics
OXIDE
Moore’s Law: The Good Old Days
• The 1980s and early 1990s were great for Moore’s Law — so much so
that computers needed a “turbo button” to counteract its effects (!!)
• But even in those halcyon years, Moore’s Law was leaving DRAM
behind: memory was becoming denser but no faster
• An increasing number of workloads began hitting the memory wall
• Caching — an essential architectural revolution born in the 1960s —
was necessary but insufficient...
OXIDE
Moore’s Law: The Good Old Days?
• By the mid-1990s, it had become clear that symmetric multiprocessing
was the path to deliver throughput on multi-threaded workloads
• SMP necessitated its own software revolution (multi-threaded systems),
but did little for single-threaded latency
• Deep pipelining and VLIW were — largely — failed experiments
• For single-threaded workloads, microprocessors turned to out-of-order
and speculative execution to hide memory latency
• Even in simpler times, scaling with Moore’s Law was a challenge!
OXIDE
Moore’s Law Deceleration
• In August 2018, GlobalFoundries suddenly stopped 7nm development,
citing economics — it was simply too expensive to stay competitive
• GlobalFoundries’ departure left TSMC and Samsung on 7nm — and
Intel on 14nm, struggling to get to 10nm
• Intel’s Cannon Lake was three years late and an unmitigated disaster —
and for Ice Lake/Cascade Lake, Intel is intermixing 14nm and 10nm
• Moving to 3nm/5nm requires moving beyond FinFETs to GAAFETs —
and to EUV photolithography; new nodes are very expensive!
OXIDE
Aside: Process nodes
• You may well wonder: when a process node is “7nm” or “5nm”, what
exactly is seven nanometers or five nanometers long? (And, um, how big
is a silicon atom anyway?)
• Answer to the second question: ~210 picometers!
• Answer to the first question: nothing! Unbelievably, the name of the
process node no longer measures anything at all (!!) — it is merely a
rough expression of transistor density (and implication of process)
• E.g. 7nm ≈ 100MTr/mm2 (but there are lots of caveats)
OXIDE
The End of Moore’s Law
• Increased transistor density is continuing to be possible, but at a greatly
slowed pace — and at outsized cost
• Moore’s Law has ceased to exist as an economic law
• But is there another way of looking at it?
OXIDE
Wright’s Law
• In 1936, Theodore Wright studied the costs of aircraft manufacturing,
finding that the cost dropped with experience
• Over time, when volume doubled, unit costs dropped by 10-15%
• This phenomenon has been observed in other technological domains
• In 2013, Jessika Trancik et al. found Wright’s Law to hold better
predictive power for transistor cost than Moore’s Law!
• Wright’s Law seems to hold, especially for older process nodes
OXIDE
Wright’s Law: Ramifications
• If Wright’s Law continues to hold, compute will be economically viable in
more and more places that were previously confined to hard logic
• This is true even on die, where chiplets have made it easier than ever to
build a heterogeneous system — and where mixed process nodes have
demanded more sophistication
• Quick, how many cores are on your server? (Don’t forget the hidden
ones!)
OXIDE
Wright’s Law: Performance Ramifications
• Having more compute in many more places is particularly germane to
system performance:
○ More compute close to data (SmartNICs, open-channel SSDs,
on-spindle compute) lowers latency
○ Bringing data to special-purpose compute (GPGPUs, FPGAs)
increases throughput
• But security and multi-tenancy cannot be an afterthought!
• We need to rethink our system software
OXIDE
Aside: A Researcher’s Call to Rethink
Timothy Roscoe, OSDI 2021 Keynote, It's Time for Operating Systems to Rediscover Hardware
OXIDE
The Needed Software Revolution
• Much of the coming compute is, at some level, special purpose
• These systems are much less balanced than our general-purpose
systems — with much less memory and/or non-volatile storage
• The overhead of dynamic environments (Java, Go, Python, etc.) is
unacceptably high — and the development benefit questionable
• Languages traditional used in this domain — C and C++ — both have
well-known challenges around safety and composability
• Enter Rust, and its killer feature...
OXIDE
Rust: no_std
• Rust is a revolutionary language in many respects, but one that may be
underappreciated is its ability to not depend on its own standard library
• Much of what is valuable about the language — sum types, ownership
model, traits, hygienic macros — is in core, not the standard library
• Crates marked “no_std” will not perform any heap allocations — and
any such allocation is a compile-time error!
• But no_std crates can depend on other no_std crates — lending real
composability to a domain for whom it has been entirely deprived
OXIDE
Rust: no_std binaries
• Rust no_std binaries are stunningly small
○ E.g., at Oxide, we are developing a message-passing, memory
protected system entirely in Rust (Rust microkernel, Rust tasks);
minimal systems are 30K — and entirely realistic ones are < 200K!
• no_std is without real precedent in other languages or environments; it
allows Rust to be put in essentially arbitrarily confined contexts
• Rust is the first language since C to meaningfully exist at the boundary
of hardware and systems software!
OXIDE
Rust, Wright’s Law and the Future
• Wright’s Law will continue to hold, resulting in more compute in more
places — and this compute will be essential for systems performance
• These compute elements will be increasingly special-purpose, and are
going to require purpose-fit software
• Rust is proving to be an excellent fit for these use cases!
• We fully expect many more open source, de novo hardware-facing
Rust-based systems — and thanks to no_std they will be able to
leverage one another; the Rust revolution is here!
Brought to you by
Bryan Cantrill
bryan@oxidecomputer.com
@bcantrill

Mais conteúdo relacionado

Mais procurados

High-Performance Networking Using eBPF, XDP, and io_uring
High-Performance Networking Using eBPF, XDP, and io_uringHigh-Performance Networking Using eBPF, XDP, and io_uring
High-Performance Networking Using eBPF, XDP, and io_uring
ScyllaDB
 

Mais procurados (20)

Data Structures for High Resolution, Real-time Telemetry at Scale
Data Structures for High Resolution, Real-time Telemetry at ScaleData Structures for High Resolution, Real-time Telemetry at Scale
Data Structures for High Resolution, Real-time Telemetry at Scale
 
Understanding Apache Kafka P99 Latency at Scale
Understanding Apache Kafka P99 Latency at ScaleUnderstanding Apache Kafka P99 Latency at Scale
Understanding Apache Kafka P99 Latency at Scale
 
Scaling Apache Pulsar to 10 Petabytes/Day
Scaling Apache Pulsar to 10 Petabytes/DayScaling Apache Pulsar to 10 Petabytes/Day
Scaling Apache Pulsar to 10 Petabytes/Day
 
Let’s Fix Logging Once and for All
Let’s Fix Logging Once and for AllLet’s Fix Logging Once and for All
Let’s Fix Logging Once and for All
 
Keeping Latency Low and Throughput High with Application-level Priority Manag...
Keeping Latency Low and Throughput High with Application-level Priority Manag...Keeping Latency Low and Throughput High with Application-level Priority Manag...
Keeping Latency Low and Throughput High with Application-level Priority Manag...
 
Rust Is Safe. But Is It Fast?
Rust Is Safe. But Is It Fast?Rust Is Safe. But Is It Fast?
Rust Is Safe. But Is It Fast?
 
DB Latency Using DRAM + PMem in App Direct & Memory Modes
DB Latency Using DRAM + PMem in App Direct & Memory ModesDB Latency Using DRAM + PMem in App Direct & Memory Modes
DB Latency Using DRAM + PMem in App Direct & Memory Modes
 
Whoops! I Rewrote It in Rust
Whoops! I Rewrote It in RustWhoops! I Rewrote It in Rust
Whoops! I Rewrote It in Rust
 
High-Performance Networking Using eBPF, XDP, and io_uring
High-Performance Networking Using eBPF, XDP, and io_uringHigh-Performance Networking Using eBPF, XDP, and io_uring
High-Performance Networking Using eBPF, XDP, and io_uring
 
How to Meet Your P99 Goal While Overcommitting Another Workload
How to Meet Your P99 Goal While Overcommitting Another WorkloadHow to Meet Your P99 Goal While Overcommitting Another Workload
How to Meet Your P99 Goal While Overcommitting Another Workload
 
Get Lower Latency and Higher Throughput for Java Applications
Get Lower Latency and Higher Throughput for Java ApplicationsGet Lower Latency and Higher Throughput for Java Applications
Get Lower Latency and Higher Throughput for Java Applications
 
G1: To Infinity and Beyond
G1: To Infinity and BeyondG1: To Infinity and Beyond
G1: To Infinity and Beyond
 
Kernel Recipes 2017 - What's new in the world of storage for Linux - Jens Axboe
Kernel Recipes 2017 - What's new in the world of storage for Linux - Jens AxboeKernel Recipes 2017 - What's new in the world of storage for Linux - Jens Axboe
Kernel Recipes 2017 - What's new in the world of storage for Linux - Jens Axboe
 
Kernel Recipes 2017 - 20 years of Linux Virtual Memory - Andrea Arcangeli
Kernel Recipes 2017 - 20 years of Linux Virtual Memory - Andrea ArcangeliKernel Recipes 2017 - 20 years of Linux Virtual Memory - Andrea Arcangeli
Kernel Recipes 2017 - 20 years of Linux Virtual Memory - Andrea Arcangeli
 
Scylla Summit 2018: Rebuilding the Ceph Distributed Storage Solution with Sea...
Scylla Summit 2018: Rebuilding the Ceph Distributed Storage Solution with Sea...Scylla Summit 2018: Rebuilding the Ceph Distributed Storage Solution with Sea...
Scylla Summit 2018: Rebuilding the Ceph Distributed Storage Solution with Sea...
 
Live migrating a container: pros, cons and gotchas
Live migrating a container: pros, cons and gotchasLive migrating a container: pros, cons and gotchas
Live migrating a container: pros, cons and gotchas
 
Practical SystemTAP basics: Perl memory profiling
Practical SystemTAP basics: Perl memory profilingPractical SystemTAP basics: Perl memory profiling
Practical SystemTAP basics: Perl memory profiling
 
IITCC15: Xen Project 4.6 Update
IITCC15: Xen Project 4.6 UpdateIITCC15: Xen Project 4.6 Update
IITCC15: Xen Project 4.6 Update
 
[POSS 2019] OVirt and Ceph: Perfect Combination.?
[POSS 2019] OVirt and  Ceph: Perfect Combination.?[POSS 2019] OVirt and  Ceph: Perfect Combination.?
[POSS 2019] OVirt and Ceph: Perfect Combination.?
 
How to Measure Latency
How to Measure LatencyHow to Measure Latency
How to Measure Latency
 

Semelhante a Rust, Wright's Law, and the Future of Low-Latency Systems

Risc cisc Difference
Risc cisc DifferenceRisc cisc Difference
Risc cisc Difference
Sehrish Asif
 
UNIT-I Intorduction To Operating System.pptx
UNIT-I Intorduction To Operating System.pptxUNIT-I Intorduction To Operating System.pptx
UNIT-I Intorduction To Operating System.pptx
Piyushbodh
 
Real-Time Operating Systems Real-Time Operating Systems RTOS .ppt
Real-Time Operating Systems Real-Time Operating Systems RTOS .pptReal-Time Operating Systems Real-Time Operating Systems RTOS .ppt
Real-Time Operating Systems Real-Time Operating Systems RTOS .ppt
lematadese670
 
39245175 intro-es-ii
39245175 intro-es-ii39245175 intro-es-ii
39245175 intro-es-ii
Embeddedbvp
 

Semelhante a Rust, Wright's Law, and the Future of Low-Latency Systems (20)

The Coming Firmware Revolution
The Coming Firmware RevolutionThe Coming Firmware Revolution
The Coming Firmware Revolution
 
Hardware/software Co-design: The Coming Golden Age
Hardware/software Co-design: The Coming Golden AgeHardware/software Co-design: The Coming Golden Age
Hardware/software Co-design: The Coming Golden Age
 
No Moore Left to Give: Enterprise Computing After Moore's Law
No Moore Left to Give: Enterprise Computing After Moore's LawNo Moore Left to Give: Enterprise Computing After Moore's Law
No Moore Left to Give: Enterprise Computing After Moore's Law
 
RTOS [Autosaved].pptx
RTOS [Autosaved].pptxRTOS [Autosaved].pptx
RTOS [Autosaved].pptx
 
Introduction to Parallel Computing
Introduction to Parallel ComputingIntroduction to Parallel Computing
Introduction to Parallel Computing
 
Fundamentals.pptx
Fundamentals.pptxFundamentals.pptx
Fundamentals.pptx
 
The Internet-of-things: Architecting for the deluge of data
The Internet-of-things: Architecting for the deluge of dataThe Internet-of-things: Architecting for the deluge of data
The Internet-of-things: Architecting for the deluge of data
 
Risc cisc Difference
Risc cisc DifferenceRisc cisc Difference
Risc cisc Difference
 
UNIT-I Intorduction To Operating System.pptx
UNIT-I Intorduction To Operating System.pptxUNIT-I Intorduction To Operating System.pptx
UNIT-I Intorduction To Operating System.pptx
 
IBM and ASTRON 64bit μServer for DOME
IBM and ASTRON 64bit μServer for DOMEIBM and ASTRON 64bit μServer for DOME
IBM and ASTRON 64bit μServer for DOME
 
Real-Time Operating Systems Real-Time Operating Systems RTOS .ppt
Real-Time Operating Systems Real-Time Operating Systems RTOS .pptReal-Time Operating Systems Real-Time Operating Systems RTOS .ppt
Real-Time Operating Systems Real-Time Operating Systems RTOS .ppt
 
Long Life Software
Long Life SoftwareLong Life Software
Long Life Software
 
Everything We Learned About In-Memory Data Layout While Building VoltDB
Everything We Learned About In-Memory Data Layout While Building VoltDBEverything We Learned About In-Memory Data Layout While Building VoltDB
Everything We Learned About In-Memory Data Layout While Building VoltDB
 
Quantum Computers New Generation of Computers PART1 by Prof Lili Saghafi
Quantum Computers New Generation of Computers PART1 by Prof Lili SaghafiQuantum Computers New Generation of Computers PART1 by Prof Lili Saghafi
Quantum Computers New Generation of Computers PART1 by Prof Lili Saghafi
 
Technology trends Moore’s law
Technology trends Moore’s lawTechnology trends Moore’s law
Technology trends Moore’s law
 
39245175 intro-es-ii
39245175 intro-es-ii39245175 intro-es-ii
39245175 intro-es-ii
 
HPC Cluster Computing from 64 to 156,000 Cores 
HPC Cluster Computing from 64 to 156,000 Cores HPC Cluster Computing from 64 to 156,000 Cores 
HPC Cluster Computing from 64 to 156,000 Cores 
 
Parallel Computing - Lec 3
Parallel Computing - Lec 3Parallel Computing - Lec 3
Parallel Computing - Lec 3
 
The DIY Punk Rock DevOps Playbook
The DIY Punk Rock DevOps PlaybookThe DIY Punk Rock DevOps Playbook
The DIY Punk Rock DevOps Playbook
 
PromCon EU 2022 - Centralized vs Decentralized Prometheus Scraping Architectu...
PromCon EU 2022 - Centralized vs Decentralized Prometheus Scraping Architectu...PromCon EU 2022 - Centralized vs Decentralized Prometheus Scraping Architectu...
PromCon EU 2022 - Centralized vs Decentralized Prometheus Scraping Architectu...
 

Mais de ScyllaDB

Mais de ScyllaDB (20)

Developer Data Modeling Mistakes: From Postgres to NoSQL
Developer Data Modeling Mistakes: From Postgres to NoSQLDeveloper Data Modeling Mistakes: From Postgres to NoSQL
Developer Data Modeling Mistakes: From Postgres to NoSQL
 
What Developers Need to Unlearn for High Performance NoSQL
What Developers Need to Unlearn for High Performance NoSQLWhat Developers Need to Unlearn for High Performance NoSQL
What Developers Need to Unlearn for High Performance NoSQL
 
Low Latency at Extreme Scale: Proven Practices & Pitfalls
Low Latency at Extreme Scale: Proven Practices & PitfallsLow Latency at Extreme Scale: Proven Practices & Pitfalls
Low Latency at Extreme Scale: Proven Practices & Pitfalls
 
Dissecting Real-World Database Performance Dilemmas
Dissecting Real-World Database Performance DilemmasDissecting Real-World Database Performance Dilemmas
Dissecting Real-World Database Performance Dilemmas
 
Beyond Linear Scaling: A New Path for Performance with ScyllaDB
Beyond Linear Scaling: A New Path for Performance with ScyllaDBBeyond Linear Scaling: A New Path for Performance with ScyllaDB
Beyond Linear Scaling: A New Path for Performance with ScyllaDB
 
Dissecting Real-World Database Performance Dilemmas
Dissecting Real-World Database Performance DilemmasDissecting Real-World Database Performance Dilemmas
Dissecting Real-World Database Performance Dilemmas
 
Database Performance at Scale Masterclass: Workload Characteristics by Felipe...
Database Performance at Scale Masterclass: Workload Characteristics by Felipe...Database Performance at Scale Masterclass: Workload Characteristics by Felipe...
Database Performance at Scale Masterclass: Workload Characteristics by Felipe...
 
Database Performance at Scale Masterclass: Database Internals by Pavel Emelya...
Database Performance at Scale Masterclass: Database Internals by Pavel Emelya...Database Performance at Scale Masterclass: Database Internals by Pavel Emelya...
Database Performance at Scale Masterclass: Database Internals by Pavel Emelya...
 
Database Performance at Scale Masterclass: Driver Strategies by Piotr Sarna
Database Performance at Scale Masterclass: Driver Strategies by Piotr SarnaDatabase Performance at Scale Masterclass: Driver Strategies by Piotr Sarna
Database Performance at Scale Masterclass: Driver Strategies by Piotr Sarna
 
Replacing Your Cache with ScyllaDB
Replacing Your Cache with ScyllaDBReplacing Your Cache with ScyllaDB
Replacing Your Cache with ScyllaDB
 
Powering Real-Time Apps with ScyllaDB_ Low Latency & Linear Scalability
Powering Real-Time Apps with ScyllaDB_ Low Latency & Linear ScalabilityPowering Real-Time Apps with ScyllaDB_ Low Latency & Linear Scalability
Powering Real-Time Apps with ScyllaDB_ Low Latency & Linear Scalability
 
7 Reasons Not to Put an External Cache in Front of Your Database.pptx
7 Reasons Not to Put an External Cache in Front of Your Database.pptx7 Reasons Not to Put an External Cache in Front of Your Database.pptx
7 Reasons Not to Put an External Cache in Front of Your Database.pptx
 
Getting the most out of ScyllaDB
Getting the most out of ScyllaDBGetting the most out of ScyllaDB
Getting the most out of ScyllaDB
 
NoSQL Database Migration Masterclass - Session 2: The Anatomy of a Migration
NoSQL Database Migration Masterclass - Session 2: The Anatomy of a MigrationNoSQL Database Migration Masterclass - Session 2: The Anatomy of a Migration
NoSQL Database Migration Masterclass - Session 2: The Anatomy of a Migration
 
NoSQL Database Migration Masterclass - Session 3: Migration Logistics
NoSQL Database Migration Masterclass - Session 3: Migration LogisticsNoSQL Database Migration Masterclass - Session 3: Migration Logistics
NoSQL Database Migration Masterclass - Session 3: Migration Logistics
 
NoSQL Data Migration Masterclass - Session 1 Migration Strategies and Challenges
NoSQL Data Migration Masterclass - Session 1 Migration Strategies and ChallengesNoSQL Data Migration Masterclass - Session 1 Migration Strategies and Challenges
NoSQL Data Migration Masterclass - Session 1 Migration Strategies and Challenges
 
ScyllaDB Virtual Workshop
ScyllaDB Virtual WorkshopScyllaDB Virtual Workshop
ScyllaDB Virtual Workshop
 
DBaaS in the Real World: Risks, Rewards & Tradeoffs
DBaaS in the Real World: Risks, Rewards & TradeoffsDBaaS in the Real World: Risks, Rewards & Tradeoffs
DBaaS in the Real World: Risks, Rewards & Tradeoffs
 
Build Low-Latency Applications in Rust on ScyllaDB
Build Low-Latency Applications in Rust on ScyllaDBBuild Low-Latency Applications in Rust on ScyllaDB
Build Low-Latency Applications in Rust on ScyllaDB
 
NoSQL Data Modeling 101
NoSQL Data Modeling 101NoSQL Data Modeling 101
NoSQL Data Modeling 101
 

Último

Why Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire businessWhy Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire business
panagenda
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Safe Software
 

Último (20)

2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...
 
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
 
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemkeProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
 
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
Apidays New York 2024 - APIs in 2030: The Risk of Technological Sleepwalk by ...
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 
ICT role in 21st century education and its challenges
ICT role in 21st century education and its challengesICT role in 21st century education and its challenges
ICT role in 21st century education and its challenges
 
Exploring the Future Potential of AI-Enabled Smartphone Processors
Exploring the Future Potential of AI-Enabled Smartphone ProcessorsExploring the Future Potential of AI-Enabled Smartphone Processors
Exploring the Future Potential of AI-Enabled Smartphone Processors
 
Corporate and higher education May webinar.pptx
Corporate and higher education May webinar.pptxCorporate and higher education May webinar.pptx
Corporate and higher education May webinar.pptx
 
Axa Assurance Maroc - Insurer Innovation Award 2024
Axa Assurance Maroc - Insurer Innovation Award 2024Axa Assurance Maroc - Insurer Innovation Award 2024
Axa Assurance Maroc - Insurer Innovation Award 2024
 
Spring Boot vs Quarkus the ultimate battle - DevoxxUK
Spring Boot vs Quarkus the ultimate battle - DevoxxUKSpring Boot vs Quarkus the ultimate battle - DevoxxUK
Spring Boot vs Quarkus the ultimate battle - DevoxxUK
 
Why Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire businessWhy Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire business
 
DBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor PresentationDBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor Presentation
 
Boost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdfBoost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdf
 
CNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In PakistanCNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In Pakistan
 
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
 
Strategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a FresherStrategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a Fresher
 
DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
DEV meet-up UiPath Document Understanding May 7 2024 AmsterdamDEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
 
TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
TrustArc Webinar - Unlock the Power of AI-Driven Data DiscoveryTrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
 
[BuildWithAI] Introduction to Gemini.pdf
[BuildWithAI] Introduction to Gemini.pdf[BuildWithAI] Introduction to Gemini.pdf
[BuildWithAI] Introduction to Gemini.pdf
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 

Rust, Wright's Law, and the Future of Low-Latency Systems

  • 1. Brought to you by Rust, Wright's Law, and the Future of Low-Latency Systems Bryan Cantrill CTO, Oxide Computer Company
  • 2. OXIDE The Arbiter of Systems Performance • If it needs to be said: software must execute within the confines of hardware — and the hardware is the ultimate arbiter of performance • The history of improving systems performance consists broadly of: ○ Process revolutions that propelled all designs ○ Architectural revolutions that optimized for certain use cases ○ Software revolutions that allowed us to better utilize hardware • All of these revolutions must live within the confines of economics!
  • 3. OXIDE Process Revolution: Moore’s Law • In his 1965 paper, Gordon Moore did not actually coin a law per se — he just a bunch of incredibly astute and prescient observations • The term “Moore’s Law” would be coined by Carver Mead in 1971 as part of his work on determining ultimate physical limits • Moore updated the law in 1975 to be a doubling of transistor density every two years (Denard scaling would be outlined in detail in 1974) • For many years, Moore’s Law could be inferred to be doublings of transistor density, speed, and economics
  • 4. OXIDE Moore’s Law: The Good Old Days • The 1980s and early 1990s were great for Moore’s Law — so much so that computers needed a “turbo button” to counteract its effects (!!) • But even in those halcyon years, Moore’s Law was leaving DRAM behind: memory was becoming denser but no faster • An increasing number of workloads began hitting the memory wall • Caching — an essential architectural revolution born in the 1960s — was necessary but insufficient...
  • 5. OXIDE Moore’s Law: The Good Old Days? • By the mid-1990s, it had become clear that symmetric multiprocessing was the path to deliver throughput on multi-threaded workloads • SMP necessitated its own software revolution (multi-threaded systems), but did little for single-threaded latency • Deep pipelining and VLIW were — largely — failed experiments • For single-threaded workloads, microprocessors turned to out-of-order and speculative execution to hide memory latency • Even in simpler times, scaling with Moore’s Law was a challenge!
  • 6. OXIDE Moore’s Law Deceleration • In August 2018, GlobalFoundries suddenly stopped 7nm development, citing economics — it was simply too expensive to stay competitive • GlobalFoundries’ departure left TSMC and Samsung on 7nm — and Intel on 14nm, struggling to get to 10nm • Intel’s Cannon Lake was three years late and an unmitigated disaster — and for Ice Lake/Cascade Lake, Intel is intermixing 14nm and 10nm • Moving to 3nm/5nm requires moving beyond FinFETs to GAAFETs — and to EUV photolithography; new nodes are very expensive!
  • 7. OXIDE Aside: Process nodes • You may well wonder: when a process node is “7nm” or “5nm”, what exactly is seven nanometers or five nanometers long? (And, um, how big is a silicon atom anyway?) • Answer to the second question: ~210 picometers! • Answer to the first question: nothing! Unbelievably, the name of the process node no longer measures anything at all (!!) — it is merely a rough expression of transistor density (and implication of process) • E.g. 7nm ≈ 100MTr/mm2 (but there are lots of caveats)
  • 8. OXIDE The End of Moore’s Law • Increased transistor density is continuing to be possible, but at a greatly slowed pace — and at outsized cost • Moore’s Law has ceased to exist as an economic law • But is there another way of looking at it?
  • 9. OXIDE Wright’s Law • In 1936, Theodore Wright studied the costs of aircraft manufacturing, finding that the cost dropped with experience • Over time, when volume doubled, unit costs dropped by 10-15% • This phenomenon has been observed in other technological domains • In 2013, Jessika Trancik et al. found Wright’s Law to hold better predictive power for transistor cost than Moore’s Law! • Wright’s Law seems to hold, especially for older process nodes
  • 10. OXIDE Wright’s Law: Ramifications • If Wright’s Law continues to hold, compute will be economically viable in more and more places that were previously confined to hard logic • This is true even on die, where chiplets have made it easier than ever to build a heterogeneous system — and where mixed process nodes have demanded more sophistication • Quick, how many cores are on your server? (Don’t forget the hidden ones!)
  • 11. OXIDE Wright’s Law: Performance Ramifications • Having more compute in many more places is particularly germane to system performance: ○ More compute close to data (SmartNICs, open-channel SSDs, on-spindle compute) lowers latency ○ Bringing data to special-purpose compute (GPGPUs, FPGAs) increases throughput • But security and multi-tenancy cannot be an afterthought! • We need to rethink our system software
  • 12. OXIDE Aside: A Researcher’s Call to Rethink Timothy Roscoe, OSDI 2021 Keynote, It's Time for Operating Systems to Rediscover Hardware
  • 13. OXIDE The Needed Software Revolution • Much of the coming compute is, at some level, special purpose • These systems are much less balanced than our general-purpose systems — with much less memory and/or non-volatile storage • The overhead of dynamic environments (Java, Go, Python, etc.) is unacceptably high — and the development benefit questionable • Languages traditional used in this domain — C and C++ — both have well-known challenges around safety and composability • Enter Rust, and its killer feature...
  • 14. OXIDE Rust: no_std • Rust is a revolutionary language in many respects, but one that may be underappreciated is its ability to not depend on its own standard library • Much of what is valuable about the language — sum types, ownership model, traits, hygienic macros — is in core, not the standard library • Crates marked “no_std” will not perform any heap allocations — and any such allocation is a compile-time error! • But no_std crates can depend on other no_std crates — lending real composability to a domain for whom it has been entirely deprived
  • 15. OXIDE Rust: no_std binaries • Rust no_std binaries are stunningly small ○ E.g., at Oxide, we are developing a message-passing, memory protected system entirely in Rust (Rust microkernel, Rust tasks); minimal systems are 30K — and entirely realistic ones are < 200K! • no_std is without real precedent in other languages or environments; it allows Rust to be put in essentially arbitrarily confined contexts • Rust is the first language since C to meaningfully exist at the boundary of hardware and systems software!
  • 16. OXIDE Rust, Wright’s Law and the Future • Wright’s Law will continue to hold, resulting in more compute in more places — and this compute will be essential for systems performance • These compute elements will be increasingly special-purpose, and are going to require purpose-fit software • Rust is proving to be an excellent fit for these use cases! • We fully expect many more open source, de novo hardware-facing Rust-based systems — and thanks to no_std they will be able to leverage one another; the Rust revolution is here!
  • 17. Brought to you by Bryan Cantrill bryan@oxidecomputer.com @bcantrill