3 ms·

The article title is misleading. It is not that Rust compiler was not able to optimize some low-level operations. Rather the author came up with encoding schema

by fpoling 26d ago

The article title is misleading. It is not that Rust compiler was not able to optimize some low-level operations. Rather the author came up with encoding schema that fit most things the interpreter dealt with into 64 bit. This replaced the previous schema that used 128 bit for everything but that can be directly mapped into Rust enums. The catch was that it was necessary to allocate some things on the heap and use pointer indirection but that was used for rare values so on average the new schema provided nice win. One cannot expect a compiler to come up with such encoding.

win311fwg 26d ago
What is misleading about the title? A custom encoding scheme is exactly what it suggests. Maybe it has been edited since your comment was posted?
- dymk 26d ago
  It wasn’t replacing one rust enum, it was replacing what are effectively multiple enums
  - dzaima 26d ago
    How so? It's replacing multiple enum variants, but just one enum, "enum Value". (also; if anything, the title is implying the exact opposite of "Rust compiler was able to optimize ...", "Replacing a Rust [...] with [...]" is clearly moving away from Rust-magic to something else)
    - Brian_K_White 26d ago
      Probably in the sense that you can remove the word rust and nothing changes. It's not about some failure of rust to be efficient at enums, but the title says it is.
      - win311fwg 26d ago
        'Enum' is ill-defined so the addition of Rust is significant as it indicates what one can expect with how data is structured. There is nothing in that speaks to the Rust compiler or Rust being inefficient or anything of the sort. It remains unclear where this idea is coming from. There is nothing in title that would send you there. Unless, again, the title was edited at some point?
      - benatkin 26d ago
        If you replaced it with Zig, the situation changes.
      - maxime_cb 25d ago
        OP here: I think you're reading too much into the title. It's not about the failure of Rust. It's about where I stepped in with some custom optimizations for better performance. If you read the blog post, the solution implemented is very Rust-y as well. It uses a newtype with custom methods to try and make the code as nice and readable as possible. FWIW this post was very well received on the Rust subreddit. They loved it and it got over 350 upvotes, so that community definitely didn't receive it as some sort of attack on Rust.
        CyberDildonics 25d ago
        I think you're reading too much into the title. I don't think it's fair to write a misleading title then tell people "they're reading too much into it". Implying one thing then walking it back in the article or having the article be about something totally different, then saying people should read the article and not pay attention to the title is just manipulative to your audience.
        win311fwg 25d ago
        The problem is that there isn't anything misleading about the title. It is well understood that creative packing of data can provide optimizations under certain circumstances. Nobody should have reason to think otherwise. The title quite accurately captures what the rest of the article is about as well as any title possible can. What appears to be happening as we see in several comments is that some users cannot find any technical reason to use Rust so they rely on a belief that it is somehow magically perfect to justify using it and and the idea that it hasn't perfectly found some creative packing solution, despite the rest of us wondering why one would expect any compiler to – it not really being its job, is felt as an attack on their use of Rust. Someone developing irrational feelings towards an inanimate tool isn't on the article's author.
- gpm 26d ago
  I'd actually point at the other half of the title than the existing comment when being pedantic "Replacing [...] with a 64-Bit Word" isn't quite right, it was replaced with a manually packed 64-Bit Word and the occasional heap allocation. I'm not sure being this pedantic is particularly useful in titles though...
  - Dylan16807 26d ago
    It's worth calling out either way. It's not just an encoding scheme, it's a reasonably significant change in architecture.
    - deleted 25d ago
      [deleted]
pbiggar 26d ago
When I think of how a "compiler" could make these optimizations, I think the right place is an optimizing LLM (so, just a regular coding agent that you prompted to find optimizations like this one), making the changes in source at the request of the developer. That provides the dev with adequate input on whether they would like to opt-in to an unsafe optimization like this one. The compiler can continue to do deterministically-safe optimizations.
- trickypr 26d ago
  That seems like a horrible idea: 1. Do you really want the rust compiler to run at the speed of an llm? 2. Compiler optimisations are already extremely unpredictable with deterministic compilers[1], I hate to think how unpredictable your compiler would be. 3. What if someone else wants to build the software, do they have to decide on optimisations now? What if the optimisation depends on your features not available on old generations of CPU? (There is a reason we don’t compile with -march=native) 4. Compilers already have “unsafe” optimisations, but people rarely enable them (-ffast-math) [1]: https://faultlore.com/blah/oops-that-was-important/ https://faultlore.com/blah/oops-that-was-important/
  - pbiggar 26d ago
    You misunderstand me. I'm saying that the developers can make these optimizations with LLMs, at the source level, and thus they don't need to be added to compilers. Like just open Claude Code and ask it to find optimizations. That's the right place for this kind of optimization.
  - jmalicki 26d ago
    > Do you really want the rust compiler to run at the speed of an llm? That... might actually be an improvement?
    - Quothling 26d ago
      What do you mean "might"? I can crank Fable or Sol up to max intelligence and they'll spend an hour reviewing my rust SDK for working with our ADLSgen2's, and it'll still be done before the rust compiler has compiled the same project.
