On Friday, 2 November 2012 at 10:24:34 UTC, Jens Mueller wrote:
> Then I have a serious misunderstanding.
> I thought D introduced array operations to allow the compiler to
> generate efficient vector operations (in the long run), i.e. generate
> SIMD code. Why is this not working out?

It works fine for large vectors. For small vectors, it is horrendously slow.

The syntax a[] += b[] essentially calls a function which is designed to work for large vectors. It has to determine alignment, load everything from memory, do the operations, then store it back.

The SIMD extensions allow you to define variables that are guaranteed to be aligned and will probably be in the right registers to start with. Using them, the vectors ops don't need to determine alignment, and often don't need to do lots of loads/stores.

Both have their purposes.

Don Clugston wrote:
> On 02/11/12 10:01, Jens Mueller wrote:
> >Jacob Carlborg wrote:
> >>On 2012-11-01 23:51, Walter Bright wrote:
> >>
> >>>What about all your feature requests? I think you've made more than anyone, by a factor of 10 at least!
> >>>
> >>>:-)
> >>>
> >>>As for Manu's request
> >>>
> >>>http://d.puremagic.com/issues/show_bug.cgi?id=8108
> >>>
> >>>I've gone over with him why he needs it, and there's no other reasonable way. He needs it for real code in a real application.
> >>
> >>This is quite interesting. Manu comes in from basically nowhere and fairly quickly manage to convince Walter to implement at least two feature requests, this one and the SIMD support. I'm not saying that they shouldn't have been implemented. Although I think something like AST macros could possible solve issue 8108 and a whole bunch of other features, a few already present in the language.
> >
> >I had the same thought when reading this. Very disappointing. An issue
> >with zero votes is fixed instead of more important ones. Why do I vote
> >anyway?
> >Regarding SIMD I have the feeling that because it is built into the
> >compiler static vectors have actually failed what they promised. I
> >thought D proposed a portable way of vector operations such that you
> >write
> >float[4] = a[] + b[]
> >and the compiler generates SIMD code for you.
> 
> Not for short vectors. They are more like the builtin operations in Fortran, ie designed for large vectors. More for scientific kinds of applications than games. (The two applications look superficially similar, but in practice they have little in common).

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?

Jens

Peter Alexander wrote:
> On Friday, 2 November 2012 at 10:24:34 UTC, Jens Mueller wrote:
> >Then I have a serious misunderstanding.
> >I thought D introduced array operations to allow the compiler to
> >generate efficient vector operations (in the long run), i.e.
> >generate
> >SIMD code. Why is this not working out?
> 
> It works fine for large vectors. For small vectors, it is horrendously slow.
> 
> The syntax a[] += b[] essentially calls a function which is designed to work for large vectors. It has to determine alignment, load everything from memory, do the operations, then store it back.
> 
> The SIMD extensions allow you to define variables that are guaranteed to be aligned and will probably be in the right registers to start with. Using them, the vectors ops don't need to determine alignment, and often don't need to do lots of loads/stores.
> 
> Both have their purposes.

I see. But can't the alignment problem be solved by using align. Then have the compiler emits a call that checks for alignment if none was specified else use a faster version.

Jens

On Friday, 2 November 2012 at 10:50:56 UTC, Jens Mueller wrote:
> Don Clugston wrote:
>> On 02/11/12 10:01, Jens Mueller wrote:
>> >Jacob Carlborg wrote:
>> >>On 2012-11-01 23:51, Walter Bright wrote:
>> >>
>> >>>What about all your feature requests? I think you've made more than
>> >>>anyone, by a factor of 10 at least!
>> >>>
>> >>>:-)
>> >>>
>> >>>As for Manu's request
>> >>>
>> >>>http://d.puremagic.com/issues/show_bug.cgi?id=8108
>> >>>
>> >>>I've gone over with him why he needs it, and there's no other reasonable
>> >>>way. He needs it for real code in a real application.
>> >>
>> >>This is quite interesting. Manu comes in from basically nowhere and
>> >>fairly quickly manage to convince Walter to implement at least two
>> >>feature requests, this one and the SIMD support. I'm not saying that
>> >>they shouldn't have been implemented. Although I think something
>> >>like AST macros could possible solve issue 8108 and a whole bunch of
>> >>other features, a few already present in the language.
>> >
>> >I had the same thought when reading this. Very disappointing. An issue
>> >with zero votes is fixed instead of more important ones. Why do I vote
>> >anyway?
>> >Regarding SIMD I have the feeling that because it is built into the
>> >compiler static vectors have actually failed what they promised. I
>> >thought D proposed a portable way of vector operations such that you
>> >write
>> >float[4] = a[] + b[]
>> >and the compiler generates SIMD code for you.
>> 
>> Not for short vectors. They are more like the builtin operations in
>> Fortran, ie designed for large vectors. More for scientific kinds of
>> applications than games. (The two applications look superficially
>> similar, but in practice they have little in common).
>
> 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?
>
> Jens

