On Mon, 2013-01-14 at 06:33 +0100, David Nadlinger wrote:
> On Monday, 14 January 2013 at 04:42:33 UTC, Andrei Alexandrescu wrote:
> > I'll candidly mention that David's request was unclear to me. It's been winding enough that I missed the key sentence. Was it that we switch dmd to using llvm as backend?
> 
> If you want, yes - but not in the form of an actionable proposal yet. I was trying to argue that the benefits of using an existing solution like GCC or LLVM are large enough (resp. the costs of using a custom backend high enough) that we should seriously consider doing so. Especially because it looks as if the amount of work needed to keep the DMD backend and thus the reference D compiler competitive is going to increase further as other backends are gaining things like auto-vectorization to light up modern CPUs and ARM is gaining in importance.

Having D in the GCC set is a good move for marketing the D language. GDC could be a vehicle for bringing more programmers to D but it needs more resource to bring it up to date.

Having D in the LLVM set is a good move for marketing the D language. LDC is a vehicle for bringing people to D. It would be good to get the Debian package updated and actively kept up. This would then get it packaged for Ubuntu and Mint. It would be good to get it packaged for Fedora.

Keeping going with DMD is fine, as long as it is in the knowledge that GDC and LDC are the D toolchains that will lead to wider D usage.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 2013-01-14 03:24, Walter Bright wrote:

> But as for optlink, I would have happily turned it over to anyone who
> expressed interest in working on it. I'd also put it on github if anyone
> wanted to look at it.

Then I would say, put in on github regardless if anyone wants to take a look at it. It doesn't hurt.

-- 
/Jacob Carlborg

On Mon, 2013-01-14 at 01:30 -0500, Chad J wrote:
[…]
> tooling.  We got the invite and we stood them up.  IMO, sticking to an x86-centric toolset cost D one of its perfect opportunities for being a killer tool.  That makes me kinda sad.

If you can't do x86_64 and ARM you are legacy. Even the JVM now runs on ARM processors.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 14 January 2013 at 07:52:49 UTC, Russel Winder wrote:
> LDC is a vehicle for bringing people to D. It would be good to get the Debian package updated and actively kept up.

As we have a recent release now: Who do I have to ping about resurrecting the Debian package? I have never really used any Debian-based distros (except for some server boxes), so I have no good idea of how to find a packager and how to best assist with the packaging process.

I know of the importance of getting an LDC package into Debian, but it would be much, much easier if somebody who is at home in both the D and Debian communities (or at least uses a Debian-based distro on a day-to-day basis) could handle this.

David

On 14 January 2013 08:03, David Nadlinger <see@klickverbot.at> wrote:

> On Monday, 14 January 2013 at 07:52:49 UTC, Russel Winder wrote:
>
>> LDC is a vehicle for bringing people to D. It would be good to get the Debian package updated and actively kept up.
>>
>
> As we have a recent release now: Who do I have to ping about resurrecting the Debian package? I have never really used any Debian-based distros (except for some server boxes), so I have no good idea of how to find a packager and how to best assist with the packaging process.
>
> I know of the importance of getting an LDC package into Debian, but it would be much, much easier if somebody who is at home in both the D and Debian communities (or at least uses a Debian-based distro on a day-to-day basis) could handle this.
>
> David
>


I could set things in motion for you, but you'd probably have to nudge me once every 6 months to push in updates.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 14 January 2013 at 08:20:11 UTC, Iain Buclaw wrote:
> I could set things in motion for you, but you'd probably have to nudge me
> once every 6 months to push in updates.

That would be great! How do we proceed?

David

On Monday, 14 January 2013 at 07:21:57 UTC, Walter Bright wrote:
> I've done some research on auto-vectorization, i.e. "The Software Vectorization Handbook" by Bik.
>
> My conclusion (Manu independently came to the same one, he's our resident SIMD expert) is that auto-vectorization is a disaster.
>
> What it is is:
>
> 1. Reverse engineer a loop into a higher level construct
> 2. Recompile that construct using vector instructions
>
> It's a disaster because (2) often fails in ways that are utterly mysterious to 99% of programmers. The failure mode is to not auto-vectorize the loop. Hence, the failure is silent and the user just sees poor performance, if he notices it at all.

Virtually all common C/C++ compilers have had SIMD types/intrinsics for years now, which is more or less exactly what core.simd is for D - well, there is some syntax sugar for arithmetic operations on the D vector types, but it doesn't cover any of the "interesting" operations such as broadcasting, swizzling, etc.

Yet *all* the big compiler vendors (Microsoft, Intel, GCC, LLVM) seem to find it necessary to spend considerable amounts of effort on improving their heuristics for the indeed quite problematic optimization process you describe.

I don't think that rehashing the common reasons cited for the importance of (auto-)vectorizing code here would be of any use, you are certainly aware of them already. Just don't forget that Manu (who seems to have disappeared from the forums, crunch time?) represents a group of programmers who would resort to hand-written assembly for their "embarrassingly parallel" code if suitable compiler intrinsics didn't exist, whereas the vast majority of programmers probably would be troubled to reliably identify the cases where vectorization would have the biggest benefits in their code bases, even if they could justify spending time/maintainability on manually optimizing their code at this level.

David

On Mon, 2013-01-14 at 09:26 +0100, David Nadlinger wrote:
> On Monday, 14 January 2013 at 08:20:11 UTC, Iain Buclaw wrote:
> > I could set things in motion for you, but you'd probably have
> > to nudge me
> > once every 6 months to push in updates.
> 
> That would be great! How do we proceed?

I just emailed the listed packager cc yourself. I guess I should have included Ian due to the GDC connection.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2013-01-14 at 08:37 +0000, Russel Winder wrote: […]
> included Ian due to the GDC connection.

/Ian/s//Iain/

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

> I.e. D's approach is to fix the language to support vector semantics, rather than trying to back-asswards fit it into the optimizer.

I agree that adding SIMD types and operations to the languages is a better approach than autovectorization. I'd just like to point out that DMD's backend still has serious problems regarding SIMD support, which makes getting SIMD code to work with DMD a pain. For example, see those two bugs:

http://d.puremagic.com/issues/show_bug.cgi?id=9304
http://d.puremagic.com/issues/show_bug.cgi?id=9200

I don't know how much work it is to fix those issues and any similar ones, but I think this is relevant to the discussion in this thread, since GCC and LLVM backends don't have those problems.