(ie, is it some kind of rust auto-simd thing, did they use the opportunity to hand optimize other parts or is it making use of newer optimized libraries, or... other)
Linked from the article is another on how they used c2rust to do the initial translation.
https://trifectatech.org/blog/translating-bzip2-with-c2rust/
For our purposes, it points out places where the code isn’t very optimal because the C code has no guarantees on the ranges of variables, etc.
It also points out a lot of people just use ‘int’ even when the number will never be very big.
But with the proper type the Rust compiler can decide to do something else if it will perform better.
So I suspect your idea that it allows unlocking better optimizations though more knowledge is probably the right answer.
reminds me a bit of the days when perl programs would often outrun native c/c++ for common tasks because ultimately they had the most efficient string processing libraries baked into the language built-ins.
how is space efficiency? last i checked, because of big libraries and ease of adding them to projects, a lot of rust binaries tend to be much larger than their traditional counterparts. how might this impact overall system performance if this trade-off is made en-masse? (even if more ram is added to counteract loss of vm page cache, does it also start to impact locality and cache utilitization?)
i'd be curious how something like redox benchmarks against traditional linux for real world workloads and interactivity measures.
[0] https://bcantrill.dtrace.org/2018/09/28/the-relative-perform...
if all the binaries are big, does it start to crowd out cache space? does static linking make sense for full systems?
So more than the absolute size of the binary, you should worry about how much is actually in the 'active set'.