On 2 November 2012 20:19, Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-02 18:46, Andrei Alexandrescu wrote:
>
>  I should add that I'm also totally behind this. When Walter jumped into
>> implementing SIMD support on a hunch, I completely disagreed, but that was a great decision.
>>
>
> I can absolutely understand why he did it but it would be really nice if you (Walter, Andrei and probably others as well) could be more transparent about things like these. I think this would really help the community.


This is probably my fault, and a matter of corporate transparency. We
didn't want to make a noise about it until we reached a particular level of
confidence.
We're fairly invested now, and quietly hopeful it will go ahead from here.

On 2 November 2012 20:36, Walter Bright <newshound2@digitalmars.com> wrote:

> On 11/2/2012 11:19 AM, Jacob Carlborg wrote:
>
>> I can absolutely understand why he did it but it would be really nice if
>> you
>> (Walter, Andrei and probably others as well) could be more transparent
>> about
>> things like these. I think this would really help the community.
>>
>
> I apologize for being circumspect about this, but I have to respect peoples' privacy and I cleared what I posted about Remedy with them before posting it.
>

That said, I think we'd perhaps appreciate that it doesn't appear all over the internets just yet. It would be much more interesting, and probably have a lot more impact if we made such an announcement alongside something to show.

On 2012-11-02 19:36, Walter Bright wrote:

> I apologize for being circumspect about this, but I have to respect
> peoples' privacy and I cleared what I posted about Remedy with them
> before posting it.

This has nothing to do with what Manu does for a living (sure, mentioning Remedy gives it more weight, at least for me). It's more in the line of creating a post/starting a new thread saying something like:

"After a throughout discussion with Manu (or 'a fellow D programmer' if he/she prefers to be anonymous) we have decided it would be in best interest of D if we implement this particular feature. From now on this is where I will focus most most of my time".

Something like this would be far better then suddenly seeing commits regarding SIMD (or whatever feature it might be) for out of the blue.

-- 
/Jacob Carlborg

On 2012-11-02 20:22, Manu wrote:

> This is probably my fault, and a matter of corporate transparency. We
> didn't want to make a noise about it until we reached a particular level
> of confidence.
> We're fairly invested now, and quietly hopeful it will go ahead from here.

This has nothing to do with corporate transparency. It has to do with transparency to the community, see my reply to Walter:

http://forum.dlang.org/thread/jauixhakwvpgsghapzvz@forum.dlang.org?page=6#post-k718iu:242iu6:241:40digitalmars.com

-- 
/Jacob Carlborg

> "After a throughout discussion with Manu (or 'a fellow D programmer' if he/she prefers to be anonymous) we have decided it would be in best interest of D if we implement this particular feature. From now on this is where I will focus most most of my time".
>
> Something like this would be far better then suddenly seeing commits regarding SIMD (or whatever feature it might be) for out of the blue.

SIMD support was discussed here at length in the days before it was implemented. See this thread:

http://forum.dlang.org/thread/jdhb57$10vf$1@digitalmars.com#post-wdjdcrkiaakmkzqtdhxu:40dfeed.kimsufi.thecybershadow.net

and this thread:

http://forum.dlang.org/post/mailman.76.1325814175.16222.digitalmars-d@puremagic.com

On 2012-11-02 21:22, jerro wrote:

> SIMD support was discussed here at length in the days before it was
> implemented. See this thread:

Yeah, I know it's been talked about and discussed, but it's the final decision that's missing.

-- 
/Jacob Carlborg

On Friday, 2 November 2012 at 14:22:34 UTC, Jens Mueller wrote:
> But the compiler knows about the alignment, doesn't it?
>
> align(16) float[4] a;
> vs
> float[4] a;
>
> In the former case the compiler can generate better code and it should.
> The above syntax is not supported. But my point is all the compiler
> cares about is the alignment which can be specified in the code somehow.
> Sorry for being stubborn.
>
> Jens

Note: My knowledge of SIMD/SSE is fairly limited, and may be somewhat out of date. In other words, some of this may be flat out wrong.

First, just because you have something that can have SIMD operations performed on it, doesn't mean you necessarily want to. SSE instructions for example have to store things in the XMM registers, and accessing the actual values of individual elements in the vector is expensive. When using SSE, you want to avoid accessing individual elements as much as possible. Not following this tends to hurt performance quite badly. Yet when you just have a float[4], you may or may not be frequently or infrequently accessing individual elements. The compiler can't know whether you use it as a single SIMD vector more often, or use it to simply store 4 elements more often. You could be aligning it for any reason, so it's not too fair a way of determining it.

Secondly, you can't really know which SIMD instructions are supported by your target CPU. It's safe to say SSE2 is supported for pretty much all x86 CPUs at this point, but something like SSE4.2 instructions may not be. Just because the compiler knows that the CPU compiling it supports it doesn't mean that the CPU running the program will have those instructions.

Lastly, we'd still need SIMD intrinsics. It may be simple to tell that a float[4] + float[4] operation could use addps, but it would be more difficult to determine when to use something like dotps (dot product across two SIMD vectors), and various other instructions. Not to mention, non-x86 architectures.

