I'm ambivalent about Rust these days.
-
So, we could have a general-purpose personal computer that runs for 15 hours on a 2000 mAh battery. Maybe more with TTS output rather than a Braille display; I gather that Braille displays are fairly power-hungry because of all the pins moving up and down. But I believe that a general-purpose personal computer needs to be good for modifying its own software, at all levels of the stack. Rust fails hard on that criterion on this low-power CPU that has performance that used to be good.
10/?
@matt maybe gccrs (when it’s ready) will be less resource hungry. There is also Mutabah’s compiler you can try now.
-
@matt my first Linux box was a 166MHz Cyrix 6x86 (so, much slower floating point than a Pentium or AMD at the same clock, but, pin compatible and similar instruction set, I think). It was a huge jump up from the Amiga 3000 I had before, and very usable for all sorts of things. I am pretty spoiled in terms of compute now, but I was writing software (well, learning to write software) on that machine. But, yeah, can't run a modern Linux or build Rust apps in 64MB. Maybe Zig, though?
@swelljoe My first Linux box was a 486SX at 33 MHz in 1996. I think I put Linux on it when it still had only 4 MB of RAM. Hard to believe you could actually compile real C code, including the kernel, on that little.
-
So do we have to accept that some level of computing power well above that of a Pentium II is simply the baseline for a modern general-purpose computer? Maybe. Perhaps the idea of something like the Mantis Braille display, with its battery efficiency, being a general-purpose personal computer is simply an impossible dream that I have to let go of. But, that was always an extreme example anyway.
12/?
Were there other paths to a software stack with minimal unsafe code at the bottom that required far fewer machine resources to compile, that the industry chose not to take? Maybe the Rust Graydon wanted that had no future (https://graydon2.dreamwidth.org/307291.html)? I guess it's kind of moot, because the industry didn't take one of those paths, meaning there's no big library ecosystem on which to build, say, a new personal computing platform with a TTS/Braille-first UI framework.
13/?
-
@inkreas.ing How long does a release build take?
-
Were there other paths to a software stack with minimal unsafe code at the bottom that required far fewer machine resources to compile, that the industry chose not to take? Maybe the Rust Graydon wanted that had no future (https://graydon2.dreamwidth.org/307291.html)? I guess it's kind of moot, because the industry didn't take one of those paths, meaning there's no big library ecosystem on which to build, say, a new personal computing platform with a TTS/Braille-first UI framework.
13/?
OK, I guess Rust compile time isn't so bad on older computers that people actually use as personal computers. See this reply that came in from Bluesky. https://bsky.app/profile/did:plc:54jgbo4psy24qu2bk4njtpc4/post/3mlptu6oycc2g 5 seconds for a debug build on a 2009 MacBook. I feel better now.
14/?
-
@inkreas.ing What CPU model does that MacBook have? And how much RAM? Thanks.
-
So, we could have a general-purpose personal computer that runs for 15 hours on a 2000 mAh battery. Maybe more with TTS output rather than a Braille display; I gather that Braille displays are fairly power-hungry because of all the pins moving up and down. But I believe that a general-purpose personal computer needs to be good for modifying its own software, at all levels of the stack. Rust fails hard on that criterion on this low-power CPU that has performance that used to be good.
10/?
@matt that's cool. I run primarily 100 percent with Braille unless Braille just won't read something.
-
@swelljoe My first Linux box was a 486SX at 33 MHz in 1996. I think I put Linux on it when it still had only 4 MB of RAM. Hard to believe you could actually compile real C code, including the kernel, on that little.
@matt I had the Amiga C compiler Matt Dillon (of FreeBSD and Dragon BSD) made and I tinkered with it. I think I used it as far back as the Amiga 2000, which I think only had 1MB. I probably upgraded it in some way, but don't remember details, probably 2MB. The 3000 used weird ass ZIP RAM, and I distinctly remember I upgraded it to 8MB. But, I'm confident I wouldn't enjoy working with those kind of limitations for serious programming.
-
OK, I guess Rust compile time isn't so bad on older computers that people actually use as personal computers. See this reply that came in from Bluesky. https://bsky.app/profile/did:plc:54jgbo4psy24qu2bk4njtpc4/post/3mlptu6oycc2g 5 seconds for a debug build on a 2009 MacBook. I feel better now.
14/?
Still, I can't help but wonder. Consider a counterfactual where the original ARM processor, the one that famously ran on about 100 mW (meaning that it could, by accident, run only on leakage current), had shipped in a personal computer that had been wildly successful, and it then became an industry norm that all personal computers going forward simply must use that little power. Where would we be now? Still writing large amounts of unsafe C code? Or would we have found a different path?
15/?
-
@inkreas.ing I gather that incremental build is a debug build? If so, do you find that, for a desktop application using an all-Rust GUI stack, the debug build is noticeably slower than the release build on that 2009 MacBook?
-
@inkreas.ing Was Rust compilation in particular painful before you upgraded the RAM to 8 GB?
-
@inkreas.ing Ah, OK. Do you have LTO enabled in the release profile?
-
@inkreas.ing If you've got some time to kill, could you please run UnixBench (https://github.com/kdlucas/byte-unixbench) and post the results somewhere, maybe a gist? I know I might seem weirdly fixated on your anecdote, but yours is the oldest x86-based machine I've heard of so far that someone is using to develop an application in Rust, and I'd like to be able to compare it against other systems. Thanks!
-
@inkreas.ing Oh, I forgot that we had talked about this topic before.
-
But, the Rust compiler is well-known for requiring significant computing power and memory. As just one recent anecdote, the prolific Hacker News commenter Thomas Ptacek recently mentioned that waiting for a Rust compile to finish was a factor in him deciding to comment on a controversial thread. And he was presumably running the Rust compiler on a high-end computer, the kind that we well-off software developers tend to use.
3/?
@matt I _highly_ doubt those assessments, because huge C/C++ code bases will compile for longer in my experience.
I think it always depends on what you are comparing to here. Sure there are other languages that compile faster, because they don't rely on the LTO way of doing things, but especially C++ are not better in terms of compilation speed.
I even had people complain about rusticl compile times, but the C++ drivers just took way longer looking at the data.
-
@matt I _highly_ doubt those assessments, because huge C/C++ code bases will compile for longer in my experience.
I think it always depends on what you are comparing to here. Sure there are other languages that compile faster, because they don't rely on the LTO way of doing things, but especially C++ are not better in terms of compilation speed.
I even had people complain about rusticl compile times, but the C++ drivers just took way longer looking at the data.
@matt Though yes, the memory usage is bigger, so if you are memory constrainted you will run into issues.
But not sure there is a nice way out of this situation sadly...
-
Still, I can't help but wonder. Consider a counterfactual where the original ARM processor, the one that famously ran on about 100 mW (meaning that it could, by accident, run only on leakage current), had shipped in a personal computer that had been wildly successful, and it then became an industry norm that all personal computers going forward simply must use that little power. Where would we be now? Still writing large amounts of unsafe C code? Or would we have found a different path?
15/?
@matt THis is a really fascinating thread, I myself have been wondering lately what specifically makes rustc such a resource hog on those lower-power chips. Is it primarily the heavy lifting of proc-macros and crate expansion, or is the borrow checker's analysis just that computationally expensive? If the former, that seems like a problem that can be solved. If the latter, there are systems programming languages that compile way faster than Rust, see also Zig, but it doesn't provide the same safety features. It's not as unsafe as C, but you can still dereference null and get a crash.
-
Still, I can't help but wonder. Consider a counterfactual where the original ARM processor, the one that famously ran on about 100 mW (meaning that it could, by accident, run only on leakage current), had shipped in a personal computer that had been wildly successful, and it then became an industry norm that all personal computers going forward simply must use that little power. Where would we be now? Still writing large amounts of unsafe C code? Or would we have found a different path?
15/?
@matt For making an user its own developer, the ideal is a language which need not compile and can be tested in real time, e.g. lisp and forth. Maybe something like they say about the 80s lisp machine, a machine programmed in a single language botton up and top down.
-
Still, I can't help but wonder. Consider a counterfactual where the original ARM processor, the one that famously ran on about 100 mW (meaning that it could, by accident, run only on leakage current), had shipped in a personal computer that had been wildly successful, and it then became an industry norm that all personal computers going forward simply must use that little power. Where would we be now? Still writing large amounts of unsafe C code? Or would we have found a different path?
15/?
@matt just one data point here, while I immensely enjoy fast compilation times on a powerful machine, at one point I contributed to the Rust compiler on a Chromebook with 2 1.1GHz cores, 4G ram and 32G disk.
I've mentored clippy contributors on android tablets with less than 4G RAM.
So yes, while rustc won't ever be optimal in terms of compile time, it is absolutely possible to use it from less beefy machines. And often one can set up guardrails through types etc. so that compilation will stop at typeck (which is pretty quick) until the code is correct.
-
@matt fuck no. look at the security features, onboard secure element and eFuses and such on some of them. I'm pretty sure that's an SoC that's covered by the CIP-LTS Linux kernel, which is what I plan to use in my device to avoid the "woops your bsp is no longer supported, fuck your updates" problem. specs I'm thinking. SAMA5D27 536MHz, 256MiB ram, 256MiB flash for OS, 4GB flash for apps and data. qwerty keyboard, D-pad, trackwheel, 2.8-inch 320x240 LCD. screenreader, obviously. custom UI layer because xorg and Wayland for this are both bad. the radio stack is SX1262 LoRa and MM8108 Wi-Fi HaLow, the former for device-to-device messaging, the latter for connection to a federated, independent, solar-powerable mesh mobile network I've been designing, based on Intel N100 base stations on lampposts and stuff. it initially started as "what if I make an accessible meshtastic device?" and expanded out to "what if we made an accessible, non-touchscreen, E2EE, federated smartphone platform, based on a mid 2000s blackberry formfactor, a device very good at making very secure communication very simple and reliable, and very not optimised for anything else?"
@freya Is the power consumption of the SAMA5D27 a major factor in your choice of SoC?
And, thank you for saying "screenreader, obviously". It's refreshing to hear about a project like this that aims to build in accessibility from the start.
