[macstl-dev] macstl on Intel/PowerPC Universal Binaries
glen.low at pixelglow.com
Thu Jun 9 08:46:20 WST 2005
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.
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 --
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
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
* -- 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
More information about the macstl-dev