| >First off, a number of statements are nonsense. 100% of my original comment is absolutely and completely correct. Indisputable correct. >Furthermore, I was writing a library. Little misunderstandings like this pervade your take. >seems to be under the impression that using a SIMD library would somehow have produced a better result. To be clear, I wasn't speaking to you or for your benefit, or specifically to your exercise. You'll notice I didn't email a list of recommendations to you, because I do not care what you do or how you do it. I didn't address my comment to you. I -- and I was abundantly clear on this -- was speaking to the random reader who might be considering optimizing their code with some hand-crafted SIMD. That following the path in this (and an endless chain of similar) submission(s) is usually ill advised, generally, not even speaking to this specific project, but rather to the average "I want to take advantage of SIMD in my code" consideration. HN has a fetish for SIMD code recently and there is almost always a better approach than hand-crafting some SSE3 calls in one's random project. >The original commentor seems to be under the impression that using a SIMD library would somehow have produced a better result. Again, I could not care less about your project. But the average developer does care that their code runs on a wide variety of platforms optimally. You don't, but again, you and your project was tangential to my comment which was general. >The thing the original commentor does get right is the notion that thinking about data layout is important. Aside from the entirety of my comment being correct, the point was that many of the SIMD tools and libraries force you down a path where you are coerced into such structures. Versus often relying upon the compiler to make the best of suboptimal structures. We've seen many times where people complain that their compiler isn't vectorizing things that they think it should, but there is a choice between endlessly fighting with the compiler, and hand-rolling SSE calls, that not only supports much more hardware it leads you down the path of best practices. Which is of course why C++ 26 is getting std::simd. Again, you are irrelevant to my comment. Your project is irrelevant to it. I know this is tough to stomach. >Right. I'll believe this when I see it. I actually cloned the project but then this submission fell off the front page and it seemed not worth my time. Not to mention that it can't be built on macOS which happened to be the machine I was on at the moment. Because again, I don't care about your or your project, and my commentary was to the SIMD sideliners considering how to approach it. >I could pick it apart more, but.. I think you get my drift. None of your retorts are valid, and my comment stands as completely correct. The drift is that you feel defensive about a general comment because you did something different, which....eh. |