Shouldn't granularity come into effect when testing small test cases such as this one? If a program is written properly I don't see how it should decrease in efficiency
jkorn
@dasteere, I think this is just looking at the purely parallel program, to make this point. You're right, using granularity to change the algorithm used on smaller problem sizes would probably prevent this from happening. The reason for the decrease in speedup is addressed in the following two slides, and is due to a decrease in arithmetic intensity for the smaller problem sizes.
pdp
Here, the problem size could be small that parallelism across 32 processors is not proving beneficial due to increased communication overheads.
1_1
The speedup drops significantly at 32 processors because as the tile size is much smaller now so the ratio of area to perimeter is much less. Thus, the ratio of computation to communication decreases.
Shouldn't granularity come into effect when testing small test cases such as this one? If a program is written properly I don't see how it should decrease in efficiency
@dasteere, I think this is just looking at the purely parallel program, to make this point. You're right, using granularity to change the algorithm used on smaller problem sizes would probably prevent this from happening. The reason for the decrease in speedup is addressed in the following two slides, and is due to a decrease in arithmetic intensity for the smaller problem sizes.
Here, the problem size could be small that parallelism across 32 processors is not proving beneficial due to increased communication overheads.
The speedup drops significantly at 32 processors because as the tile size is much smaller now so the ratio of area to perimeter is much less. Thus, the ratio of computation to communication decreases.