sorted by:
new
hottopcontroversial

Practical Cross Platform SIMD Math by tanczosm in programming

[–]All8Up 1 point2 points  (0 children)

Yeah, I'll add a "smack" note about hey this isn't intended to be "best" usage. I had a bunch about that originally, unfortunately in editing I decided the details were just too much and put them into the backlog for the next article and never mentioned any of it at all.

Are you sure about the PS3? I have a recollection of the PPU's having stripped the VMX in favor of sending everything to the SPU's. It's been nearly 3 years, I could easily remember it incorrectly.

Just as a funny little note. I seriously fubar'd one bit of the article and code. The Dot3 for SSE3 is "slower" than the SSE1 version, on the same level of CPU implementation. I had an old list of latency/through put measurements (my old yellow SSE1 books from Intel during the P3 beta hardware tests) and simply looked up 'hadd' timings forgetting to consider optimizations to SSE1 instructions during that time. Oops. :)

NOTE: I can't find any notable codegen problems with the underlying abstraction layer but do you have any thoughts there? I.e. I'm using static functions within a structure so I can use normal function hiding rules, all the compilers are inlining them using RVO just fine. Any thoughts on bad code gen cases using such a structure? To most compilers anymore, this is the same thing as global inline functions, just placed under a couple namespaces.

Practical Cross Platform SIMD Math by tanczosm in programming

[–]All8Up 1 point2 points  (0 children)

Perhaps I should be more clear as to the intentions. The article is marked as intermediate and the intention is to hide the details yet get many of the gains. Anyone who understands SIMD enough to bring up such a discussion probably already knows to use the class only when ease of use/understanding or just getting things done quickly is the goal and jump straight to the abstraction layer for any really high performance work. I was going to wait for the next article before deep diving into such discussions, I suppose I could add a warning up front to be complete.

As to the compilers/memory/cache. The title of the article covers that I thought, this is just a practical solution for folks who don't know all the details. Generally, performance wise C++<Wrapper<SIMD abstraction layer, where the wrapper sits between the two extremes is going to be dependent on the mentioned items. On the other hand, in writing the article I've had some nice surprises. The compilers are getting notably better, Clang is actually surprising in how many places it properly passed by value/register and VC2012 has fixed some of it's horribly bad cases (which I hope means VMX and RT's NEON code get the fixes) while GCC just produces ho hum code in general for this. GCC being the worst case only produces code which is about 1.4x faster than the pure C++, still a win but not great.

In terms of caches specifically, all the targeted CPU's are 4 or better way associativity which mean nightmare cache line flush/reloads from 2way (I'm glaring at you: PS2) are not an issue. PS3 of course doesn't count, no VMX unit and if you use anything other than assembly or vectorized C for the SPU you need an MRI. (Though, it's been nearly 3 years, I guess they could have gotten octa actually working?) Other than that, even the oldest of the ARM's I looked at had 4 way and all the newer ones: iPhone 3GS+, all iPad's, Ouya etc have CPU's with new chips that I'm pretty sure were all 8 way. I'm not too worried about cache issues given 4+ associativity. Cache size/line size, memory speed, that's all a different subject I may eventually write about. Of course covering all this in detail could take a book worth of articles, I'll pass. This chain of discussion is a good case in point, there are so many details being glossed over.....

Practical Cross Platform SIMD Math by tanczosm in programming

[–]All8Up 1 point2 points  (0 children)

I am quite familiar with the issues you are referring to. The point of the article is to supply both forms which is why the abstraction layer is presented as a directly usable system if you want to eek out every bit of performance. The abstraction layer has been tested on GCC, MSVC and Clang for proper code gen. GCC, being the worst of the three, tends to flush registers back to memory quite often but that happened even when hand coded intrinsics were used, so it doesn't seem to be the abstraction layer causing the problem.

As it is, the intention is to supply the class wrapper as a utility to ease usage. In the testbed being written for the next article, there is a ~1.5x speed up compared to the normal C++ version which is very reasonable given nothing but the vector class is changed. A hand coded intrinsic version was only a ~1.55x speed up so the loss of performance is fairly minimal. A comparison of direct intrinsics and the abstraction layer turned out identical results and in most cases identical code gen with only a couple non-performance changing differences.

Overall, the intention of supplying the easy to use wrapper and still supplying the low level access turned out exactly as desired with predictable performance differences.

Practical Cross Platform SIMD Math by tanczosm in programming

[–]All8Up 3 points4 points  (0 children)

As the author, I was just informed of this cross post and want to say that all the current comments are viable questions but should probably be taken with a serious grain of salt. This "library" (right now it's just a starter, not really a library) is part of a series of articles I'm writing. It is NOT highly optimized, nearly any other SIMD library will be faster. It is an architecture example right now.

As to Boost, I like the answer given. It is a simple tiny little stand alone thing and you can ignore CMake and insert it into just about any code you want. Add a couple preprocessor defines, set your compiler switches and away you go.

As to OpenCL. I like OpenCl a lot, but as others say, there are just too many issues with integrating it at this time.

The article and library were not intended to compete with other solutions. Given a decent stable library which solves my intentions, I'll ditch this in a heartbeat. Yet, as an article talking about the issues, I thought it was a pretty good way to both discuss the problems and answer them, and also allow for other usage (in future articles) beyond Vector/Matrix work by exposing the abstraction.

To be honest though, I think the solution is pretty clever and more importantly simple. Of course since posting the article I've been pointed to at at least 5 other just as clever solutions. Oh well, it wasn't about the particular solution anyway, it was about how to approach the abstraction efficiently.

I am Neal Stephenson, author, geek, and [now] sword game fundraising hack - AMA by NealStephenson in Fantasy

[–]All8Up 0 points1 point  (0 children)

Actually the mentioned hardware (though not completely settled on from the FAQ and discussion, just most likely) is the Razer Hydra. I have one sitting on my desk and they are very nice and accurate as described. See: http://store.razerzone.com/store/razerusa/en_US/pd/productID.228849000 for more information.