3 ms·

> Rust is also very focused on performance, and Rust users do care about making such trade-offs consciously. You care about binary size, I may care about inline

> Rust is also very focused on performance, and Rust users do care about making such trade-offs consciously. You care about binary size, I may care about inlined autovectorized code. Everyone can agree with this. The question is whether this ought to be a property of the target platform or whether this ought to be a property of the software itself. Rust implicitly takes the stance that it is a property of the software. Suppose we had a chip today that runs poorly due to icache thrash, so you rewrite portions of it with dynamic dispatch. Then someday we get a chip with an insanely large icache that would benefit from static dispatch. You rerewrite it. Or today if you work on embedded linux and want to use a rust library whose primary users are on powerful servers. I will concede that I have no idea whether it’s possible to come up with a reasonable abstraction for this, because you certainly know more than me.

pornel 5y ago
There are already plenty of architectural differences that change optimal trade-offs in the code, e.g. memory speed affects lookup tables vs recomputation choice and inlined data vs pointer chasing, branch prediction cost affects conditionals vs branchless/redundant code, data layout needs to be adjusted for SIMD and cache line sizes, memory hierarchy and core topology limit when it's beneficial to parallelize algorithms, and so on. These trade-offs don't even require oddball futuristic CPUs, and already vary significantly even within existing CPU families. There are some languages that focus on "what" and magically optimize "how" (ISPC, Halide, and good'ol SQL), but for better or worse, Rust has chosen the "portable assembly" angle and micromanagement of everything. The upside is that you have very few surprises and "performance cliffs", and rest assured that if something is slow, you have enough control to fix it (as opposed to e.g. JIT-based language).

pornel 5y ago

There are already plenty of architectural differences that change optimal trade-offs in the code, e.g. memory speed affects lookup tables vs recomputation choice and inlined data vs pointer chasing, branch prediction cost affects conditionals vs branchless/redundant code, data layout needs to be adjusted for SIMD and cache line sizes, memory hierarchy and core topology limit when it's beneficial to parallelize algorithms, and so on. These trade-offs don't even require oddball futuristic CPUs, and already vary significantly even within existing CPU families. There are some languages that focus on "what" and magically optimize "how" (ISPC, Halide, and good'ol SQL), but for better or worse, Rust has chosen the "portable assembly" angle and micromanagement of everything. The upside is that you have very few surprises and "performance cliffs", and rest assured that if something is slow, you have enough control to fix it (as opposed to e.g. JIT-based language).