[macstl-dev] Re: [AGG] Re: [Fwd: Multiplication?]

[Glen Low]

Maxim:

On 03/03/2005, at 1:06 AM, Maxim Shemanarev wrote:

>> Hmm... given your specific expression above, it seems you really want
>> the high byte (or word) of the multiplication as with the SSE PMULHUW
>> opcode?
>>
>> Something like
>>
>> mulhi (cr - r, alpha) + r
>>
>> That could be arranged...
>
> Absolutely! I'm not sure about losing accuracy, but I don't think it's 
> too
> important in this case.
>
> What important is this operation is rather specific and I don't think 
> it makes
> sense to support it on the high level. Although, it'd be nice to have 
> such an
> operation. That is,
>
> macstl::vec<u16x8> v1 = . . .;
> v1.mulhi(alpha);
>
> Here we multiply a vector of say, 8x16 bit values to a scalar value 
> and have
> the elder 16 bits as the result.

The mulhi operation makes sense to me since there are also variants of 
the same on Altivec and/or vecLib, so it's something that should be 
standardized. We just need to agree on a name :-) -- any comments from 
the others?

Once the operation is implemented on the low-level vec interface, it's 
only another line away from being implemented in the high-level 
valarray, so it will be in both.

>
> BTW, does macstl::vec support arithmetic operations with scalars? Like 
> v1 >> 8?
> v1 *= alpha, etc? It's very important too.

vec doesn't support arithmetic with scalars directly because it's a 
close-to-the-metal solution. On Altivec especially, there are two ways 
to create a vector out of a scalar, depending on whether you have a 
compiler constant (which may invoke the faster constant generation 
routines) or a variable. So you'd have to do:

v1 *= vec <float, 4>::fill <8> (); // 8 is a compile-time constant
v1 *= vec <float, 4>::fill (alpha); // alpha is a variable

If you use the high-level valarray, then yes, you can simply pass in a 
scalar which gets transparently splatted into the appropriate vector. 
Since valarrays are expected to run for longer, the overhead of not 
using a generated constant would be barely seen.

>> Also, I'd like to see macstl compile and work correctly on as many
>> compilers as possible, so it would be good to see results on those
>> compilers you mentioned -- can someone try compiling macstl on those
>> other compilers. The main requirement is a close-to-standard C++98
>> compiler, e.g. VC 6.0 and 7.0 fare badly but 7.1 is OK.
>
> But there won't be any SIMD optimizations, will there?

If the processor targets did not have SIMD, then there won't be any 
optimizations. However my valarray uses expression templates for speed, 
so that even without SIMD optimization, their use is almost equivalent 
to a scalar hand-coded loop. And if you're familiar with template 
metaprogramming, you can use that (instead of coarse-grained and 
platform-specific macros like __VEC__ or __SSE__) to see if a 
particular vec class exists on that platform and call through to your 
appropriate code; vectest.cpp demonstrates this technique.

I'm interested in code contributions for the other SIMD architectures 
of course, and am mildly (!) exploring using GPU's.

>> There might be licensing issues as well. macstl is RPL and I 
>> originally
>> thought AGG was BSD, but the SF page lists you as CPL. We'd have to
>> work something out, if you're the owner of AGG, that including macstl
>> is OK but anyone who wants the optimizations of macstl should respect
>> its RPL rules.
>
> Exactly! This is a dependence too. The AGG license is very liberal, 
> yours is
> more strict. It means that if AGG natively used macstl, the only legal 
> way to
> use it is to obey the requirements of the most restrictive license, 
> that is,
> macstl. And you don't have a choice in this case. If there are only a 
> couple of
> files that depend on macstl, you do have a choice - you can remove 
> those files
> and do without macstl (sacrificing the performance). It's how I handle 
> the Alan
> Murta's General Polygon Clipper. I include it into AGG (the GPC 
> license allows
> for that), but it's the user's responsibility whether to use GPC or 
> not. If
> not, you just remove it and do without this functionality.

OK. Sounds good to me.

>> I'll work on a refarray for 0.2.2.
>
> BTW, do you consider submitting macstl to BOOST? http://www.boost.org
>

They have liberal license arrangements too, and require that the 
libraries be free. On the other hand, I need to eat :-).



Cheers, Glen Low


---
pixelglow software | simply brilliant stuff
www.pixelglow.com