Update blog

Author: cmdr2

content/blog/2025-11-13-1763027191.md

@@ -39,7 +39,7 @@ For fusion, PolyBlocks uses a Polyhedral slicing-based approach in the affine pa
 
 Some other random notes:
 - There are a fixed number of physical registers in each SM/multiprocessor. These are divided (logically) between the threads running on that SM. So the number of threads that can run at a time is determined by the total number of physical registers divided by the number of registers required by each thread.
-- This means that there's no one-right-answer for kernel fusion. Jobs that have slow memory transfers would benefit from smaller kernels, so that lots of threads can run in parallel (to hide the latency of memory transfers), while jobs that are light on memory transfers can have heavier-but-fewer kernels.
+- This means that there's no one-right-answer for kernel fusion. Jobs that have slow memory transfers would benefit from smaller kernels, so that lots of threads can run in parallel (to hide the latency of memory transfers), while jobs that are light on memory transfers can have heavier-but-fewer kernels. Edit: Wait, is this correct? Shouldn't it be the other way round?
 - User-facing API: TensorRT-style AOT compiled engine files, or Torch/Mojo/PolyBlocks-style JIT compilers inside Python, or in between (e.g. TensorRT-RTX).
 - For the host-side code (i.e. the code that talks to the driver), it might be a good idea to generate C++ code that people can compile themselves (for power users). But this would add more hoops for the user to jump through, so maybe this might be just an option?
 - Quantization hardware-awareness in the compiler is important, so that it can factor that in during tiling and memory layout.