Re: std.math API rework

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

Re: std.math API rework

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

Re: std.math API rework

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

Re: std.math API rework

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

Re: std.math API rework

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.

Re: std.math API rework

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.

Re: std.math API rework

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

Re: std.math API rework

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

Re: std.math API rework

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

Re: std.math API rework

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

Re: std.math API rework

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

Re: std.math API rework

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

std.math API rework

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