digitalmars.D.bugs - [Issue 7509] New: Allow SIMD variable contents to have all their values changed to a single float variable
- d-bugmail puremagic.com (30/30) Feb 15 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7509
- d-bugmail puremagic.com (16/16) Mar 11 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7509
- d-bugmail puremagic.com (11/11) Mar 12 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7509
- d-bugmail puremagic.com (19/19) Mar 13 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7509
- d-bugmail puremagic.com (14/14) Apr 20 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7509
- d-bugmail puremagic.com (21/22) Apr 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7509
- d-bugmail puremagic.com (20/35) Apr 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7509
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
--- Comment #0 from junk.Nebster gmail.com 2012-02-15 08:15:45 PST ---
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
d-bugmail puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=7509
Manu <turkeyman gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |turkeyman gmail.com
--- Comment #1 from Manu <turkeyman gmail.com> 2012-03-11 12:19:46 PDT ---
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
http://d.puremagic.com/issues/show_bug.cgi?id=7509 --- Comment #2 from junk.Nebster gmail.com 2012-03-12 18:33:42 PDT --- 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
http://d.puremagic.com/issues/show_bug.cgi?id=7509 --- Comment #3 from Manu <turkeyman gmail.com> 2012-03-13 11:40:54 PDT --- 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
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
--- Comment #4 from SomeDude <lovelydear mailmetrash.com> 2012-04-20 00:35:47
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
http://d.puremagic.com/issues/show_bug.cgi?id=7509
Martin Nowak <code dawg.eu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |code dawg.eu
--- Comment #5 from Martin Nowak <code dawg.eu> 2013-04-08 12:51:33 PDT ---
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
http://d.puremagic.com/issues/show_bug.cgi?id=7509 --- Comment #6 from Manu <turkeyman gmail.com> 2013-04-09 03:45:14 PDT --- (In reply to comment #5)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; }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: -------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?
Apr 09 2013