The auto vectorization code in Visual Studio 2012 seems to work pretty well.

On 11/1/12 6:51 PM, Walter Bright wrote:
> On 11/1/2012 2:20 PM, bearophile wrote:
>> Some complexity comes from the
>> desire to do more and more. As example see this recent request from Manu,
>
> What about all your feature requests? I think you've made more than
> anyone, by a factor of 10 at least!
>
> :-)
>
> As for Manu's request
>
> http://d.puremagic.com/issues/show_bug.cgi?id=8108
>
> I've gone over with him why he needs it, and there's no other reasonable
> way. He needs it for real code in a real application.

I'd argue this actually is part of a category of features that does not increase the complexity of the language (quite the contrary in fact). This is because stating that declaration+definition in the same file won't work takes actually more cognitive load than just allowing it.

By the consistency principle, one should infer unknown parts of a complex system from knowing the others. Consider then this setup:

* Declarations (without definition) of functions are allowed.

* Definitions are allowed.

* Declarations and definitions are allowed in distinct files in the same project as long as they match.

At this point, it is more tenuous to argue that "same file" is a special case that should prevent declarations and definitions to coexist, than to just let it happen and let the consistency principle take care of explaining it.


Andrei

On 02/11/12 11:57, Jens Mueller wrote:
> Peter Alexander wrote:
>> On Friday, 2 November 2012 at 10:24:34 UTC, Jens Mueller wrote:
>>> Then I have a serious misunderstanding.
>>> I thought D introduced array operations to allow the compiler to
>>> generate efficient vector operations (in the long run), i.e.
>>> generate
>>> SIMD code. Why is this not working out?
>>
>> It works fine for large vectors. For small vectors, it is
>> horrendously slow.
>>
>> The syntax a[] += b[] essentially calls a function which is designed
>> to work for large vectors. It has to determine alignment, load
>> everything from memory, do the operations, then store it back.
>>
>> The SIMD extensions allow you to define variables that are
>> guaranteed to be aligned and will probably be in the right registers
>> to start with. Using them, the vectors ops don't need to determine
>> alignment, and often don't need to do lots of loads/stores.
>>
>> Both have their purposes.
>
> I see. But can't the alignment problem be solved by using align. Then
> have the compiler emits a call that checks for alignment if none was
> specified else use a faster version.

No. For SIMD, you cannot afford to have even a single machine instruction inserted, or the benefit is entirely lost.

Don Clugston wrote:
> On 02/11/12 11:57, Jens Mueller wrote:
> >Peter Alexander wrote:
> >>On Friday, 2 November 2012 at 10:24:34 UTC, Jens Mueller wrote:
> >>>Then I have a serious misunderstanding.
> >>>I thought D introduced array operations to allow the compiler to
> >>>generate efficient vector operations (in the long run), i.e.
> >>>generate
> >>>SIMD code. Why is this not working out?
> >>
> >>It works fine for large vectors. For small vectors, it is horrendously slow.
> >>
> >>The syntax a[] += b[] essentially calls a function which is designed to work for large vectors. It has to determine alignment, load everything from memory, do the operations, then store it back.
> >>
> >>The SIMD extensions allow you to define variables that are guaranteed to be aligned and will probably be in the right registers to start with. Using them, the vectors ops don't need to determine alignment, and often don't need to do lots of loads/stores.
> >>
> >>Both have their purposes.
> >
> >I see. But can't the alignment problem be solved by using align. Then have the compiler emits a call that checks for alignment if none was specified else use a faster version.
> 
> No. For SIMD, you cannot afford to have even a single machine instruction inserted, or the benefit is entirely lost.

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

On 11/02/2012 09:07 AM, Jacob Carlborg wrote:
> On 2012-11-01 23:51, Walter Bright wrote:
>
>> What about all your feature requests? I think you've made more than
>> anyone, by a factor of 10 at least!
>>
>> :-)
>>
>> As for Manu's request
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=8108
>>
>> I've gone over with him why he needs it, and there's no other reasonable
>> way. He needs it for real code in a real application.
>
> This is quite interesting. Manu comes in from basically nowhere and
> fairly quickly manage to convince Walter to implement at least two
> feature requests, this one and the SIMD support. I'm not saying that
> they shouldn't have been implemented.


SIMD support is necessary and the fix for 8108 is very simple. If the way default arguments work shall be improved though, it would add additional ways that the compiler can screw up conditional compilation.

> Although I think something like
> AST macros could possible solve issue 8108 and a whole bunch of other
> features, a few already present in the language.
>

A sufficiently well/badly designed macro feature can potentially replace most other language features.

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).

On 11/2/2012 10:22 AM, Walter Bright wrote:
> such as the big push for Win64 support

I want to give a shoutout here for Rainer Schuetze who has been a big help behind the scenes in getting the Win64 symbolic debug support working. He's saved me a ton of time.