On 9/27/2016 3:20 AM, Andrei Alexandrescu wrote:
> Can we make sure all issues that Mir has with dmd and gdc be present in bugzilla
> and tagged with "Mir"? Thanks! -- Andrei

The ones I've seen so far have all been SIMD issues, and I've been tagging them that way.

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.

Isn't it just a matter of adding "version(LDC)" around the more optimized blocks?
Having it work in DMD, however slower, is good enough.

On Tuesday, 27 September 2016 at 10:44:28 UTC, Guillaume Piolat wrote:
> 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.
>
> Isn't it just a matter of adding "version(LDC)" around the more optimized blocks?
> Having it work in DMD, however slower, is good enough.

50 times slower for modern CPUs.

On 9/27/2016 3:48 AM, Ilya Yaroshenko wrote:
> 50 times slower for modern CPUs.

I understand, and that's a drastic speed difference. But removing support for dmd can have the effect of balkanizing the D community. That's happened in the past, and it was terrible for all of us.

I have looked at:

  https://github.com/libmir/mir/pull/347/files

I propose as a first step we can work towards eliminating the conditional compilation based on which compiler is running. Then we can look for low hanging fruit on the codegen to reduce the performance gap.

On 9/27/2016 3:36 AM, Ilya Yaroshenko wrote:
> Will fill them tomorrow --Ilya

Thank you. Looking forward to it.

On Tuesday, 27 September 2016 at 10:44:28 UTC, Guillaume Piolat wrote:
> 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.
>
> Isn't it just a matter of adding "version(LDC)" around the more optimized blocks?
> Having it work in DMD, however slower, is good enough.

(copying from the previous thread:)

I thought so too but if the algorithm is 50x slower, it probably means you can't develop that algorithm any more (I wouldn't). I think the common use-case for Mir is a calculation that takes seconds, so 50x turns a test into a run of several minutes, defeating the compilation speed advantage of DMD. The way I see it, faster development with Mir+DMD is not possible.

It is easy to want something, but someone else has to do it and live with it too. It's up to the Mir devs (**volunteers!**) to choose which compilers they support. As you can see from the PR that removed DMD support, the extra burden is substantial.
https://github.com/libmir/mir/pull/347

An extra subjective comment from recent experience: I think LDC has been very responsive to Mir's needs, thinking _with_ Mir development instead of fighting it and debating things to death. Imagine you are developing Mir, want to get something done, and then read the discussion starting here
https://forum.dlang.org/post/brieiuuuslpzfeioxuql@forum.dlang.org
The LDC PR with the requested functionality was submitted less than two weeks after
(pull was stalled because we don't control our own frontend).

On Tuesday, 27 September 2016 at 10:48:40 UTC, Ilya Yaroshenko wrote:
> On Tuesday, 27 September 2016 at 10:44:28 UTC, Guillaume Piolat wrote:
>> 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.
>>
>> Isn't it just a matter of adding "version(LDC)" around the more optimized blocks?
>> Having it work in DMD, however slower, is good enough.
>
> 50 times slower for modern CPUs.

version (DMD)
{
    pragma(message, "It seems you are building with DMD instead of LDC. Be aware that some functions will go up to 50x slower");
}

=> no misrepresentation of Mir performance
=> the user testing Mir keeps testing instead of having it not working

On Tuesday, 27 September 2016 at 11:33:54 UTC, Johan Engelen wrote:
> An extra subjective comment from recent experience: I think LDC has been very responsive to Mir's needs, thinking _with_ Mir development instead of fighting it and debating things to death. Imagine you are developing Mir, want to get something done, and then read the discussion starting here
> https://forum.dlang.org/post/brieiuuuslpzfeioxuql@forum.dlang.org
> The LDC PR with the requested functionality was submitted less than two weeks after
> (pull was stalled because we don't control our own frontend).

I've read the thread. I think Walter was right and correctly advised you the whole thread. One thing Mir users will do is copying executables from machine to machines. If it has runtime dispatch, it will work everywhere.

On Tuesday, 27 September 2016 at 13:36:50 UTC, Guillaume Piolat wrote:
> 
> If it has runtime dispatch, it will work everywhere.

I'm sorry but, like others, clearly you have not understood the issue.

On 9/27/16 1:33 PM, Johan Engelen wrote:
> I thought so too but if the algorithm is 50x slower, it probably means
> you can't develop that algorithm any more (I wouldn't). I think the
> common use-case for Mir is a calculation that takes seconds, so 50x
> turns a test into a run of several minutes, defeating the compilation
> speed advantage of DMD. The way I see it, faster development with
> Mir+DMD is not possible.

Yes, 50x is not going to pass. In my experience, generally (not for numerics code) dmd generated code is somewhat in between 5% faster and 40% slower. I'd say if we get it within the same range for Ilya's library we can call it a successful port.

> It is easy to want something, but someone else has to do it and live
> with it too. It's up to the Mir devs (**volunteers!**) to choose which
> compilers they support. As you can see from the PR that removed DMD
> support, the extra burden is substantial.
> https://github.com/libmir/mir/pull/347

We need to do what it takes to make dmd work with Mir properly.

> An extra subjective comment from recent experience: I think LDC has been
> very responsive to Mir's needs, thinking _with_ Mir development instead
> of fighting it and debating things to death. Imagine you are developing
> Mir, want to get something done, and then read the discussion starting here
> https://forum.dlang.org/post/brieiuuuslpzfeioxuql@forum.dlang.org
> The LDC PR with the requested functionality was submitted less than two
> weeks after
> (pull was stalled because we don't control our own frontend).

That's far from the worst we've had, but I agree that generally the endless debates are often gridlocking our progress.


Andrei