Walter Bright wrote:
> On 11/2/2012 3:50 AM, Jens Mueller wrote:
> > Okay. For me they look the same. Can you elaborate, please? Assume I want to add two float vectors which is common in both games and scientific computing. The only difference is in games their length is usually 3 or 4 whereas in scientific computing they are of arbitrary length. Why do I need instrinsics to support the game setting?
> 
> Another excellent question.
> 
> Most languages have taken the "auto-vectorization" approach of reverse engineering loops to turn them into high level constructs, and then compiling the code into special SIMD instructions.
> 
> How to do this is explained in detail in the (rare) book "The Software Vectorization Handbook" by Bik, which I fortunately was able to obtain a copy of.
> 
> This struck me as a terrible approach, however. It just seemed stupid to try to teach the compiler to reverse engineer low level code into high level code. A better design would be to start with high level code. Hence, the appearance of D vector operations.
> 
> The trouble with D vector operations, however, is that they are too general purpose. The SIMD instructions are very quirky, and it's easy to unwittingly and silently cause the compiler to generate absolutely terribly slow code. The reasons for that are the alignment requirements, coupled with the SIMD instructions not being orthogonal - some operations work for some types and not for others, in a way that is unintuitive unless you're carefully reading the SIMD specs.
> 
> Just saying align(16) isn't good enough, as the vector ops work on slices and those slices aren't always aligned. So each one has to check alignment at runtime, which is murder on performance.
> 
> If a particular vector op for a particular type has no SIMD support, then the compiler has to generate workaround code. This can also have terrible performance consequences.
> 
> So the user writes vector code, benchmarks it, finds zero improvement, and the reasons why will be elusive to anyone but an expert SIMD programmer.
> 
> (Auto-vectorizing technology has similar issues, pretty much meaning you won't get fast code out of it unless you've got a habit of examining the assembler output and tweaking as necessary.)
> 
> Enter Manu, who has a lot of experience making SIMD work for games. His proposal was:
> 
> 1. Have native SIMD types. This will guarantee alignment, and will guarantee a compile time error for SIMD types that are not supported by the CPU.
> 
> 2. Have the compiler issue an error for SIMD operations that are not supported by the CPU, rather than silently generating inefficient workaround code.
> 
> 3. There are all kinds of weird but highly useful SIMD instructions that don't have a straightforward representation in high level code, such as saturated arithmetic. Manu's answer was to expose these instructions via intrinsics, so the user can string them together, be sure that they will generate real SIMD instructions, while the compiler can deal with register allocation.
> 
> This approach works, is inlineable, generates code as good as hand-built assembler, and is useable by regular programmers.
> 
> I won't say there aren't better approaches, but this one we know works.

I see. Thanks for clarifying.
If I want fast vector operations I have to use core.simd. The built-in
vector operations won't fit the bill. I was of the opinion that a vector
operation in D should (at some point) generate vectorized code.

Jens

Walter Bright wrote:
> On 11/2/2012 2:01 AM, Jens Mueller wrote:
> > I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones.
> 
> It's a very fair question.
> 
> Manu works for Remedy Games, a developer of hit PC games, such as Max Payne and Alan Wake. He champions a team that is investigating committing to D for a major new game. This would be a huge design win for D, and an enormous boost for D. I view the most effective use of my time at the moment is to ensure that they can bet on D and win. Remedy's use of D for a high profile product will prove that D is ready and able for the big time, and that others can develop using D with confidence.
> 
> Nearly all of what he needs the D community needs anyway, such as the big push for Win64 support and the SIMD support (more on that in another post).

Now I can understand why you made these decisions. It makes sense to me.
But I'd like to know which direction the ship is sailing.
The current rationale is to proof that D is ready for prime time. Though
I fear that some issues in the bug tracker may give a bad impression.
But in general the decision process should be as open and transparent as
possible. In Jacob's words: We need a road map.

Jens

Andrei Alexandrescu wrote:
> On 11/2/12 1:22 PM, Walter Bright wrote:
> >On 11/2/2012 2:01 AM, Jens Mueller wrote:
> > > I had the same thought when reading this. Very disappointing. An issue with zero votes is fixed instead of more important ones.
> >
> >It's a very fair question.
> >
> >Manu works for Remedy Games, a developer of hit PC games, such as Max Payne and Alan Wake. He champions a team that is investigating committing to D for a major new game. This would be a huge design win for D, and an enormous boost for D. I view the most effective use of my time at the moment is to ensure that they can bet on D and win. Remedy's use of D for a high profile product will prove that D is ready and able for the big time, and that others can develop using D with confidence.
> >
> >Nearly all of what he needs the D community needs anyway, such as the big push for Win64 support and the SIMD support (more on that in another post).
> 
> I should add that I'm also totally behind this. When Walter jumped into implementing SIMD support on a hunch, I completely disagreed, but that was a great decision.

>From the inside you can tell it is a great decision. From the outside it
looks different.

Jens