__restrict, architecture intrinsics vs asm, consoles, and other

Manu Evans turkeyman at gmail.com
Fri Sep 23 16:45:57 PDT 2011


== Quote from bearophile (bearophileHUGS at lycos.com)'s article
> Manu Evans:
> I appreciate your efforts. I answer to the OP that DMD doesn't yet
offer most of the things discussed in this thread. But I think that
it's better to add and work on high-performance features when the
basics of D are in better shape. Currently there are more basic
fishes to implement or debug, like tuples syntax sugar, module
system issues, const issues, inout, and so on and on (on the other
hand I agree that it's OK to discuss even now D design ideas that
will allow that future high performance).

I make the point because, while I agree the topics you mention are
of greater immediate performance, the previous posts in this thread
suggest there is already experimentation/implementation of these
features happening in the language now, and if they are defined now,
and defined incorrectly, it's always very difficult to go back on
these decisions.

> > Hardware vectors are NOT float[4]'s, they are a reference to an
> > 128bit hardware register upon which various vector operations
may be
> > supported, they are probably aligned, and they are only
accessible
> > in 128bit quantities. I think they should be explicitly defined
as
> > such.
> What do you want to do when CPU with 256 bit registers appear?
When they grow to 512 bit? To 1024? Do you want to keep adding
specific types?

Yes.
I don't think it's likely to progress as you suggest though.
I foresee perhaps a 4 component 64bit-word vector (256bit), and a
hardware matrix.
I can't see it being any less appropriate to implement a v256 in
addition to v128 than a long in addition to an int.
A matrix is a fundamentally different concept, and surely worthy of
its own type.

> How many things do you want to add to D in the next 15 years of
CPU evolution?

As many things as are universally accepted by computer hardware as a
normal/standard feature. Hardware vectors definitely fit this bill.

We've had hardware vector support in virtually every architecture
for 10-15 years now, and yet there is still no language that really
supports it.


More information about the Digitalmars-d mailing list