The humble for loop in Rust

Post by arllk » Fri, Dec 13, 2024, 1:03 AM UTC

ridiculous_fish wrote: post #19

nemo1618 wrote: post #4

> Why is map so much faster? I am not sure. I suspect with the map() option the Rust compiler figures out it can avoid allocations altogether by simply writing over the original vector, while with the loop it can't. Or maybe it's using SIMD? I tried to look in the compiler explorer but I'm not competent enough yet to figure it out. Maybe someone else can explain! Yep, it's due to SIMD -- in the assembly for `using_ma…

SIMD is true, but the original guess is correct, and that effect is bigger! using_map is faster because it's not allocating: it's re-using the input array. That is, it is operating on the input `v` value in place, equivalent to this: pub fn using_map(mut v: Vec ) -> Vec { v.iter_mut().for_each(|c| *c += 1); v } This is a particularly fancy optimization that Rust can perform.

Post by chabska » Fri, Dec 13, 2024, 1:58 AM UTC

recursive wrote: post #39

kstrauser wrote: post #33

Earlier quoted context omitted.

That surprises me, and I'd expect the FP version to be at least as fast, with the option to be much faster. With the for loop, you're saying "run against this value, then run against the next one, then run against the next one, then...". If the compiler isn't certain that the iterations aren't free of side effects, then it would have to run each one in order before moving on to the next. `.map(...)` implies "I don't…

> `.map(...)` implies "I don't care about ordering, and therefore you don't need to, either" In plenty of languages, no such implication exist. `map` can be specified to run in a certain order.

Post by xpe » Fri, Dec 13, 2024, 2:26 AM UTC

Post by IshKebab » Fri, Dec 13, 2024, 7:25 AM UTC

mijoharas wrote: post #34

IshKebab wrote: post #17

Yeah I kind of wish there was a way to still use `?` inside map/filter/etc. lambdas. Error handling with that functional style is generally way more awkward than for loops, but also it's often more elegant in other ways (e.g. Rayon). I think Ruby has some kind of feature that works like that but IIRC it looked less foot-gun more foot-bazooka. Does anyone know of any languages that solve that problem elegantly?

What's the ruby feature you're referring to?

Post by ynik » Fri, Dec 13, 2024, 1:00 PM UTC

varikin wrote: post #37

kstrauser wrote: post #33

Earlier quoted context omitted.

That surprises me, and I'd expect the FP version to be at least as fast, with the option to be much faster. With the for loop, you're saying "run against this value, then run against the next one, then run against the next one, then...". If the compiler isn't certain that the iterations aren't free of side effects, then it would have to run each one in order before moving on to the next. `.map(...)` implies "I don't…

Streams (FP in java) is slower than for loops for a couple reasons. A big one is java doesn't natively support real closures or lambdas. It does have syntax for them, but that is just syntactic sugar for an class with a single method under the hood. So streams end up doing lot of object allocation and garbage for the fake closures. Also, streams operate on objects, so they have to be on the heap. You can't use them w…