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