May 20, 2017 Re: [4Walter&Andrei] D is 40 times slower. We need a new language feature! | ||||
---|---|---|---|---|
| ||||
Posted in reply to 9il | 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 Re: [4Walter&Andrei] D is 40 times slower. We need a new language feature! | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | 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 Re: [4Walter&Andrei] D is 40 times slower. We need a new language feature! | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | 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 Re: [4Walter&Andrei] D is 40 times slower. We need a new language feature! | ||||
---|---|---|---|---|
| ||||
Posted in reply to 9il | 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 |
Copyright © 1999-2021 by the D Language Foundation