Vector performance

[simendsjo]

On 13.01.2012 12:21, Marco Leise wrote:
> Am 13.01.2012, 11:37 Uhr, schrieb Iain Buclaw <ibuclaw at ubuntu.com>:
>
>> On 13 January 2012 04:16, Marco Leise <Marco.Leise at gmx.de> wrote:
>>> Am 12.01.2012, 16:40 Uhr, schrieb Iain Buclaw <ibuclaw at ubuntu.com>:
>>>
>>>> On 12 January 2012 08:29, Manu <turkeyman at gmail.com> wrote:
>>>>>
>>>>> On 12 January 2012 02:46, F i L <witte2008 at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> Well the idea is you can have both. You could even have a:
>>>>>>
>>>>>> Vector2!(Transition!(Vector4!(Transition!float))) // headache
>>>>>> or something more practical...
>>>>>>
>>>>>> Vector4!(Vector4!float) // Matrix4f
>>>>>> Vector4!(Transition!(Vector4!float)) // Smooth Matrix4f
>>>>>>
>>>>>> Or anything like that. I should point out that my example didn't
>>>>>> make it
>>>>>> clear that a Matrix4!(Transition!float) would be pointless
>>>>>> compared to
>>>>>> Transition!(Matrix4!float) unless each Transition held it's own
>>>>>> iteration
>>>>>> value. Example:
>>>>>>
>>>>>> struct Transition(T, bool isTimer = false) {
>>>>>>
>>>>>> T value, start, target;
>>>>>> alias value this;
>>>>>>
>>>>>> static if (isTimer) {
>>>>>> float time, speed;
>>>>>>
>>>>>> void update() {
>>>>>> time += speed;
>>>>>> value = start + ((target - start) * time);
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> That way each channel could update on it's own time frame. There may
>>>>>> even
>>>>>> be a way to have each channel be it's own separate Transition type.
>>>>>> Which
>>>>>> could be interesting. I'm still playing with possibilities.
>>>>>
>>>>>
>>>>>
>>>>> The vector's aren't quite like that.. you can't make a hardware vector
>>>>> out
>>>>> of anything, only things the hardware supports: __vector(float[4]) for
>>>>> instance.
>>>>> You can make your own vector template that wraps those I guess if you
>>>>> want
>>>>> to make a matrix that way, but it sounds inefficient. When it comes to
>>>>> writing the vector/matrix operations, if you're assuming generic code,
>>>>> you
>>>>> won't be able to make it anywhere near as good as if you write a
>>>>> Matrix4x4
>>>>> class.
>>>>>
>>>>>
>>>>>>> I think that is also possible if that's what you want to do, and
>>>>>>> I see
>>>>>>> no
>>>>>>> reason why any of these constructs wouldn't be efficient (or
>>>>>>> supported).
>>>>>>> You can probably even try it out now with what Walter has already
>>>>>>> done...
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cool, I was unaware Walter had begun implementing SIMD operations.
>>>>>> I'll
>>>>>> have to build DMD and test them out. What's the syntax like right
>>>>>> now?
>>>>>
>>>>>
>>>>>
>>>>> The syntax for the types (supporting basic arithmetic) look like
>>>>> __vector(float[4]) float4vector.. Try it on the latest GDC.
>>>>>
>>>>
>>>> This will change. I'm uploading core.simd later which has a Vector!()
>>>> template, and aliases for vfloat4, vdouble2, vint4, etc...
>>>>
>>>> I don't plan on implementing vector instrinsics in the same way Walter
>>>> is doing it.
>>>>
>>>> a) GCC already prodives it's own intrinsics
>>>> b) The intrinsics I see Walter has already implemented in core.simd is
>>>> restricted to x86 line of architectures.
>>>>
>>>>
>>>> Regards
>>>
>>>
>>> Looks like you two should discuss this. I see how Walter envisioned D to
>>> have an inline assembler unlike C, which resulted in several vendor
>>> specific
>>> syntaxes and how GCC has already done the bulk load of work to
>>> support SIMD
>>> and multiple platforms. Naturally you don't want to redo that work to
>>> wrap
>>> Walter's immature approach around the solid base in GDC.
>>> Can you please have a meeting together with the LDC devs and decide on a
>>> fair way for everyone to support inline ASM and SIMD intrinsics? Once
>>> there
>>> is a common ground for three compilers other compilers will want to
>>> go the
>>> same route and everyone is happy with source code that can be
>>> compiled by
>>> every compiler.
>>> I think this is a fundamental decision for a systems programming
>>> language.
>>
>> Who are the LDC devs? :)
>
> :) Actually I don't know. Only heard about this "LLVM" that's supposed
> to be good at source-to-source compilation and is more of a framework
> than a single compiler. And then LDC emerged around that and I recently
> heard that 'its pretty much up to date'. Since you are working on GDC it
> seemed natural someone else must be actively maintaining LDC...
> But dsource.org shows commits that are at least 2 years old. Look at the
> positive side: One less party to satisfy!

It was at bitbucket (updated ~6 months ago), but it seems it has moved 
to github (updated 2 days ago) https://github.com/ldc-developers/ldc