Programming for Larrabee

Wednesday, April 22. 2009

Programming for Larrabee

Short status update from me for all who still don't know:
I'm working on my diploma thesis this year. My day to day work is making the TPC Trackfinder software for the Alice detector of the LHC as fast as possible. (TPC Images) Target hardware is Multicore x86(_64) or GPUs. It's a challenging task, and I enjoy getting more experience in the HPC sector.

What I wanted to point everybody at, though, is that Intel has released the intrinsics it will be supporting with the Larrabee with the last gaming conference. What I didn't notice until today is that they also released a complete header that allows you to program with those intrinsics now. At home... The header provides a scalar and an SSE implementation of the full set of Larrabee intrinsics. Once the Larrabee and its development tools will be available your program will then run on LRB and be able to use the vector instructions in no time.

If you don't know why LRB vector instructions are so cool let me tell you: SSE is nice. You can do four floating point instructions in one (or int, or two doubles...). With LRB the vector width is four times bigger: 16 floats/ints, 8 doubles. But the LRB instructions are a lot nicer than SSE. You have a 16/8 bit mask available to select the entries of the vector the instruction should write. You have all arithmetic instructions for float, int and double available (SSE 4.1 finally brought the multiply instruction for int). You have gather/scatter instructions that make it easy to access data that is stored in structs. You have free conversions and swizzles in the loads and stores. (e.g. you can store data as half-floats and compute as floats, halfing the I/O bandwidth your code needs)

Now, intrinsics are already a lot nicer than writing inline assembly. But in the end you want to have a C++ class for this, right? If you do let me know.

Posted by Matthias Kretz in Programming at 12:46 | Comments (10) | Trackbacks (0)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Crazy stuff!
Did you also think about using CUDA? (to use the power of nVidia Graphic-Cards).
This technology is already available and usable today, and even "cheap" graphics-cards can churn through data faster than CPUs can. Used in SLI-mode there is quite some power available.

You could also consider using the CELL BE processors. The 8 SPUs of the Cell-Processor also have quite some computing power. You could easily start development on a consumer Playstation3 (putting linux on it) and use the processor right away. There also exist some nice libraries to use when programming for SPUs. For production use you could use IBM Blades with CELL-processors, which also have way more RAM available than the Playstation 3.

This all sounds like a very exciting job, keep us (me

) posted on the progress!

#1 Shyru on 2009-04-22 13:35 (Reply)

I actually started HPC on GPUs with CUDA. CUDA sure is a powerful language/platform. There are some people here also working with this. I am working on a machine that has a GTX280 built in and a Tesla connected. Lots of NVIDIA hardware to play with.
But since NVIDIA is covered by others I don't do that much with it. Keeping my eyes open for everything OpenCL, Ct, SIMD, GPU, Multi-Core related though.

#1.1 Matthias Kretz (Homepage) on 2009-04-22 14:36 (Reply)

I'm quite sure that x86 manycore is the future, not specific graphics cores like on todays graphics hardware. IMHO, CUDA is nice to play around with and do some stuff with lowcost hardware (I use it regularily), but if you want to use existing code (solvers, etc.), it's not worth porting or rewriting (if its even possible).
That kind of specialized hardware and codes was used decades ago, and later dismissed for more general x86 processors. I don't think we will move backward in time just because it's fancy gamers graphics cards now.

#1.2 Andre on 2009-04-22 16:15 (Reply)

You are then working at CERN?? cool!!

Maybe I'm wrong, but I think Eigen [ http://eigen.tuxfamily.org ] is pretty close to what you might be looking for. It's a great C++ template library for Linear Algebra that under the hood uses all these vectorization intrinsics. I guess you already know about it.

However, I think that Eigen does not make use of the SSE 4.1 instructions set yet, but it's pretty well designed and it could probabily be added (I know they have SSE and Altivec vectorization implementations).

Of course, for some stuff, like some algorithms which you might want to optimize in a specific way, you might end up using directly the intrinsics.

#2 Ricard on 2009-04-22 15:46 (Reply)

Eigen currently does only SSE2/SSE3/SSSE3 and AltiVec. It would be very easy to add Larrabee support (or SSE 4 if you like), it's just that nobody has done it so far.

