When it says to change all array accesses to A[0], this just means that we consider using cache only and that memory latency would no longer be an issue in our analysis?
xiaoguaz
@Lawliet If we "change all array accesses to A[0]", the A[0] will be stored in cache and have extremely great locality. If out original program have good locality, this change will not bring too much improvement. If our program can improve a lot because of that, we will know where may be some space to improve in data locality.
patrickbot
When we remove math, why should we suspect a memory bottleneck? Couldn't it still be coming from sync overheads?
Instead of removing all the math, suppose we replace memory fetches with hard-coded values (e.g. 0, or pointers to stack allocated variables) and looked at the behavior of the program. Is this a better way to see if it's a memory bottleneck?
mallocanswer
@patrickbot Using hard-coded values may also change the computation time. For example, like question 3 in exercise 2, if the input is random, the core will run both the if and else branches. However, if the input is the same, the core could only run one branch of the code, which may affect the execution time. Then in your suggestion, you both change the computation time and memory fetch time which violates Control Variable Method.
Allerrors
@patrickbot I think remove math should be combined with remove atomic operations to test which one is the bottleneck. It doesn't mean if you use one method, you can't use another.
When it says to change all array accesses to A[0], this just means that we consider using cache only and that memory latency would no longer be an issue in our analysis?
@Lawliet If we "change all array accesses to A[0]", the A[0] will be stored in cache and have extremely great locality. If out original program have good locality, this change will not bring too much improvement. If our program can improve a lot because of that, we will know where may be some space to improve in data locality.
When we remove math, why should we suspect a memory bottleneck? Couldn't it still be coming from sync overheads?
Instead of removing all the math, suppose we replace memory fetches with hard-coded values (e.g. 0, or pointers to stack allocated variables) and looked at the behavior of the program. Is this a better way to see if it's a memory bottleneck?
@patrickbot Using hard-coded values may also change the computation time. For example, like question 3 in exercise 2, if the input is random, the core will run both the if and else branches. However, if the input is the same, the core could only run one branch of the code, which may affect the execution time. Then in your suggestion, you both change the computation time and memory fetch time which violates Control Variable Method.
@patrickbot I think remove math should be combined with remove atomic operations to test which one is the bottleneck. It doesn't mean if you use one method, you can't use another.