What is restricted pointer?
K.Nakagawa
・C++同様に「//」でコメントができる
・boolean,long longという新しい型が追加された
・関数のinline
など、いろいろあって、なんとなく仕様がわかるものばかりですが、
１つだけ、
・restricted pointerを採用
というのがあるらしいのですが、このrestricted pointerなるものは
いったい何者なんでしょうか？
また、これを使う意義やメリットとは何なんでしょうか？
--
Ｋ仲川 <mail:nk...@sikasenbey.or.jp>
<http://www.vector.co.jp/authors/VA007446/> 公式 Web ページ
(自作ソフトの公開＆Macプログラム講座。REALbasicのメールマガジンなど)
Kusakabe Youichi
<nk...@sikasenbey.or.jp> wrote:
> ・restricted pointerを採用
>
> というのがあるらしいのですが、このrestricted pointerなるものは
> いったい何者なんでしょうか？
最適化するコンパイラーへのヒントを与えるものらしいですね。
「このポインターの指す範囲は、ほかの配列とかの範囲と重複していない(本当)」
とか
宣言しているんじゃないですか?
そいでもって、コンパイラーはそれを聞いて安心してある種の最適化をその変数に
ついても適用する...っていう寸法なのでは?
ヘ_ヘ ____________________________
ミ・・ ミ vo...@merope.pleiades.or.jp
( ° )～ 日下部陽一
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UEHARA, Junji
In article <38B11753...@sikasenbey.or.jp> "K.Nakagawa" <nk...@sikasenbey.or.jp> writes:
| ・restricted pointerを採用
|
| というのがあるらしいのですが、このrestricted pointerなるものは
| いったい何者なんでしょうか？
| また、これを使う意義やメリットとは何なんでしょうか？
C99においてmemmoveとstrncpyのプロトタイプ宣言を比べてみますと、
void *memmove(void *s1, const void *s2, size_t n);
void *memcpy(void * restrict s1,
const void * restrict s2,
size_t n);
です。ご存知のようにmemmoveはs1とs2がオーバーラップしていても正しく動
作することが規格上保障されており、memcpyはs1とs2の指す先がオーバーラッ
プしていた場合の動作はundevinedです。
このとき、memcpyではs1とs2のポインタがrestrictedであると宣言されている
ので、コンパイラはmemcpyの本体をコンパイルするときに「両者は同じ領域を
指すことはない」ことを仮定することができ、より多くの最適化のチャンスを
得ることができます。
要するにrestricted指定は、引数に与えられたポインタ引数の指すものに
aliasが無いことを仮定してよい、というコンパイラへのヒントです。
--
§NTTS○FT 技術開発部エレクトロニックコマース技術センター 上原 潤二 §
PGP Key fingerprint = B7 C0 CB 1F 1C 88 69 2A 25 36 8A EE 93 A3 61 72
Shinji Kono
In article <88rqi1$9g9$1...@news.cds.ne.jp> ,
Yuki Shiino <yu...@cds.ne.jp> writes
> 随分前から予定も需要もあったのですが導入されるには時間が掛った様です。
>（ベクトルコンピュータを使っているFORTRANユーザからCを使いたいのに、と
>いう愚痴を聞いたことがあります。）
そうね。これに関しては僕も随分前に議論した記憶があります。僕
も、aliasing がないことを示す compiler directive が良いと思
いましたが、こんな風にするのか... これって呼出時にチェックす
るコードがでるんでしょうかね?
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
UEHARA, Junji
In article <7058.95...@rananim.ie.u-ryukyu.ac.jp> ko...@ie.u-ryukyu.ac.jp (Shinji Kono) writes:
| そうね。これに関しては僕も随分前に議論した記憶があります。僕
| も、aliasing がないことを示す compiler directive が良いと思
| いましたが、こんな風にするのか... これって呼出時にチェックす
| るコードがでるんでしょうかね?
呼び出し時に、呼ぶ側でチェックはしないと思いますよ。コンパイル時のチェッ
クは実行履歴を考える必要があるのでまず不可能だし、実行時のチェックも難
しいでしょう。だって重なるかどうかは関数のセマンティクスに依存しますか
ら。memcpyの例で言うと、size_t nが転送するバイト数であるという意味を考
えないと重なるかどうかは判断できないです。
# コンパイラがバッファオーバーランバグを発見してくれたら素敵..。
あくまで呼ばれる側での最適化に使用されるのだと思います。
そして、aliasが無いことを仮定しているコードにaliasがある引数を渡したと
きの振る舞いは未定義動作か何かになる(＝知ったことじゃない)のでしょう。
Yuki Shiino
上原さんの記事<UEHARA.00F...@maia0.ec.ntts.co.jp>から
> C99においてmemmoveとstrncpyのプロトタイプ宣言を比べてみますと、
>
> void *memmove(void *s1, const void *s2, size_t n);
>
> void *memcpy(void * restrict s1,
> const void * restrict s2,
> size_t n);
>
> です。ご存知のようにmemmoveはs1とs2がオーバーラップしていても正しく動
> 作することが規格上保障されており、memcpyはs1とs2の指す先がオーバーラッ
> プしていた場合の動作はundevinedです。
>
> このとき、memcpyではs1とs2のポインタがrestrictedであると宣言されている
> ので、コンパイラはmemcpyの本体をコンパイルするときに「両者は同じ領域を
> 指すことはない」ことを仮定することができ、より多くの最適化のチャンスを
> 得ることができます。
>
> 要するにrestricted指定は、引数に与えられたポインタ引数の指すものに
> aliasが無いことを仮定してよい、というコンパイラへのヒントです。
Rationale for ANSI C
3.9 Future language directions
3.9.6 Array parameters
As vector and parallel hardware, and numeric applications in C,
become more common, the aliasing semantics of C have been a source
of frustration for implementors wanting to make optimum use of
such hardware. If arrays are known not to overlap, certain
optimizations become possible, but C currently provides no way
to specify to a translator that argument arrays indeed do not overlap.
The Committee, in adopting this future direction, hopes to provide
common ground for implementors and users concerned with this problem,
so that some future C Standard can adopt this non-overlapping rule
on the basis of widespread experience.
随分前から予定も需要もあったのですが導入されるには時間が掛った様です。
（ベクトルコンピュータを使っているFORTRANユーザからCを使いたいのに、と
いう愚痴を聞いたことがあります。）
椎野 裕樹 <yu...@cds.ne.jp>
Kusakabe Youichi
ko...@ie.u-ryukyu.ac.jp (Shinji Kono) wrote:
> そうね。これに関しては僕も随分前に議論した記憶があります。僕
> も、aliasing がないことを示す compiler directive が良いと思
> いましたが、こんな風にするのか... これって呼出時にチェックす
> るコードがでるんでしょうかね?
その「コンパイル単位」内に1つもない(のでaliasing checkはしなくてもいい)と
いう
指示はLattice C 2.0の時代から合ったと思いますので、
かなり実装は簡単だったのでしょう。(そのレヴェルだと標準規格に入れるのは
つまんないと思われたのかも^^)
Yuki Shiino
上原さんの記事<UEHARA.00F...@maia0.ec.ntts.co.jp>から
> 呼び出し時に、呼ぶ側でチェックはしないと思いますよ。コンパイル時のチェッ
> クは実行履歴を考える必要があるのでまず不可能だし、実行時のチェックも難
> しいでしょう。だって重なるかどうかは関数のセマンティクスに依存しますか
> ら。memcpyの例で言うと、size_t nが転送するバイト数であるという意味を考
> えないと重なるかどうかは判断できないです。
さらに付け加えるなら、そもそも（余計なチェックなしに）並列処理を
施して良いことを保証する為のものですから、チェックをする訳はないで
しょう。（少なくとも並列処理を行う為に、という目的に対しては本末転
倒です。）
椎野 裕樹 <yu...@cds.ne.jp>
Shinji KONO
In article <88uilc$41l$1...@news.cds.ne.jp> ,
Yuki Shiino <yu...@cds.ne.jp> writes
> さらに付け加えるなら、そもそも（余計なチェックなしに）並列処理を
>施して良いことを保証する為のものですから、チェックをする訳はないで
>しょう。（少なくとも並列処理を行う為に、という目的に対しては本末転
>倒です。）
たしかにその通りですね。チェックできるんだったら、やってるものな。
ただ、ちょっと安易な解決な気もしますが...
Kazuo Fox Dohzono
In article <12528.9...@rananim.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> ただ、ちょっと安易な解決な気もしますが...
プログラマの負担が増えるだけ, という気もします. じゃあ restrict でない
ポインタを引数に持つ関数へ重なった領域を渡して万事 ok かというと否, で
すよね. 互換性を考えると.
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
[12],(6,9),0,0,2
UEHARA, Junji
In article <88uilc$41l$1...@news.cds.ne.jp> Yuki Shiino <yu...@cds.ne.jp> writes:
| さらに付け加えるなら、そもそも（余計なチェックなしに）並列処理を
| 施して良いことを保証する為のものですから、チェックをする訳はないで
| しょう。（少なくとも並列処理を行う為に、という目的に対しては本末転
| 倒です。）
なるほど。すごく納得しました。
ここらへんのヒントはVLIWのコンパイラで活用されそうですね。
UEHARA, Junji
In article <88vml3$4ao$1...@netnews.rim.or.jp>
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
| In article <12528.9...@rananim.ie.u-ryukyu.ac.jp>
| ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
|
| > ただ、ちょっと安易な解決な気もしますが...
|
| プログラマの負担が増えるだけ, という気もします. じゃあ restrict でない
| ポインタを引数に持つ関数へ重なった領域を渡して万事 ok かというと否, で
| すよね. 互換性を考えると.
負担が「今までより」増えはしないと思いますよ。restrictをつけなければ、
今までどおり、安全サイドに倒して、最適化してくれないだけです。「安全サ
イドに倒す」というのも、それは最適化するときの態度の問題であり、「万事
ok」とはならないのは当然です。重なった領域を渡すことによってCプログラ
ムが問題を引き起こすなら、それはそういうCプログラムであるというだけで、
今までどおりです。
「restrict」と数文字タイピングする面倒さを我慢して、restrictをつければ、
出力コードがいままで以上に最適化されてコードの実行が速くなるかもしれま
せん(もちろん、環境やコンパイラによってはならないかもしれません)。
ちなみに今までのVisual C++でも、
> エイリアスを行うと、レジスタに記憶される変数が減ったり、ループを最
> 適化しにくくなるので、アプリケーションの実行速度が低下する場合があ
> ります。
>
> /Oa オプションを指定すると、コンパイラはプログラムでエイリアスが使
> われていないと仮定します。エイリアスとは、ある名前で既に参照されて
> いるメモリ位置を参照するための別の名前のことです。
>
> /Ow オプションを指定すると、コンパイラはエイリアスの位置が関数本体
> 内ではなく、関数呼び出し間であると想定します。したがって、各関数呼
> び出しの後に、ポインタ変数をメモリから再ロードする必要があります。
(Visual Studioオンラインマニュアルより)
こんなオプションがあってプログラマとしては
・危険覚悟で/Oa, /Owを指定する
・遅くなるのを我慢して/Oa, /Owを指定しない
という選択肢を強いられてきており、コード上も意識しなければならないこと
でした。C99のおかげで、上の指定が言語仕様として標準化され、堂々と両者
を区別してコーディングできるようになりました。
～ ～ ～ ～ ～
ちなみにrestrictは並列処理にも関係ありますが、必ずしもベクトル処理とか
数値演算とかだけに限るわけではなく、一般のプログラミングでメリットがあ
るもののようです。もう一度VCのマニュアルから引用しますと、
> 次のコードでは、エイリアスで問題が発生する場合があります。
>
> i = -100;
> while( i < 0 )
> {
> i += x + y;
> *p = i;
> }
>
> /Oa や /Ow が指定されていないと、コンパイラは x または y が *p への
> 代入によって変わることがあると想定し、ループの各反復処理で x + y が
> 不変であるとは見なしません。/Oa または /Ow が指定されていると、コン
> パイラは *p を変更しても x や y には反映されないと想定し、x + y を
> ループから削除できると見なします。
とあります。C9Xの場合、ここでpがrestrictならば、上のような最適化が期待
できるようになるわけです。
Kazuo Fox Dohzono
In article <UEHARA.00F...@maia0.ec.ntts.co.jp>
ueh...@po.ntts.co.jp (UEHARA, Junji) writes:
> | プログラマの負担が増えるだけ, という気もします. じゃあ restrict でない
> | ポインタを引数に持つ関数へ重なった領域を渡して万事 ok かというと否, で
> | すよね. 互換性を考えると.
まあこの辺りは const のようなエラーチェックが比較的簡単な機構と異なり,
人間 (プログラマ) の助けになるようなものではないという感じの意味です.
専ら機械資源, コンパイラのための機構ですよね.
> こんなオプションがあってプログラマとしては
>
> ・危険覚悟で/Oa, /Owを指定する
> ・遅くなるのを我慢して/Oa, /Owを指定しない
>
> という選択肢を強いられてきており、コード上も意識しなければならないこと
> でした。
本当に意味をちゃんと知っていて /Oa を使っていた人って居るんでしょうか.
私は怖くて使う気になれずじまいでした.
> C99のおかげで、上の指定が言語仕様として標準化され、堂々と両者を区別
> してコーディングできるようになりました。
ううむ. この辺りは“そうとも言える”としか言えないです. 結局そういうの
を使って書くことが多くなるだろうとは思いますけど.
UEHARA, Junji
| 人間 (プログラマ) の助けになるようなものではないという感じの意味です.
| 専ら機械資源, コンパイラのための機構ですよね.
そうですね。volatileみたいなもんです。
あと、Cは、たとえばJavaじゃなくSmallTalkじゃなくC++ですらなく、よりに
もよってCを使う人のための言語ですので、そういう方向性は差別化という観
点からはおそらく有効であり、すがすがしささえ感じられます。
constだって実はオプティマイズのため、ということが理由として重要視され
ていたのかもしれませんね(知りませんが)。
K.Nakagawa
方がたよりいただきました。ありがとうございます。
restricted pointerというのを翻訳ソフトにかけると「限定された指針」と出ます
ので、何を「限定」しているのだろうと思ったのですが、エイリアスがないことを
人間が保証してやるという、ある意味、「わかって」いないとドツボにはまりそうな
新規格という感じですね。
ちなみに私も「/Oa」は恐くて使ったことがありません。
》あと、Cは、たとえばJavaじゃなくSmallTalkじゃなくC++ですらなく、よりに
》もよってCを使う人のための言語ですので、そういう方向性は差別化という観
》点からはおそらく有効であり、すがすがしささえ感じられます。
「よりにもよって」というところが、まさに「漢のためのC」って感じですね。:-)