41
edits
Changes
m
One We found that the most efficient version of the code was the 2d version that used constant memory and did not use shared memory. Because the shared memory version of the issues encountered when trying kernel required synchronization of threads to profile allocate shared memory every time a kernel was run, and a kernel was run 5000 times for each version of our code , the if statements required to set up the ghost cells for shared memory may have created a certain amount of warp divergence, thus slowing down the runtimes of each individual kernel. Below, are two images that show 4 consecutive kernel runs for both global and shared versions of the code. It is apparent that shared kernel runs actually take more time than the global memory versions. TIMES FOR THE GLOBAL KERNEL[[File:kernelGlobalTimes.png]] TIMES FOR THE SHARED KERNEL [[File:sharedKernelTimes.png]] Note how the run times for each kernel with shared memory are significantly longer than those with global. To try to determine if this issue was one of warp divergence, we tried to time a kernel with global memory that also initialized shared memory, although referenced global memory when carrying out the actual calculations: [[File:GlobalInitSharedKernelTimes.png]] The run of a kernel that allocated shared memory using a series of if statements, but executed instructions using global memory is shown in the figure above. While slightly longer than the run with global memory where shared memory is not initialized for ghost cells, it still takes less time to run than the fact version with Global memory. It is likely that different Our group members were trying 's attempts to work with different hardwareemploy shared memory failed because we did not adequately schedule or partition the shared memory, and the kernel was slowed as a result. The hardware changed based on supposed occupancy of a block of shared memory was 34x32 (the dimensions of the rooms we ended up profiling in shared memory matrix) x 4 (open lab vs lab computers vs laptops the size of a float) which equals 4,352 bytes per block, which is supposedly less than the maximum of about 49KB stated for a device with different video cards)a 5. The above graph 0 compute capability (which this series of tests on individual kernel run times was done performed on an open lab computer with ). With this is mind it is still unclear as to why the shared memory performed more poorly that the global memory implementation. Unfortunately our group's inability to effectively use profiling tools has left this discrepancy as a QuadroK620 cardmystery.[TODO: INCLUDE PROFILING BREAKDOWNS OF INDIVIDUAL In conclusion, while it may be possible to parallelize the algorithm we chose well, the effort to do so would involve ensuring that shared memory is properly synchronized in two block dimensions (NOT 50002 dimensions of ghost cells rather than the 1 we implemented) KERNEL RUNS TO SEE SPECIFIC TIMELINE FEATURES, and to ensure that shared memory is allocated appropriately such that maximum occupancy is established within the GPU. Unfortunately, our attempts fell short, and while implementing constant memory seemed to speed up the kernel a bit, our solution was not fully scalable in both dimensions, and shared memory was not implemented in a way that improved kernel efficiency. EXPLAIN THE DIFFERENCES IN RUN TIMES]
→Assignment 3
</source>
<nowiki>****************</nowiki>
A NOTE ON SCALABILITY:
In our attempts to make the kernel scalable with ghost cells, we scaled along one dimension. However, we were inconsistent in our scaling. The 1D kernel scaled along the n (y) dimension while the 2d kernels scaled along the m (x) dimension. Scaling along the x dimension, while allowing results to be testable between serial and 2D parallelized versions of the code, produced distributions that were strangely banded and skewed. In other words, we made the code render weird things faster:
[[File:MDimensionScale.png]]
FINAL TIMINGS <pre style="color: red"> THE GRAPH IMMEDIATELY BELOW IS INCORRECT: there was an error recording the 1D runtimes for assignment 2</pre>
PROPER TIMINGS:
[[File:code_timingsCode_timings2.png]] Blue = Serial (A1)Orange = Parallel (A2)Grey = Optimized Global (A3)Yellow = Optimized Shared (A3)
The above graph includes the total run times for the serial code, the 1D kernel from assignment 2, a kernel with global and constant memory with a 2D thread arrangement, and the same 2D arrangement but with shared memory utilizing ghost cells.
We found that the most efficient version of the code was the 2d version that used constant memory and did not use shared memory. Because the shared memory version of the kernel required synchronization of threads to allocate shared memory every time a kernel was run, and a kernel was run 5000 times for each version of our code, this increased overhead for memory setup actually made the execution slower than the version with global memory.
