The crazy part about this is that (auto) vectorization in Rust looks something like this: iter.chunks(32).map(vectorized)
Where the vectorized function checks if the chunk has length 32, if yes run the algorithm, else run the algorithm.
The compiler knows that the chunk has a fixed size at compile time in the first block, which means it can now attempt to vectorize the algorithm with a SIMD size of 32. The else block handles the scalar case, where the chunk is smaller than 32.
Sometimes, you just need to know if an idea will even work or what it would look like. If you have to refactor half the codebase (true story for me once), it makes the change a much harder sell without showing some benefits. IE, it keeps you from discovering better optimizations because you have to pay the costs upfront.
In Rust, it's a lot easier to refactor half the codebase than it would be in another language. Once you're done fighting the compiler, you're usually done! instead of NEVER being sure if you did enough testing.
I don't know either. Personally I can spend days or more on exploratory efforts that end up scrapped. My source code is usually version controlled, so I never have to worry about messing things up. But I suppose not everyone has this kind of time for stuff that isn't guaranteed to pan out.
Sometimes I will prototype an exploration in another crate or module so I can see if there are performance gains in a more limited application. Sometimes these explorations will grow into a full rewrite that ends up better than if I had refactored.
> Sometimes, you just need to know if an idea will even work or what it would look like.
I think what GP is trying to say is that the value of such exploration might be limited if you end up with something incompatible with "proper" Rust anyways.
I suppose it depends on how frequently "transition through invalid Rust while experimenting and end up with valid Rust" happens instead of "transition through invalid Rust while experimenting and end up with invalid Rust", as well as how hard it is to fix the invalid Rust in the latter case.
In my case, I was adding a new admin api endpoint, which meant pulling through a bunch of stuff that was never meant for the api and got in a fight with the borrow checker. For me, I just wanted to see if I broke something on a feature level (it was never meant to be exposed by the api after all), and I didn’t care about memory safety at that point. Refactoring it properly just to get memory safety just to see what would have broke, ended up breaking out of my time-box, so it never saw the light of a merge request. Had I been able to prove the concept worked, I would have opened a PR and against the open issue to find out the best way to refactor it “properly” into a right way. As it was, I would need to completely guess what the right way was without ever even knowing if the idea would work in the first place.
I guess that doesn't neatly fall into the categories I described, though I think it's closer to the former than the latter.
That being said, I think what you describe sounds like a case where relaxed checks could be beneficial. It's the eternal tradeoff of requiring strong static checks, I suppose.
Can't you usually just throw some quick referenced counted cells in there, to make the borrow checker happy enough for a prototype without refactoring the whole code base?
Yeah yeah, every gcc update I need to patch rocksb sources somehow, because now compiler doesn't ship some includes by default.
I remember only a single breakage of previously compiling code with the time crate because of a change in type inference, but even there the compiler told me to update the lib. And that’s in 6 years of using Rust.
Your favorite llm will give you several good options. You can use an mpsc channel where you have a task per sender which waits on each branch in the select and then sends a message and then just wait on the receiver end of that channel. Or you could use https://docs.rs/futures/latest/futures/future/fn.select.html (or the select_all version). Both make it more obvious what is going on. The last way would be to implement a future manually. This would probably be my favorite option in many cases as it would be least overhead, but if you've never implemented a future it may be a bit intimidating.
reply