RossBencina 26d ago
> One cannot expect a compiler to come up with such encoding. One could, however, imagine a sufficiently expressive language that allows the developer to specify the encoding schema without resorting to raw 64-bit words.
- aa-jv 25d ago
  This breaks the language. Do you want safety or do you want expression?

by fpoling 26d ago

win311fwg 26d ago

What is misleading about the title? A custom encoding scheme is exactly what it suggests. Maybe it has been edited since your comment was posted?

dymk 26d ago
It wasn’t replacing one rust enum, it was replacing what are effectively multiple enums
- dzaima 26d ago
  How so? It's replacing multiple enum variants, but just one enum, "enum Value". (also; if anything, the title is implying the exact opposite of "Rust compiler was able to optimize ...", "Replacing a Rust [...] with [...]" is clearly moving away from Rust-magic to something else)
  - Brian_K_White 26d ago
    Probably in the sense that you can remove the word rust and nothing changes. It's not about some failure of rust to be efficient at enums, but the title says it is.
    - win311fwg 26d ago
      'Enum' is ill-defined so the addition of Rust is significant as it indicates what one can expect with how data is structured. There is nothing in that speaks to the Rust compiler or Rust being inefficient or anything of the sort. It remains unclear where this idea is coming from. There is nothing in title that would send you there. Unless, again, the title was edited at some point?
    - benatkin 26d ago
      If you replaced it with Zig, the situation changes.
    - maxime_cb 25d ago
      OP here: I think you're reading too much into the title. It's not about the failure of Rust. It's about where I stepped in with some custom optimizations for better performance. If you read the blog post, the solution implemented is very Rust-y as well. It uses a newtype with custom methods to try and make the code as nice and readable as possible. FWIW this post was very well received on the Rust subreddit. They loved it and it got over 350 upvotes, so that community definitely didn't receive it as some sort of attack on Rust.
      - CyberDildonics 25d ago
        I think you're reading too much into the title. I don't think it's fair to write a misleading title then tell people "they're reading too much into it". Implying one thing then walking it back in the article or having the article be about something totally different, then saying people should read the article and not pay attention to the title is just manipulative to your audience.
        win311fwg 25d ago
        The problem is that there isn't anything misleading about the title. It is well understood that creative packing of data can provide optimizations under certain circumstances. Nobody should have reason to think otherwise. The title quite accurately captures what the rest of the article is about as well as any title possible can. What appears to be happening as we see in several comments is that some users cannot find any technical reason to use Rust so they rely on a belief that it is somehow magically perfect to justify using it and and the idea that it hasn't perfectly found some creative packing solution, despite the rest of us wondering why one would expect any compiler to – it not really being its job, is felt as an attack on their use of Rust. Someone developing irrational feelings towards an inanimate tool isn't on the article's author.
gpm 26d ago
I'd actually point at the other half of the title than the existing comment when being pedantic "Replacing [...] with a 64-Bit Word" isn't quite right, it was replaced with a manually packed 64-Bit Word and the occasional heap allocation. I'm not sure being this pedantic is particularly useful in titles though...
- Dylan16807 26d ago
  It's worth calling out either way. It's not just an encoding scheme, it's a reasonably significant change in architecture.
  - deleted 25d ago
    [deleted]

pbiggar 26d ago

When I think of how a "compiler" could make these optimizations, I think the right place is an optimizing LLM (so, just a regular coding agent that you prompted to find optimizations like this one), making the changes in source at the request of the developer. That provides the dev with adequate input on whether they would like to opt-in to an unsafe optimization like this one. The compiler can continue to do deterministically-safe optimizations.

trickypr 26d ago
That seems like a horrible idea: 1. Do you really want the rust compiler to run at the speed of an llm? 2. Compiler optimisations are already extremely unpredictable with deterministic compilers[1], I hate to think how unpredictable your compiler would be. 3. What if someone else wants to build the software, do they have to decide on optimisations now? What if the optimisation depends on your features not available on old generations of CPU? (There is a reason we don’t compile with -march=native) 4. Compilers already have “unsafe” optimisations, but people rarely enable them (-ffast-math) [1]: https://faultlore.com/blah/oops-that-was-important/ https://faultlore.com/blah/oops-that-was-important/
- pbiggar 26d ago
  You misunderstand me. I'm saying that the developers can make these optimizations with LLMs, at the source level, and thus they don't need to be added to compilers. Like just open Claude Code and ask it to find optimizations. That's the right place for this kind of optimization.
- jmalicki 26d ago
  > Do you really want the rust compiler to run at the speed of an llm? That... might actually be an improvement?
  - Quothling 26d ago
    What do you mean "might"? I can crank Fable or Sol up to max intelligence and they'll spend an hour reviewing my rust SDK for working with our ADLSgen2's, and it'll still be done before the rust compiler has compiled the same project.

RossBencina 26d ago

> One cannot expect a compiler to come up with such encoding. One could, however, imagine a sufficiently expressive language that allows the developer to specify the encoding schema without resorting to raw 64-bit words.

aa-jv 25d ago
This breaks the language. Do you want safety or do you want expression?