On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei Alexandrescu wrote:
> On 9/27/16 2:52 AM, Joakim wrote:
>> Why not?  I think people will understand that ldc is meant for higher
>> performance, which you want from such code anyway.
>
......

> provincial notability to global success. I've said in the past I'm not that good, but I am good enough to recognize great work. Ilya's work is that.
>
>
> Andrei


Better support inline. i am not an expert but dmd can not handle inline if there are few if.. else

On Tuesday, 27 September 2016 at 01:55:17 UTC, Nicholas Wilson wrote:
> On Monday, 26 September 2016 at 22:34:59 UTC, Andrei Alexandrescu wrote:
>> On 9/26/16 10:11 PM, Ilya Yaroshenko wrote:
>>> A precompiled library based on top of Mir GLAS can be used with DMD.
>>
>> That would work out as long as interaction is seamless. Please advise. Overall: I think Ilya's work can make a real difference for D, and we can't afford it to not work with the reference implementation. -- Andrei
>
> Mir will be (optionally) integrated with dcompute (once it is ready)
> and dcompute CANNOT be compiled at all by dmd, although I suppose
> you could use dmd for rapid development cycle, but you would have to
> make dmd only figure out the .mangleof of the kernel (as the .mangleof
> is required for the library-side API bashing magic) and not try to do any
> semantic analysis or compilation, as it would fail horribly.

Can dcompute even be compiled by stock ldc?  If so, you should change the documents as code.dlang.org suggests otherwise.

As I understand it dcompute is a GPU library.   Not everyone will want to or need GPU for doing work with matrices,  so even if/when dcompute can be compiled by stock ldc, I wonder if it makes sense to prevent Mir being compiled without the dependency.   You say it us optional,  but then the rest of your message when read quickly almost suggests it's difficult not to include it.

