|
|
Subscribe / Log in / New account

Filesystem-oriented flags: sad, messy and not going away

Filesystem-oriented flags: sad, messy and not going away

Posted Mar 17, 2020 21:44 UTC (Tue) by rvolgers (guest, #63218)
In reply to: Filesystem-oriented flags: sad, messy and not going away by rvolgers
Parent article: Filesystem-oriented flags: sad, messy and not going away

To clarify my point a bit more: the way native Rust APIs are written is just very different from how C APIs are written. Due to the rich type system you can have a lot more back-and-forth between a library and its consumers than you would have in a C API.

Consider for example the Iterator trait in Rust. People expect code written using iterators to compile down to something that you would find hard to distinguish from a C for loop in disassembly, which requires the compiler to inline a whole bunch of calls to tiny functions and remove some intermediate values. And not all those tiny functions have to come from the same library, they can come from many different ones, and many will have generic arguments or callbacks with generic arguments from still other libraries.

And it's not just Iterator, the same goes for asynchronous I/O using Futures, and probably more absolutely core functionality that I'm forgetting about right now. As soon as parts of that become dynamically linked, you start having to make some really tough calls about what the compiler can statically assume and optimize out.


to post comments

Filesystem-oriented flags: sad, messy and not going away

Posted Mar 17, 2020 21:47 UTC (Tue) by areilly (subscriber, #87829) [Link]

Agree completely. You just beat me to it!

Filesystem-oriented flags: sad, messy and not going away

Posted Mar 20, 2020 10:15 UTC (Fri) by jezuch (subscriber, #52988) [Link]

The rich type system also means that there are a lot of generic functions taking traits as inputs, which are not "real" types. So either you have a lot of monomorphization ("instantiation" in terms of C++ templates) where you substitute real types for the parameters, or you have dynamic dispatch, which is, well, akin to uncoditional surrender. Forcing dynamic linking also forces the latter, and this has huge impact on performance, maybe as much as impeded inlining has.

(Disclaimer: I speak from theory, not practice, so I may be more than a little wrong :) )


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds