www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7509] New: Allow SIMD variable contents to have all their values changed to a single float variable

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7509

           Summary: Allow SIMD variable contents to have all their values
                    changed to a single float variable
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: druntime
        AssignedTo: nobody puremagic.com
        ReportedBy: junk.Nebster gmail.com



Sure this code should be allowed to compile?
In C, it is similar to _mm_set1_ps(b[i]);

import core.simd;
import std.stdio;

void load(float4 fl, const float a) {
  fl = a;
}

void main() {
  float4 fl;
  load(fl, 5);
  foreach(f; fl.array)
    writefln("%f", f);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 15 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7509


Manu <turkeyman gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |turkeyman gmail.com



I think this should be prohibited at all costs. This is a very slow operation
on every architecture other than x64.

I'm carefully crafting std.simd with functions that encourage the best results
on all platforms, and I'm addressing this issue there.

Allowing this implicit case would ruin many libraries implementing SIMD code on
all non-x64 platforms. They should rather be encouraged to use the library
appropriately instead.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 11 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7509




How should something like this be done then on other architectures?

I'm creating a matrix multiplication library and I tried using a value like
this and it didn't work.
I also tried float4 fl = 5; as a test and that didn't set fl to anything. (See
my other bug).
Shouldn't that second one cause a error (either while compiling or at runtime)?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 12 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7509




Note that as yet, constant's aren't actually properly supported. There are
bugs, and the feature is incomplete.

Down the track, if you want to use scalar variables, you should be encouraged
to load it into a float4 using a the loadFloat(float f) api as far outside your
hot code as possible, and use the produced 4x float vector instead.

I have a fork with std.simd work in progress if you wanna have a peek:
https://github.com/TurkeyMan/phobos/commits/master/std/simd.d
Coming together, still a bit to do.
This library will be efficient on all architecture, if only a little archaic,
but it follows D conventions quite closely.

I'd encourage people to build higher level maths libraries ontop of std.simd
instead of implementing the hardware abstraction themselves. It'll make
libraries a whole lot more portable, ctfe-able, and I expect it'll become very
highly tuned with use, which will benefit all maths libs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 13 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7509


SomeDude <lovelydear mailmetrash.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lovelydear mailmetrash.com
           See Also|                            |http://d.puremagic.com/issu
                   |                            |es/show_bug.cgi?id=7507



PDT ---
See also 
http://d.puremagic.com/issues/show_bug.cgi?id=7507
http://d.puremagic.com/issues/show_bug.cgi?id=7508

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 20 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7509


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code dawg.eu



Actually GDC and LDC are capable of generating optimal code for scalar to
vector assignment.

auto foo(float a)
{
    __vector(float[4]) va = void;
    va = 2 * a;
    return va;
}


 I think this should be prohibited at all costs.


It's not helpful that dmd currently disallows this assignment
because it promotes usage of 'vec.array = val' which uses the stack.
Of course one could write a library wrapper but isn't it much
better to leave this to the compiler?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 08 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7509






 Actually GDC and LDC are capable of generating optimal code for scalar to
 vector assignment.


It's not a portable concept. It's an operation that should generally be
avoided/discouraged.
I'd rather supply an explicit function like "v = loadScalar(s);", which is
documented with its performance characteristics, and is completely clear to the
programmer that they're using it.
If programmers think v = s; is a benign operation, they'll merrily write bad
code.


 auto foo(float a)
 {
     __vector(float[4]) va = void;
     va = 2 * a;
     return va;
 }
 

 I think this should be prohibited at all costs.


 
 It's not helpful that dmd currently disallows this assignment
 because it promotes usage of 'vec.array = val' which uses the stack.
 Of course one could write a library wrapper but isn't it much
 better to leave this to the compiler?


If I had my way, .array would be removed ;)
Interacting vectors/scalars should be a deliberate and conservative operation.
It's very expensive on most architectures. Used within a tight SIMD loop, it
will ruin your code.

I probably won't win this argument though... people like to be able to write
slow code conveniently ;)
It's not the worst thing in the world, but it's a slippery slope.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 09 2013