[HN Gopher] Rust, Wright's Law, and the Future of Low-Latency Sy...
___________________________________________________________________
Rust, Wright's Law, and the Future of Low-Latency Systems
Author : zdw
Score : 100 points
Date : 2021-10-08 15:07 UTC (7 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| brundolf wrote:
| So the idea is that the low-level abstraction becomes more like a
| distributed system where different pieces of actual hardware
| coordinate independently, instead of where they all go through
| this single, central CPU that has the final word on everything?
| Almost like "edge computing" at the scale of the motherboard
| bitwize wrote:
| I hate to be the smug Amiga weenie but the Amiga was doing this
| in 1985... the idea that everything goes through the CPU is
| largely an accident of PC dominance and the dearth of beauty
| and elegance in system design resulting therefrom.
| brundolf wrote:
| Interesting! I didn't know that
| devmunchies wrote:
| he says that rust can fit into these hidden cores (special
| compute elements) but that there won't be dedicated CPUs or
| memory.
|
| I'm not a hardware guy so I don't have the imagination of what
| you could do on these cores without CPUs or meaningful memory.
| ncmncm wrote:
| They have CPUs, and memory. The memory is generally managed in
| a more restricted and idiosyncratic way than POSIX programs
| like to use. The CPUs are often not what you are used to
| compiling code for.
|
| The tricky part is providing a programming model that is
| usable, understandable, and useful, given the wide variability
| of the conditions the code would need to operate in. The eBPF
| project has made remarkable progress in that direction. eBPF
| code can be generated from C, C++, Rust, and a bunch of other
| languages. The "no_std" feature in Rust has no substantial role
| in getting your code compiled down to eBPF, in preparation to
| be further translated to the object code that actually runs in
| the peripheral gadget.
| [deleted]
| ncmncm wrote:
| The first 15 minutes are just historical rehash, and can be
| skipped over without missing anything at all.
|
| The rest just says that compute elements are showing up in our
| peripherals, and that we will need, and want, to program them.
| (People have said this for decades, but there has been little
| movement toward enabling it, because it will always be hard, for
| reasons.) Then it makes the absurd claim that Rust is uniquely
| capable of programming those elements, because it has a feature
| called "no_std", where your build fails if your code tries to use
| any standard library features.
|
| Of course, all those peripheral processors are _already_
| programmed, today, _almost all_ in C and C++. It is arbitrarily
| hard to run your own code on most, today, because where it is
| possible at all, you need to solder in a JTAG connector and
| reverse-engineer the code in there to figure out how your code
| can operate in the environment.
|
| Lots of peripherals, though, get their object code loaded into
| them by the kernel driver at startup before they will do anything
| useful.
|
| _Maybe someday_ it will get easier to download your own code
| into them from a running system, to extend what they are already
| doing, and _maybe someday_ somebody will document what your code
| would need to do to contribute to such operation. But if that
| ever happens -- and, to be clear, it _is_ happening in certain,
| select places, like some NICs -- Rust will have no advantage over
| other languages. Using "no_std" will not materially help.
|
| For example, a company Netronome has today a NIC that lets you
| run your own code on it, e.g. to filter or alter packets before
| they get DMA'd out to the ring buffer where the kernel sees them.
| It is programmed using eBPF, which is a virtual object code
| format that a kernel driver will translate to native machine
| code. eBPF code can be generated by running LLVM over a file
| generated by a compiler for C, C++, Rust, or really almost any
| language that can be compiled to LLVM intermediate code, and
| offers some way to call out to a C library API.
|
| The Netronome kernel driver takes your eBPF object code, compiled
| from any language, translates it to machine code for one of the
| cores in the NIC, copies that onto the NIC, and patches it into
| what is already running there.
|
| Of course none of the other languages have "no_std", and don't
| need it. Your Rust code doesn't need it either. Don't want to use
| library features? Just don't use them. The things an eBPF program
| is allowed to do are quite limited, but surprisingly powerful,
| including calling out to a special ("standard") eBPF library.
| That Rust's sum types are core language features gives it no
| advantage over the equivalent C++ Standard Library features that
| (also) do not depend on linking to a runtime support library.
| zozbot234 wrote:
| You can't just take Rust code and transpile it into eBPF, it's
| not a Turing-complete language. Now WASM with the addition of
| some tailored API's could do what you're talking about.
| ncmncm wrote:
| Yet, Turing-complete or no, Rust (like C, like C++) can _in
| fact_ be compiled to LLVM intermediate code, and that
| intermediate code, provided it conforms to eBPF requirements,
| can _in fact_ be compiled down to eBPF. And, that is how what
| I 'm "talking about" is _in fact_ done today.
|
| It is _not_ being done with WASM, and probably will not be.
| secondcoming wrote:
| > The first 15 minutes are just historical rehash, and can be
| skipped over without missing anything at all.
|
| I think the software world has got to the point where the
| obligatory Moore's Law graphs, etc are no longer required when
| talking about CPU performance.
| brundolf wrote:
| I thought the "historical rehash" was interesting and well-
| presented
| brundolf wrote:
| > Of course none of the other languages have "no_std", and
| don't need it. Your Rust code doesn't need it either. Don't
| want to use library features? Just don't use them.
|
| 1) no_std allows _composability_. One of Rust 's biggest
| strengths is its package ecosystem, and I imagine this will
| only become more true in the increasingly "weird" and sprawling
| hardware ecosystem described by the OP, where the ability to
| re-use code that other people might have written for your
| hardware could save you from having to "solder in a JTAG
| connector and reverse-engineer the code in there to figure out
| how your code can operate in the environment". "Just don't use
| [the standard library]" doesn't work when you want to use
| third-party libraries.
|
| 2) no_std's static checks are nice even in your own code. The
| value of static analysis has been argued about so many times in
| threads like these that I don't feel like re-treading that
| ground. But suffice to say: it's clear some people think they
| can write flawless code and don't see the benefits of
| assistance, but plenty of others know their limitations and
| benefit from static analysis.
|
| 3) Rust seems to have straddled an interesting and useful line
| in terms of which features are available in these limited
| contexts and which ones aren't, giving you as much to work with
| as possible. And thanks to #1 and #2 you can use those features
| fearlessly; you never have to guess about whether or not
| they're in the "safe" category. Hygenic macros in particular
| can act as a compile-time force-multiplier when you want better
| abstractions but don't want to (or can't afford to) do extra
| things at runtime.
|
| As always comes up in these discussions: yes, you can
| _technically_ cover this usecase with C and C++. You can
| technically cover it with raw assembly code, or binary strings,
| or a pair of wires. Don 't discount ease-of-use as a factor
| that can take things from "technically possible but practically
| infeasible" to "doable and worth doing".
| ncmncm wrote:
| > "you can _technically_ cover this usecase "
|
| Not just technically: _essentially all_ code covering "this
| usecase" -- operating peripheral cores -- _is today_ C++ or C
| code.
|
| It would be more meaningful to say you can _technically_ do
| it in Rust, because it is possible in principle to do it,
| even though practically nobody ever has, and vanishingly few
| ever will.
|
| _Everyone_ who makes up an "embedded subset" congratulates
| themselves for identifying just the right subset. Then they
| immediately start moving other stuff over the line. And never
| stop. This is all familiar ground. All that is new is new
| people noticing it.
|
| An embedded program _in any language_ that relies on a
| library function not implemented in its runtime environment
| will, in any case, fail to link. That _is_ static checking.
| Rust is not doing more static checking here. It is just doing
| it sooner, _and_ forbidding a truly enormous amount of what
| would also be useful to embedded programs. Most of us would
| rather have access to all of that, and let the linker
| identify what support is needed for what is used.
| brundolf wrote:
| > essentially all code covering "this usecase" -- operating
| peripheral cores -- is today C++ or C code.
|
| When has "essentially all...today" _ever_ placed a
| limitation on future progress?
| ncmncm wrote:
| Not the point. Saying something is only "technically"
| possible when in fact it is already done in billions of
| devices is to suggest an absurdity.
| jmull wrote:
| I'm not sure I'm understanding this correctly... Rust
| libraries are generally composable, so that's not what makes
| no_std interesting.
|
| I guess the advantage is that it sets a bar that means "can
| run in a wide range of environments" and it's a standard bar
| so that everything that's "no_std" can (more or less) run in
| the same wide range of environments.
|
| But I don't know. A standard bar is nice, but I'm not sure
| it's really that much of a help.
|
| I just dabble with embedded programming as a hobby, but it
| doesn't seem to me like non-Rust approaches (I'm thinking of
| C and Python) are suffering from a lack of composability.
| brundolf wrote:
| Consider this scenario: you're writing some code that needs
| to run in an environment where some aspect of the standard
| library isn't an option (allocation, or whatever else)
|
| Now you want to pull in a library
|
| Does that library work in that constrained environment, or
| will it break in obvious or subtle ways?
|
| In Rust, no_std is a first-class crate attribute. It's
| enforced inside the crate, and it tells your crate as much
| when on a dependency. It's impossible (as far as I know) to
| accidentally use a std crate from your no_std crate, and
| for a no_std crate to accidentally use something from std
| internally (or in its dependencies). You can search for a
| crate on crates.io, and it can have dependencies of its own
| and dependencies for those dependencies, and you can
| integrate it all into your project without having to dig
| into the source code or whatever else to try and find out
| whether it will fit this set of constraints. That's
| powerful.
|
| In C you would have to either write everything yourself,
| read through all of your dependencies, or just cross your
| fingers.
| ncmncm wrote:
| Or, you link and see what symbols need definitions. As,
| in fact, _everyone already does_ , and has done for
| decades.
|
| Since no_std would forbid an enormous amount of what you
| probably also want to use, you probably don't use it.
| Instead, you see what symbols the linker says need to be
| defined in your runtime support library, and add those.
| jmull wrote:
| Thanks... that is what I thought. Honestly, like I
| mentioned, I don't see that as a particularly useful
| advantage.
|
| The thing is, there is no single line that makes a
| library suitable for my project, whether it's for a
| constrained environment or not. I carefully consider many
| aspects of a library, all from the perspective of what,
| specifically, my project needs. no_std might be one thing
| to look for, but I don't know that it's really answering
| that many of my questions. Also, in my embedded dabbling,
| there seem to be such an incredibly rich set of libraries
| available for constrained environments it is astounding.
| So the lack of no_std doesn't seem to be holding non-Rust
| back.
|
| > In C you would have to either write everything
| yourself, read through all of your dependencies, or just
| cross your fingers.
|
| I really don't think no_std changes that at all.
| brundolf wrote:
| Fair points. I wonder what it would look like to have
| multiple kinds of enforceable crate-level constraints so
| that everyone doesn't have to take or leave the same
| "single line"?
|
| > in my embedded dabbling, there seem to be such an
| incredibly rich set of libraries available for
| constrained environments it is astounding
|
| What about more general libraries that aren't
| specifically designed for embedded scenarios? It seems
| like being able to know up-front whether or not those,
| for example, allocate, would be helpful
| ncmncm wrote:
| The speaker does what many promoters of niche languages do:
| picks out a named feature and insists that it makes
| possible what other languages don't. It is immediately
| walked back to "makes feasible", and shortly "makes more
| convenient", before dissolving in meaninglessness.
|
| I don't think Rust needs or benefits from that kind of
| promotion. It's a pretty good language that will get usable
| in more places as it matures. Overpromoting it into places
| it is not mature enough for yet causes problems. Is Rust
| mature enough for embedded use? In some places,
| _certainly_. In all places? Certainly not.
| brundolf wrote:
| Making enough easy things "more convenient" can make
| harder things "feasible", which can lead to virtually-
| impossible things becoming realistically-possible.
|
| You've intentionally taken mine and others' words in the
| most uncharitable ways possible and you've displayed a
| general willingness to make this an unproductive
| discussion, so I'm going to stop engaging with you now.
| ncmncm wrote:
| I would be happy not to contradict you if you were to
| post comments that do not express absurdities.
|
| Rust the language and Rust the community do not benefit
| from people posting transparent falsehoods. There is
| plenty of substance to Rust. It doesn't need puffing.
| bcantrill wrote:
| Wow, what a caustic collection of strawmen. So, I am not
| a "promoter of a niche language"; I am explaining why a
| language that many already find compelling is, in my
| experience, _very_ compelling for our use case. I am not
| "immediately walking back anything"; I very much stand by
| everything I said. And I am certainly not saying that
| Rust is a fit for all use cases. What I _am_ saying is
| that it 's a fit for ours, and that I believe that our
| use case will be seen by an increasing number of
| engineers as we see more and more constrained compute
| elements in more and more places. You clearly disagree,
| which is fine -- but that doesn't invalidate our
| experience.
| gnurizen wrote:
| Anybody else chuckling at the irony here that eBPF is inspired
| by dtrace which was invented by Cantrill?
| ncmncm wrote:
| No.
|
| If you want to do stuff like this, anything you use to do it
| will have to look a lot like eBPF. eBPF doesn't make it easy,
| it only makes it possible. But dtrace was not eBPF.
| bcantrill wrote:
| Well, it would have been hard to be eBPF because it pre-
| dated it. But perhaps you meant to say that eBPF is not
| DTrace? On that point, certainly agreed.
| ncmncm wrote:
| Dtrace provided huge value for quite little
| implementation effort. It has taken a positively enormous
| amount of more grueling, detailed work to make eBPF much
| more capable. It might not have been done without dtrace
| demonstrating the value available, but I credit eBPF to
| the people who did that hard work.
| Animats wrote:
| _The first 15 minutes are just historical rehash, and can be
| skipped over without missing anything at all._
|
| Right. Short version: Moore's law over, fabs too expensive.
|
| _Then it goes on to make the absurd claim that Rust is
| uniquely capable of programming those elements. This is
| asserted to be because of a feature called "no_std", where your
| build fails if your code tries to use any standard library
| features._
|
| He's a bit vague there. What he's getting at, though, is that a
| common heap is a problem when you have enough CPUs. Shared-
| memory multiprocessor architecture is hitting a wall. Caches,
| and cache sharing, and cache intercommunication have made it
| possible to get a large number of CPUs to pretend they share
| memory. But they really don't share, and trying to maintain
| that illusion adds considerable overhead.
|
| This is an old observation. It's led to lots of distributed
| systems - the Transputer, the Cell, and a whole bunch of
| experimental one-offs. All failed.
|
| Now, there are successes of loosely coupled parallelism. GPUs.
| Neural net simulation chips. Bitcoin miners. Supercomputers
| doing finite element analysis. Those are useful for very
| specific problems where you need a large number of semi special
| purpose compute elements. What this guy may be thinking is some
| general product to do all that.
|
| But he doesn't say much about how to do that.
| ncmncm wrote:
| He makes the same mistake that people always have in
| promoting what the ISO C and C++ Standards call a "free-
| standing implementation". That is supposed to be a build mode
| intended for use in embedded systems, where the program is
| itself the whole system, so it cannot rely on OS services.
|
| This gets conflated, absurdly, with an inability to allocate,
| manage, and use heap memory. Billions of embedded devices
| reserve and manage heap memory without difficulty. Indeed,
| every OS kernel is running in just such an embedded
| environment. Managing memory for its own use and on behalf of
| user processes is among its chief activities.
|
| The problem with defining a "free-standing" version of a
| Standard is that, in practice, real systems invariably need
| to use some of what is not specified to be part of the
| negotiated "free-standing" subset. There are _at all times_
| active proposals to add this or that extra library feature to
| the "free-standing" subset. Meanwhile, the language
| implementers have very little incentive to package any "free-
| standing" subset at all, because no one such subset that any
| substantial number of embedded users can actually use is
| possible.
|
| In practice, embedded-system developers use the regular
| toolchain, and just link a runtime support library that
| implements the things they need. So, for example, C++'s
| _std::vector_ will, by default, call _operator new()_. But
| any particular use of it, in an embedded program, may specify
| a custom allocator, and the object code for the program then
| ends up with no calls to _operator new()_ , and so links
| happily to a runtime library without one.
| steveklabnik wrote:
| Rust allows you to layer on "just the heap please" and yes,
| many projects do exactly that. The point is that it is
| clearly delineated: no_std has no system dependencies, and
| then you can layer things like alloc on top of that, up to
| and maybe finally including full standard library support.
| Rust allows projects to explicitly signal what stuff they
| need, which helps make the ecosystem interoperable, which
| is the point made in the talk.
|
| Incidentally, "every" OS does not have a heap. Many do,
| possibly even "most," but that's not required. It is
| extremely nice to be able to know what needs a heap and
| what does not.
| ncmncm wrote:
| I made no claim that every OS has a heap. Every OS _does_
| manage memory, and use memory.
|
| It is not just nice, but essential, to know what needs a
| heap. And, every embedded coder does know. Or quickly
| learns.
| [deleted]
| chubot wrote:
| Reminds me of _Your computer is already a distributed system. Why
| isn't your OS?_ from HotOS 2009:
|
| https://www.usenix.org/legacy/events/hotos09/tech/full_paper...
|
| _We argue that a new OS for a multicore machine should be
| designed ground-up as a distributed system, using concepts from
| that field. Modern hardware resembles a networked system even
| more than past large multiprocessors: in addition to familiar
| latency effects, it exhibits node heterogeneity and dynamic
| membership changes_
|
| And now that I look at the author list, I see Roscoe, who gives
| the 2021 keynote that Cantrill recommends:
|
| https://www.youtube.com/watch?v=36myc8wQhLo
| ozten wrote:
| These hidden cores are fascinating.
|
| In the past, I was interviewing at a hardware company and one of
| the things they had just discovered was an "unused" and
| undocumented processing unit that they could run a process on to
| get squeeze out more compute from the cameras they used for
| calibration for the hardware bill of materials that they had
| already settled on.
| bcantrill wrote:
| I know that I recommended it in the talk, but I highly
| recommend Timothy Roscoe's OSDI keynote[0] -- and may also be
| worth catching the Twitter Space we did a few weeks ago
| discussing it.[1]
|
| [0] https://www.youtube.com/watch?v=36myc8wQhLo
|
| [1] https://github.com/oxidecomputer/twitter-
| spaces/blob/master/...
| CalChris wrote:
| I liked your talk but I didn't get the connection with
| Wright's Law. You did a good presentation of WL but I just
| didn't get its connection with low latency and future
| hardware software co-design.
| zozbot234 wrote:
| I guess the connection is just that Rust is an up-and-
| coming language, so developing with it is going to get
| gradually easier and cheaper as the surrounding ecosystem
| grows to a larger scale.
| aidenn0 wrote:
| - Low latency is desirable
|
| - Transistors are getting cheaper
|
| - Therefore it is cheap to put computing closer to I/O
| (which reduces latency)
|
| - That computing will not have the sorts of things a
| general-purpose CPU has (maybe no MMU, limited RAM, perhaps
| it's a harvard architecture)
| convolvatron wrote:
| a channel controller! last time i used one of those it
| was a 68k hanging off a convex
| hinkley wrote:
| We're swinging from The Network is the Computer to The
| Computer is a Network
| RobLach wrote:
| That keynote is great. It feels like looking up and seeing
| the sun from the floor of a deep hole you've been too focused
| on digging.
| sremani wrote:
| Roasting a conference in the keynote is whole another level
| of charisma. This talk is impressive even for non-OS people
| like me.
| zja wrote:
| I discovered Oxide's youtube channel a couple weeks ago, and
| I've been really enjoying listening to your twitter space
| discussions. Thanks for all the interesting content!
| dralley wrote:
| Hey Bryan, just curious, what are your thoughts on the
| tradeoffs that Zig is making compared to Rust?
| aidenn0 wrote:
| Given that you continuously recommend Roscoe's keynote, and
| you are working on a message-passing microkernel; will that
| microkernel support message passing between heterogenous
| cores with heterogenous physical address spaces?
| bcantrill wrote:
| I'm not sure what you mean by "continuously", but the
| answer to your question is "no, it doesn't."
| h0h0z wrote:
| Neither Go nor Java or dynamically typed languages. I also think
| it is hilarious he shits all over every language yet he himself
| spent the better part of a decade pushing javascript onto the
| server.
|
| I wouldn't trust a thing that comes out of this SJW factory. Who
| put money into this company?
| RobLach wrote:
| What is a SJW factory?
| smoldesu wrote:
| Simply Just Widgets
| gostsamo wrote:
| Not op, but most likely "social justus warrior".
| RobLach wrote:
| I guessed that but this is a talk about the history and
| democratization of hardware and how it relates to
| software...
| gostsamo wrote:
| Consider me surprised as well.
| cle wrote:
| I'm guessing in reference to this:
| https://www.scylladb.com/2021/01/17/an-open-letter-to-the-
| sc...
| secondcoming wrote:
| Interesting, this the part of the ScyllaDB licence that
| Parler is accused of having violated:
|
| > or (vii) use the Software or any part thereof in any
| unlawful, harmful or illegal manner.
|
| 'harmful'... is there a legal definition of that? I know
| adtech companies that use Scylla. Are they, or could they
| be, 'considered harmful'?
| thekozmo wrote:
| It's not the open source license which we can't forbid
| using, it's the enterprise version.
| gostsamo wrote:
| Didn't know about this case, thanks.
|
| Interesting though why my comment is downvoted. For maybe
| accusing someone in using alt right language or for
| knowing about the existence of such language and what its
| abbreviations mean? People, I'm not even american, I
| don't fight in this war!
| dundarious wrote:
| I think the _vast_ majority of people know what SJW
| stands for. I can 't see the flagged comment, but asking
| what's an SJW factory is most likely a rhetorical joke,
| making fun of the flagged comment containing the phrase
| -- the factory aspect is unintentionally funny to me.
| bcantrill wrote:
| I have the same question! I guess this makes my kids SJWs?
| wyldfire wrote:
| Skip towards the end and Cantrill talks about:
|
| * no_std
|
| * composability of no_std crates
|
| IMO the development-time packaging (cargo) means that as a
| developer I can have a deep and broad list of dependencies
| without having to orchestrate my development environment. This is
| Rust's killer feature, I agree. The fact that you can do it
| w/no_std is also very awesome.
|
| Does anyone have more info about "Hubris" - the OS he refers to
| as under development?
| zozbot234 wrote:
| IMHO we need to allow for local allocators as well as a bunch
| of other stuff (in-place constructors for pinned objects, ala
| C++) before we can claim to have true composability in a no_std
| environment. You see this stuff crop up all the time in "Rust
| kernel modules" discussions too, and there's a reason for that.
| steveklabnik wrote:
| We will reveal more about hubris at the conference he
| referenced at the end, which is happening end of November/start
| of December.
|
| I am extremely excited.
| PeterCorless wrote:
| We also had a great chat about Hubris in the Speaker's Lounge
| at the event. Brian was definitely on fire about the topic!
|
| The one thing I wanted to point out is that there's already a
| "namespace collision" when you search on "Rust" and "Hubris"
| -- a language called Hubris written in Rust:
|
| https://github.com/hubris-lang/hubris
| filereaper wrote:
| Really looking forward to Hubris and especially the design
| decisons made in building it. Like Bryan says, the _why_
| behind it all.
|
| Cheers.
| mooman219 wrote:
| I agree that no_std is incredible. I really want to see more
| crates embrace it and encapsulate their no_std logic away from
| their standard logic. I very often see crates that are like 95%
| of the way to no_std but then choose to bundle some standard
| only features without flagging them.
|
| I wrote fontdue [0] (which is very incomplete spec wise)
| because there just wasn't another font library that was no_std
| at that time. It felt like the existing libraries were in an
| arms race for gpu caches and bundling file loading. Like if I
| wanted to commit to a running on a platform I'd do the sane
| thing and use harfbuzz or the platform APIs.
|
| It's very naive because I don't understand all of the
| complexity, but I'd really like to see the standard library
| being easier to piecewise implement from crates. Like a
| standard trait library and a standard implementation library
| for those traits.
|
| [0] https://github.com/mooman219/fontdue
| scrubs wrote:
| Ummm ... you cannot reason from H/W (video spends 80% of its time
| recounting H/W manufacturing history which is in the domain of
| natural sciences with a formal model e.g. physics, chem,
| statistical physics) to software. The first 80% of the video is
| not relevant.
| replygirl wrote:
| sorry but the kantian project is dead bro.
___________________________________________________________________
(page generated 2021-10-08 23:01 UTC)