View mode: basic / threaded / horizontal-split · Log in · Help
January 14, 2013
Re: Ready for review: new std.uni
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
January 14, 2013
Re: Ready for review: new std.uni
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.
January 14, 2013
Re: Ready for review: new std.uni
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
January 14, 2013
Re: DMD, GDC, LDC [was Re: Ready for review: new std.uni]
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';
January 14, 2013
Re: DMD, GDC, LDC [was Re: Ready for review: new std.uni]
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';
January 14, 2013
Re: Ready for review: new std.uni
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>.
January 14, 2013
Re: DMD, GDC, LDC [was Re: Ready for review: new std.uni]
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.
January 14, 2013
Re: DMD, GDC, LDC [was Re: Ready for review: new std.uni]
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.
January 14, 2013
Re: DMD, GDC, LDC [was Re: Ready for review: new std.uni]
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
January 14, 2013
Re: DMD, GDC, LDC [was Re: Ready for review: new std.uni]
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
3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home