[macstl-dev] macstl on Intel/PowerPC Universal Binaries

[Glen Low]

Dear All,

It's been quite a week, hasn't it? I had to postpone the release of  
macstl 0.2.3 to see if I can easily support the new Intel SSE ISA for  
x86 on OS X, aka Macintel aka Aptel aka Mintelac (no kidding, that's  
MacWorld's name for it). It turns out that because I had already  
ported the vec code to x86 SSE/SSE2/SSE3 earlier this year, it was  
indeed a couple of lines of code change only.

So, macstl 0.2.3 will be released early next week. macstl 0.2.2.18,  
available to macstl licensees only, already has the changes in.

http://www.pixelglow.com/macstl/

I'll have more to say on this topic come Monday, but I'd seriously  
encourage you to take a look at macstl for your continued SIMD  
development. Especially if you're the group most affected by Apple's  
move away from Altivec -- developers who code directly to Altivec --  
here's why:

1.    Rosetta cannot run your Altivec code, so Apple gives you no  
choice but to port it anyway or leave the platform you know and love.

2.    You're not already using vAccelerate and other libraries  
because you wanted the closest-to-the-metal performance, so a library  
call isn't going to make you happy.

3.    macstl is the only cross-platform, low-level SIMD toolkit there  
is. It's all inlined, and there are objects that correspond exactly  
to __vector float etc. at full performance. No library calls. Run it  
at full compiler optimization.

4.    With your single source code, you can compile to PowerPC and  
Intel code. There are many common functions and a mostly full set of  
platform functions as well.

5.    You need to support both PowerPC and Intel, at least for the  
2-3 years the transition is in full swing. It's no use running an awk  
script on your Altivec code to turn it into SSE code when you have to  
laboriously coordinate the two for future development.

6.    macstl was designed from an Altivec user's (me!) point of view,  
so it's a natural fit for your Altivec programming style:
     A.    SSE intrinsics have very poor type support e.g. the SSE2  
__m128i stands in for __vector signed int, __vector signed char etc.  
On the other hand, macstl has implemented transparent objects that  
cover __m128i in its various uses to make it work correctly like  
__vector signed int , __vector signed char ....
     B.    There are no __vector bool types in SSE intrinsics, but  
macstl implements objects to cover these, so that e.g. comparisons  
return the right vector bool type, just as they do in Altivec.
     C.    More horrendously, the intrinsics have type information  
coded in e.g. _mm_add_si32, _mm_add_si8. That means at the very  
least, your awk conversion script has got to be preternaturally  
smart, to convert the overloaded Altivec vec_add intrinsic into the  
right non-overloaded SSE intrinsic! In fact this neat feature of  
Altivec relies on something akin to C++ overloading but in a C  
context. macstl actually uses C++ overloading to hide all the SSE  
intrinsics under the equivalent of Altivec overloaded intrinsics.

7.    You might be allergic to C++. Don't blame you, it has it's  
share of problems in the past. But:
     A.    It has overloading, and C doesn't. The Altivec intrinsic  
overloading was a clever hack but it's now in the past. If you're  
used to the way it happened in Altivec, you'll fit right in with macstl.
     B.    It has good template and inline support, but you don't  
have to delve deep into the intricacies of this -- macstl keeps the  
gory guts of C++ away from you. Yet it's precisely this support that  
makes modern C++ as fast as (or faster than) raw C.
     C.    Best of both worlds. You can still program largely in C  
language, don't have to futz around with object-oriented, template  
stuff at all -- just use the vec objects as you used to use the  
__vector floats.

8.    It's dual licensed:
     A.    It has an open source license that lets new developers  
come in to improve the code all the time. Right now we have SKY  
Computers (the same SKY Computers mentioned in the simdtech list!)  
contributing YDL code and investigating complex number syntax for  
example. Come join us and make macstl a better solution for all of us!*
     B.    It has a proprietary license that allows you to keep your  
own code private, with appropriate but low license fees. So if you're  
making money with your product and don't want to open up your own  
code, I'm cool with that.


Cheers, Glen Low


---
pixelglow software | simply brilliant stuff
www.pixelglow.com
aim: pixglen

* -- and if your name is H. Bettag, we need someone to come up with a  
set of generated constants for SSE, like you've done famously for  
Altivec.