On Sat, May 20, 2017 at 12:00:37PM +, 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
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
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
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
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
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
On Saturday, 20 May 2017 at 03:24:41 UTC, 9il wrote:
The reason is that `matrixX[i, j]` is opIndex call, opIndex is
a function. It can be inlined. But optimizers can not split its
body and move half of opIndex computations out of the inner
loop, which it required for vectorization.
Hmm, look
On Saturday, 20 May 2017 at 03:53:42 UTC, Vladimir Panteleev
wrote:
On Saturday, 20 May 2017 at 03:24:41 UTC, 9il wrote:
What can I do to make it happen?
Sounds like you're asking for opIndex currying?
https://en.wikipedia.org/wiki/Currying
Have you tried implementing opIndex as a function
On Saturday, 20 May 2017 at 03:50:31 UTC, rikki cattermole wrote:
On 20/05/2017 4:24 AM, 9il wrote:
snip
Looks like Rust macro system can do something similar.
Just to confirm, in Rust is it calling a function to assign the
value?
I mean that Rust has macro system. I do not know if it can
On Saturday, 20 May 2017 at 03:53:19 UTC, Nicholas Wilson 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
[...]
I assume you compiled with LDC and used pragma(inline, true).
Have you had a chance to
On Saturday, 20 May 2017 at 03:24:41 UTC, 9il wrote:
What can I do to make it happen?
Sounds like you're asking for opIndex currying?
https://en.wikipedia.org/wiki/Currying
Have you tried implementing opIndex as a function which takes a
single argument, and returns an object which then also
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
[...]
I assume you compiled with LDC and used pragma(inline, true).
Have you had a chance to look at what
`-fsave-optimization-record` gives you? (This was
On 20/05/2017 4:24 AM, 9il wrote:
snip
Looks like Rust macro system can do something similar.
Just to confirm, in Rust is it calling a function to assign the value?
E.g.
```D
void opIndexAssign(T v, size_t j, size_t i);
```
Because if the compiler is seeing a function call, it probably won't
Hello,
When users write math code, they expect [2, 3, 4] that the code
like
--
import mir.ndslice; //[1]
...
foreach (i; 0..m)
{
foreach (j; 0..n)
{
// use matrix1[i, j], matrix2[i, j], matrix3[i, j]
}
}
--
will be vectorized like in Fortran and other math
14 matches
Mail list logo