The emphasis is that mir is faster than openblas,  which is great,  and natural as a library author to be proud of.   I guess to displace other options in other languages you will also need to be faster than any other sensible choices,  including Blaze (and I don't know if this is yet the case).   It's a tough sell persuading the Julia and Rust guys to use your library instead,  because people aren't completely rational about languages,  and it's almost an admission of defeat for them to adopt your solution permanently (more likely in my view us they try to use your tricks to improve their own performance) - it would need to be a lot better,  is my guess.

Whatever the outcome there is, the emphasis in superior performance isn't the only one that users will have.   If you want to do matrix work in D, then having a sensible native solution is much easier - speed is nice,  but mostly about ease of use and reduction in complexity and context switching.   Most people are not at the frontier of performance needs,  so this point applies to many potential users, not a minority.

On Monday, 26 September 2016 at 18:43:38 UTC, Ilya Yaroshenko wrote:
> 5. LDC compiler support for ARM, MIPS, MIPS64, Alpha

Alpha CPU nowadays? I supposed it is died forever, except small amount of old hardware.

> Can dcompute even be compiled by stock ldc?  If so, you should change the documents as code.dlang.org suggests otherwise.
>
PR is open, CI is green, but needs some more work before it will be accepted.

> As I understand it dcompute is a GPU library.   Not everyone will want to or need GPU for doing work with matrices,  so even if/when dcompute can be compiled by stock ldc, I wonder if it makes sense to prevent Mir being compiled without the dependency.
DCompute will target OpenCL and CUDA so it can run on the cpu as well.
OpenCL requires a "non-standard" llvm.
>   You say it us optional,  but then the rest of your message when read quickly almost suggests it's difficult not to include it.
As in it will be a setting in mir to support dcompute.
It will be difficult to do the 'compile kernels with ldc and the rest with dmd'
trick that Ilya suggested for using mir with dmd.
>
> The emphasis is that mir is faster than openblas,  which is great,  and natural as a library author to be proud of.   I guess to displace other options in other languages you will also need to be faster than any other sensible choices,  including Blaze (and I don't know if this is yet the case).   It's a tough sell persuading the Julia and Rust guys to use your library instead,  because people aren't completely rational about languages,  and it's almost an admission of defeat for them to adopt your solution permanently (more likely in my view us they try to use your tricks to improve their own performance) - it would need to be a lot better,  is my guess.
>
> Whatever the outcome there is, the emphasis in superior performance isn't the only one that users will have.   If you want to do matrix work in D, then having a sensible native solution is much easier - speed is nice,  but mostly about ease of use and reduction in complexity and context switching.

I can't speak for mir, but I intend dcompute to be as user friendly as CUDA.

> Most people are not at the frontier of performance needs,  so this point applies to many potential users, not a minority.

On 9/26/2016 11:43 AM, Ilya Yaroshenko wrote:
>> I think we need to make it a point to support Mir in dmd. -- Andrei
>
> Required features for Level 3:
> 1. https://issues.dlang.org/show_bug.cgi?id=16489
> 2. https://issues.dlang.org/show_bug.cgi?id=16488
> 3. AVX & AVX2 floating point vector arithmetic
> 4. Generic unaligned load/store like (like LDC loadUnaligned and storeUnaligned)
> 5. Generic routine to pack and unpack real and imaginary parts. For usage
> example, see
> https://github.com/libmir/mir/blob/master/source/mir/glas/internal/copy.d#L699

Could you provide more detail on these, please?

For example, on the last link there is no documentation on what those templates do or what their parameters are. For example,

  template _mix0(V)
  {
    import ldc.simd;
    enum _pred(size_t a) = (a & 1) == 0 ? a / 2 : a / 2 + V.length;
    alias _mix0 = shufflevector!(V, staticMap!(_pred, Iota!(V.length)));
  }

??

I'd like to see each of the points at least put into an Enhancement Request on bugzilla, where we can evaluate them in an organized fashion. (Like what you've done for (1) and (2).)

On 2016-09-26 21:49, bachmeier wrote:

> To me, it seems pointless to support Mir in DMD. The "functionality"
> that it brings is speed. Nobody needing absolutely the fastest code is
> not going to have any interest in DMD. From what I understand of Mir
> (but correct me if I'm wrong) it is easy enough to replicate its
> functionality by linking to existing linear algebra libraries. Others
> can construct a compatible interface if that's something they want.
>
> I think Ilya and everyone else working on Mir should push forward with
> the LDC-based project. Anything else is a distraction.

He mentions several front end issues, those apply to LDC as well.

-- 
/Jacob Carlborg

On 2016-09-27 02:52, Joakim wrote:
> On Monday, 26 September 2016 at 20:11:19 UTC, Ilya Yaroshenko wrote:
>> Yes, the same true for Mir too. A precompiled library based on top of
>> Mir GLAS can be used with DMD.
>
> Are you sure about this?  I thought there were ABI incompatibilities
> between D compilers.

They're not ABI compatible.

-- 
/Jacob Carlborg

On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei Alexandrescu wrote:
> On 9/27/16 2:52 AM, Joakim wrote:
>> Why not?  I think people will understand that ldc is meant for higher
>> performance, which you want from such code anyway.
>
> I'm not going to argue this much further. Essentially Mir is touted as a highly generic and portable library. Having it only work on one language implementation works against that statement, the credibility of Mir, and the credibility of D as an universal platform for creating fast code.

Just let dmd die.

On Tuesday, 27 September 2016 at 08:40:38 UTC, Temtaime wrote:
> On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei Alexandrescu wrote:
>> On 9/27/16 2:52 AM, Joakim wrote:
>>> Why not?  I think people will understand that ldc is meant for higher
>>> performance, which you want from such code anyway.
>>
>> I'm not going to argue this much further. Essentially Mir is touted as a highly generic and portable library. Having it only work on one language implementation works against that statement, the credibility of Mir, and the credibility of D as an universal platform for creating fast code.
>
> Just let dmd die.

This so-called "reference implementation" makes people suffer because of code portability and another differences between the compilers (e.g. compiler building, compiler's command line arguments, compiler's extensions).

On Tuesday, 27 September 2016 at 07:01:08 UTC, Jacob Carlborg wrote:
> On 2016-09-26 21:49, bachmeier wrote:
>
>> To me, it seems pointless to support Mir in DMD. The "functionality"
>> that it brings is speed. Nobody needing absolutely the fastest code is
>> not going to have any interest in DMD. From what I understand of Mir
>> (but correct me if I'm wrong) it is easy enough to replicate its
>> functionality by linking to existing linear algebra libraries. Others
>> can construct a compatible interface if that's something they want.
>>
>> I think Ilya and everyone else working on Mir should push forward with
>> the LDC-based project. Anything else is a distraction.
>
> He mentions several front end issues, those apply to LDC as well.

No, LDC for example does not have the issue https://issues.dlang.org/show_bug.cgi?id=16488 and others too.