First of all, it did not even occur to me that when writing parallel code, I was assuming that my code is the only thing running on the machine. I suppose I am, but I've never even really thought about it. If I did not make this assumptions, what kinds of things would change about the way I parallelized my code?
Some of the other problems associated with using locks (and why you may want to use lock-free data structures), which I think might've been mentioned earlier in the lecture: reading and writing locks for every operation results in more memory transactions, and storing a lock for each smaller structure in a larger data structure can take up a lot of space in memory.
This comment was marked helpful 0 times.
idl
@jmnash yeah me neither. I guess this is a fair assumption to make, because each program is in its own process anyways and so races can't occur within black boxes. However of course we need to keep in mind how performance can be affected by other users on the same machine (like on Blacklight).
This comment was marked helpful 0 times.
mchoquet
I think the main reason we assume our code is the only thing running is because that's the way it's been in this class; our goal has been to write the fastest-running code possible, and code runs fastest when it has exclusive access to the machine. In particular, other programs running on the machine can cause weird and inconsistent performance patterns, which is frustrating for students and bad for autograding.
First of all, it did not even occur to me that when writing parallel code, I was assuming that my code is the only thing running on the machine. I suppose I am, but I've never even really thought about it. If I did not make this assumptions, what kinds of things would change about the way I parallelized my code?
Some of the other problems associated with using locks (and why you may want to use lock-free data structures), which I think might've been mentioned earlier in the lecture: reading and writing locks for every operation results in more memory transactions, and storing a lock for each smaller structure in a larger data structure can take up a lot of space in memory.
This comment was marked helpful 0 times.
@jmnash yeah me neither. I guess this is a fair assumption to make, because each program is in its own process anyways and so races can't occur within black boxes. However of course we need to keep in mind how performance can be affected by other users on the same machine (like on Blacklight).
This comment was marked helpful 0 times.
I think the main reason we assume our code is the only thing running is because that's the way it's been in this class; our goal has been to write the fastest-running code possible, and code runs fastest when it has exclusive access to the machine. In particular, other programs running on the machine can cause weird and inconsistent performance patterns, which is frustrating for students and bad for autograding.
This comment was marked helpful 0 times.