Hacker News Reader

Comment by timschmidt | Hacker News Reader

Safe threading seems like fully exploiting hardware features to me. That's the biggest thing smart pointers and Rc, Arc, and Cell types enable. Perhaps I could have been clearer.

The comment about memory layout was an additional point that dealing with hardware requires that you format, align, and position information in memory as the hardware expects, which requires either exposing those details, or encoding them in a runtime.

View on HN

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 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.

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?

Whether you use raw threads or not in no way changes that thread safety is completely independent of that; eg a work stealing queue of a fixed thread pool still can have issues. And high performance code often needs you to implement certain constructs which means someone has to implement them and be sure they’re safe.

Also I’ve worked on a lot of different codebases, from iOS at Apple to Android at Meta, from machine learning to VR video streaming. Claiming that people aren’t using raw threads in C++ a) isn’t borne out by the evidence b) is ignoring the challenges of writing thread safe code that has nothing to do with manually creating a thread. Hell, my team hit a libc++ bug in std::conditional_var.

IOS and related codebases at Apple are not using raw threads unless unavoidable.

> 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.

What kind of charmed life do you lead to where use of reliable abstractions over threads is common in C++ codebases you touch?

My experience has been the exact opposite.

> My experience has been the exact opposite

Okay, can you try and find a relatively modern large open source C++ codebase that actively uses raw threads?

Reply on news.ycombinator.com