On 4/7/13, Dominic Burghuber <dmb.youcangetme@googlemail.com> wrote:
> At moment, if performance is a concern of yours then aliasing
> should be too. Where pointer aliasing would be an issue, for a
> portable solution (i.e. non-compiler specific) you have to do a
> lot of small value passing, local variable usage (i.e. temps),
> & even class member copying, &/or manual common subexpression
> elimination. Also generally minimising the use of references &
> pointers (i.e. you are on a strict subset of C++).

Certainly aliasing is a performance issue, but that paper was only
trying to address it in the context of parameters.  The solution
I detail in the paper should in no way be taken as a replacement
for generalized aliasing control.

> It's a disappointment that there is no clean portable way (like
> C's restrict keyword) to assist the compiler to generate optimal
> code.  Instead work arounds such as those listed lead to more
> fuzzy code, greater instruction cache load, & lot more mental
> overload than if there were a default go-to solution like having a
> "restrict" keyword.

I'm not sure I would go so far as to call restrict clean, but your
point is well taken.

> The in parameter proposal is another decent solution, but will
> likely face difficulty in being adopted due to the significant
> change it proposes.  With the restrict keyword as part of C,
> & implemented by some compilers already (though for some,
> implementation covers specific forms only - it appears that
> LLVM, for example, ignores restrict everywhere except function
> parameters) it does seem the most likely way forward for
> acceptance. C++ programmers got override & final keywords as
> opposed to attributes (a good thing IMHO). I'm really hoping we
> can get "restrict" in the next language enhancement.
>
> What critical arguments have there been against "restrict"?

All I can say is "stay tuned".

> What has the general/initial reaction to N3538
> (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3538.html)
> been like?

There has been one very comprehensive response.  Otherwise, I think
most folks are waiting for someone else to speak first.  Thank you
for doing so!

> Also, once upon a time was there not a restricted pointer/reference
> proposal? I guess, without having reviewed it, this would now
> be a type of pointer/reference not to allow reseating and to
> somehow block the memory location from aliasing (like a cross
> between a unique pointer & a reference-counted pointer, in that
> it can be moved around (not copied), and a reference of only 1 is
> allowed on the memory location)? An idea, but still a restrict
> keyword applicable to both pointers & references is likely a
> better solution.

The restrict qualifier was on the list of features in C99 that
we would consider for C++11, but no one wrote the paper, so
nothing happened.  Partly the problem is that there are bound to
be non-trivial issues when translating the feature from C to C++.

--
Lawrence Crowl

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_867_21632508.1365691548811
Content-Type: text/plain; charset=ISO-8859-1



Certainly aliasing is a performance issue, but that paper was only trying
> to address it in the context of parameters.  The solution I detail in the
> paper should in no way be taken as a replacement for generalized aliasing
> control.
>

Appreciated, but if it were possible (i.e. a solution could be applied to
locals, the implicit this, etc) then we're really looking at taking C++'s
speed to another level.  I hear that for some solutions some languages can
get close to the performance of C++ when, if it were not for their managed
pointer aliasing, there wouldn't be much to bring them close.



> I'm not sure I would go so far as to call restrict clean, but your point
> is well taken.
>

On man's mud is another man's gold! When I have parts of a system to speed
up & can just literally apply a word or 2 to assist the compiler, as
opposed to reorder algorithms, add in new stages, manually perform parts of
the compilers work, etc. it's clean enough for me.

One thing I like with the restrict keyword is that you could take it or
leave it. If you didn't care about the aliasing issues, it's left out, if
you did it's there for you to utilise. It doesn't break an old code base,
but may be applied to enhance it. Also it's a tool if you're forward
thinking on new code.


Partly the problem is that there are bound to be non-trivial issues when
> translating the feature from C to C++.
>

(If you have time) Do you know of any issues?

Also I do wonder how restrict on aliases would/could relate to iterators
(or their underlying implementation), being that:

   - Iterators are a generalised kind of pointer hiding the layout of
   elements; &
   - It's considered good practice to take iterators as opposed to specific
   container aliases if needing to access a container from a function. In
   doing so you place less restriction on client code as per the actual
   container used.


The restrict qualifier was on the list of features in C99 that we would
> consider for C++11, but no one wrote the paper, so nothing happened.


> There has been one very comprehensive response.  Otherwise, I think most
> folks are waiting for someone else to speak first.  Thank you for doing so!
>

It does seem a little quiet regarding a solution to pointer aliasing,
including looking for a discussion on your proposal in here, so I was
really just making some noise. Thanks for putting a proposal forwards & I
wish you the best of luck with it.






