An interesting story, but I’m not sure about the conclusion. It sounds as if lock contention was the problem here. I’m a bit surprised that retain / release was hitting this because I thought Apple’s implementation used some spare bits in the isa pointer and didn’t need to acquire a lock unless this overflowed.
There are also other reasons for wanting to do the first refactoring. It’s incredibly hard to debug Monte-Carlo simulations if you use a cryptographically secure random number generator. Ideally, you’d:
Generate a single cryptographic random number.
Use this as the seed for a PRNG.
Use that PRNG to seed a PRNG for each independent run.
If you record the first number then you can deterministically reproduce the entire run and so reproduce bugs that only occur with specific inputs. If you output that number in CI testing then you can debug CI failures locally.
I agree with this, but to take it further, I think the premise of the article is a bit misguided. I could be mistaken, but I think much of what was discussed can be considered constant-time, which Big O doesn’t care so much about. It could use a better title I think. But still fun to look at where locks play a part!
Even if I didn’t care about security, I would still care about randomness quality if that randomness was feeding into a simulation. GKLinearCongruentialRandomSource likely doesn’t even have a long enough period let alone other distribution measures you’d want. While the author switched to xoshiro, the fact that this was ever a choice is concerning.
For doing better, David below describes the way I’m familiar with doing things, but I’ll note your prng still needs to be good enough quality that your simulation measures what you’re looking for rather than the quality of the prng.
The title is also misleading since a more accurate conclusion would be that shared mutable state is bad for parallel performance.
An interesting story, but I’m not sure about the conclusion. It sounds as if lock contention was the problem here. I’m a bit surprised that retain / release was hitting this because I thought Apple’s implementation used some spare bits in the
isapointer and didn’t need to acquire a lock unless this overflowed.There are also other reasons for wanting to do the first refactoring. It’s incredibly hard to debug Monte-Carlo simulations if you use a cryptographically secure random number generator. Ideally, you’d:
If you record the first number then you can deterministically reproduce the entire run and so reproduce bugs that only occur with specific inputs. If you output that number in CI testing then you can debug CI failures locally.
I agree with this, but to take it further, I think the premise of the article is a bit misguided. I could be mistaken, but I think much of what was discussed can be considered constant-time, which Big O doesn’t care so much about. It could use a better title I think. But still fun to look at where locks play a part!
Even if I didn’t care about security, I would still care about randomness quality if that randomness was feeding into a simulation. GKLinearCongruentialRandomSource likely doesn’t even have a long enough period let alone other distribution measures you’d want. While the author switched to xoshiro, the fact that this was ever a choice is concerning.
For doing better, David below describes the way I’m familiar with doing things, but I’ll note your prng still needs to be good enough quality that your simulation measures what you’re looking for rather than the quality of the prng.
The title is also misleading since a more accurate conclusion would be that shared mutable state is bad for parallel performance.