View mode: basic / threaded / horizontal-split · Log in · Help
November 02, 2012
Re: A little Py Vs C++
On 11/2/12, Walter Bright <newshound2@digitalmars.com> wrote:
> 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.

Wow that's really cool!

Manu if you know of any trivial-type bugs you'd like to get fixed (for
example error messages) let me know so I can prioritize them. There's
a ton of open issues and I usually select the ones for fixing by
random. I've managed to fix a few so far. :)
November 02, 2012
Re: A little Py Vs C++
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.

Andrei
November 02, 2012
Re: A little Py Vs C++
On Thursday, 1 November 2012 at 18:06:21 UTC, Peter Alexander 
wrote:
> On Wednesday, 31 October 2012 at 23:04:15 UTC, bearophile wrote:
>>
>> The thread contains some sad comments:
>
> It's unfortunate that there's still bad press circulating about 
> a situation that is long gone. I suppose you just have to try 
> and ignore those people.
>
> A more interesting comment is this one:
>
> "But the real problem here is that in order to achieve even 
> that, the complexity and amount of concepts you have to deal 
> with in C++11 is mind boggling."
>
> The same is true in D. Well-written D code often does look 
> rather elegant, but the amount of understanding needed to write 
> beautiful D code is staggering.

I think that is the case of any multi-paradigm language. It is 
already enough to allow both functional and OO style of 
programming to have hundreds of things to think about... That is 
exactly one of the major reasons why people prefer Java over 
other languages...
November 02, 2012
Re: A little Py Vs C++
On 11/2/2012 10:32 AM, Andrej Mitrovic wrote:
> Manu if you know of any trivial-type bugs you'd like to get fixed (for
> example error messages) let me know so I can prioritize them. There's
> a ton of open issues and I usually select the ones for fixing by
> random. I've managed to fix a few so far. :)

Thanks, any help would be appreciated. I'll ask Manu for a list of his priority 
issues, and even minor ones.

What will also help is trying out the beta Win64 target. I've been posting 
nightly new betas for it.
November 02, 2012
Re: A little Py Vs C++
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.
November 02, 2012
Re: A little Py Vs C++
On Friday, 2 November 2012 at 08:38:21 UTC, Don Clugston wrote:
> On 02/11/12 09:07, 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.
>
> He just knows how to convince Walter.
> (Hint: use real-world use cases. Arguments from theoretical 
> computer science carry almost no weight with Walter).
>
> > 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.
>
> Yes, and they could cure cancer. "AST macros" can do anything, 
> because they are completely undefined. Without even a vague 
> proposal, it seems like a rather meaningless term.

How do you think people came up with those bug reports? By some 
magic? :) You think they did not actually *pull their hair off* 
trying to figure out why their REAL LIFE program does not work, 
and when we could not find the reason we naturally started 
thinking "oh, it might be yet another missing thing in D" or "oh, 
yet another DMD/phobos/druntime bug!"...
Or, another scenario (a very typical one) - after 
DMD/phobos/druntime is updated, my production application no 
longer compiles...
November 02, 2012
Re: A little Py Vs C++
On 2012-11-02 09:38, Don Clugston wrote:

> Yes, and they could cure cancer. "AST macros" can do anything, because
> they are completely undefined. Without even a vague proposal, it seems
> like a rather meaningless term.

I know, I know. It's be brought up before and without any more detailed 
specification/definition is hard to do anything about it. I've done some 
research in the subject in the hope I can write down something useful 
that could be a proposal for D, but I don't have anything yet.

-- 
/Jacob Carlborg
November 02, 2012
Re: A little Py Vs C++
On 2012-11-02 19:03, Dejan Lekic wrote:

> How do you think people came up with those bug reports? By some magic?
> :) You think they did not actually *pull their hair off* trying to
> figure out why their REAL LIFE program does not work, and when we could
> not find the reason we naturally started thinking "oh, it might be yet
> another missing thing in D" or "oh, yet another DMD/phobos/druntime
> bug!"...
> Or, another scenario (a very typical one) - after DMD/phobos/druntime is
> updated, my production application no longer compiles...

Good point. When you do put the whole real life program in the bug 
report "it's too big, you need to create a small test case". When you do 
create a small test case for the feature/bug it's suddenly not "real 
life" code.

-- 
/Jacob Carlborg
November 02, 2012
Re: A little Py Vs C++
Le 02/11/2012 18:46, Andrei Alexandrescu a écrit :
> 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.
>
> Andrei

I still don't understand the benefice over align(16) float[4] .
November 02, 2012
Re: A little Py Vs C++
On Fri, 02 Nov 2012 18:10:39 -0000, deadalnix <deadalnix@gmail.com> wrote:

> Le 02/11/2012 18:46, Andrei Alexandrescu a écrit :
>> 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.
>>
>> Andrei
>
> I still don't understand the benefice over align(16) float[4] .

http://forum.dlang.org/thread/jauixhakwvpgsghapzvz@forum.dlang.org?page=4#post-k711rd:242786:242:40digitalmars.com

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home