Thanks for expanding on your viewpoint. > Why would writing an optimizing compiler qualify as territory for directly writing SIMD code, but anything else is of

Thanks for expanding on your viewpoint. > Why would writing an optimizing compiler qualify as territory for directly writing SIMD code, but anything else is off the table? I understood "directly writing" to mean assembly or even intrinsics. In general, I would advise not touching intrinsics directly, because the intrinsic definitions themselves have in several cases had bugs. Here's one AVX-512 example: https://github.com/google/highway/commit/7da2b760c012db04103d96a930e9c1cb445667ca https://github.com/google/highway/commit/7da2b760c012db04103.... When using a wrapper library, these can be fixed in one spot, but every direct user of intrinsics has to deal with it themselves. > it's extremely easy to write your own wrappers (like I did) and not take a dependency. A good trade IMO I understand wanting to reduce dependencies. The tradeoff is a bit more complex: for example many readers would be familiar with Highway terminology. We have also made efforts to be a lightweight dependency :) > doing it yourself as a learning exercise has value. Understandable :) Though it's a bit regrettable to tie your user code to the library prototype - if used elsewhere, it would probably have to be ported. > The fact is, the library code is super fucking boring. True for many ops. However, emulating AES or other complex ops is nontrivial. And it is easy to underestimate the sheer toil of keeping things working across compiler versions and their many bugs. We recently hit the 3000 commit mark in Highway :)