On Friday, 7 October 2016 at 17:02:02 UTC, Andrei Alexandrescu
wrote:
On 10/07/2016 03:42 AM, Ilya Yaroshenko wrote:
For example, SUM_i of sqrt(fabs(a[i])) can be vectorised using
mir.ndslice.algorithm.
vxorps instruction can be used for fabs.
vsqrtps instruction can be used for sqrt.
LDC's @fas
On Friday, 7 October 2016 at 17:02:02 UTC, Andrei Alexandrescu
wrote:
On 10/07/2016 03:42 AM, Ilya Yaroshenko wrote:
2. Math funcitons are not templates -> They are not inlined ->
No vectorization + function calls in a loop body. One day this
may be fixed, but (1.a, 1.b).
That trivial non-t
On 10/07/2016 03:42 AM, Ilya Yaroshenko wrote:
For example, SUM_i of sqrt(fabs(a[i])) can be vectorised using
mir.ndslice.algorithm.
vxorps instruction can be used for fabs.
vsqrtps instruction can be used for sqrt.
LDC's @fastmath allows to re-associate summation elements.
Depend on data cache
On Friday, 7 October 2016 at 01:53:27 UTC, Andrei Alexandrescu
wrote:
On 10/6/16 12:53 PM, Ilya Yaroshenko wrote:
Effective work with std.experimental.ndslice and and
mir.ndslice.array
requires half of std.math be an exactly aliases to LLVM
intrinsics (for
LDC).
Why?
To enable vectorization
On 10/6/16 12:53 PM, Ilya Yaroshenko wrote:
Effective work with std.experimental.ndslice and and mir.ndslice.array
requires half of std.math be an exactly aliases to LLVM intrinsics (for
LDC).
Why?
To enable vectorization for mir.ndslice.algorithm I created internal
math module [1] in Mir. Bu
On Thursday, 6 October 2016 at 20:55:55 UTC, Ilya Yaroshenko
wrote:
So, I don't see a reason why this change break something, hehe
No, Iain is right. These LLVM intrinsics are most often simple
forwarders to the C runtime functions; I was rather negatively
surprised to find out a while ago.
On 6 October 2016 at 22:55, Ilya Yaroshenko via Digitalmars-d
wrote:
> On Thursday, 6 October 2016 at 20:45:24 UTC, Iain Buclaw wrote:
>>
>> On 6 October 2016 at 22:31, Ilya Yaroshenko via Digitalmars-d
>> wrote:
>>>
>>> On Thursday, 6 October 2016 at 20:07:19 UTC, Iain Buclaw wrote:
>>
On Thursday, 6 October 2016 at 20:45:24 UTC, Iain Buclaw wrote:
On 6 October 2016 at 22:31, Ilya Yaroshenko via Digitalmars-d
wrote:
On Thursday, 6 October 2016 at 20:07:19 UTC, Iain Buclaw wrote:
On 6 October 2016 at 18:53, Ilya Yaroshenko via Digitalmars-d
wrote:
[...]
If you can pro
On 6 October 2016 at 22:31, Ilya Yaroshenko via Digitalmars-d
wrote:
> On Thursday, 6 October 2016 at 20:07:19 UTC, Iain Buclaw wrote:
>>
>> On 6 October 2016 at 18:53, Ilya Yaroshenko via Digitalmars-d
>> wrote:
>>>
>>> [...]
>>
>>
>> If you can prove that llvm intrinsics are pure (gcc math intr
On Thursday, 6 October 2016 at 20:07:19 UTC, Iain Buclaw wrote:
On 6 October 2016 at 18:53, Ilya Yaroshenko via Digitalmars-d
wrote:
[...]
If you can prove that llvm intrinsics are pure (gcc math
intrinsics are not) and that llvm intrinsics pass the unittest
(gcc math intrinsics aren't guar
On 6 October 2016 at 18:53, Ilya Yaroshenko via Digitalmars-d
wrote:
> Effective work with std.experimental.ndslice and and mir.ndslice.array
> requires half of std.math be an exactly aliases to LLVM intrinsics (for
> LDC).
>
> To enable vectorization for mir.ndslice.algorithm I created internal m
On Thursday, 6 October 2016 at 16:53:54 UTC, Ilya Yaroshenko
wrote:
Effective work with std.experimental.ndslice and and
mir.ndslice.array requires half of std.math be an exactly
EDIT: mir.ndslice.algorithm
Effective work with std.experimental.ndslice and and
mir.ndslice.array requires half of std.math be an exactly aliases
to LLVM intrinsics (for LDC).
To enable vectorization for mir.ndslice.algorithm I created
internal math module [1] in Mir. But this is weird, because third
side packages like
13 matches
Mail list logo