--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_867_21632508.1365691548811
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Certainly aliasing is =
a performance issue, but that paper was only
trying to address it in the context of parameters. &nbsp;The solution
I detail in the paper should in no way be taken as a replacement
for generalized aliasing control.<br></blockquote><div><br>Appreciated, but=
 if it were possible (i.e. a solution could be applied to locals, the impli=
cit this, etc) then we're really looking at taking C++'s speed to another l=
evel.&nbsp; I hear that for some solutions some languages can get close to =
the performance of C++ when, if it were not for their managed pointer alias=
ing, there wouldn't be much to bring them close.<br><br>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">I'm not sure I would go so far as to =
call restrict clean, but your
point is well taken.
<br></blockquote><div><br>On man's mud is another man's gold! When I have p=
arts of a system to speed up &amp; can just literally apply a word or 2 to =
assist the compiler, as opposed to reorder algorithms, add in new stages, m=
anually perform parts of the compilers work, etc. it's clean enough for me.=
<br><br>One thing I like with the restrict keyword is that you could take i=
t or leave it. If you didn't care about the aliasing issues, it's left out,=
 if you did it's there for you to utilise. It doesn't break an old code bas=
e, but may be applied to enhance it. Also it's a tool if you're forward thi=
nking on new code.<br><br><br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
Partly the problem is that there are bound to
be non-trivial issues when translating the feature from C to C++.
<br></blockquote><br>(If you have time) Do you know of any issues?<br><br>A=
lso I do wonder how restrict on aliases would/could relate to iterators (or=
 their underlying implementation), being that:<br><ul><li>Iterators are a g=
eneralised kind of pointer hiding the layout of elements; &amp;</li><li>It'=
s considered good practice to take iterators as opposed to specific contain=
er aliases if needing to access a container from a function. In doing so yo=
u place less restriction on client code as per the actual container used.<b=
r></li></ul><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The rest=
rict qualifier was on the list of features in C99 that
we would consider for C++11, but no one wrote the paper, so nothing happene=
d.</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>There has b=
een one very comprehensive response. &nbsp;Otherwise, I think
most folks are waiting for someone else to speak first. &nbsp;Thank you
for doing so!
<br></blockquote><div><br>It does seem a little quiet regarding a solution =
to pointer aliasing, including looking for a discussion on your proposal in=
 here, so I was really just making some noise. Thanks for putting a proposa=
l forwards &amp; I wish you the best of luck with it.<br><br></div><br><div=
>&nbsp;</div><br><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_867_21632508.1365691548811--

.

On 4/11/13, Dominic Burghuber <dmb.youcangetme@googlemail.com> wrote:
> > Certainly aliasing is a performance issue, but that paper
> > was only trying to address it in the context of parameters.
> > The solution I detail in the paper should in no way be taken
> > as a replacement for generalized aliasing control.
>
> Appreciated, but if it were possible (i.e. a solution could be
> applied to locals, the implicit this, etc) then we're really
> looking at taking C++'s speed to another level.  I hear that for
> some solutions some languages can get close to the performance
> of C++ when, if it were not for their managed pointer aliasing,
> there wouldn't be much to bring them close.

I think you are referring to Fortran's parameters being implicitly
restrict.  That does make a significant difference.

> > I'm not sure I would go so far as to call restrict clean,
> > but your point is well taken.
>
> One man's mud is another man's gold! When I have parts of a system
> to speed up & can just literally apply a word or 2 to assist the
> compiler, as opposed to reorder algorithms, add in new stages,
> manually perform parts of the compilers work, etc. it's clean
> enough for me.
>
> One thing I like with the restrict keyword is that you could take
> it or leave it. If you didn't care about the aliasing issues,
> it's left out, if you did it's there for you to utilise. It
> doesn't break an old code base, but may be applied to enhance
> it. Also it's a tool if you're forward thinking on new code.

My concern is that the restrict feature basically changes
a performance problem in the implementation into a correctness
problem for the user.  There is a potentially significant debugging
problem when the keyword is added after clients have written code
to the original non-restrict interface.  I'm not suggesting that
we should not add restrict because of that, though, since it is
existing practice solving a significant problem.

> > Partly the problem is that there are bound to be non-trivial
> > issues when translating the feature from C to C++.
>
> (If you have time) Do you know of any issues?

C appears to ignore restrict on fields.  However, C++ will often
gather parameters into a struct.  We would not want to accidentally
lose the performance of restrict simply because the abstract
parameters are copied into fields.

> Also I do wonder how restrict on aliases would/could relate to
> iterators (or their underlying implementation), being that:
>
> - Iterators are a generalised kind of pointer hiding the layout
> of elements; &
>
> - It's considered good practice to take iterators as opposed to
> specific container aliases if needing to access a container from
> a function. In doing so you place less restriction on client code
> as per the actual container used.

There is a definite issue here, but I have no immediate ideas on
how best to address it.

--
Lawrence Crowl

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.