3 ms·

Speculative ad hominem aside, the point in this case was to learn to write code so that good compilers can output performant SIMD-heavy code. It's not trivial a

Speculative ad hominem aside, the point in this case was to learn to write code so that good compilers can output performant SIMD-heavy code. It's not trivial and can include a lot of trial and error and looking at assembly. But once you learn these tricks, code can be clean, portable and performant, I would say that's a win.

EpicEng 8y ago
> Speculative ad hominem aside I can only judge you by what you say here. Obviously I don't know you, but what other choice do I have? In my experience, those who rely on their tools to do everything for them are useless when things go sideways. > the point in this case was to learn to write code so that good compilers can output performant SIMD-heavy code No, the point is that comments like yours serve little purpose. No one is suggesting that you should roll your own lib for matrix math in every situation. However, if you _understand_ what happens behind the scenes you write better code and can more easily diagnose performance issues. The problem with "don't worry about it" type responses is that sometimes you _do_ end up having to worry about it, and now you're not equipped to solve the problem. Hell, you may not even know that there is a problem to begin with because you have no idea what the runtime characteristics of your algorithm _should_ be. Maybe you'll have to write some code like this someday. How would you know if your algorithm is performing well? Perhaps you think your 10 hour run is totally acceptible... until someone who read this article and has some experience comes by. They laugh at the absurd performance and spend a bit of time making it 60% faster _because they know how this stuff works_. There's a lot of value in learning how things work, and "premature optimization" responses like you see all over SO are worthless.

3 ms·

Speculative ad hominem aside, the point in this case was to learn to write code so that good compilers can output performant SIMD-heavy code. It's not trivial a

by svantana 8y ago

EpicEng 8y ago
> Speculative ad hominem aside I can only judge you by what you say here. Obviously I don't know you, but what other choice do I have? In my experience, those who rely on their tools to do everything for them are useless when things go sideways. > the point in this case was to learn to write code so that good compilers can output performant SIMD-heavy code No, the point is that comments like yours serve little purpose. No one is suggesting that you should roll your own lib for matrix math in every situation. However, if you _understand_ what happens behind the scenes you write better code and can more easily diagnose performance issues. The problem with "don't worry about it" type responses is that sometimes you _do_ end up having to worry about it, and now you're not equipped to solve the problem. Hell, you may not even know that there is a problem to begin with because you have no idea what the runtime characteristics of your algorithm _should_ be. Maybe you'll have to write some code like this someday. How would you know if your algorithm is performing well? Perhaps you think your 10 hour run is totally acceptible... until someone who read this article and has some experience comes by. They laugh at the absurd performance and spend a bit of time making it 60% faster _because they know how this stuff works_. There's a lot of value in learning how things work, and "premature optimization" responses like you see all over SO are worthless.