On Sat, Apr 04, 2015 at 04:31:06PM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/4/2015 1:48 PM, H. S. Teoh via Digitalmars-d wrote:
> >Besides, even if you could, you're just one person, whereas gdc/ldc have a much larger number of contributors, some of whose specialty is optimization.  Do you realistically think you can singlehandedly outdo all of them?
> 
> I did for decades, until the early 2000's or so when I began spending all my time on the front end.
[...]

Well, yes, that's because we need you more on DMDFE than on the backend, and that's why there will probably never be enough time for you to do everything you need to do with the backend. And that's why the backend will probably never be as good as gdc/ldc.


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.

On Sunday, 5 April 2015 at 05:04:52 UTC, H. S. Teoh wrote:
> On Sat, Apr 04, 2015 at 04:31:06PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 4/4/2015 1:48 PM, H. S. Teoh via Digitalmars-d wrote:
>> >Besides, even if you could, you're just one person, whereas gdc/ldc
>> >have a much larger number of contributors, some of whose specialty is
>> >optimization.  Do you realistically think you can singlehandedly
>> >outdo all of them?
>> 
>> I did for decades, until the early 2000's or so when I began spending
>> all my time on the front end.
> [...]
>
> Well, yes, that's because we need you more on DMDFE than on the backend,
> and that's why there will probably never be enough time for you to do
> everything you need to do with the backend. And that's why the backend
> will probably never be as good as gdc/ldc.
>
>
> T

You can't reason people out of what the haven't been reasoned into.

On Sunday, 5 April 2015 at 01:59:21 UTC, Daniel Murphy wrote:
> "weaselcat"  wrote in message news:rspoyryeklgjychqfyuk@forum.dlang.org...
>
>> Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team?
>
> The ldc and gdc teams have been involved since the first discussions at dconf13.

Yeah, I distinctly remember Iain, you and me plotting how we'd achieve world domination even if Walter couldn't be convinced in the Aloft lobby. ;)

 — David

On 4 April 2015 at 22:48, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sat, Apr 04, 2015 at 01:10:43PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 4/3/2015 9:41 AM, David Nadlinger wrote:
>> >On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote:
>> >>On 4/3/15 3:10 AM, Andrea Fontana wrote:
>> >>>It would be great to have dmd on embedded platforms.
>> >>
>> >>I agree. We just don't have the champion for that yet. -- Andrei
>> >
>> >I might obviously be biased, but to be honest I don't see much value in starting to port a largely obsolete backend to a whole new processor architecture.
>>
>> It's not obsolete at all. There's nothing fundamentally wrong with it, or preventing new optimizations being added to it. After all, I didn't have trouble upgrading it from 16 to 32 bits, from 32 to 64, to Linux, to OSX, to SIMD, etc.
>
> The trouble with the dmd backend is that it currently doesn't produce very well-optimized code. I have consistently observed a 20-30% performance degradation with code compiled with dmd vs. code compiled with gdc (both with all optimization switches turned to the max). From cursory investigation of the asm output, dmd appears to be unable to inline beyond the most trivial function calls, doesn't do loop refactoring / unrolling as well as gdc does, and a host of other little things that all add up to poorer performance when CPU-intensive inner loops are concerned. A lot of this deficiency shows up especially in range-based code, which consists of lots of calls to small functions from inner loops, where performance really matters.
>

Not just inlining, each CPU has it's own quirks that need tending to
as well, for instance, a Bonnel (Atom) CPU should have loop branches
aligned to a 16-byte boundary, where-as other chips (Core i7,
Sandybridge, etc) are fine on an 8-byte boundary.  (Observation made
in issue 5100)

Iain.

On 5 April 2015 at 13:49, David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 5 April 2015 at 01:59:21 UTC, Daniel Murphy wrote:
>>
>> "weaselcat"  wrote in message news:rspoyryeklgjychqfyuk@forum.dlang.org...
>>
>>> Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team?
>>
>>
>> The ldc and gdc teams have been involved since the first discussions at dconf13.
>
>
> Yeah, I distinctly remember Iain, you and me plotting how we'd achieve world domination even if Walter couldn't be convinced in the Aloft lobby. ;)
>

Step one being steering the development and direction of D awaying from Walter and into the hands of the community. ;-)

Incidentally, it's step two (convincing the community to switch priorities) is the more difficult part.

Iain.

Am 03.04.2015 00:44, schrieb Andrei Alexandrescu:
> switching to ddmd,  hopefully with 2.068.
>
> Andrei

That sounds nice, I just hope that there is going to be some nice migration path for people currently working on Pull-Requests for the C++ Version of dmd. I would prefer to not redo all the changes in D code.

-- 
Kind Regards
Benjamin Thaut

On 4/5/15 10:32 AM, Benjamin Thaut wrote:
> Am 03.04.2015 00:44, schrieb Andrei Alexandrescu:
>> switching to ddmd,  hopefully with 2.068.
>>
>> Andrei
>
> That sounds nice, I just hope that there is going to be some nice
> migration path for people currently working on Pull-Requests for the C++
> Version of dmd. I would prefer to not redo all the changes in D code.

