A small, but important milestone has been achieved!

Many thanks for the help from Sebastian Wilzbach and Rainer Schuetze.

On Tuesday, 3 July 2018 at 21:57:07 UTC, Walter Bright wrote:
> A small, but important milestone has been achieved.

Nice!

On Tue, Jul 03, 2018 at 02:57:07PM -0700, Walter Bright via Digitalmars-d wrote:
> A small, but important milestone has been achieved!
> 
> Many thanks for the help from Sebastian Wilzbach and Rainer Schuetze.

Hopefully this eventually translates to actual improvements to the optimizer?


T

-- 
If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.

On 04/07/2018 9:57 AM, Walter Bright wrote:
> A small, but important milestone has been achieved!
> 
> Many thanks for the help from Sebastian Wilzbach and Rainer Schuetze.

On that note, I have a little experiment that I'd like to see done.
How would the codegen change, if you were to triple the time the optimizer had to run?

On Tuesday, 3 July 2018 at 21:57:07 UTC, Walter Bright wrote:
> A small, but important milestone has been achieved!
>
> Many thanks for the help from Sebastian Wilzbach and Rainer Schuetze.

Great job guys! Does this mean you will take advantage of asm feature?

-Aleaxander

On Tuesday, 3 July 2018 at 21:57:07 UTC, Walter Bright wrote:
> A small, but important milestone has been achieved!
>
> Many thanks for the help from Sebastian Wilzbach and Rainer Schuetze.

Fantastic, I see that 35 of 88 files in the backend have been translated or added in D, with more being done:

https://github.com/dlang/dmd/pulls?q=is%3Apr+is%3Aopen+label%3A"D+Conversion"

Hope we can get DMD 2.082 out as almost fully written in D. :)

On Tuesday, 3 July 2018 at 23:05:00 UTC, rikki cattermole wrote:
>
> On that note, I have a little experiment that I'd like to see done.
> How would the codegen change, if you were to triple the time the optimizer had to run?

Would it make any difference to compile DMD with LDC?

On 05/07/2018 4:06 AM, jmh530 wrote:
> On Tuesday, 3 July 2018 at 23:05:00 UTC, rikki cattermole wrote:
>>
>> On that note, I have a little experiment that I'd like to see done.
>> How would the codegen change, if you were to triple the time the optimizer had to run?
> 
> Would it make any difference to compile DMD with LDC?

We already know the answer to this, and the answer is yes. Dmd does run faster. But that isn't what I'm interested in.

What I want to know is if dmd will produce better code if you give the optimizer longer time to run. Because right now that is the limiting factor.

For older hardware like 20 years ago, the number being used might be quite desirable, but perhaps we can fine tune it a bit and get drastically better results. Who knows? Gotta test that out!

On Thu, Jul 05, 2018 at 04:55:09AM +1200, rikki cattermole via Digitalmars-d wrote:
> On 05/07/2018 4:06 AM, jmh530 wrote:
> > On Tuesday, 3 July 2018 at 23:05:00 UTC, rikki cattermole wrote:
> > > 
> > > On that note, I have a little experiment that I'd like to see done.  How would the codegen change, if you were to triple the time the optimizer had to run?
> > 
> > Would it make any difference to compile DMD with LDC?
> 
> We already know the answer to this, and the answer is yes. Dmd does run faster. But that isn't what I'm interested in.
> 
> What I want to know is if dmd will produce better code if you give the optimizer longer time to run. Because right now that is the limiting factor.
[...]

Actually, what will make dmd produce better code IMO is: (1) a more
aggressive metric for the inliner (currently it gives up too easily, at
the slightest increase in code complexity), and (2) implement loop
unrolling.

Both are pretty big factors because of the domino-effect in optimization: inlining a function opens up opportunities for refactoring wrt the surrounding code, which may yield simplified code that can be further optimized.  Similarly, (possibly speculative) loop unrolling may produce simplified code wrt the surrounding context, thus revealing more loop optimization opportunities. In turn, these opportunities may lead to more optimization opportunities.

Giving up too early on either front means you miss the first step in this chain of successive optimizations, so you lose the whole chain.

I came to this conclusion after looking at disassembly comparisons between dmd and gdc/ldc over several of my projects.  At first I thought that the dmd optimizer doesn't implement loop optimizations, but it turns out to be false; dmd *is* capable of things like strength reduction and code lifting, but as Walter himself has said, it does *not* implement loop unrolling. Comparing with gdc's output, for example, it's pretty clear to me that the lack of unrolling causes further optimization opportunities to be missed.  Ditto with inlining -- gdc's inliner, for example, is far more aggressive and inlines a lot more things, whereas dmd's inliner gives up earlier.  While for simple code this may actually be better, for more complex code (and most importantly, for range-based code), it causes missed optimization opportunities down the road.

If we can nail down these two things, I think dmd's codegen quality should improve significantly.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi

On 05/07/2018 5:22 AM, H. S. Teoh wrote:
> If we can nail down these two things, I think dmd's codegen quality
> should improve significantly.

Not disagreeing with your assessment. But that is a lot of work, so why not try out a 'free' experiment as an addition? Just for interests sake.