RustConf 2019 - Taking Constant Evaluation to the Limit by Oliver Schneider

Ғылым және технология

RustConf 2019 - Taking Constant Evaluation to the Limit by Oliver Schneider
Have you ever wanted to write a static with a complex initial value? Are you programming microcontrollers? Do you want to run as little code as possible at runtime or are you trying to reduce your memory footprint? If you answered yes to any of these questions, then you probably want to evaluate all-the-things™ at compile-time with a constant evaluator.
This talk will focus on explaining the inner workings of the new theoretically unrestricted constant evaluator in rustc (nicknamed Miri for "MIR interpreter") and give a short outlook on the future features Miri will enable in the Rust language.

Пікірлер: 5

  • @bytefu
    @bytefu4 жыл бұрын

    It should be noted that many things, that const eval is supposed to be able to do, are possible now with code generation via build.rs. For example, you can precompute a CRC table and emit a module with it to src, no problem. Of course, it's not very ergonomic and has limitations, but it's better than nothing. By nothing I mean features that are missing from const eval, I am not calling const eval useless 😀. If anyone wants to see what you can potentially do with it, just look what D can do with its CTFE right now. Rust will be there in no time (by compiler development standards).

  • @bernardlowe5433
    @bernardlowe54334 жыл бұрын

    I feel like we won't be able to predict the full extend the awesomeness that const eval will bring until it gets all the basic features it needs and people start using it. There must be so many cool new design patterns and tricks that it will allow. But when thought in the abstract, what would benefit the most from being able to compute things at compile time? Well, if you have a polyglot app (which is especially common for the Web to use a combination HTML, CSS, JS, Typescript, Rust, Wasm), then const eval opens a lot of possibilities for flexible code generation, because code generation is something that you want to do at compile time. Another thing that I imagine become possible are all kinds of crazy optimizations where you precompute things at compile time for parts of data that you already know, or avoiding the need for heap. Not sure if this is a good idea, but a more practical example doesn't come to mind, so I'm going to use HTML generation as an example. You could even generate HTML without needing heap. Let's say that you have a page that know nearly everything about, but the only thing that changes is `current_date`. You need to get that `current_date` at runtime and return HTML. Well, if you have a max size for that data that varies, like that it can have 20 chars max, then you basically know the max size of your WHOLE data (in this case HTML page) and can go and preallocate that. Even if the string is not fully known, if your data somehow can have padding (in case of HTML you can do `12 September `) then it would work even with some variability in size, as long as you agree on the maximum possible size (and if at runtime it's less than max, then the rest you just fill with padding). So, you already have your whole buffer precomputed and you just replace the part that you need at runtime.

  • @JonathanDunlap

    @JonathanDunlap

    4 жыл бұрын

    If this sounds exciting to you, I'd recommend checking out the D language, which has the best implementation of const-evaluation of any language I know. There's really fascinating things are can do- the best I've seen is a compile time regex parser that automatically creates a state machine for that particular regex expression. :)

  • @MrR0FL0LMA0MG

    @MrR0FL0LMA0MG

    4 жыл бұрын

    Create complex SQL query at compile time?

  • @Harry-sf9sc
    @Harry-sf9sc4 жыл бұрын

    Love it

Келесі