Required DMD changes for Mir and few thoughts about D future

[Ilya Yaroshenko via Digitalmars-d]

> 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