Daniel, any thoughts? Can we help with tooling? -- Andrei

On Sunday, 5 April 2015 at 18:30:16 UTC, Andrei Alexandrescu wrote:
> On 4/5/15 10:32 AM, Benjamin Thaut wrote:
>> Am 03.04.2015 00:44, schrieb Andrei Alexandrescu:
>>> switching to ddmd,  hopefully with 2.068.
>>>
>>> Andrei
>>
>> That sounds nice, I just hope that there is going to be some nice
>> migration path for people currently working on Pull-Requests for the C++
>> Version of dmd. I would prefer to not redo all the changes in D code.
>
> Daniel, any thoughts? Can we help with tooling? -- Andrei

Shouldn't it be possible to tag the last C++ version of dmd? Then rebase the pull-reuqest on top of that and run it through the C++ to D conversion tool. Afterwards the output of the tool could be used to do a diff against the first D version of dmd (tagged again). This diff could then be used as a starting point for a new pull request. This will obviously not be perfect and might require some additional manual merging but at least people with larger pull requests (like me) don't have to redo the entire thing. A page with instructions how to do this conversion should be enough. Main points in question beeing, where to get the conversion tool and how to use it.

Kind Regards
Benjamin Thaut

On 5 April 2015 at 21:37, Benjamin Thaut via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 5 April 2015 at 18:30:16 UTC, Andrei Alexandrescu wrote:
>>
>> On 4/5/15 10:32 AM, Benjamin Thaut wrote:
>>>
>>> Am 03.04.2015 00:44, schrieb Andrei Alexandrescu:
>>>>
>>>> switching to ddmd,  hopefully with 2.068.
>>>>
>>>> Andrei
>>>
>>>
>>> That sounds nice, I just hope that there is going to be some nice migration path for people currently working on Pull-Requests for the C++ Version of dmd. I would prefer to not redo all the changes in D code.
>>
>>
>> Daniel, any thoughts? Can we help with tooling? -- Andrei
>
>
> Shouldn't it be possible to tag the last C++ version of dmd? Then rebase the pull-reuqest on top of that and run it through the C++ to D conversion tool. Afterwards the output of the tool could be used to do a diff against the first D version of dmd (tagged again). This diff could then be used as a starting point for a new pull request. This will obviously not be perfect and might require some additional manual merging but at least people with larger pull requests (like me) don't have to redo the entire thing. A page with instructions how to do this conversion should be enough. Main points in question beeing, where to get the conversion tool and how to use it.
>

Have a look here: https://github.com/D-Programming-Language/dmd/pull/3410

I believe the first goal is to get the automated conversion in as part of the autotester.  So any new PRs in will go through compilation (in C++), automated conversion to D, then re-compilation (in D).  If the PR cannot be automatically converted to D, then you'll need to fix it up in order to make conversion possible.

Regards
Iain

On Friday, 3 April 2015 at 17:51:00 UTC, Andrei Alexandrescu wrote:
> On 4/3/15 4:04 AM, Dennis Ritchie wrote:
>> On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote:
>>> It's the end of Q1. Walter and I reviewed our vision document. We're
>>> staying the course with one important addition: switching to ddmd,
>>> hopefully with 2.068.
>>>
>>> http://wiki.dlang.org/Vision/2015H1
>>>
>>>
>>> Andrei
>>
>> Are there any plans for the creation of a powerful AST-macro system in D?
>> http://wiki.dlang.org/DIP50
>
> Not for the time being. -- Andrei

Thanks. I hope that in the near future will be a powerful D macrosystem. If you ever start to create a macro system in D, then I suggest you explore approaches Lisp family of languages, because they have a very powerful macro-framework that allows modifying the language to suit your needs. In the family of Lisp contains a lot of powerful features that can once and for all to eclipse C++. It would be very nice if in the future you add these features in D. Sorry if I did something wrong said.

For Example,

D mixin's:
-----
import std.stdio;
import std.algorithm;

string print(string s)
{
	return `writeln(` ~ s ~ `);`;
}

void main()
{
	auto a = 3;
	auto arr = [1, 2, 3, 4, 5];
	
	mixin(print(`5`)); // prints 5
	mixin(print(`'c'`)); // prints c
	mixin(print(`"str"`)); // prints str
	mixin(print(`arr`)); // prints [1, 2, 3, 4, 5]
	mixin(print(`arr.map!(t => ++t)`)); // prints [2, 3, 4, 5, 6]
	mixin(print(`a`)); // prints 3
}
-----

Mixin, created by a powerful macro system Common Lisp:
-----
(defmacro mixin (f) (read-from-string (eval f)))

(defun pr (s)
  (format nil "(print ~A)" s))

(defun main (&aux (a 3) (arr '(1 2 3 4 5)))
  (mixin (pr "5"))
  (mixin (pr "#\\c"))
  (mixin (pr "\"str\""))
  (mixin (pr "arr"))
  (mixin (pr "(mapcar (lambda (x) (1+ x)) arr)"))
  (mixin (pr "a"))
  (values))
-----
CL-USER> (main)

5
#\c
"str"
(1 2 3 4 5)
(2 3 4 5 6)
3 ; No value