12 ms·
Rust, Wright's Law, and the Future of Low-Latency Systems
- scrubs 5y agoUmmm ... 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.
- scrubs 5y agoOK, downvoted. The point of my comment was not that software cannot be aligned or co-located with hardware. As others pointed out C/C++ is just as capable. My point was that spending the first 75% of the video recounting H/W advances which is based in formal science (chem-eng and the rest) is orthogonal to software. Moore's law does not carry over into software. The video could have just started by pointing out with H/W specialization there are more places to put Rust code. This way 99% of the video could have been on the OP's like of Rust. Right? The top comment shares much the same sentiment: "Skip towards the end and Cantrill..."
- replygirl 5y agosorry but the kantian project is dead bro.
- ozten 5y agoThese 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 5y agoI 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 https://www.youtube.com/watch?v=36myc8wQhLo [1] https://github.com/oxidecomputer/twitter-spaces/blob/master/2021_09_06.md https://github.com/oxidecomputer/twitter-spaces/blob/master/...
- RobLach 5y agoThat 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 5y agoRoasting a conference in the keynote is whole another level of charisma. This talk is impressive even for non-OS people like me.
- CalChris 5y agoI 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 5y agoI 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 5y ago- 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 5y agoa channel controller! last time i used one of those it was a 68k hanging off a convex
- hinkley 5y agoWe're swinging from The Network is the Computer to The Computer is a Network
- h0h0z 5y agoNeither 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 5y agoWhat is a SJW factory?
- gostsamo 5y agoNot op, but most likely "social justus warrior".
- cle 5y agoI'm guessing in reference to this: https://www.scylladb.com/2021/01/17/an-open-letter-to-the-scylla-community/ https://www.scylladb.com/2021/01/17/an-open-letter-to-the-sc...
- gostsamo 5y agoDidn'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 5y agoI 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.
- secondcoming 5y ago
- devmunchies 5y agohe 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 5y agoThey 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 5y ago[deleted]
- wyldfire 5y agoSkip 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 5y agoIMHO 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.
- pas 5y agoFor anyone who wants to know a bit more about this, this a recent talk about how to implement move constructors in Rust: https://www.youtube.com/watch?v=UrDhMWISR3w https://www.youtube.com/watch?v=UrDhMWISR3w
- steveklabnik 5y agoWe 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 5y agoWe 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 https://github.com/hubris-lang/hubris
- filereaper 5y ago
- ncmncm 5y agoThe 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.
- 5y ago
- brundolf 5y agoSo 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 5y agoI 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 5y agoInteresting! I didn't know that
- zozbot234 5y agoThe early home computers were invariably designed around the video signal clock, so they were quite deterministic and predictable - very little was truly 'independent'. The PC with its custom extension cards was more of a pure distributed platform.
- chubot 5y agoReminds 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_papers/baumann/baumann.pdf 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 https://www.youtube.com/watch?v=36myc8wQhLo
- thelazydogsback 5y agoQNX? - been around for a while - the first OS to run in protected 386 mode FWIR. (And I remember it booting from a single floppy :))