3 ms·
> In practice, I never had a problem with "restrict". That's exactly because it's too dangerous and the developers quickly learn to avoid it instead of using i
by Expurple 1y ago
> In practice, I never had a problem with "restrict".
That's exactly because it's too dangerous and the developers quickly learn to avoid it instead of using it where appropriate! Same with multithreading. C leaves a lot of optimization on the table by making the available tools too dangerous and forcing people to avoid them altogether.
That's how you get stuff like memory-safe Rust PNG decoders being 1.5x faster than established C alternatives that had much more effort put into them (https://www.reddit.com/r/rust/comments/1ha7uyi/memorysafe_png_decoders_now_vastly_outperform_c/ https://www.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...). Or the first parallel CSS engine being written in Rust after numerous failed attempts in C++ (https://www.reddit.com/r/rust/comments/7dczj9/can_stylo_be_implemented_in_another_language_like/dpx85es/ https://www.reddit.com/r/rust/comments/7dczj9/can_stylo_be_i...). Read those threads in full, there are some good explanations there.
> you need to exaggerate the practical problems in C
I thought, the famous "70% of vulnerabilities" report settled this once and for all.
- uecker 1y agoNa, sorry. The "70%" is just nonsense. And cherry picking individual benchmarks too.
- Expurple 1y ago> The "70%" is just nonsense. Care to elaborate why? > And cherry picking individual benchmarks too. Do you have any general, comprehensive benchmarks or statistics that would indicate the opposite? I would include one if I had one at hand, because that would be a stronger argument! But I'm not aware of such benchmarks. I have to cherry pick individual projects. I don't want to. I still claim that, as a general trend, Rust replacements are faster while also being less bug-prone and taking much less time to write. Another such example is ripgrep.