Day 14/100 of the Mlsys journey:
- Completed chapter 7: convolution, learnt constant memory and effective caching
- Chapter 8: Stencil, learnt about how GPUs can help build applications involving differential equations
- Chapter 9: Parallel histogram, A single thread is now not mapped to a single output cell, instead, multiple threads now modify a single cell. Topics related to contention, privatization came here.
Day 13/100 of the MLsys journey:
- Delayed posting and working on this for a bit because of my resignation process. I'm unemployed again...
- Worked on modifying torch.profiler to generate json traces instead of tensorboard traces, since tensorboard traces are deprecated now.
- Used perfetto to analyze the generated traces.
Day 12/100 of the Mlsys journey:
- Setup pytorch DDP for the MNIST dataset. Will begin with a simple dataset before adding complexity.
- Added simple visualizations to verify loss improvements.
- Need to add baselines in training experiments to measure and improve performance.
Day 11/100 of the Mlsys journey:
- Completed my matrix multiplication benchmarks on a T4 GPU. Need to add further enhancements to it.
- Started working on pytorch DDP.
Day 10/100 of the MLsys journey:
- Completed chapter 6 exercises.
- Setup matrix multiplication repo and code for writing and benchmarking different kernels.
Day 9/100 of the MLsys journey:
Finished PMPP chapter 6. Learnt about thread coarsening. The performance improvements were pretty significant.
The idea is to let a thread do multiple "tasks" instead of doing just one task. This prevents overheads that are caused due to parallel execution to some extent.
These 6 chapters are actually fundamental to understanding how a GPU works. They also leave you with the skill of reading Nvidia whitepapers on GPU architectures...
Day 8/100 of the MLsys journey:
The enemy of GPU performance is "Strided Access", ie, not accessing elements consecutively.
Because DRAM reads in bursts, asking for data in a vertical column (stride) is inefficient - it's like taking 32 cars to move 32 people who live in the same house.
Multiple entries of the data are fetched at once so that you could access other elements quickly. This hides memory latency. However, for strided retrieval, data isn't present in a consecutive order. So multiple fetches are supposed to be performed which decreases efficiency...
The fix is "Coalescing."
I explored "Corner Turning" - a technique where you load data into Shared Memory (which doesn't care about strides) to swap rows/columns, ensuring the final write to Global Memory is perfectly linear.
Also learned about memory Banks and how Interleaving addresses helps keep all Channels busy using round robin scheduling.