View mode: basic / threaded / horizontal-split · Log in · Help
November 02, 2012
Re: A little Py Vs C++
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.
November 02, 2012
Re: A little Py Vs C++
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.
November 02, 2012
Re: A little Py Vs C++
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
November 02, 2012
Re: A little Py Vs C++
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
November 02, 2012
Re: A little Py Vs C++
> "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
November 02, 2012
Re: A little Py Vs C++
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
November 02, 2012
Re: A little Py Vs C++
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.
November 02, 2012
Re: A little Py Vs C++
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
November 02, 2012
Re: A little Py Vs C++
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
November 02, 2012
Re: A little Py Vs C++
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
2 3 4 5 6 7
Top | Discussion index | About this forum | D home