Re: [eigen] eigen short support: discussion thread

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

initially I thought this support for small integers would fit in the
Array module, but for all the reasons Benoit listed, I'm now in favor
to put it in a separate module.


gael.

On Sun, Aug 30, 2009 at 5:51 AM, Rohit Garg<rpg.314@xxxxxxxxx> wrote:
> On Sun, Aug 30, 2009 at 12:53 AM, Benoit Jacob<jacob.benoit.1@xxxxxxxxx> wrote:
>> 2009/8/29 Rohit Garg <rpg.314@xxxxxxxxx>:
>>> It wont be a complete integer types module without taking int32 there.
>>
>> Is that a big deal? Is it better if we call it instead MoreIntegers?
>> Or stick to SmallIntegers?
>>
>> another question is how we deal with int32 at all. Currently we
>> support int and while it's 32bit on most common platforms, it can also
>> be 64 bit. Or 16 bit, by the way. I wonder how the compiler deals with
>> collisions in template specializations.
>>
>> For example, is this code legal C++?
>>
>> template<typename T> void foo() {}
>> template<> void foo<int>() {}
>> template<> void foo<long long>() {}
> Yeah, on 16, 32, 64 platforms, long long is differently sized compared
> to int, so should be ok.
>>
>> or is this potentially ambiguous? I don't have access to a machine
>> where sizeof(int)==8 (or 2 for that matter) but they do exist...
> int is 16 bits on 16 bit machines, those we can safely ignore. on 64
> bit machines, the conventions is to have the int 32 bits and long as I thought
> 64 bits. (Stevens's network programing book)
>>
>>> And that might break API/ABI. (Not sure, just guessing). How about
>>> making it a sub module of Core?
>>
>> a sub module? How does that work? How is this different from putting
>> that into Core?
>>
>>>>
>>>> That would be no less than 7 integer types (in addition to the int
>>>> that we have in Core) so having these 7 types in Core would more than
>>>> double the number of types handled in PacketMath.h ---> i think that
>>>> warrants the creation of a new module.
>>>>
>>>> I should have presented this as a "scalability" argument from the onset...
>>>>
>>>>>> When you do vectorization, add also packetmath.cpp. Keep all that
>>>>>> templated, so it can easily be extended to cover more new small
>>>>>> integer types. Just wipe what is not wanted / not applicable for small
>>>>>> integer types.
>>>>> Actually, I have looked at char and uchar support in SSE2 as well.
>>>>> Let's just say that we have a SNAFU (thank you, Intel, :P ) here.
>>>>
>>>> heh, i can believe it's not going to be easy!
>>> It isn't about it being easy.
>>>
>>> Let me try to list out the vector operations available in int8/uint8
>>>
>>> int8
>>>
>>> add,
>>> sub,
>>> saturated add, sub
>>> and,or,not
>>> ==, <, > comparison
>>>
>>> uint8
>>> add with saturation
>>> average
>>> min
>>> max
>>> saturated add, sub
>>> and, or, not
>>> ==, <, > comparison
>>>
>>> That's all what is there in SSE2. No multiplication, no division, no
>>> bit shifts. With these handicaps, is char/uchar even useful to
>>> _anyone_ ?
>>
>> Hm, indeed I don't know, especially as Eigen isn't designed to expose
>> "add with saturation" and "average" in a useful way.
>>
>> How about later SSE instruction sets?
> SSE3 has no integer instructions. SSSE3 and SSE4.1 have some integer
> instructions, but they are pretty non-orthogonal. As for, bare bones
> non vector support, I think that can be easily done.
>>
>> Anyway, it's fine to leave uint8 non vectorized for now. Basic
>> support(no vectorization) would be cool though.
>>
>> Benoit
>>
>>
>>
>
>
>
> --
> Rohit Garg
>
> http://rpg-314.blogspot.com/
>
> Senior Undergraduate
> Department of Physics
> Indian Institute of Technology
> Bombay
>
>
>