A little Py Vs C++

[Manu]

Uh oh, I just caught wind of this thread! ;)

If there's a single argument I'd like to make in defense of the changes
that have gone through as a result of my motivating, it's that they're
either big tickets and mutually beneficial for the whole community anyway
(DMD-win64), or relatively trivial (function prototypes + definitions)
details that enable us to realistically consider proceeding with D
commercially.

The SIMD types support may be considered a little grey, but I've
encountered loads of general D users who appreciate the SIMD work already,
and while it's certainly not trivial, it's nowhere the mammoth scale of
task auto-vectorisation would be. I can't see it as a loss for the language
or the community, and again, it has further enabled our consideration of D
commercially; which I'd like to think is a general goal for the language.

I know plenty of you don't care about me or my industry, but I maintain
that it's an entire industry in desperate need of salvation from C++,
there's a lot of potential in the games industry to get fantastic value
from using D, and I'm interested in proving that it's a realistic
consideration.

I'd also like to note that we are also very conscious of the time Walter
and other contributors have kindly offered to our support, and we are
hopeful to be able to give reasonable value back to the community should it
all go well for us, in whatever way that manifests...

On 2 November 2012 11:01, Jens Mueller <jens.k.mueller at gmx.de> wrote:

> Jacob Carlborg wrote:
> > On 2012-11-01 23:51, Walter Bright wrote:
> >
> > >What about all your feature requests? I think you've made more than
> > >anyone, by a factor of 10 at least!
> > >
> > >:-)
> > >
> > >As for Manu's request
> > >
> > >http://d.puremagic.com/issues/show_bug.cgi?id=8108
> > >
> > >I've gone over with him why he needs it, and there's no other reasonable
> > >way. He needs it for real code in a real application.
> >
> > This is quite interesting. Manu comes in from basically nowhere and
> > fairly quickly manage to convince Walter to implement at least two
> > feature requests, this one and the SIMD support. I'm not saying that
> > they shouldn't have been implemented. Although I think something
> > like AST macros could possible solve issue 8108 and a whole bunch of
> > other features, a few already present in the language.
>
> I had the same thought when reading this. Very disappointing. An issue
> with zero votes is fixed instead of more important ones. Why do I vote
> anyway?
> Regarding SIMD I have the feeling that because it is built into the
> compiler static vectors have actually failed what they promised. I
> thought D proposed a portable way of vector operations such that you
> write
> float[4] = a[] + b[]
> and the compiler generates SIMD code for you.
>

As I mentioned above, I think that is a MUCH larger task, and probably
fairly unrealistic in the near-term regardless.
But secondly, it's just not that simple. (I can see Walter has already
addressed it in a previous post)

It's worth considering that a very significant portion of the silicon on
modern processors (well in excess of 50% on some chips) is dedicated to
hardware acceleration of SIMD/media functions. Until recently, D simply
offered no mechanism at all to interact with half of the silicone in your
box. That's a massive language hole.
At least as a starting point, low level access to this hardware is vital.
Portable libraries can be built using this technology, which are
immediately useful.

The definition of hardware SIMD types doesn't rule out possible future
auto-vectorisation either. And you can probably access auto-vectorising
backends right now if you use GDC or LDC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121102/8a5cea2a/attachment.html>