On 2012-01-15 06:00, Michel Fortin wrote:
> On 2012-01-15 03:06:22 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:
>
>> It seems that the problem is that while Walter can be saved effort by
>> having someone else do that kind of work, it doesn't necessarily save
>> him all that much effort, since he still must ultimately take the time
>> to fully understand what's being changed and what the implications are
>> before he merges it in.
>
> It still saves the effort of coming up with a solution, implementing
> that solution, updating the test suite, etc. I think this is
> significant. But you're right, it's more effort to review than most
> other pull requests, and it might not be something he likes to do.
>
>
>> And the ramifications of pull request #3 are larger than most, so it
>> makes sense if it takes longer for it to be sorted out. Still, given
>> the importance of pull request #3, I would have thought that it would
>> have been handled much sooner than this. It's getting very close to
>> being a year old.
>
> A year old and outdated: it won't merge cleanly anymore (despite the
> update I made this summer). I should probably keep maintaining it, but
> as it is now I don't think I'll bother until Walter is ready to look at it.
>
> But I'm a little surprised he hasn't even looked at it yet given this is
> a problem he tried to fix himself before. In his place, I'd be very
> curious to understand how it works.
>
> And also, #3 is pretty small compared to something else I could come
> with one day (D/Objective-C).

Oh, yeah. But I'm looking forward to it.

-- 
/Jacob Carlborg

On Sunday, 15 January 2012 at 03:31:15 UTC, Andrei Alexandrescu wrote:
> On 1/14/12 9:06 PM, Jonathan M Davis wrote:
>> On Saturday, January 14, 2012 20:54:55 Michel Fortin wrote:
>>> Still, Walter perfectly has the right to decide on what he wants to
>>> work. I understand that he saw implementing SIMD as an interesting
>>> challenge, and if working on SIMD keeps things interesting for him,
>>> that can only be great.
>>
>> Sure. I can understand why the most important thing to work  on might not be
>> the most interesting thing to work on. And Walter certainly has the right to
>> work on whatever he wants to work on.
>
> Exactly and perfectly right. To add to that, with my limited time, I can hardly afford to work on stuff that isn't fun (although lately I've done some of it - e.g. I'm not a web designer). There comes a point, however, when we need to decide whether our main priority is having fun or making D successful.

I would argue that a happy coder is a productive coder. I'm personally very please Walter and others are so interested in SIMD support. Then again, it suites my interests so I admit bias.


> 2. We haven't identified game designers as a core market, and one that's more important than e.g. general purpose programmers who need the like of working qualifiers, multithreading, and shared libraries.
> 
> 3. There was never a promise or even a mention that we'll deliver SIMD. We virtually promise we deliver threads and expressive qualifiers, and there's still work to do on that.

> 5. The SIMD work has _zero_ acceleration on existing code; it only allows experts to write non-portable code that uses SIMD instructions. Updating to the next release of dmd has zero SIMD-related benefit to statistically our entire user base.
>
> Walter and I spend hours on the phone discussing strategies and tactics to make D more successful. And then comes this binge. Doing anything on SIMD now is a mistake that I am sorry I was unable to stop. About the only thing that's good about it all is that it'll be over soon.
>
>
> Andrei

To put it plainly, I wouldn't really be interested in D if it wasn't for game design and art applications. C/C++ has been loosing ground to languages like Java and C# in the business/server world for years because of painless development, fancy libraries, and features like Linq. But one area C/C++ still remain strong is among performance critical code. Given D's opening message: "Modeling power. Native efficiency." and it's goal of succeeding C++, I don't see how you can sideline one of C's most invested parties so easily.

Andrei Alexandrescu:

> 2. We haven't identified game designers as a core market, and one that's more important than e.g. general purpose programmers who need the like of working qualifiers, multithreading, and shared libraries.

From what I've seen games were one of the very few significant applications of D1 language.

Bye,
bearophile

