OXIDE Revolutions past • The software revolutions of the past three decades: ○ The Internet ○ Distributed version control ○ Open source • And of course, Moore’s Law dominated hardware • Aside: revolutions like cloud computing are the confluence of all of these
OXIDE Hardware: The End of Moore’s Law • When phrases exclusively as increased transistor density, Moore’s Law holds at a greatly slowed pace — but 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: Software Ramifications • Having more compute in many more places means software in many more places, many of them hard to get to! • Historically, we have referred to the software that’s hard to get to by its own malapropism: firmware • More compute means much more of this lowest level system software, but security and multi-tenancy cannot be an afterthought! • We need to rethink our system software; could software revolutions past guide to firmware revolutions future?
OXIDE The Coming Challenges • 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 security • But why are safety and security important?
OXIDE The Needed Software Revolution • Safety and security are necessary for composability! • Composability fuels open source: when composability is absent, source code may serve as blueprint and literature -- but not building block • Open source is itself the most important coming revolution in firmware... • But for the open source revolution to gain purchase within firmware, we must have open, safe, secure, composable components • 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 The Coming Firmware Revolution • Wright’s Law will continue to hold, resulting in more compute in more places — bringing with it more firmware! • We know from the last three decades that open source is essential -- but it needs composability to become non-linear • Rust brings new levels of composability to firmware • 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, greatly accelerating open source firmware!
bcantrill
matsujirushi
mercari
red_frasco
k9i
trycycle
.png){kind=icon}
pharma_x_tech
charmichokshi
oracle4engineer
yujisoftware
mmclsntr
hosimesi11
hatefulcrawdad
searls
akosma
holman
samlambert
jcasabona
lara
philhawksworth
iamctodd
morganepeng
skipperchong