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
