@YoussefHosni951: Most engineers don't fail at CUDA because it's hard. They fail because they read the right books in the wrong order. CU…

Most engineers don’t fail at CUDA because it’s hard.

They fail because they read the right books in the wrong order.

CUDA has a reputation for breaking people. The usual advice, “just read PMPP”, drops a beginner straight into the deepest book in the field and then wonders why they quit by chapter 4.

The book isn’t the problem. The sequence is. After going through the whole shelf, here’s the order that actually compounds: each book earns the next one:

𝐂𝐔𝐃𝐀 𝐛𝐲 𝐄𝐱𝐚𝐦𝐩𝐥𝐞 (Sanders & Kandrot): Don’t learn kernels yet. Learn to feel the GPU. This builds the intuition that every later book assumes you already have.

𝐏𝐫𝐨𝐠𝐫𝐚𝐦𝐦𝐢𝐧𝐠 𝐌𝐚𝐬𝐬𝐢𝐯𝐞𝐥𝐲 𝐏𝐚𝐫𝐚𝐥𝐥𝐞𝐥 𝐏𝐫𝐨𝐜𝐞𝐬𝐬𝐨𝐫𝐬 (Hwu, Kirk, El Hajj): The foundation. This is where the mental model gets built: threads, blocks, parallel patterns. Now it lands, because Book 1 gave you something to attach it to.

𝐏𝐫𝐨𝐟𝐞𝐬𝐬𝐢𝐨𝐧𝐚𝐥 𝐂𝐔𝐃𝐀 𝐂 𝐏𝐫𝐨𝐠𝐫𝐚𝐦𝐦𝐢𝐧𝐠 (Cheng, Grossman, McKercher): The architecture book. Memory hierarchy, streams, and the why behind every performance cliff you’re about to hit.

𝐆𝐏𝐔 𝐏𝐫𝐨𝐠𝐫𝐚𝐦𝐦𝐢𝐧𝐠 𝐰𝐢𝐭𝐡 𝐂++ 𝐚𝐧𝐝 𝐂𝐔𝐃𝐀 (Motta): The modern workflow. Nsight profiling, the full dev loop, packaging kernels into libraries you can call from Python.

𝐓𝐡𝐞 𝐂𝐔𝐃𝐀 𝐇𝐚𝐧𝐝𝐛𝐨𝐨𝐤 (Wilt): The reference you grow into. You don’t read this cover to cover. You reach for it when “works on my machine” stops being enough.

𝐂𝐔𝐃𝐀 𝐟𝐨𝐫 𝐃𝐞𝐞𝐩 𝐋𝐞𝐚𝐫𝐧𝐢𝐧𝐠 (Arledge): The payoff. Where kernels stop being an exercise and start accelerating the models you actually ship.

The pattern across all six: intuition before theory, theory before architecture, architecture before application.

Most people quit at the wrong book. Almost nobody quits in the wrong order, because nobody told them that order was the thing.

I think one of them might be enough, which one of them will depend on your use case and goal, and then go build

Yeah well done, keep it up