Rewriting the GNU Coreutils in Rust [LWN.net]

Rewriting the GNU Coreutils in Rust

Posted Jun 8, 2021 22:58 UTC (Tue) by Sesse (subscriber, #53779)
Parent article: Rewriting the GNU Coreutils in Rust

One thing I'd love for a new and more modern coreutils: io_uring support everywhere. There's already a cp fork that supposedly does great (https://wheybags.com/blog/wcp.html), but when ls-ing a bazillion files on HDD, it screams for io_uring to get into the head of that elevator algorithm. Same with tar! (Even if tar isn't part of coreutils.)

to post comments

Rewriting the GNU Coreutils in Rust

Posted Jun 8, 2021 23:41 UTC (Tue) by tux3 (subscriber, #101245) [Link] (81 responses)

io_uring everywhere to take care of the async I/O, and work-stealing thread pools on every for loop for the computation.

Now that languages like Rust are making thread-safety practically the default, it is getting a bit silly to iterate over items with only one core while the other 7 or 15 watch.

Legacy tools are being very innefficient with both, currently. Even git is criminally underthreaded and often blocking on serial I/O.

Though that is slowly being improved, the software has not kept up with the silicon, and that is because the abstractions we had made it too hard.

Hail the new languages and the bloated libraries like Tokio. They compile to megabytes of statically linked copies, but boy is it nice to have a modern and fast runtime underneath instead of all the barely-reentrant-half-the-time and definitely blocking POSIX legacy!

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 3:25 UTC (Wed) by notriddle (subscriber, #130608) [Link]

Note: uutils compiles to a single, “multicall” binary. Just like busybox.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 6:19 UTC (Wed) by LtWorf (subscriber, #124958) [Link] (7 responses)

In ls doing all those stat() and systemcalls are way way heavier than any CPU processing.

You can use several threads but they are blocking each other out to access the same hardware resource, and remember that switching thread is not cheap at all, so in the end you are likely to end up with a multicore version of ls that is also way slower and has much much more complex code that is also more error prone.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 7:01 UTC (Wed) by mokki (subscriber, #33200) [Link]

I think the point of using io_uring was not try to use mulitiple cores in user space, but to allow kernel to do stat IO operations in parallel. On both SSD and HDD it should be 10x faster.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 7:17 UTC (Wed) by warrax (subscriber, #103205) [Link] (5 responses)

> remember that switching thread is not cheap at all

This isn't really true in this day and age. It used to be quite expensive, but that's no longer the case (in the common case). Of course it's still more expensive than not doing it (assuming that you cannot do anything productive with that parallelism), but that's neither here nor there.

Anyway, the point of io_uring is avoiding traversing the userland<->kernel boundary unless absolutely required because *THAT* is expensive.

More generally, I'd also challenge your assertion that accessing the hardware in a multithreaded fashion doesn't have gains. Sure, it might not do much for spinning rust, but SSDs can certainly handle multiple non-interfering I/O operations.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 7:21 UTC (Wed) by warrax (subscriber, #103205) [Link] (2 responses)

(Apologies for the self-reply.)

Note also that parallelizing I/O can actually also help with the latency incurred between userland and the actual device latency. The more commands you can queue ahead of time, the more commands the device can go through in a rapid fire fashion -- even in the case where no actual parallel fetching/writing can happen on the device itself.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 16:24 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

And if you scattergun 10 requests at one hdd, the kernel tries to re-order them to minimise the overall time - it should spot if two are close together, and read them one after the other in the right order, etc etc.

Cheers,
Wol

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 14:55 UTC (Thu) by farnz (subscriber, #17727) [Link]

Not just the kernel - all modern storage devices also reorder requests to minimise the overall time.

Every level in the stack below the application benefits from having deep queues; the only reason to not issue all the I/O you can at once is that you might not be able to handle the responses as fast as they come in. Otherwise, you might as well queue up as much I/O as you can keep track of; the kernel will do its re-ordering, and the device can reorder anything from 31 commands upwards to maximise throughput.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 8:06 UTC (Wed) by Sesse (subscriber, #53779) [Link] (1 responses)

> Anyway, the point of io_uring is avoiding traversing the userland<->kernel boundary unless absolutely required because *THAT* is expensive.

That is certainly a part of the point, but not the entire point. Probably more important than that is to be able to do issue many I/Os in parallel, ie., it finally gives Linux usable, performant async I/O. This is required if you want to drive modern SSDs fast, but also for many small files on a HDD. When I implemented io_uring support in plocate, that was the big killer; being able to issue 256 stat()s at once and watch the kernel reorder them into one big head sweep, as opposed to jittering back and forth over the disk. (You'll see a similar thing when ls-ing or cp-ing many (small) files.) Syscall overhead didn't play into it at all; in fact, nearly all the gains were realized in the prototype implementation where I called io_uring_enter() once for every stat, ie., no reduction in syscall overhead at all.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 22:59 UTC (Thu) by warrax (subscriber, #103205) [Link]

You're right. I was being a bit oblique I suppose... One of the advantages is the ability to avoid the syscall overhead of all of select(), epoll() etc. ... which means that it's a lot cheaper to just queue up IO. :)

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 9:44 UTC (Wed) by eru (subscriber, #2753) [Link] (69 responses)

it is getting a bit silly to iterate over items with only one core while the other 7 or 15 watch.

Only if that program is the only process running! Especially with utilities like this, you may not assume you have the whole CPU to yourself. Sometimes it is true, usually not.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 10:18 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

True, but can't the utility also increase its CPU nice value while keeping the I/O niceness low to reflect that the parallelism is mainly about I/O than CPU utilization?

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 10:31 UTC (Wed) by matthias (subscriber, #94967) [Link] (1 responses)

Why should a utility that is I/O-bound and only uses minimal CPU time increase the CPU nice value? Such a utility should have a low CPU-nice value such that in case it needs the CPU (for a very short time) to issue the next IO operation it can do so and make the most efficient use of the available IO bandwidth. For other tasks it should not matter whether the few msec of CPU time needed are nice or non-nice, but for the utility it certainly matters whether it has to wait for the CPU or not.

And of course, high nice values are for background tasks where the user is not waiting for the output. If I run a core utility from the shell, I want to have the result now and I do not care whether a background task has to wait.

Rewriting the GNU Coreutils in Rust

Posted Jun 20, 2021 14:35 UTC (Sun) by roblucid (guest, #48964) [Link]

I suppose as it's a long running non-interactive command it's just giving interactive tasks first crack at the CPU.
If there's multiple io commands in flight, waiting a little to process one of them won't hurt.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 18:09 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (63 responses)

It should be pretty trivial to add a switch or an environment variable to restrict concurrency for the cases where you don't want it.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 20:17 UTC (Wed) by Wol (subscriber, #4433) [Link] (62 responses)

Except you're changing the default API. You need to add a switch to enable concurrency instead. And then you're dumping all the cost of this new feature on the people who want improved performance (fine), but who probably won't realise this option is available ... :-)

Cheers,
Wol

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 6:59 UTC (Thu) by jem (subscriber, #24231) [Link] (61 responses)

It is funny how it was said that advances in CPU design had hit a wall. You couldn't increase clock frequency anymore and the only way to squeeze more computing power out of a CPU was to increase the number of cores. But this was a big problem, because it required software to be rewritten to increase parallelism, and we all know the massive inertia built in in the software industry. And now, when someone comes up with a genuine improvement (a language that advertises built-in thread safety), people start complaining that the programs hog the CPU.

Also, what default Application Programming Interface is this changing?

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 23:02 UTC (Thu) by warrax (subscriber, #103205) [Link] (60 responses)

> (a language that advertises built-in thread safety)

I'm obviously just nitpicking, but Rust "only" guarantees freedom from *data* races.

Rust lacunae

Posted Jun 11, 2021 1:44 UTC (Fri) by ncm (guest, #165) [Link] (59 responses)

This is not a negligible distinction.

Similarly, Rust does not trap integer overflows (except in signed types in non-release builds, i.e. unit tests), so does not prevent such bugs. Complacency around bugs the Rust compiler permits is encouraged by neglect as part of the Holy Mission to drive Rust into universal enterprise use. ("Rewrite It in Rust" has lately been repudiated as official policy of Rust advocacy, for reasons, but uutils seems to have missed the memo.)

When bugs do trap, such as array indexing errors, the resulting panic cannot be presumed to clean up properly before exiting. This sort of thing is hard to get right, and only comes with maturity. Coreutils probably still have bugs of their own, but they are manifestly bugs we have found we can live with.

All of the core utilities, and many others, could be switched over to build with a C++ compiler and then incrementally modernized with overwhelmingly smaller effort than a wholesale rewrite, at much less risk of introducing new bugs, and without abandoning those targets LLVM poorly serves. No Holy Mission drives such activity, so we see it happen with resounding success in Gcc and Gdb, but not yet in less active projects, or in more hidebound ones like PosgreSQL, SQLite, Git, Systemd, the BSDs, or Linux.

There is more than one way to get memory safety without compromising performance. Rust offers one way. Modern C++ practice, writing at a level of abstraction that confines risky operations to trusted libraries, is another. As such libraries are needed anyway, the cost is small. In effect, one places the trust in such libraries that Rust users place in their compiler and in audited "unsafe" blocks in their corresponding libraries.

It could be seen as tragic when wholly new projects, like Pipewire, Vulkan, and Wayland, are coded in archaic, bug-prone C for no defensible reason; but they can anyway be redeemed starting with a 1-line change to their build script.

Rust lacunae

Posted Jun 11, 2021 2:14 UTC (Fri) by rodgerd (guest, #58896) [Link] (1 responses)

Perhaps if you spent as much time doing this work which you claim is so trivial, rather than slagging off people who are shipping code that I can use, you'd have more of a case.

Rust lacunae

Posted Jun 11, 2021 2:51 UTC (Fri) by ncm (guest, #165) [Link]

Not interested in slagging anyone off, thanks.

Unfortunate choices are unfortunate, including choices that generate unnecessary extra work; but as none of them make extra work for me, I happily coexist. You?

Rust lacunae

Posted Jun 11, 2021 2:26 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

> ("Rewrite It in Rust" has lately been repudiated as official policy of Rust advocacy, for reasons, but uutils seems to have missed the memo.)

Or they found the Rust benefits worth it regardless of advocacy. Your scorn is unwarranted.

Rust lacunae

Posted Jun 11, 2021 3:05 UTC (Fri) by ncm (guest, #165) [Link] (6 responses)

If you read scorn, you read wrong.

Rust is manifestly a better language than C for any use where it works at all. But it is not the only, and often enough not the wisest choice. Everyone chooses for their own reasons, and wisdom may come too late, but late is better than never.

Rust lacunae

Posted Jun 11, 2021 4:47 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

> If you read scorn, you read wrong.

I wasn't the only who read it that way. Couple of examples:

"Complacency around bugs the Rust compiler permits is encouraged by neglect as part of the Holy Mission to drive Rust into universal enterprise use"

Sounds like a conspiracy with no evidence cited.

"No Holy Mission drives such activity"

Sounds scornful to me. If you didn't intend to be read that way, you should rephrase these.

Rust lacunae

Posted Jun 11, 2021 10:13 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

> But it is not the only, and often enough not the wisest choice.

Sadly today they are precisely one language suitable for writing safe low-level code. Well… one and half, essentially: Rust and “GCC's C with set of flags Linus insisted on being added to GCC”. C++ is flat-out unsuitable.

And as you readily admit Rust is the best of these.

Rust lacunae

Posted Jun 12, 2021 13:50 UTC (Sat) by BirAdam (guest, #132170) [Link] (1 responses)

One?

Did everyone suddenly forget about Ada and it’s sinking Spark? These two have been in use in mission critical work for decades.

Ada for the win

Posted Jun 21, 2021 22:04 UTC (Mon) by rc_rocks (guest, #152877) [Link]

Indeed. I think that Ada would be an excellent choice for a safer more reliable set of utilities.

Rust lacunae

Posted Jun 12, 2021 22:52 UTC (Sat) by ncm (guest, #165) [Link] (1 responses)

You are the first simultaneous Rust promoter and C apologist I have encountered. You might be all alone in the world.

Rust lacunae

Posted Jun 12, 2021 23:22 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Why? C is a de-facto systems language (duh), and Rust is the only modern-ish alternative. I believe that C++ can be used as well, but it has way too many drawbacks to justify rewrite of low-level systems in C++.

Rust lacunae

Posted Jun 11, 2021 4:19 UTC (Fri) by marcH (subscriber, #57642) [Link]

> All of the core utilities, and many others, could be switched over to build with a C++ compiler and then incrementally modernized with overwhelmingly smaller effort than a wholesale rewrite,

Great plan on paper. The reasons why this does not work in practice are well known and have been detailed in about every single article about Rust.

- While much safer than C, even the "most modern" C++ is not as safe as Rust [1]

- Different C++ programmers seem to have different opinions about "modernity" (and everything C++?) "There is more than one way to do it", famous last words.

- Similarly, there is no simple tool or set of rules to detect unsafe/old C and tell when such a safety effort is "done". With Rust you know that safety is done when it compiles and all the unsafe blocks have been very carefully review. In C/C++ there is instead a patchwork of external checkers [2] with varying and overlapping coverage, rules and false positives.

- For the above reasons, safety regressions are easy even after you think you're done.

Last but not least:
- It's not fun, so no one is doing it.

The problem with safety and security is that they depend on "the weakest link". So incremental approaches that don't tell you when the job is done are flawed by design.

[1] https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
[2] ... that everyone should absolutely use despite their limitations

> Modern C++ practice, writing at a level of abstraction that confines risky operations to trusted libraries, is another. As such libraries are needed anyway, the cost is small.

Modularity and code re-use in C are indeed a joke, unlike safety this is a very good reason to switch to C++; no "weakest link" problem with modularity and immediate benefits. I bet there are other very good reasons to switch to C++; but not safety. Sorry.

Rust lacunae

Posted Jun 11, 2021 9:52 UTC (Fri) by james (guest, #1325) [Link] (3 responses)

When bugs do trap, such as array indexing errors, the resulting panic cannot be presumed to clean up properly before exiting.

OK, I'm curious: what sort of clean up would be reasonable for a coreutils utility beyond just dying?

Rust lacunae

Posted Jun 11, 2021 14:24 UTC (Fri) by zlynx (guest, #2285) [Link] (2 responses)

One that I can think of is the mv command. If anything goes wrong it is nice if mv deletes any temporary copy it had made in the process of moving a file across filesystems.

Of course, if the cleanup is truly important than you cannot implement cleanup using exceptions, panics, or error return codes. There is just no way to be sure that the process isn't killed, so for thorough, reliable cleanup it needs to fork() and have the parent wait for successful completion. If the child fails the parent can clean up. That works for OOM Kill, segmentation fault, illegal instruction and other failures.

Rust lacunae

Posted Jun 13, 2021 13:52 UTC (Sun) by jezuch (subscriber, #52988) [Link]

Well, nobody's safe from SIGTERM, but other than that the Rust devs go out of their way to make sure that panics unwind everything safely. There were major features held up just because they could not guarantee this.

I myself would be completely satisfied if mv did not clean up completely after it was killed by an unmaskable signal. After all, it seemed like this was the intent of the killer!

Rust lacunae

Posted Jun 13, 2021 14:14 UTC (Sun) by james (guest, #1325) [Link]

If anything goes wrong it is nice if mv deletes any temporary copy it had made in the process of moving a file across filesystems.

I've no idea if any version of mv actually does this, but I understand it's possible to open an un-named, unlinked temporary file and write to it, then when you've finished create a link to the file (meaning it has a name and isn't temporary any more), fsync as necessary, and then delete the original file. If the program crashes before the file is linked, then Linux will automatically delete it.

Once the file is linked, you've got a full copy where you want it. Deleting that copy is not obviously the right thing. Deleting the original copy is, but the program crashed when it tried to do that.

Rust lacunae

Posted Jun 11, 2021 10:08 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

> All of the core utilities, and many others, could be switched over to build with a C++ compiler and then incrementally modernized with overwhelmingly smaller effort than a wholesale rewrite, at much less risk of introducing new bugs, and without abandoning those targets LLVM poorly serves.

Unfortunately the time have come to accept that C and especially C++ are not languages you can use to write bug-free programs. Even if your code is bug-free today it wouldn't be bug-free tomorrow. Modern compilers insist that code compiler with --std=c89 or --std=c++98 should obey rules introduced in 2023 (sic! they use not yet developed and not yet approved rules from not yet existing standard to compile code written decades ago — look here for details). With C you can piggyback on the Linux need to actually produce reliable code and the fact that Linus keeps one (just one) C compiler in a state where it can actually be used for that. With C++ that's just plain out impossible.

Rust is built on the same unstable foundation, but, fortunately, this quicksand is only for the unsafe part of the language, safe mode (the default mode) is supposed to not have any undefined behaviors which compiler couldn't detect. This make it actually suitable for reliable software.

> No Holy Mission drives such activity, so we see it happen with resounding success in Gcc and Gdb, but not yet in less active projects, or in more hidebound ones like PosgreSQL, SQLite, Git, Systemd, the BSDs, or Linux.

Linux already contemplates Rust, too.

> Modern C++ practice, writing at a level of abstraction that confines risky operations to trusted libraries, is another.

Modern C++ is unsitable. You can't write safe software using it. Simply because you never know how and when code style would be retroactive changed. Google writes such code in C++, but it's special: they “own” both sides of the equation and thus can actually change code-which-was-safe-but-is-now-unsafe when they are changing the compiler. Most C++ developers don't have such luxury. And since Linux doesn't use C++ they couldn't rely on Linus, too.

> Rust users place in their compiler and in audited "unsafe" blocks in their corresponding libraries.

Rust tries to make sure that code written according to the rules of the book is not only safe today but would stay safe tomorrow. That's big practical difference. The fact that this promise doesn't cover unsafe code is quite unfortunate, but typical rust project doesn't include a lot of unsafe code thus there are at least some hope. No such hope with C++, sadly.

> It could be seen as tragic when wholly new projects, like Pipewire, Vulkan, and Wayland, are coded in archaic, bug-prone C for no defensible reason

C++ maybe more convenient and sometimes even offer faster code (with the use of rvalue-references and other such things) but they also make it more bug-prone. Time have come to start thinking about abandoning it. And Rust is the only viable alternative.

And I say that as someone who likes C++ and hates Rust syntax. Bug I guess I would have to accept it.

Rust lacunae

Posted Jun 12, 2021 9:29 UTC (Sat) by ncm (guest, #165) [Link] (6 responses)

You can repeat "unsuitable" until you turn blue. Meanwhile, thousands of pages of C++ code that you will come to depend upon every day, suitable or not, are coded for every single page of Rust. This will still be true five and ten years on.

Thus, every tiny increment in safety of C++ code being written, from any cause, whether via compiler improvements, language evolution, standard library improvements, third-party library improvements, new libraries released, or developer education, *each* have overwhelmingly more real-world impact than the entire output of the entire Rust ecosystem, from language spec through to "hello world" beginner. All these incremental steps accumulate, day in and day out, adding up to thousands of times as much real-world result, and more again soon after.

Thus, if you actually care even a little bit about the correctness and safety of code you depend on every day, the overwhelmingly greatest effect you can have now and for the foreseeable future would be in helping make the C++ code being written today and tomorrow better, and in helping get C++ code, which can be improved, to be written in place of C code, which cannot.

You can of course continue playing with Rust, for your amusement, but to pretend that it may have any substantive effect in this decade will fool only yourself. In another decade, you will likely have discovered some other enthusiasm of likely similar real-world impact.

I don't make reality, I only observe and report it. Whether you have any effect on it is up to you. Promoting Rust is one way to choose not to. That is allowed much like fooling yourself is.

Rust lacunae

Posted Jun 12, 2021 10:33 UTC (Sat) by khim (subscriber, #9252) [Link] (3 responses)

> Meanwhile, thousands of pages of C++ code that you will come to depend upon every day, suitable or not, are coded for every single page of Rust.

Sure. And they would be buggy and there would be lots of CVEs and data loss. That's fine: if safety is not your goal, data loss is accetable and only performance matters to you then C++ is fine choice.

“Unsuitable for any purpose” is definition from some “better world” position. Where people are more honest and care about security and not just about security certificates. We don't live in that world, sadly.

Indeed. Only you misrepresent direction. Today programs written in C++ code are worse from security perspective than it was yesterday and tomorrow they would be even less safe. Just look on number of CVEs in Chrome, e.g. Yes, 2020 had less vulnerabilities than 2019 — but that's mostly because COVID-19 made development slower. And 2021 is shaping to beat record of 2019, so…

Also note how DoS vulnerabilities have disappeared. That's good, right? C++ is doing great, right? Nope: it just means that there are so many other, more serious, vulnerabilities that DoS ones are no longer even worth reporting.

> All these incremental steps accumulate, day in and day out, adding up to thousands of times as much real-world result, and more again soon after.

Indeed. Pain accumulates slowly but steadily. And even Google and Microsoft are thinking about abandoning ship (and before you misinterpret me: no, they are not ready to embrace Rust, Google have just only added it to Android… even the decision whether to drop C++ or not is not yet finalized… but discussions are underway).

> Thus, if you actually care even a little bit about the correctness and safety of code you depend on every day, the overwhelmingly greatest effect you can have now and for the foreseeable future would be in helping make the C++ code being written today and tomorrow better,

That I agree with.

> and in helping get C++ code, which can be improved, to be written in place of C code, which cannot.

That I couldn't agree with, sorry. While C++ can be improved it's actually less secure than C code. Simply because language is just so complex and insecure. And most mitigations techniques (sanitizers, static analysis, etc) improve safety of both C and C++ thus C stays ahead.

Heck, if you compare C and C++ standard you will find out that C have (and always had) four nicely-prepared lists in it's annex: unspecified behavior list, undefined behavior list, implementation-defined behavior list and locale specific behavior list.

With C++… after 36 years of developers we only have proposal… and it doesn't even includes such lists, it just says that it would be nice to, you know, have an actual list of rules for the programmer to follow somewhere.

That's not security, that's a joke.

> You can of course continue playing with Rust, for your amusement, but to pretend that it may have any substantive effect in this decade will fool only yourself.

Only time will tell. Rust was added to Android only just one year ago. And only couple of small subsystems were implemented in Rust. Microsoft joined the Rust Foundation and actually supports development in Rust, but is not yet ready to drop C++.

But the fact that these companies with billions of investment in C++ tools, lots of in-house expertise and their own compilers (clang's C++ is basically Google work at this point, Apple never was all that interested in C++ and other contributors do even less) are even contemplating switch says you something about C++ safely, I'm afraid.

Yes, it's true: we don't yet know if Rust would be able to replace C++ or not. But the fact remains: it's the only relatively popular language that can do that. C#, Go or Java are all very nice languages but they couldn't be used as low-level system languages. Rust can be used for that.

And it's more secure than C, unlike C++, which is less secure, so why would you advocate switching to C++?

Rust eliminates certain classes of bugs entirely (not all of them, of course, you can write buggy code in any language) while C++ warmly embraces latter choice in the infamous “Hoare dilemma” (There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies).

Thus if you need security you go with Rust. If you only need security certificates then C++ is better for now. But why would anyone want a security certificate for coreutils replacement?

Rust lacunae

Posted Jun 12, 2021 23:51 UTC (Sat) by ncm (guest, #165) [Link] (2 responses)

We already know whether Rust will displace C++. It won't. Any plans you have that depend on displacing C++ have already failed, right out of the gate.

It doesn't matter what you agree or don't agree with; nobody asks you.

Instead, they continue to choose to use C++ because it works, is fully mature, yet is on a cycle of continuous improvement. It reliably brings in billions of dollars, quarter after quarter, for myriad serious users. They invest in continuous improvement by sending literally hundreds of representatives to ISO Standard meetings three times a year, more at each meeting than at any prior, to help prepare the next Standard. Each Standard published on a reliable 3-year schedule has had as much work than the sum total ever devoted to Rust.

I have spent strictly more time in the past decade filing bug reports against compilers than I have in chasing down memory errors in my C++ code. So, whatever Rust has to offer in avoiding memory errors is of no practical value to me or people who code like me: we don't make memory errors. Overwhelmingly more of us are coding C++ than have ever even heard of Rust. More pick up coding C++ anew each month than the total who have ever so much as compiled hello.rs.

You can pretend all you like that C++ code is less secure than C, or that it is getting less secure, or that Google et al. are preparing to drop it, but it is your fantasy. Your need to invent falsehoods to promote your case only shows you have no case, and that people have been correct to ignore you.

Rust lacunae

Posted Jun 13, 2021 7:28 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> We already know whether Rust will displace C++. It won't. Any plans you have that depend on displacing C++ have already failed, right out of the gate.

We already know whether Rust will displace C++. It will. Any plans you have that depend on not displacing C++ have already failed, right out of the gate.

It doesn't matter what you agree or don't agree with; nobody asks you.

Rust lacunae

Posted Jun 13, 2021 8:43 UTC (Sun) by farnz (subscriber, #17727) [Link]

In at least one large engineering organisation I'm aware of, Rust is displacing C++ in internal tooling, and there are people looking at using it in customer-facing code because the internal tooling that's written in Rust has the performance characteristics of tooling written in C++, but with many fewer bugs, and all of those bugs being either non-security or in the FFI layer to existing C++ libraries that are being reused.

I would not bet on Rust displacing C++ in the next 5 years; I also wouldn't bet on C++ retaining dominance in the next 20, because the Rust ownership and borrowing model is the killer feature over C++17 (the current internal standard for C++ in that organisation). And the problem with the ownership model is that it needs full ecosystem buy-in to be useful - everything has to respect it in order for it to give benefits - which means that a C++23 with a Rust ownership model will take decades to upgrade existing C++ code to the point where it's useful.

With Rust, because there's a clear FFI boundary (e.g. using the CXX crate), you get tooling assistance in enforcing the model at that boundary, and with experience, it becomes clear when a bug is in the FFI layer or C++ code, and when it's in Rust.

Rust lacunae

Posted Jun 13, 2021 18:30 UTC (Sun) by Wol (subscriber, #4433) [Link]

> You can repeat "unsuitable" until you turn blue. Meanwhile, thousands of pages of C++ code that you will come to depend upon every day, suitable or not, are coded for every single page of Rust. This will still be true five and ten years on.

> I don't make reality, I only observe and report it. Whether you have any effect on it is up to you. Promoting Rust is one way to choose not to. That is allowed much like fooling yourself is.

You only observe and report reality? Like the future? Well they do say prediction is always difficult, especially if it's about the future.

It won't take much, and you could suddenly find all those thousands of pages you describe are legacy. There's probably *still* more Cobol than C++ in regular production use, but nobody hears about it because it's all in maintenance mode. What will you say if that description becomes true of C++ in the next decade?

Cheers,
Wol

Rust lacunae

Posted Jun 28, 2021 13:38 UTC (Mon) by immibis (subscriber, #105511) [Link]

> Meanwhile, thousands of pages of C++ code that you will come to depend upon every day, suitable or not, are coded for every single page of Rust. This will still be true five and ten years on.

This was true of every now-dead language, at some point.

Rust lacunae

Posted Jun 11, 2021 11:19 UTC (Fri) by daniels (subscriber, #16193) [Link] (14 responses)

> It could be seen as tragic when wholly new projects, like Pipewire, Vulkan, and Wayland, are coded in archaic, bug-prone C for no defensible reason; but they can anyway be redeemed starting with a 1-line change to their build script.

Wayland literally predates Rust, so sadly that wasn't an option.

The core library is quite tiny though, and its primary role in life is to act as a mediator between UNIX sockets (raw bytes) and an FFI bridge (C base types) to whichever language clients or servers are written in. Maybe C++ has matured a bit since Wayland's inception, but at the time C++ interfacing with itself might as well have been an FFI given how difficult it was. Either way, the code in between the sockets and the FFI is so thin that you'd probably increase the code complexity and error factor by converting it to C++.

I get frustrated at C when working on Weston because it's so unhelpful. But C++ doesn't help me with that, because remembering what the name of my type isn't my problem, nor is more ergonomic list/array iteration (because everyone augments the laughably-inadequate C standard library with their own anyway). Working with a language like Rust - which has a real type system unlike C/C++, the benefit of which flows through your entire codebase - would be a lot more compelling though.

Rust lacunae

Posted Jun 11, 2021 12:02 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

> Working with a language like Rust - which has a real type system unlike C/C++, the benefit of which flows through your entire codebase - would be a lot more compelling though.

Indeed. Rust is so nice (except for syntax which I still hate) that I fear for the Mozilla a lot nowadays. Because most (if not all) really popular languages which were developed in companies either belong to companies are no longer are relevant in the software field (like AT&T with C) or extinct (like Sun with C++ and Java, like Netscape with JavaScript, etc).

Rust was separated from Mozilla, though, let's hope it would save Mozilla from that fate.

Rust lacunae

Posted Jun 14, 2021 16:45 UTC (Mon) by anton (subscriber, #25547) [Link] (1 responses)

Not sure why you mention Sun for C++. Bjarne Stroustroup worked at AT&T Bell Labs from 1979 to 2002.

Rust lacunae

Posted Jun 14, 2021 16:49 UTC (Mon) by khim (subscriber, #9252) [Link]

Memory wart, sorry. So both C and C++ were by AT&T and Java was by Sun.

Thanks for the correction, but it still doesn't bode well for Mozilla.

Except Rust is now separated from it thus there are hope.

Rust lacunae

Posted Jun 12, 2021 8:00 UTC (Sat) by ncm (guest, #165) [Link] (10 responses)

To suggest that C++ does not have a real type system, when in fact its type system was the primary model for Rust's, and which power Rust language developers still seek to match, illustrates how what you write about the language wholly lacks factual foundation.

When you show you need to rely on falsehoods to make your case, you reveal you have no case.

Rust lacunae

Posted Jun 13, 2021 14:10 UTC (Sun) by jezuch (subscriber, #52988) [Link] (3 responses)

> when in fact its type system was the primary model for Rust's

Um, excuse me? C++'s type system is based on misunderstanding of object orientedness (which in C++, and just about any other "OO" language, is just an extension of structural programming and a far cry from Simula's design, which we're only now rediscovering). Rust's type system is based on algebraic types, in the ML tradition (not as pure as in Haskell, but still). Traits are first-class citizen in Rust, while in C++ they're a design pattern at best, and everything is centered on classes. Completely different paradigms.

BTW, I know that my interpretation of history of programming language design is un-orthodox, no need to point it out ;)

Rust lacunae

Posted Jun 13, 2021 18:38 UTC (Sun) by zlynx (guest, #2285) [Link] (1 responses)

I hear OO purists complain about C++ design all the time.

But no, it was not a "misunderstanding." I think C++ design is probably one of the best compromises possible between efficient machine code and OO. And of course we must remember it stayed compatible with C.

"Pure" object oriented languages are just disgustingly inefficient. Java succeeds because of the immense work put into its JVM and JIT compiling. Python and Ruby show off what happens when everything is an object.

Anyone can look and see that C++ is used where speed matters.

Also it is very funny that you use Simula of all languages as an example of object oriented. Smalltalk was the pure object oriented language. Simula was a mashup of Algol and OO juist as C++ is a mix of C and OO. Simula doesn't contain even half of what became Object Oriented in Smalltalk.

Rust lacunae

Posted Jun 14, 2021 12:28 UTC (Mon) by jezuch (subscriber, #52988) [Link]

Yes, sorry, should have not clouded my point with my peeves :)

The claim was that Rust bases its type system on C++ and is far behind it. My point was that Rust, while syntactically in the C family, explicitly breaks away from its type system. And is more powerful thanks to a conscious design and not being a heap of ad-hoc.

Rust lacunae

Posted Jun 13, 2021 19:28 UTC (Sun) by ncm (guest, #165) [Link]

"Unorthodox" meaning wrong, of course.

Language purity is a farce. C++ was never promoted as an "object-oriented language". It has always been a language that provides support for an object-oriented style as one among many, and supports promiscuous mixing of styles for anyone not stupidly wedged into just one.

Most of its type operations are inspired by ML, as in Haskell. Algebraic types are just types. There is no paradigm. Paradigms are a farce too.

Rust lacunae

Posted Jun 13, 2021 14:13 UTC (Sun) by jezuch (subscriber, #52988) [Link] (5 responses)

> which power Rust language developers still seek to match

Oh, and I believe that Rust's type system is way more powerful than C++'s, which is a complete mess. So the catch-up goes the other way.

Rust lacunae

Posted Jun 13, 2021 15:02 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (2 responses)

Well, C++ does have NTTP (non-type template parameters) and HKT (higher-kinded types; "template templates" in C++). Specialization is also probably more powerful in C++, though I'm less versed in Rust's capabilities here. So in that respect, C++ does have more expressiveness, but Rust adds expressiveness in terms of knowing how ownership of data flows through an API. The lack of exceptions also means that error cases are exposed directly on the API too (checked exceptions being, largely, a failed experiment AFAIK). It can sort of be done with C++, but the corner cases that exist are annoying. The one that comes to mind is `std::optional<T&>` and `std::variant<T&>` are not usable in C++ today (one can wrap `std::reference_wrapper` around it, but is tedious to type and juggle).

Rust lacunae

Posted Jun 13, 2021 21:54 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

Type system of C++ is built like everything else in that language: 100 stories tall skyscraper with the foundation of quicksand. Yes, I know why, but the fact that size > -1 is always false if size is unsigned with no warnings or errors caused far more real-world problems than anything related to issues with references. The fact that uint32_t, uint64_t and size_t are not distinct is seriously problematic, too.

Rust have a pretty decent type system. Not perfect but pretty good. Type system of C++ is collection of footguns. Yes, you can make your program misbehave in so many interesting ways… but does anyone finds it fun to explore all these ways when they are debugging something?

Back then when C++ at least tried to be compatible with old versions it sounded justified at least, but now, when new versions of C abd C++ are designed to add new and exciting bugs into programs which were perfectly safe yesterday that “compatibility!” excuse just doesn't sound convincing. At least Linus works as good enough brake for that activity in “Kernel C”. But nobody does the same with C++.

At least safe Rust doesn't try to pretend that someone may write code in 1990 which obeys rules which are not yet finalized yet in 2021. Unsafe Rust, sadly, inherits that issue because of it's LLVM foundation, but in typical program there are limited amount of unsafe rust code.

Rust lacunae

Posted Jun 24, 2021 15:24 UTC (Thu) by nye (guest, #51576) [Link]

> size > -1 is always false if size is unsigned with no warnings

$ clang++ -Weverything /tmp/test.cpp
/tmp/test.cpp:4:14: warning: result of comparison 'unsigned int' > 4294967295 is always false [-Wtautological-type-limit-compare]
    if (size > -1) {
        ~~~~ ^ ~~
/tmp/test.cpp:4:16: warning: implicit conversion changes signedness: 'int' to 'unsigned int' [-Wsign-conversion]
    if (size > -1) {
             ~ ^~

Even if you don't like using -Weverything because you don't want to opt in to newly added warnings, I do think that -Wsign-conversion is something that should always be turned on for code under active development. If you have substantial legacy codebase then you will doubtless need to add a lot of explicit casts to silence false positives, but, well, that's what you asked for.

Rust lacunae

Posted Jun 13, 2021 19:35 UTC (Sun) by ncm (guest, #165) [Link] (1 responses)

You are free to believe as many falsehoods as you like.

Or, you can look at the actual proposals to strengthen Rust's type system to be able to express more of what can now be expressed in C++ and Haskell but not in Rust.

Rust lacunae

Posted Jun 14, 2021 12:22 UTC (Mon) by jezuch (subscriber, #52988) [Link]

Well, Rust's type system is Turing-complete[1], so it's hard to argue that it's less powerful than anything.

[1] https://sdleffler.github.io/RustTypeSystemTuringComplete/

Rust lacunae

Posted Jun 11, 2021 12:14 UTC (Fri) by roc (subscriber, #30627) [Link] (19 responses)

"Modern C++" doesn't give you memory safety. It's still easy to create dangling references and the standard library doesn't do array bounds checks. If modern C++ provided memory safety, "writing at a level of abstraction that confines risky operations to trusted libraries", Google, Microsoft, etc would not be adopting Rust.

> the resulting panic cannot be presumed to clean up properly before exiting. This sort of thing is hard to get right, and only comes with maturity.

GNU coreutils can't even be bothered handling SIGPIPE when stdout is a closed pipe. "Graceful exit" is not their forté.

OTOH, in Rust RAII is *the* way to clean up resources, and panics run those drop handlers, so Rust panics generally clean up after themselves quite well.

Rust lacunae

Posted Jun 11, 2021 13:48 UTC (Fri) by Sesse (subscriber, #53779) [Link] (18 responses)

Do you have any references that Google is adopting Rust at any scale? So far, it seems to be very small swaths of Rust that get hyped up by the media. No large-scale rewrites of anything (unlike for Go, in which actually a fair bit of internal projects have been retasked).

Rust lacunae

Posted Jun 11, 2021 14:06 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (17 responses)

There are a bunch of efforts. The one with the widest impact is their efforts to integrate Rust into Linux kernel and Android

https://security.googleblog.com/2021/05/integrating-rust-...

Rust lacunae

Posted Jun 11, 2021 14:15 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

Ah, missed out on the second link

https://security.googleblog.com/2021/04/rust-in-linux-ker...

Rust lacunae

Posted Jun 11, 2021 14:18 UTC (Fri) by Sesse (subscriber, #53779) [Link] (15 responses)

That's precisely the kind of small-scale adoption I was talking about. Nothing at scale, no big rewrites, hyped by the media.

Rust lacunae

Posted Jun 11, 2021 14:27 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (14 responses)

> That's precisely the kind of small-scale adoption I was talking about. Nothing at scale, no big rewrites, hyped by the media.

Which media? Also, integrating Rust into Linux kernel and Android isn't exactly what I would consider small-scale.

Rust lacunae

Posted Jun 11, 2021 14:33 UTC (Fri) by Sesse (subscriber, #53779) [Link] (13 responses)

The tech media?

Google's scale is staggering. Around 100B of lines of C++ by now (I don't have updated numbers). In comparison, the Linux kernel with its ~30M LOC is a drop in the ocean; assigning one or two engineers onto looking at the prospect of maybe writing device drivers in Rust one day, even more so.

Rust lacunae

Posted Jun 11, 2021 15:16 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

Really sounds like you're moving the goalposts.

- Rust isn't used anywhere at Google. <shown uses>
- Oh, it's being looked at for Linux drivers, that's meaningless at the scale of Google.

As if on day 1 there has to be millions of lines of code for it to be meaningful. There is massive momentum for these kinds of things and it takes time. Google having their pet language probably has way more buy-in from management and whatnot, so that specific comparison isn't really useful in my mind.

Rust lacunae

Posted Jun 11, 2021 18:08 UTC (Fri) by Sesse (subscriber, #53779) [Link]

_I_ am not moving the goalposts. It was said that Google was adopting Rust, and that this was proof of C++'s unsuitability. I pointed out that Google has a comparatively tiny adoption of Rust (at least to my knowledge), and now I'm suddenly being asked to defend the position “Rust isn't used anywhere at Google”? That's a strawman. I mean, Google uses x86 assembly code, too, but not at any large enough scale that it shows intent to move from C++ to assembly.

Rust lacunae

Posted Jun 11, 2021 17:08 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (10 responses)

> The tech media?

Too vague. Which article(s) are you referring to?

> Google's scale is staggering.

Yes and the fact that they have shown significant interest and movement towards integrating Rust into projects with massive user bases like Linux and Android is yet another evidence of growing large scale adoption by multiple companies across many different industries. This is the only realistic way you are ever going to see adoption of any new(er) language. It won't be massive code dumps of millions of lines of code one fine day.

Rust lacunae

Posted Jun 12, 2021 9:39 UTC (Sat) by ncm (guest, #165) [Link] (9 responses)

"Significant" is what is being challenged. There has been exactly zero evidence of any significance. Every big company fools with anything you can think of, from Forth to Haskell. It will be a long time before any significance can be demonstrated, if ever. In the meantime, it is not honest to assume it.

Rust lacunae

Posted Jun 12, 2021 10:19 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

> "Significant" is what is being challenged. There has been exactly zero evidence of any significance. Every big company fools with anything you can think of, from Forth to Haskell

Calling all the existing adoption and momentum from several major players as zero evidence or fooling around is pretty dismissive. This isn't remotely comparable to Forth or Haskell. We are talking about code in production from Mozilla, npm, discord, dropbox, cloudfare and so on. I can't think of any other language comparable to C or C++ that has gotten this level of traction in this timeframe. Feel free to continue overlooking this and we will find out even more conclusively in a few years.

Rust lacunae

Posted Jun 13, 2021 18:47 UTC (Sun) by ncm (guest, #165) [Link] (4 responses)

Which part of "In the meantime, it is not honest to assume it" are you confused about?

Rust lacunae

Posted Jun 13, 2021 19:11 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

> Which part of "In the meantime, it is not honest to assume it" are you confused about?

I just don't agree with your opinion. There is no confusion around that.

Rust lacunae

Posted Jun 13, 2021 20:07 UTC (Sun) by ncm (guest, #165) [Link] (2 responses)

Just so we are clear, you are assuming despite overwhelming evidence to the contrary that the amount of Rust usage at Google, relative the scale of its operations, is significant, and furthermore think it is honest to present such a tale.

Your relationship with truth is duly noted. I will not need any further information.

Rust lacunae

Posted Jun 13, 2021 20:14 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

> Just so we are clear, you are assuming despite overwhelming evidence to the contrary that the amount of Rust usage at Google, relative the scale of its operations, is significant, and furthermore think it is honest to present such a tale.

That's not accurate. My comments weren't limited to Google.

Rust lacunae

Posted Jun 13, 2021 20:36 UTC (Sun) by nix (subscriber, #2304) [Link]

ncm: as a relatively unbiased observer (liking both C++ and Rust)... your arguments are not covering you with glory here. Rust is seeing *substantial* usage -- yes, it's not more usage than the entire installed base of C++, but expecting anything of the kind is utterly ridiculous: the language is younger and hasn't had massive adoption for its entire lifetime (of course it hasn't), so its effective lifetime in terms of large-scale usage is shorter than that. But it definitely *is* seeing large-scale usage. Not higher usage than C++, no, not yet -- but ask which language is growing faster, and which language new projects are being written in, and I'd be astonished if you answered C++.

Rust lacunae

Posted Jun 12, 2021 23:24 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

Neither Forth nor Haskell are considered as possible C++ replacements by Google and Microsoft. Rust is in that list. Which not very long, BTW. Less than half-dozen languages were considered… Swift was considered, too and while some technical issues were found they looked fixable but the fact that there are no “Swift Foundation” and Apple doesn't plan to relinquish control any time soon was the deal-breaker.

Rust lacunae

Posted Jun 15, 2021 19:43 UTC (Tue) by Wol (subscriber, #4433) [Link]

Forth scores when you're writing a small program for storing in EPROM or stuff like that. And that means that it's small enough to vet thoroughly for errors.

And of course, Forth also has the reputation of producing executables that are smaller than well-written assembler :-)

Writing a KLOC and more program in Forth would probably be a bit of a nightmare.

Cheers,
Wol

Rust lacunae

Posted Jun 13, 2021 7:26 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Amazon is investing heavily in Rust. For example, they are running production customer workloads on Firecracker VM that is written in Rust. And they have other products (both internal and external) in Rust.

I don't work in Amazon, but I've heard from my friends there that Rust in practice turns out to be a more productive language than C++ and much easier to pick up. One major advantage is that you don't have to learn the particular subset of C++ and its libraries that is in use in your new workplace.

Rust lacunae

Posted Jun 11, 2021 19:51 UTC (Fri) by notriddle (subscriber, #130608) [Link]

except in signed types in non-release builds

In non-release builds, unsigned integer overflow also traps. There is no difference between signed and unsigned integer overflow in Rust.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 13:15 UTC (Thu) by moltonel (subscriber, #45207) [Link] (1 responses)

Who says those other processes are more urgent than your uutils process ? And what if there are a couple of other urgent single-threaded processes but you still have have your CPU cores available for the uutils process ?

Assigning priorities should be done at the system and kernel level, not at the process level. It's nice to have `-jN` style options with a "-j$(nproc)" default, but they remain a bit of a kludge. Instead we have nice, cgroups, etc. It'd be great if something like Apple's grand central dispatch became ubiquitous on Linux.

Rewriting the GNU Coreutils in Rust

Posted Jun 10, 2021 15:07 UTC (Thu) by Sesse (subscriber, #53779) [Link]

Linux has cgroup scheduling, so even if you fire up 100 uutils threads, you're still competing on a fair level against that other urgent single-threaded process. (I mean, ninja fires up N threads for N CPUs, and yet my precious background music plays just fine.)

Rewriting the GNU Coreutils in Rust

Posted Jun 20, 2021 14:31 UTC (Sun) by roblucid (guest, #48964) [Link] (1 responses)

If you're processing disk input, one process on one core per disk was always able to max it out, if you're waiting for i/o there's little point in parallelising the fast CPU part.
If you're using a good asynchronous implementation even less so, as you're giving the freedom to the disk to reorder fetches.
Copying and moving data on disks wasn't CPU bound even with relatively weak uni-processors.
In the article it mentioned performance gains due to using zero copy calls rather than the threading.

Rewriting the GNU Coreutils in Rust

Posted Jun 20, 2021 22:51 UTC (Sun) by zlynx (guest, #2285) [Link]

"IO is slow" is an old and now outdated idea. It takes several CPU cores to make use of multiple Intel P5800X drives. The P5800X is the new Optane based PCIe 4 drive.

The new game consoles are using tricks to transfer data directly from NVMe to the GPU. Because the CPU is slow, busy and doesn't need to be involved.

Anyway, to repeat myself, storage and network IO is rapidly catching up in speed as CPU speed stalls out in favor of multiple cores.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 0:02 UTC (Wed) by wahern (subscriber, #37304) [Link] (5 responses)

sendfile and especially copy_file_range would be much faster than using io_uring for copying files. Technically many copy_file_range use cases could be probably be abstracted by sendfile.

You can also use sendfile to copy files from disk to socket and vice-versa. With kernel-based TLS (aka kTLS) you can do this on TLS-encrypted TCP sockets.

I suppose somebody will at some point add a sendfile operation to io_uring, though that wouldn't necessarily buy you performance, just user space convenience.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 2:30 UTC (Wed) by Paf (subscriber, #91811) [Link] (4 responses)

Fun fact, from a file system developer:
Send file is very often *not* faster than read and write because many file system implementations use a 64KB pipe, generating 64 KB I/Os. It’s often much better to do larger I/O from user space, even on SSDs.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 3:46 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (2 responses)

Now I'm wondering how sendfile's performance compares to, say, mmap'ing the file and handing the pointer directly to write (or perhaps fwrite, if we're doing this from userspace). I can't imagine that it could be too much worse than what you describe, seeing as most of the real work is taking place in the page cache, which is supposed to be good at this sort of thing...

Would it be legal/advisable for sendfile to actually be implemented by doing that (with write, not fwrite), in cases where the file to read is mmap'able? Or does that break some sort of "don't alloc buffers in userspace without userspace explicitly asking for it" rule? I can't imagine that any reasonable implementation of malloc would care, but I'm sure there's some ridiculous use case where you go trawling through /proc/self/maps and do something clever with it.

Alternative #2: What if you could mmap file A, somehow tell the kernel that "this mmap now belongs to file B," and then unmap it? I'm guessing that you can't do the second step, though. AFAIK, there's currently no such thing as filesystem-to-memory-to-filesystem COW, so you'd have to fault everything into memory, at which point this is clearly a terrible idea (for large files, anyway).

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 13:51 UTC (Wed) by Paf (subscriber, #91811) [Link] (1 responses)

Yeah, I don’t fully follow some of the details of your thought, but I think you’ve found a few of the issues. My impression - I’m a file system developer but I don’t actually know this, it’s just an impression - is that send file is implemented this way to avoid allocating large buffers inside the kernel.

You can do things like mmap in the kernel; in general you can kind of do ... whatever. But a lot of it is ugly or weird (using syscall type functionality within the kernel is prone to weird reentrancy issues), or requires allocating big blobs of memory in the kernel.

Things like COW for page cache memory would be ... weird. It gets in to areas I’m not familiar with, but I would think faulting, etc, might be a problem.

(Also, I misremembered above - send file is *always* via a pipe.)

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 13:58 UTC (Wed) by Sesse (subscriber, #53779) [Link]

You can use splice() to go directly from one file descriptor to another with no pipe in-between (sendfile is just a special case of splice), or use the new copy_file_range() call.

Rewriting the GNU Coreutils in Rust

Posted Jun 9, 2021 8:39 UTC (Wed) by LtWorf (subscriber, #124958) [Link]

Yeah I had tried doing a bunch of ifdef in a project of mine to use send file, but after checking the benchmarks I scrapped it all, as it was slower than the regular read/write loop.