Comment by fooker
8 hours ago
Safe threading sounds great, as long as the language gets out of my way when I absolutely do not care about safe threading.
I write compilers (and have contributed to the Rust compiler!), and there has been approximately zero times in twenty or so years that thread safety has been a concern.
I don’t buy at all that you’ve coded in a language like C++ and thread safety has never been a concern. Either:
1. You work on esoterically simple problems where nothing is worth threading (implied by you questioning whether it bought any meaningful performance).
2. You code in languages like Rust where it’s not a problem or significantly less of one (Go, Java, c#, Haskell, Ocaml, etc).
You’re being awfully dismissive of people who’s experiences don’t match yours, especially when it seems like your experience isn’t the norm.
Thread safety has not usually been a concern because it’s pretty rare to use raw threads in C++.
Rust folks always seem to assume people write C++ like it is 1995.
> implied by you questioning whether it bought any meaningful performance
This is the first thing you should always ask when you do anything with parallelism! Are you familiar with Amdahl’s law?
I write a bit of everything, including a little Rust CAD library which is a continuation of work I did in C++ 20 years ago. The C++ version was never multithreaded. The Rust library was fully multithreaded in an afternoon by importing Rayon behind a cargo feature, and using par_iter in place of iter in a few hot loops. That alone made the rewrite worth it.
Great, how much faster was this multithreaded version for a real use case?
That afternoon effort on the hot loops netted ~3x improvement on the test suite on an 8 core machine. The test suite is intentionally minimal, so I'd say that represents a reasonable low bound. The greater the number of polygons in an operation, the more it would benefit.