▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=4nJ2tEPD4-k
• Original title :: Learning is Cool

ThePrimeagen reacts to the Hacker News backlash against Mitchell Hashimoto's blog post "Everyone Should Know SIMD," then spends the rest of the video actually learning SIMD from scratch by writing a newline-finding benchmark, comparing a naive scalar loop against a hand-rolled SIMD version.

The video opens with ThePrimeagen describing how he first saw a tweet praising Hashimoto's practical SIMD writeup (using real examples from Ghostty) and initially shrugged it off, since a flame graph of his own game showed only 0.83% of runtime spent in the update loop, i.e., no real performance pressure to justify learning SIMD. The next day the same post hit Hacker News and drew hostile comments, which he reads aloud: people accusing Hashimoto of "misleading" developers by claiming "everyone" should know SIMD, and pushing back specifically on the article's opening line that "SIMD can be simple to understand." ThePrimeagen argues the backlash proves the article's original point: engineers dismissing SIMD as needlessly complex or niche is exactly the attitude Hashimoto was writing against. He frames this as a broader complaint about developers who want to avoid learning anything not immediately billable, contrasting that with his own instinct to "rather work with the person that wants to know more."

Motivated to settle the argument empirically, he sets out to learn SIMD by building a small project: scanning long log lines to find newline characters as a stand-in for JSON line-parsing (explicitly skipping the JSON parsing itself). He explains SIMD conceptually as Single Instruction Multiple Data: instead of comparing one byte against a target value at a time, you load a chunk of bytes into a vector register and compare the whole vector in one operation, then inspect the resulting bitmask to see which lane(s) matched.

He walks through the concrete implementation. His naive/scalar version simply indexes byte by byte looking for a newline. The SIMD version follows five steps he learned from the blog post's pattern: (1) broadcast — build a constant vector of "lanes" copies of the newline byte (hex 0x0A), where "lanes" is however many bytes fit in one SIMD register on his CPU (256-bit register, so 16 lanes of 8-bit bytes); (2) iterate the input 16 bytes at a time instead of 1 byte at a time; (3) compare the 16-byte input chunk against the 16-byte newline constant in a single vector equality operation; (4) extract the most significant bits into a mask and do a cardinality check — if nonzero, at least one lane matched, so scan that small vector manually to find which lane; (5) handle the "scalar tail" — the remaining bytes at the end of the buffer too short to fill a full 16-byte vector, processed one byte at a time the old-fashioned way.

He reports timing results: the naive scalar version took about 1.54 seconds, while the SIMD version was "massively faster" (exact number not stated on screen but described emphatically). His conclusion is that the whole exercise took about an hour, including learning the concept, writing the code, and debugging it, and that despite having no real performance need for SIMD in his own game (given the earlier flame graph showing 0.83% time in update logic), the exercise was worthwhile: it clarified why "structure of arrays" data layouts (versus "array of structures") matter for future SIMD-friendly optimizations, and it was simply enjoyable to understand rather than remaining ignorant. He closes by siding firmly with Hashimoto: yes, everyone should try to learn SIMD, even if they never use it, preferring to carry "useless" knowledge in the back of their head over being the kind of developer who argues against learning things. He also notes, as a quick aside, that Go 1.6 is adding an experimental SIMD architecture package, underscoring that hardware vector instructions are becoming more mainstream and accessible even in high-level languages.

The video is sponsored by WorkOS (enterprise auth/SSO/passkeys), mentioned early on as a way to avoid hand-rolling authentication.