"Michel Fortin" <michel.fortin@michelf.com> wrote in message news:jetbld$23qt$1@digitalmars.com...
> Looks good in theory, but in practice this approach hasn't worked very well for pull request number 3.
>

I may have mentioned this before, but there are a couple of things that make me think pull 3 shouldn't be merged as is. (Even if it was made merge-ready)

1. The patch tries (and in some places, doesn't try) to match implicit conversion and template deduction behaviour for pointers and arrays which are badly defined and in some cases don't make any sense.  I'd prefer to get those sorted out before adding a third referencey TypeNext to dmd.

2. The addition of head() means a huge amount of changes that aren't really necessary.  Most of the changes are insertions of calls to this function, which introduces quite a bit of mess and potential for easy bugs if someone forgets to use it.

I don't know if Walter has a similar list of reservations he's keeping to himself, or just hasn't gotten around to it yet.  Hopefully I'll find some time to work on these issues (or somebody else will).

On 15/01/2012 14:26, Daniel Murphy wrote:
> "Michel Fortin"<michel.fortin@michelf.com>  wrote in message
> news:jetbld$23qt$1@digitalmars.com...
>> Looks good in theory, but in practice this approach hasn't worked very
>> well for pull request number 3.
>>
>
> I may have mentioned this before, but there are a couple of things that make
> me think pull 3 shouldn't be merged as is. (Even if it was made merge-ready)
>
> 1. The patch tries (and in some places, doesn't try) to match implicit
> conversion and template deduction behaviour for pointers and arrays which
> are badly defined and in some cases don't make any sense.  I'd prefer to get
> those sorted out before adding a third referencey TypeNext to dmd.
>
> 2. The addition of head() means a huge amount of changes that aren't really
> necessary.  Most of the changes are insertions of calls to this function,
> which introduces quite a bit of mess and potential for easy bugs if someone
> forgets to use it.
>
> I don't know if Walter has a similar list of reservations he's keeping to
> himself, or just hasn't gotten around to it yet.  Hopefully I'll find some
> time to work on these issues (or somebody else will).

Might be worth adding this as a comment on the pull request!

-- 
Robert
http://octarineparrot.com/

On 2012-01-15 14:26:45 +0000, "Daniel Murphy" <yebblies@nospamgmail.com> said:

> I may have mentioned this before, but there are a couple of things that make
> me think pull 3 shouldn't be merged as is. (Even if it was made merge-ready)
> 
> 1. The patch tries (and in some places, doesn't try) to match implicit
> conversion and template deduction behaviour for pointers and arrays which
> are badly defined and in some cases don't make any sense.  I'd prefer to get
> those sorted out before adding a third referencey TypeNext to dmd.
> 
> 2. The addition of head() means a huge amount of changes that aren't really
> necessary.  Most of the changes are insertions of calls to this function,
> which introduces quite a bit of mess and potential for easy bugs if someone
> forgets to use it.
> 
> I don't know if Walter has a similar list of reservations he's keeping to
> himself, or just hasn't gotten around to it yet.  Hopefully I'll find some
> time to work on these issues (or somebody else will).

Great points. You should post them in the pull request, which is the right place to discuss them (especially the second one, since you already sort-of commented on the first issue by annotating the test cases).

Also, if Walter has similar reservations, I hope he'd write them in a pull request comment. Negative feedback is much better than no feedback at all, because with no feedback there is nothing anyone can do to improve things.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 1/15/12 5:30 AM, Peter Alexander wrote:
> On 15/01/12 3:31 AM, Andrei Alexandrescu wrote:
>> 1. SIMD is not the top of the list. Two weeks ago it wasn't _on_ the
>> list. Now it's like the last 'copter outta Saigon.
>
> That's not true. SIMD intrinsics has always been on the list. I've only
> been in this newsgroup for a year or so, but I've definitely seen D's
> lack of SIMD support mentioned in several discussions so far. It's a
> frequent complaint about the language.

I made a cursory search and the last thread before nowadays is "Vectorizations intrinsics for DMD?" started on 2/6/11 by... Peter Alexander.

>> 2. We haven't identified game designers as a core market, and one that's
>> more important than e.g. general purpose programmers who need the like
>> of working qualifiers, multithreading, and shared libraries.
>
> Game programming is quite clearly a very large market for D.

We've never identified it as such. My perception is that adoption of D is much larger in other industries (while still small in absolute numbers).

> The game
> industry is perhaps one of the largest software industries that still
> relies on having C/C++ level of efficiency and low-level access. It's
> also an industry that is absolutely sick of having to use C++. D is
> quite close to the perfect language for game developers.
>
> I think it's also telling that perhaps the most prolific (ex-)D coder,
> Tomasz, was a game programmer, and that one of the largest D libraries
> is Derelict, which is also aimed at games.
>
> Finally, if you look at the dsource projects,
> http://dsource.org/projects/ you'll see that Games make up quite a large
> chunk of what people are using D for.
>
> What do you think our core market is?

Walter and I think that our core market consists of general purpose programmers who don't want to compromise one of productivity and code efficiency in their work. This group includes programmers in other languages than C++.

>> 3. There was never a promise or even a mention that we'll deliver SIMD.
>> We virtually promise we deliver threads and expressive qualifiers, and
>> there's still work to do on that.
>
> Fair point.

Fair is not the half of it. As a speaker and ambassador of D, it is difficult for me to stay with the conservative examples, being unable to showcase the really strong differentiating features because they're insufficiently implemented.

>> 4. There was broad agreement that the main foci going forward would be
>> quality, expressive qualifiers, shared libraries, Phobos work, and
>> publicizing the language. We can't work with and publicize D's awesome
>> concurrency design if parts of it aren't implemented.
>
> I suspect that SIMD support will greatly help to publicize the language.

I don't. I have zero evidence to believe that claim. Not one reader or one attendee asked me about that. They ask me about things such as (a) compiler quality; (b) concurrency; (c) availability on non-Intel platforms; (d) libraries, including the frequent "algorithms are cool, but when will you have STL-like containers?" Thank God the question "what's the deal with D1/D2 and Phobos/Tango?" is not asked anymore. Announcing support cessation for D1 must have been the best decision we took in 2011.

>> 5. The SIMD work has _zero_ acceleration on existing code; it only
>> allows experts to write non-portable code that uses SIMD instructions.
>> Updating to the next release of dmd has zero SIMD-related benefit to
>> statistically our entire user base.
>
> Where are you getting the figures for the % of people that will benefit
> from SIMD support? The SIMD support thread is rather large, so that
> suggests to me that a significant number of people are quite interested
> in the SIMD work.

I think it's tempting but inaccurate to gather numbers from the thread. I predict SIMD support will come and stay, and it will make no impact on D.

>> Walter and I spend hours on the phone discussing strategies and tactics
>> to make D more successful. And then comes this binge. Doing anything on
>> SIMD now is a mistake that I am sorry I was unable to stop. About the
>> only thing that's good about it all is that it'll be over soon.
>
> I can't speak on your private conversations with Walter, but I think
> you're underestimating how important SIMD support is for D.

I understand. I think you're overestimating it. The future will tell.

> Also, it appears (from his rate of progress) that Walter is quite
> enjoying the SIMD work. I see no harm in a short-lived "binge" if it
> reinvigorates Walter's interest in compiler work -- especially if you
> please a large part of the community in the process.

Yes. Totally agree. The way I see it, it's a welcome vacation.


Andrei

On 01/14/2012 10:31 PM, Andrei Alexandrescu wrote:
>
> 2. We haven't identified game designers as a core market

You probably should, as C++ is the de facto standard in the games
industry, and the one area where D could shine above languages like C#
or Java. You might even be able to get some funding from big companies
like EA or others if you can convince them you're on the right track.

> and one that's more important than e.g. general purpose programmers
> who need the like of working qualifiers, multithreading, and shared
> libraries.

And this is just as, if not more important, in the games industry as
elsewhere. I do agree that a correct and full implementation of these
features is more important than Walter getting distracted on a late-game
feature request. Since Walter is gating pull requests, he should either
prioritize them or delegate the responsibility.

I'm interested in game development using D, so I'll post my opinion.

I think the discussions here show how particularly specialized people
here are. I've seen some Manu's posts and it was clear that he is a person
in gamedev who thinks most development is like gamedev and can't see the bigger
picture. For a gamedev person, SIMD support is not simply a cool feature, it's
a gamechanger. Just like const, ranges, D threading features and so on. However,
his posts often show that he doesn't understand positions of other people in other
areas, e.g. people here working on scientific computing, who are also interested
in SIMD but their thinking of terms such as "vector" is completely different.

I think you're making the same mistake here - you have very little (or no?) idea about gamedev and aren't exposed to game programmers, so you just assume specific gamedev issues don't exist or are unimportant. I don't think you get much of exposure to game devs when evangelizing D either - you don't evangelize D in game companies.


For me, SIMD support is extremely important. I can live without it, because I'm not working on some AAA title that needs to squeeze every last bit of performance from a PC/PS3/ARM phone or whatever (I'm an open source dev - doing this for fun). But regardless it's bean a great disadvantage until now that the only way to use SIMD was inline ASM which also happe

Also, I have been trying to evangelize D in my environment - an university (UPJS in Kosice, Slovakia) - and to other people who do game development as a hobby. The fact that there have been no SIMD intrinsics has been a disadvantage when promoting D - in fact, I know at least one person who considered D for his project and did _not_ use it due to that.

Furthermore, I think we can get even better than C/C++ compiler's vendor's solutions by creating portable Phobos modules that would encapsulate the platform-specific intrinsics - e.g. to provide basic vector and matrix structs which are present in every game project and usually always implemented from scratch (in particular, I think the gl3n library, which was recently announced and provides a very nice GLSL-plus-improvements syntax, could be built on top of the SIMD intrinsics).

A game-oriented linear algebra module backed by SIMD in Phobos would be superior to the approach taken by various C/C++ compiler/library vendors - where the code must be rewritten for each compiler.

I could use that to better promote D.

D happens to be pretty much the perfect language for game development - the GC
scares people away but I found the combination of GC-in-most-code and
manually-managed-critical-stuff to work quite well.
It's a far better language for this purpose that C# - to which many people
have been moving - and C++ is just getting obsolete

You also seem to be unaware of the size of game development industry - this is in fact one of the largest software development industries that still needs a systems programming language. You shouldn't underestimate that just because you don't frequently come into contact with game developers.


To be clear: I'm not saying that fixing the advertised features is unimportant. In fact, the greatest problems I see in promoting D are that we don't even have finished containers in the API - and that many features described in TDPL don't work correctly. But I find the statement that SIMD is a waste of time, or, for that matter, that it will help little in promoting D's adoption - to be completely incorrect.

On 15-01-2012 18:02, Jeff Nowakowski wrote:
> On 01/14/2012 10:31 PM, Andrei Alexandrescu wrote:
>>
>> 2. We haven't identified game designers as a core market
>
> You probably should, as C++ is the de facto standard in the games
> industry, and the one area where D could shine above languages like C#
> or Java. You might even be able to get some funding from big companies
> like EA or others if you can convince them you're on the right track.

Not gonna happen until the GC is fixed. That much is safe to say.

>
>> and one that's more important than e.g. general purpose programmers
>> who need the like of working qualifiers, multithreading, and shared
>> libraries.
>
> And this is just as, if not more important, in the games industry as
> elsewhere. I do agree that a correct and full implementation of these
> features is more important than Walter getting distracted on a late-game
> feature request. Since Walter is gating pull requests, he should either
> prioritize them or delegate the responsibility.

--
- Alex