I'm sure he agrees that algorithmic improvements are more effective than constant-factor improvements like optimizing the assembly code. I think he'd also agree

I'm sure he agrees that algorithmic improvements are more effective than constant-factor improvements like optimizing the assembly code. I think he'd also agree that algorithmic improvements are also easier to make in higher-level languages than in assembly. I'd argue, then, that it's more worth your time to spend your time iterating and squeezing as much algorithmic optimization of the higher-level program, than squeezing as much assembly optimization out of x86 as you can. There is the case that there is a solution is known to be algorithmically optimal, or there is only one leading contender for optimal and it's unlikely to be toppled and you have to have a PhD and a couple postdocs in theoretical CS to begin to approach a way to challenge it, in which case it would indeed be more worth your time to optimize the assembly code. I hear Adobe Photoshop uses an FFT written in optimized assembly because almost every CPU-intensive thing they do uses it. Has he taken a gander at that? Pretty sure the fastest known way to calculate prime numbers changes a couple times a year. However, that is only the case with textbook CS problems, and I think most HN members would agree that in industry, software engineering is almost never actually about solving textbook problems, and tends to have quirks that lead to clever algorithmic optimizations that are continually being discovered.