> 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

Level 1 and Level 2 requires additional features like automatic loop unrolling with associative math.

In the same time, I don't think that DMD support is important for D and Mir. The following features are _much_ more important:

1. Lightweight `nothrow @nogc` threads, implemented using `struct`s
2. Lightweight `nothrow @nogc` mutexes and barriers, implemented using `struct`s
3. Low level and detailed CPUID with proper cache sizes (already implemented for x86 here: https://github.com/libmir/cpuid)
4. Ability to use some phobos modules like std.traits, std.meta, std.complex.Complex (without ^^), std.experimental.ndslice, std.allocator without current (old) DRuntime, "module info" and other harmful for "better C" feature.
5. LDC compiler support for ARM, MIPS, MIPS64, Alpha
6. LDC SDK, which can work out of the box (including windows). It is required for D to be popular for scientists

This features are good not only for Mir, but for the D future. I think that D can not be more popular then Go and Rust. This is reality and I don't think that it is bad. Why? Because D can be a backend language fo Go and Rust. It can replace C/C++/Fortran in following fields:

1. Low level high performance computation libraries like BLAS, Eigen, Intel MKL, MAGMA, scaLAPACK, and many others
2. Close to metal drivers
3. OS kernels
4. Aerospace and related software
5. The Khronos Group software (!)

We have not new concurrents in this fields, but C/C++/Fortran. Our problem is that we trying to be more hight level language than the IT industry needs. Lets forget about Go and Rust "concurrents" and remember about the initial D goal, which is more actual then ever: replace C/C++ in the IT industry.

Best regards,
Ilya

On Monday, 26 September 2016 at 18:43:38 UTC, Ilya Yaroshenko wrote:
>> I think we need to make it a point to support Mir in dmd. -- Andrei

[...]

> We have not new concurrents in this fields, but C/C++/Fortran. Our problem is that we trying to be more hight level language than the IT industry needs. Lets forget about Go and Rust "concurrents" and remember about the initial D goal, which is more actual then ever: replace C/C++ in the IT industry.
>
> Best regards,
> Ilya

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.

On Monday, 26 September 2016 at 19:49:27 UTC, bachmeier wrote:
> On Monday, 26 September 2016 at 18:43:38 UTC, Ilya Yaroshenko 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.

Yes, the same true for Mir too. A precompiled library based on top of Mir GLAS can be used with DMD.

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.

Ah, then no worries.

On Monday, 26 September 2016 at 19:49:27 UTC, bachmeier wrote:
> On Monday, 26 September 2016 at 18:43:38 UTC, Ilya Yaroshenko wrote:
>>> I think we need to make it a point to support Mir in dmd. -- Andrei
>
> [...]
>
>> We have not new concurrents in this fields, but C/C++/Fortran. Our problem is that we trying to be more hight level language than the IT industry needs. Lets forget about Go and Rust "concurrents" and remember about the initial D goal, which is more actual then ever: replace C/C++ in the IT industry.
>>
>> Best regards,
>> Ilya
>
> 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.

The functionality that it brings is also ease of use and simplicity if what you are doing is not only matrix stuff and will have other code in D.  It's an impressive effort,  and congratulations to Ilya and others.

DMD is useful for fast edit / compile cycle.   Maybe there are some advantages for gdc too for some people in some circumstances.  It's behind currently,  but in the respects that matter here I don't suppose it will always be so. Sometimes LDC has bugs that makes it difficult to compile one's code,  and new features will always show up on DMD first.

It's a pity to fragment the ecosystem - to potentially have a library that works on one of three main compilers, but that's sufficiently good that nobody else will write a competing library that works on all compilers.

It's not for your or me to tell Ilya and colleagues what to do,  and it certainly won't do any good to do so.   One could access Mir in DMD from a D wrapper on top of C bindings to Mir,  but is anyone likely to write these and keep them up to date? I am not so sure.

Everyone is entitled to their own view about the proper role of D,  and I know Ilya has strong views on this topic,  and that's normal because people think in different ways and is in a different situation.

So I think Andrei's goal makes much sense strategically,  though I have no idea how it might be achieved.


Laeeth

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

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.

On Monday, 26 September 2016 at 22:34:59 UTC, Andrei Alexandrescu wrote:
> 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

Why not?  I think people will understand that ldc is meant for higher performance, which you want from such code anyway.

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. One way or another we need to get Mir to be portable across all D implementations and hopefully convince Ilya to move it into D's standard library.

Put another way: we have a beautiful use case of what primitives we need to offer to allow definition of a generic library that beats the pants off hand-optimized assembler. We should be all over implementing said primitives. There's clear proof and there's a clean short list of things we need to do. If we're asking ourselves "what kind of primitives we should add to D to make it awesomely fast?" this is the best experience report we could ever hope for.

Instead of debating minor things herein, and instead of adding "little projects that could" to an ever-growing wishlist, we should rally behind a real strong project and take it from 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

On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei Alexandrescu wrote:
> 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. One way or another we need to get Mir to be portable across all D implementations and hopefully convince Ilya to move it into D's standard library.
>
> [...]

In order to create code as efficient as ldc or gdc we need to rewrite dmds backend.

Are you suggesting that ?

Or are you arguing for importing a huge amount of pre-generated asm into phobos,
which would be much more likely to succeed.

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.