May 20, 2017
On Saturday, 20 May 2017 at 11:34:55 UTC, 9il wrote:
> On Saturday, 20 May 2017 at 11:30:54 UTC, John Colvin wrote:
>> On Saturday, 20 May 2017 at 03:24:41 UTC, 9il wrote:
>>> Hello,
>>>
>>> When users write math code, they expect [2, 3, 4] that the code like
>>>
>>> [...]
>>
>> What you are saying is that there is a specific shortcoming that you are observing in optimisers, yes? Perhaps we should investigate how to fix the optimisers first before insisting on language additions / changes.
>>
>> Have you talked to someone with experience writing optimisers about what stops the relevant optimisation being done after inlining?
>
> I just found that new LLVM solves this issue (and was very surprised).
> The reason that ndslice <=v0.6.1 was so slow is LDC Issue 2121.
> I have added workaround in [2], it is v0.6.2.
>
> [1] https://github.com/ldc-developers/ldc/issues/2121
> [2] https://github.com/libmir/mir-algorithm/pull/41

What's​ surprising about it? Thinking very simplistically (I don't know how it actually works), if inlining happened first then surely the later optimisation stages wouldn't have a problem detecting the necessary loop invariants and hoisting them out.
May 20, 2017
On Saturday, 20 May 2017 at 11:47:32 UTC, John Colvin wrote:
>
> What's​ surprising about it? Thinking very simplistically (I don't know how it actually works), if inlining happened first then surely the later optimisation stages wouldn't have a problem detecting the necessary loop invariants and hoisting them out.

Inlining is usually one of the first passes scheduled.
So that should not be an issue,
However loop-invariant code motion is not straight-forward.
May 20, 2017
On Saturday, 20 May 2017 at 11:47:32 UTC, John Colvin wrote:
> On Saturday, 20 May 2017 at 11:34:55 UTC, 9il wrote:
>> On Saturday, 20 May 2017 at 11:30:54 UTC, John Colvin wrote:
>>> [...]
>>
>> I just found that new LLVM solves this issue (and was very surprised).
>> The reason that ndslice <=v0.6.1 was so slow is LDC Issue 2121.
>> I have added workaround in [2], it is v0.6.2.
>>
>> [1] https://github.com/ldc-developers/ldc/issues/2121
>> [2] https://github.com/libmir/mir-algorithm/pull/41
>
> What's​ surprising about it? Thinking very simplistically (I don't know how it actually works), if inlining happened first then surely the later optimisation stages wouldn't have a problem detecting the necessary loop invariants and hoisting them out.

It did not work before. I did similar benchmarks a year ago.
May 20, 2017
On Sat, May 20, 2017 at 12:00:37PM +0000, 9il via Digitalmars-d wrote:
> On Saturday, 20 May 2017 at 11:47:32 UTC, John Colvin wrote:
> > On Saturday, 20 May 2017 at 11:34:55 UTC, 9il wrote:
> > > On Saturday, 20 May 2017 at 11:30:54 UTC, John Colvin wrote:
> > > > [...]
> > > 
> > > I just found that new LLVM solves this issue (and was very
> > > surprised).
> > > The reason that ndslice <=v0.6.1 was so slow is LDC Issue 2121.
> > > I have added workaround in [2], it is v0.6.2.
> > > 
> > > [1] https://github.com/ldc-developers/ldc/issues/2121
> > > [2] https://github.com/libmir/mir-algorithm/pull/41
> > 
> > What's surprising about it? Thinking very simplistically (I don't know how it actually works), if inlining happened first then surely the later optimisation stages wouldn't have a problem detecting the necessary loop invariants and hoisting them out.
> 
> It did not work before. I did similar benchmarks a year ago.

I don't think this warrants a language change.  It's an implementation issue, specifically, an optimizer issue. Optimizers can always be refined and improved further.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi
1 2
Next ›   Last »