On 1/14/2013 12:28 AM, David Nadlinger wrote:
> 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.

Actually, they do a crappy job of it in my experiments.

> 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.

The fundamental problem they face is they cannot change the language - they have to work with bog standard code that has no notion of SIMD.


> 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.

Here's the problem. Draw a table of SIMD vector types on one axis, and arithmetic operations on the other. Plot an X for what is supported.

You'll find that the pattern of X's doesn't follow much of a pattern, and it varies all over the place for different CPUs and architectures.

Now consider your autovectorizer. If an X isn't there, it (silently) generates workaround code. The only way you'll really be able to tell it went wrong is to disassemble the result - and who is going to do that?

And what's much, much worse about this, is pulling values out of and into SIMD registers to do those workarounds causes massive stalls (the SIMD unit and the arithmetic unit are separate), so bad that you're better off doing no vectorization at all.

The next problem with an autovectorizer is alignment - consider the C function:

    int func(float *p) { ... }

Now you want to autovectorize inside func(). Is p aligned? Who knows? So you must emit code to do misaligned vectors, which is another performance disaster.

The D approach is if you are able to get your vector code to compile, it will be:

1. aligned properly
2. compiled to real SIMD instructions

On 1/14/2013 12:54 AM, jerro wrote:
>> 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

Yeah, I know about those, I'll fix 'em. The SIMD support in the compiler is still young.

On Monday, 14 January 2013 at 09:02:25 UTC, Walter Bright wrote:
>> 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.
>
> The fundamental problem they face is they cannot change the language - they have to work with bog standard code that has no notion of SIMD.

They *are* changing the language using SIMD intrinsics and built-in types. It might be that D can do a somewhat nicer job at that by standardizing them and using less cryptic names, but the fundamental concept remains the same.

And again, you don't have to convince me about the problems inherent to auto-vectorization, I'm well aware of them. I'm just pointing out that despite these obstacles, compiler vendors are still trying to implement it, probably because writing vector code is fundamentally difficult (as you mentioned, you can easily shoot yourself in the foot in many ways, performance-wise), and you can't justify just not using the vector units on today's chips.

It's not that I think __vector, core.simd and friends would be a *bad* idea. But your general dismissal of auto-vectorization seems a bit too quick and convenient to me.

David

On 14 January 2013 08:44, Russel Winder <russel@winder.org.uk> wrote:

> On Mon, 2013-01-14 at 08:37 +0000, Russel Winder wrote: […]
> > included Ian due to the GDC connection.
>
> /Ian/s//Iain/
>
>
Thanks for the name correction. :)

-- 
Iain Buclaw

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

On 14 January 2013 08:26, David Nadlinger <see@klickverbot.at> 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?
>
> David
>

Mattias is the current maintainer IIRC.  I can request a transfer of ownership to either myself or someone who is willing to maintain the package for LDC.  Also I need to post updates for the GDC package too, so might as well do both in one hit.

-- 
Iain Buclaw

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

On 1/14/2013 1:41 AM, David Nadlinger wrote:
> It's not that I think __vector, core.simd and friends would be a *bad* idea. But
> your general dismissal of auto-vectorization seems a bit too quick and
> convenient to me.

I agree it's more convenient not to implement it.

I also prefer using a lawnmower to a pair of scissors <g>.

On Mon, Jan 14, 2013 at 09:03:13AM +0100, David Nadlinger 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.
[...]

I'm a Debian developer (a very dormant one ever since I got married, I'll admit, but nevertheless one). I am rusty with the procedures due to not having used them for a while, but at least I know where to look and am familiar with the conventions used. So I'm willing to help. I can probably even sponsor uploads, if that's what it takes.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.

On Monday, 14 January 2013 at 16:11:00 UTC, H. S. Teoh wrote:
> On Mon, Jan 14, 2013 at 09:03:13AM +0100, David Nadlinger wrote:
>> On Monday, 14 January 2013 at 07:52:49 UTC, Russel Winder
> I'm a Debian developer (a very dormant one ever since I got married,
> I'll admit, but nevertheless one). I am rusty with the procedures due to
> not having used them for a while, but at least I know where to look and
> am familiar with the conventions used. So I'm willing to help. I can
> probably even sponsor uploads, if that's what it takes.

Hi,

 I would love to see gdc-4.7 (ie. based on gcc 4.7) in Debian Sid ASAP (maybe it still on schedule to be included into next Ubuntu - Raring Ringtail).

 Currently, the gdc package is still at the pre-historic era of gcc 4.6.3:

http://packages.debian.org/sid/devel/gdc

and Ubuntu follows closely with:

http://packages.ubuntu.com/ko/raring/devel/gdc

while its gcc package is 4.7.2:

http://packages.ubuntu.com/ko/raring/gcc

Many thanks for any implication on that side.

Al 14/01/13 08:52, En/na Russel Winder ha escrit:
> 
> 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.

LDC is already available on Fedora 17.

-- 
Jordi Sayol

On Mon, 2013-01-14 at 19:01 +0100, Jordi Sayol wrote:
[…]
> LDC is already available on Fedora 17.

LDC is already available in Debian, it is just a very old version. Looks like the Fedora version is LDC as at 2012-06-24 from the Git repository. One up to Fedora :-)

-- 
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