See e.g. this file:
http://websvn.kde.org/trunk/kdesupport/eigen2/Eigen/src/Core/arch/SSE/PacketMath.h?view=markup

adding SSE4.1 support would just be a matter of adding the code between ifdef's in that file.

adding Larrabee support would be writing a new file (taking this one as starting point), see in particular the struct ei_packet_traits, here you'd change the value of size, etc...

#2.1 Benoit (Homepage) on 2009-04-22 16:16 (Reply)

Actually I tried to port Eigen2 to LRBni as one of my first experiments with the Larrabee intrinsics. But I didn't understand how to make Eigen use 16 vectors efficiently. AFAIU the Eigen code the vector size of 4 is a little deeper down in the system.

Another important point why I'm not so interested in Eigen with Larrabee intrinsics is that Eigen doesn't fully use the vectors as SIMD, only sometimes. Here I understand SIMD as having some data being fully equal in how the algorithm works on it. And normally the entries in euclidean vectors / matrices are not fully equal (unless all you do is additions/subtractions).

Think of SIMD rather as putting the x coordinate of 16 particles into vector x, the 16 y coordinates into y. Then to calculate the coordinates in r and \phi you do

__m512 r = _mm512_mul_ps(x, x); // x^2
r = _mm512_madd213_ps(y, y, r); // y^2 + x^2
r = _mm512_sqrt_ps(r); // sqrt(y^2 + x^2)

__m512 phi = _mm512_atan_ps(abs(_mm512_div_ps(x, y))); // implement abs with _mm512_and_pi and the 0x7fffffff mask which you can broadcast in the same instruction to all 16 vector entries

So that's 6 intrinsics called, and you have converted 16 vectors from euclidean coordinates into polar coordinates.

#2.1.1 Matthias Kretz (Homepage) on 2009-04-22 17:24 (Reply)

Ah, and with a Larrabee Vector class this example would read:

float_v r = sqrt(y.multiplyAndAdd(y, x * x);
float_v phi = atan(abs(x / y));

One day I might replace multiplyAndAdd by C++ magic so that it can be written as

r = sqrt(y * y + x * x);

#2.1.1.1 Matthias Kretz (Homepage) on 2009-04-22 17:44 (Reply)

"AFAIU the Eigen code the vector size of 4 is a little deeper down in the system."

Maybe some more isolated places in the code need to be adjusted to allow bigger packet sizes, but nothing fundamental.

About the rest of your reply: yes it's well-known that "horizontal" / "across the objects" vectorization is more powerful than per-object vectorization as Eigen does. It also means that technical details (such as the need to group objects) are exposed to the user, while per-objet vectorization a la Eigen is completely transparent. At the end of the day, yes it's different use cases. Notice though that for computations on large enough matrices, per-object vectorization is optimally fast. The benefit of horizontal vectorization is when one is dealing with many small objects -- admittedly a very important use case.

#2.1.1.2 Benoit (Homepage) on 2009-04-22 18:03 (Reply)

Oh, and actually, when the object size is big, per-object vectorization is actually faster than horizontal vectorization because you don't need to deal with X objects simultaneously so it's much more cache-friendly. To summarize:

horizontal vectorization: faster (always possible) for small objects, slower for big objects, forces cumbersome API
per-object vectorization: not always possible for small objects (especially not with Larrabee's big packet sizes), faster for big objects, no impact on API

#2.1.1.2.1 Benoit (Homepage) on 2009-04-22 18:09 (Reply)

Yes, I can see how per-object vectorization is better for big objects, cache wise. So here's my particular problem shining through: I'm working mostly with two or three coordinates. Trackfinding is about efficient searching through the hit coordinates, not about big matrix/vector operations.

But I'd use Eigen immediately if it were the right tool for the problem.

#2.1.1.2.2 Matthias Kretz (Homepage) on 2009-04-22 22:17 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: HTML-Tags will be converted to Entities. You can use [geshi lang=lang_name [,ln={y\|n}]][/lang] tags to embed source code snippets Standard emoticons like :-) and ;-) are converted to images.
	Remember Information? Subscribe to this entry