C++でFORTRAN並みの実行速度を出すPGを組むスレ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2007/04/22(日) 13:19:42どういう技術を駆使したり、どういうことをすればいいか考えるスレです。
0002デフォルトの名無しさん
2007/04/22(日) 13:27:41性能上げればいいんじゃね？
0003デフォルトの名無しさん
2007/04/22(日) 13:40:36kwsk
0004デフォルトの名無しさん
2007/04/22(日) 13:45:320005デフォルトの名無しさん
2007/04/22(日) 13:51:390006デフォルトの名無しさん
2007/04/22(日) 14:51:580007デフォルトの名無しさん
2007/04/22(日) 16:08:16その全てを直接埋め込んでやればいいんじゃね？
0008デフォルトの名無しさん
2007/04/22(日) 18:21:12コンパイラメーカ側に最適化のノウハウが沢山あるってだけだろ？
0009デフォルトの名無しさん
2007/04/22(日) 18:50:12C のプログラムを動かす事を前提にチューニングされているという話もある上に…
0010デフォルトの名無しさん
2007/04/22(日) 19:06:21ポインタの有無が最適化に大きく影響すると聞いた事があるよ。
あとは、並列化コンパイルのやりやすさとか。
0011デフォルトの名無しさん
2007/04/22(日) 20:54:55具体的な実行環境と、それぞれのコンパイラは？
前提条件すら明示せずに、何を考えようと言うんだ？
頭が悪いにも程がある。
条件設定を行わずにいきなりこの手の話で喚き始める
他の奴らも無能の境地を極めてるな。
0012デフォルトの名無しさん
2007/04/22(日) 21:20:310013デフォルトの名無しさん
2007/04/22(日) 21:30:13>>10
あと、90以前のFORTRANは、変数が全てヒープ領域に置かれている点も特徴的だった。
今考えると、それ単体ではさほど速度的に有利になるとは思えないのだけど
データフロー解析がやりやすくなるとか、何かしらメリットがあったような気がする。
0014デフォルトの名無しさん
2007/04/22(日) 21:45:380015デフォルトの名無しさん
2007/04/22(日) 21:52:07バカっぽいというよりは、単なる異常者（東京在住４４歳）
001611＝14
2007/04/22(日) 22:04:28何か寂しくなっちゃって全然関係ないこと書き込みしちゃいました。
反省したので明日ボウズにしてきます。
（；＿；）
0017デフォルトの名無しさん
2007/04/22(日) 22:12:03自分の言いたいことを言ってりゃいいんだよ。
裏付けなんて必要ないし、ソースもいらない。
001811＝14＝17
2007/04/22(日) 22:17:35何か寂しくなっちゃってまたまた全然関係ないこと書き込みしちゃいました。
反省したので一週間オナニーがまんします。
（；＿；）
0019デフォルトの名無しさん
2007/04/22(日) 22:18:55煽ったり謝ったり、また煽ったり謝ったり
もしかして精神状態不安定か（ﾜﾛｽ
0020デフォルトの名無しさん
2007/04/22(日) 22:26:570021デフォルトの名無しさん
2007/04/22(日) 22:34:280022デフォルトの名無しさん
2007/04/23(月) 04:01:29これとか見ると、FORTRAN並のスピードを出すには、相当のチューニングが必要みたいだね
0023デフォルトの名無しさん
2007/04/23(月) 08:05:330024デフォルトの名無しさん
2007/04/23(月) 08:39:29ぶっちゃけこれはウチの先生が異常なんすよね…？
0025デフォルトの名無しさん
2007/04/23(月) 08:45:34他なら普通
0026デフォルトの名無しさん
2007/04/23(月) 08:51:49今からFortranで新たに何か作るのは正直お勧めしないが，
過去にジジイ達が書いてきたライブラリはそれなりにいい感じに枯れてるから
利用価値はあるわな
0027デフォルトの名無しさん
2007/04/23(月) 09:37:28FORTRAN書いてるジジィどもは圧倒的に社会的地位が上だけどな。
0028デフォルトの名無しさん
2007/04/24(火) 12:53:17だったらマ板にでも逝けよ。
0029デフォルトの名無しさん
2007/04/24(火) 19:44:08アセンブリとCの次にC++が速いのかと思ってた。
0030デフォルトの名無しさん
2007/04/24(火) 19:56:17しかし、Cと同等の速度にまで上げられるC++が
FORTRANに勝てない状況が想像できない。
ベクトル化技術くらいじゃね？C++が劣ってるの。
0031デフォルトの名無しさん
2007/04/24(火) 20:36:170032デフォルトの名無しさん
2007/04/25(水) 01:30:470033デフォルトの名無しさん
2007/04/25(水) 01:45:56C++のランタイムライブラリってどうせ糞だから、
C++のライブラリは使わないようにして
Cのランタイムライブラリをリンクをすればおｋ
0034デフォルトの名無しさん
2007/04/25(水) 20:28:10C++で演算子のオーバーロード使って行列演算なんかおこなうと
データコピーのしまくりで絶望的に遅くなる。
Fortranの数値計算ライブラリは枯れていて信頼性があるし、
アルゴリズムで対応できる限界まで高速に作られている。
自分も今ではFortranではなくC++を使っているが、残念ながら
実感としてFortranの実行速度の方がかなり速いと思う。
Fortranに匹敵する実行速度をC++で出すにはかなり難しい。
C言語的な使い方をするならそこそこ速いだろうけど。
0035デフォルトの名無しさん
2007/04/25(水) 21:10:28Fortranにかなうかどうかはともかく、C++で無駄なコピーを減らすための
式テンプレート (Expression Template)は有名。
自分で実装するのは面倒だが。
0036デフォルトの名無しさん
2007/04/25(水) 23:32:45コードになるでしょ。
それにサイズ固定だし、行列のサイズが1000×1000になるとコンパイル時間
が。。。
そもそも、コンパイラがテンプレート機能に完全に対応できてなくて、コン
パイルできないという事態も。。。
0037デフォルトの名無しさん
2007/04/26(木) 11:32:16>データコピーのしまくりで絶望的に遅くなる。
作りがヘタクソだから、としか思えないんだが。つかオーバーロード関係ないし。
0038デフォルトの名無しさん
2007/04/26(木) 11:35:46範囲が重なるものと見なされて最適化の妨げになる。(エイリアス問題。
最近のキャッシュを積んだCPUでコヒーレンシの問題になる)
そのためC99や一部のCコンパイラではrestrict修飾子をつけて、それら
のポインタの範囲が重ならないとコンパイラに知らせる事ができ、この
機能を使って書いた演算ライブラリはFORTRAN並みまでは行かないと
しても従来のCよりは早く動作すると期待できる。
0039デフォルトの名無しさん
2007/04/26(木) 11:38:23上の例はここら辺。
0040デフォルトの名無しさん
2007/04/26(木) 14:30:56何いってんのさ。
行列の乗算に＊を使う限り、関係するよ。
お前が
C=prod(A,B)しか連想できないからだ。
よくわかりもしないくせに書くな。馬鹿が
0041デフォルトの名無しさん
2007/04/26(木) 14:36:030042デフォルトの名無しさん
2007/04/26(木) 14:38:310043デフォルトの名無しさん
2007/04/26(木) 14:47:05#include <iostream>
using namespace std;
class A {
public:
A() { cout << "A()" << endl; }
A(const A&) { cout << "A(): copy" << endl; }
A(const char* name) { cout << "A(" << name << ")" << endl; }
A operator*(const A&) { A a("*"); return a; }
};
int main() {
A a("a"), b("b");
A c = a * b;
}
結果
A(a)
A(b)
A(*)
0044デフォルトの名無しさん
2007/04/26(木) 14:56:03つまらんコードをダラダラ書くな
0045デフォルトの名無しさん
2007/04/26(木) 14:56:52結果は同じだけど。
const A& operator=(const A&) { cout << "=" << endl; return *this; }
0046デフォルトの名無しさん
2007/04/26(木) 14:58:000047デフォルトの名無しさん
2007/04/26(木) 15:52:27いつも馴れ合ってるから見ず知らずの相手に弱いんだなｗ
0048デフォルトの名無しさん
2007/04/26(木) 15:55:200049デフォルトの名無しさん
2007/04/26(木) 16:52:14初期化シーケンスの一部ならそうだろうが、式の一部で使われたらどのみち
一時オブジェクトのコンストラクタと最終結果の operator=() 呼び出しは避けられんね。
まあ、そもそも operator*() 定義するならその前に operator*=() 定義すべきなんだが。
0050デフォルトの名無しさん
2007/04/26(木) 16:56:15関数にした方がいい。
0051デフォルトの名無しさん
2007/04/26(木) 17:20:43オーバーロードはあくまで可読性向上のためのものであって、
処理効率向上のためのものじゃない。
0052デフォルトの名無しさん
2007/04/26(木) 17:21:31○演算子オーバーロードは
略しすぎた。
0053デフォルトの名無しさん
2007/04/26(木) 19:14:24C++でオブジェクト指向プログラミングしてのことかわからんが、
前者ならそこそこの速度ものが作れんじぇね。
後者ならどう考えても無理だろ。
0054デフォルトの名無しさん
2007/04/30(月) 19:47:25C++と言っている時点でオブジェクト指向プログラミングでの話でしょ。
0055デフォルトの名無しさん
2007/04/30(月) 21:27:30動的型システム(仮想関数)を含むオブジェク指向、
テンプレート機構によるジェネリック・プログラミング
等々を取り入れたマルチパラダイム言語ですが、何か？
0056デフォルトの名無しさん
2007/04/30(月) 21:38:05オブジェクト指向プログラミングは
オブジェクト指向プログラミングだろ。
0057デフォルトの名無しさん
2007/04/30(月) 22:02:580058デフォルトの名無しさん
2007/04/30(月) 22:11:140059デフォルトの名無しさん
2007/04/30(月) 22:36:130060デフォルトの名無しさん
2007/04/30(月) 22:51:560061デフォルトの名無しさん
2007/05/01(火) 00:28:09対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。
抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。
0062デフォルトの名無しさん
2007/05/01(火) 13:19:01速度で勝ち目がなさそうなC++厨がC++がいかにすばらしいかを語るってか。
0063デフォルトの名無しさん
2007/05/01(火) 14:15:38何が言いたいんだ？
一方的にダラダラと書き込みやがって 馬鹿か
0064デフォルトの名無しさん
2007/05/01(火) 14:58:39おちつけ
ただのマルチのコピペにマジ切れするな
0065デフォルトの名無しさん
2007/05/01(火) 21:43:08「・・・マルチパラダイム言語ですが、何か？」
って、それと実行速度関係あんのか？
0066デフォルトの名無しさん
2007/05/02(水) 09:49:20「ベクトル化」って言葉が出てきたけど
イマイチよく分からん。誰か説明plzzzzzzzzzzzz
0067デフォルトの名無しさん
2007/05/02(水) 11:49:23http://ja.wikipedia.org/wiki/%E3%83%99%E3%82%AF%E3%83%88%E3%83%AB%E8%A8%88%E7%AE%97%E6%A9%9F
0068デフォルトの名無しさん
2007/05/02(水) 13:04:19Cで言えば
for(i=0; i<size; i++) {
ary1[i] = ary2[i] * 2;
}
って書いたら
CPU0で ary1[0] = ary2[0] * 2;
CPU1で ary1[1] = ary2[1] * 2;
みたいにコンパイラ側で展開してくれるってこと？
0069デフォルトの名無しさん
2007/05/02(水) 13:05:11もしかしてPS3のコアってFORTRANと相性が良いのか…
0070デフォルトの名無しさん
2007/05/02(水) 15:27:22多 CPU や多コアの場合はベクトル化といわずに並列化と言う。
ベクトル化した場合は、CPU の一命令で複数の計算を同時に行う。
0071デフォルトの名無しさん
2007/05/03(木) 02:41:460072・∀・）っ-○◎●
2007/05/03(木) 03:20:240073デフォルトの名無しさん
2007/05/03(木) 11:20:14integer, target :: n = 1
p => n
print *, p
n = 2
print *, p
0074デフォルトの名無しさん
2007/05/03(木) 13:57:010075デフォルトの名無しさん
2007/05/06(日) 00:14:29コンストラクタをreturnしたんだが、コピーコンストラクタ
が呼ばれまくってた。
A*B*Cなどのような連続演算では最適化を期待する
こと自体が無理かな。やっぱり関数呼び出しで１回
ずつ処理するしかないか。
0076デフォルトの名無しさん
2007/05/06(日) 00:16:400077デフォルトの名無しさん
2007/05/06(日) 09:12:03抽象化の度合いが適切だと最適化し易いから
コンパイラの最適化を必死でやってる人と、
末端で頑張るプログラマでは、やっぱり、そりゃ採用出来るアルゴリズムに差が出てしまうでしょ。
0078デフォルトの名無しさん
2007/05/06(日) 11:36:50小手先の実装技術が大きくものをいう場合もあるわけよ。
1000×1000の行列演算なんかちょっとしたテクニックで計算
時間が1/3以下になることだってざらだし。
ま、実装技術に凝りすぎると泥沼の世界にはまるのは確か
なんだけど。
0079デフォルトの名無しさん
2007/05/06(日) 11:49:07畳み込みをＦＦＴでやると何桁も改善出来るような、そういう高速アルゴリズムは無いの？
0080デフォルトの名無しさん
2007/05/06(日) 14:37:200081デフォルトの名無しさん
2007/05/06(日) 20:42:45それよりおまいはその程度のレスしかできんのか、と。バーカｗ
0082デフォルトの名無しさん
2007/05/06(日) 20:44:120083デフォルトの名無しさん
2007/05/06(日) 22:09:50お前は俺が教えた話を二ヶ月も引っ張るバカだという事を再確認した。
0084デフォルトの名無しさん
2007/05/06(日) 22:12:450085デフォルトの名無しさん
2007/05/06(日) 23:01:22はいはい、と
0086デフォルトの名無しさん
2007/05/07(月) 06:20:100087デフォルトの名無しさん
2007/05/07(月) 12:21:26「PGを組む」って辺りでもう駄目だと思ってたが。
0088デフォルトの名無しさん
2007/05/07(月) 13:01:56最初マかと思った
0089デフォルトの名無しさん
2007/05/20(日) 08:01:49で
a=0;
としたばあい、
a=0.0;
よりもキャストの分だけ遅くなる可能性はありますか？
0090デフォルトの名無しさん
2007/05/20(日) 09:46:08ただ、今の多くの実装では定数はあらかじめ処理される。
0091デフォルトの名無しさん
2007/05/20(日) 17:34:48それで遅くなるように実装する方がめんどくさい罠。
0092デフォルトの名無しさん
2007/05/28(月) 19:56:30そうでもあんめー
0093デフォルトの名無しさん
2007/06/04(月) 01:39:491次元を複数用意したほうがいいのかな？
0094デフォルトの名無しさん
2007/06/04(月) 01:54:13009593
2007/06/04(月) 02:08:20c++も同じでしたっけ？
0096デフォルトの名無しさん
2007/06/04(月) 04:43:09規格票にも普通に多次元配列とか書いてるんだけど・・・。
0097デフォルトの名無しさん
2007/06/04(月) 04:44:19・ 何をやりたいのかが分からない
・ 何と比べたいのかが分からない
0098デフォルトの名無しさん
2007/06/04(月) 08:09:56それは配列の配列を便宜的にそう呼んでいるだけだ。
0099デフォルトの名無しさん
2007/06/04(月) 08:30:44自分の中の定義とか、C 以外における定義を
勝手に押しつけてるだけだよ、それは。
C では配列の配列 = 多次元配列だと規格票で認めてるんだから、
C においてはその定義を受け入れるべき。
0100デフォルトの名無しさん
2007/06/04(月) 17:06:000101デフォルトの名無しさん
2007/06/04(月) 17:07:450102デフォルトの名無しさん
2007/06/05(火) 02:22:28Cの多次元配列は多次元配列
0103デフォルトの名無しさん
2007/06/05(火) 03:27:06・・・
連続した添字演算子は，多次元配列の要素を指し示す。Eが次元i×j×...×kをもつn次元配列（n≧2）
である場合，E（左辺値以外として用いた場合。）は，次元j×...×kをもつ（n-1）次元配列へのポインタ
に型変換する。
・・・
例 次の宣言で定義された配列オブジェクトを考える。
int x[3][5];
ここでxは，intの3×5の配列である。より正確には，xは三つの要素オブジェクトの配列であ
り，その各要素は，五つのintの配列である。
・・・
0104デフォルトの名無しさん
2007/06/05(火) 04:56:41どう読んでも配列の配列です。
0105デフォルトの名無しさん
2007/06/05(火) 20:36:15>>99
>C では配列の配列 = 多次元配列だと規格票で認めてるんだから、
>C においてはその定義を受け入れるべき。
99の言うとおりでいいんじゃないの？
0106デフォルトの名無しさん
2007/06/09(土) 19:38:580107デフォルトの名無しさん
2007/06/09(土) 20:09:030108デフォルトの名無しさん
2007/06/09(土) 23:10:580109デフォルトの名無しさん
2007/06/09(土) 23:28:35あれ？ 現代文章の場合左って書かないといけないんだっけ？
どうみても右じゃなくて左だもんなぁ。
0111デフォルトの名無しさん
2007/06/09(土) 23:31:34>そのポインタはcharの配列へのポインタですよね？
そうだよ。
>argvは配列の配列とは違うのですか？
うん、違う。
0112デフォルトの名無しさん
2007/06/09(土) 23:58:26int a[3][3] = {
{ 1, 2, 3 },
{ 4, 5, 6 },
{ 7, 8, 9 }
};
と
int a0[3] = { 1, 2, 3 };
int a1[3] = { 4, 5, 6 };
int a2[3] = { 7, 8, 9 };
int *a[3] = { a0, a1, a2 };
がメモリ上でどうなってるか考えてみれ。
0113105
2007/06/10(日) 00:29:55int a[3][3] → 配列の配列（メモリ上でintが3つ並んでいるものが3つ並んでる）
int *a[3] → ポインタの配列（メモリ上でintへのポインタが3つ並んでる）
このように考えると良いでしょうか？
0114デフォルトの名無しさん
2007/06/10(日) 01:22:570115105
2007/06/10(日) 09:04:51int a0[3] = { 1, 2, 3 };
int a1[3] = { 4, 5, 6 };
int a2[3] = { 7, 8, 9 };
int (*a[3])[3] = { &a0, &a1, &a2 };
だったら
int (*a[3])[3] → 配列へのポインタの配列
ということですよねぇ。ややこしいなぁ。
0116105
2007/06/10(日) 09:41:38仮引数で配列を宣言するとポインタになるそうです。
ということは、argvは正確には
ポインタの配列ではなくて
ポインタのポインタですよね？
0117デフォルトの名無しさん
2007/06/10(日) 11:17:030118105
2007/06/10(日) 12:56:14C言語が持っている機能は 配列の配列 なのに
C言語の規格では、なぜか
配列の配列 = 多次元配列 ということになっている。
というような感じですか？
0119デフォルトの名無しさん
2007/06/10(日) 13:27:20C だと「配列の配列 = 多次元配列」だ、という、ただそれだけの話。
0120105
2007/06/10(日) 14:03:24>>99
>C では配列の配列 = 多次元配列だと規格票で認めてるんだから、
>C においてはその定義を受け入れるべき。
じゃぁ、やっぱり99の言うとおりでいいってことですよねぇ・・・。
0121デフォルトの名無しさん
2007/06/10(日) 14:18:46基本的にはそうなんだが、Cの「多次元配列」が色々と不便なのでそういう話も
出てくるんだろ。
N×Mの2次元配列(N, Mは任意)を扱う関数を作りたい、といった
ニーズは普通にある訳だが、Cの多次元配列の仕様だと困ることになるので、
1次元配列を代わりに用いたり、特殊なメモリ割付をしたり、といったことが
必要になる。
0122デフォルトの名無しさん
2007/06/10(日) 14:20:090123105
2007/06/10(日) 15:13:11えっ？よく分かりません。
>>110の質問に対するレスが>>111と>>112なのですが
その中におかしいところがあるのですか？
0124デフォルトの名無しさん
2007/06/10(日) 15:32:100125デフォルトの名無しさん
2007/06/10(日) 16:58:220126デフォルトの名無しさん
2007/06/10(日) 20:32:50ソース中にそういう処理を埋め込むことはできます。
0127デフォルトの名無しさん
2007/07/06(金) 17:26:000128デフォルトの名無しさん
2007/07/06(金) 22:17:23a[0], a[1], a[2], a[3], a[4], a[5]
b[0], b[1], b[2]
c[0], c[1], c[2], c[3], c[4]
配列の配列
d[0]=a
d[1]=b
d[2]=c
多次元配列
a[0][0], a[0][1], a[0][2]
a[1][0], a[1][1], a[1][2]
a[2][0], a[2][1], a[2][2]
0129105
2007/07/07(土) 17:59:17>配列の配列
>d[0]=a
>d[1]=b
>d[2]=c
これは「配列の配列」ではなくて「ポインタの配列」だと思うのですが。
0130デフォルトの名無しさん
2007/09/24(月) 07:41:220131デフォルトの名無しさん
2007/09/24(月) 10:56:00今のコンパイラにとって、違いがあるとは思えないのだが。
敢えて考えれば、ループ構造まで含めて考えたときにループアンロールやベクタ化しやすいとは言える。
0132デフォルトの名無しさん
2007/09/24(月) 21:13:58ポインタ解析では完全な解析は不可能
0133デフォルトの名無しさん
2007/10/12(金) 17:09:470134デフォルトの名無しさん
2007/10/12(金) 17:17:360135デフォルトの名無しさん
2007/10/12(金) 17:20:41つ[Google]
0136デフォルトの名無しさん
2007/10/16(火) 09:24:420137デフォルトの名無しさん
2007/10/16(火) 09:45:14memsetは？
0138デフォルトの名無しさん
2007/10/16(火) 11:08:35適当なコンパイラを使えばループで回すだけでも充分速いコードを出力するのだが、
コンパイラオプションなどは適切に設定しているのか?
0139デフォルトの名無しさん
2007/10/16(火) 19:19:480140デフォルトの名無しさん
2007/10/16(火) 21:44:44calloc
メモリを0クリアと胡散臭いことになるが、一応doubleでも0.0として利用可能
0141デフォルトの名無しさん
2007/10/22(月) 16:37:25if (xx>10)a=20;
というコードは
double a;
if (xx>10)a=20;
else a=10;
というコードよりも速い？
0142デフォルトの名無しさん
2007/10/22(月) 16:52:58恐らくは、最適化によって同じコードになります。そうでなかったとしても、問題になるほどの差は出ません。
安心して、他の問題点を探してください。
0143デフォルトの名無しさん
2007/11/28(水) 22:07:120144デフォルトの名無しさん
2007/12/27(木) 21:59:540145デフォルトの名無しさん
2008/02/07(木) 14:09:160146デフォルトの名無しさん
2008/02/08(金) 11:06:140147デフォルトの名無しさん
2008/02/08(金) 19:17:490148デフォルトの名無しさん
2008/03/01(土) 12:40:270149デフォルトの名無しさん
2008/03/01(土) 13:21:05cには二次元配列というものが実はないので、(1次元)配列のオフセットを計算する形で実装する方が素直に扱えます。
# 例えばcの文脈上、array[x][y]とあってもそれが配列の配列なのか配列のポインタ配列なのか区別つきませんし。
0150デフォルトの名無しさん
2008/03/01(土) 13:29:310151デフォルトの名無しさん
2008/03/01(土) 13:37:59だうと。次の(A)と(B)を比べてみよ
(A)
int array[][3] = {{0, 1, 2}, {3, 4, 5}};
(B)
int a_0[] = {0, 1, 2};
int a_1[] = {3, 4, 5};
int *array[] = {a_0, a_1};
0152デフォルトの名無しさん
2008/03/01(土) 13:42:55Aの宣言の後にarray[0][0]と書いてある場合と、
Bの宣言の後にarray[0][0]と書いてある場合を較べると、
どちらも値0なことは判るが区別はつかないんだけど。
0153デフォルトの名無しさん
2008/03/01(土) 14:28:45return array[1][1];
}
int bar(int *array[]) {
return array[1][1];
}
アセンブラ出力を見てみそ
0154デフォルトの名無しさん
2008/03/01(土) 14:35:150155デフォルトの名無しさん
2008/03/01(土) 14:41:00「文脈上」区別できないと言っているのになんでそこまでして区別できると認めさせようとするのさ。
処で、>153の前者は固定長配列だから不便だし、後者は後者で一回余計なメモリアクセスが入るので
パフォーマンスが落ちるし、擬似二次元アクセスの方がいいという点は理解できているのかな?
0156デフォルトの名無しさん
2008/03/01(土) 14:46:220157デフォルトの名無しさん
2008/03/01(土) 19:49:040158デフォルトの名無しさん
2008/03/01(土) 20:36:58便宜上多次元配列と呼ばれているものは、その実態は配列の配列として実装されているんだから
他の言語にあるような多次元配列とは違うのよ。
0159デフォルトの名無しさん
2008/03/01(土) 21:07:40他の言語にある多次元配列と違うことは別に重要じゃないだろ。
0160デフォルトの名無しさん
2008/03/01(土) 21:23:49では、>149は理解できましたか?
0161デフォルトの名無しさん
2008/03/01(土) 21:44:02内容からは「そこだけ見ると」という意味だとしか思えないが
だとすれば日本語としておかしいぞ
0162デフォルトの名無しさん
2008/03/01(土) 21:55:42>>149 が書いてるのは、その例で言うと
int array[2][3]; に対する array[1][1] と
int (*array)[3]; に対する array[1][1] が
同じものだ、ということだ。アセンブリ出力で確認してみろ。
あと「配列へのポインタ」でググる。
0163デフォルトの名無しさん
2008/03/01(土) 21:57:210164デフォルトの名無しさん
2008/03/02(日) 10:33:28> Cで2次元配列は使わない方がいいの？
スレタイに沿って答えるなら、
限界まで性能を叩き出すためなら、1次元に展開したほうが
うまいコードを書ける場合もある。
普通のコードなら普通に書いておいて、機械的なやって当たり前の
最適化はコンパイラに任せればいい。
0165デフォルトの名無しさん
2008/03/02(日) 11:00:09＞cには二次元配列というものが実はないので
だからあるっていってるだろ。
C では 二次元配列＝配列の配列 と定義されてるだけであって。
0166デフォルトの名無しさん
2008/03/02(日) 12:07:21紛い物の二次元配列しかないと言い換えようw
0167デフォルトの名無しさん
2008/03/02(日) 12:28:570168デフォルトの名無しさん
2008/03/02(日) 12:30:220169デフォルトの名無しさん
2008/03/02(日) 15:26:270170デフォルトの名無しさん
2008/03/02(日) 16:34:58return a[ x * col + y ];
要はこうしろと。
・・・別に、これで不便はないね。
0171デフォルトの名無しさん
2008/03/02(日) 16:38:230172デフォルトの名無しさん
2008/03/02(日) 16:40:13一次元配列を使って実装するしかない。
C++ ならクラスを使ってごまかせるし、
C でもインデックスを計算する関数かマクロでも用意しておけばいい。
0173デフォルトの名無しさん
2008/03/02(日) 16:45:370174デフォルトの名無しさん
2008/03/02(日) 18:27:04「配列」とは別の何かだろ。
「配列の配列」とか。
0175デフォルトの名無しさん
2008/03/02(日) 18:31:450176デフォルトの名無しさん
2008/03/03(月) 01:11:03コンパイラの最適化阻害要因になるけどな。
0177デフォルトの名無しさん
2008/03/03(月) 02:48:08効率は落ちるかもしれんけど柔軟性は増す
0178デフォルトの名無しさん
2008/03/03(月) 07:16:36boost::multi_array 使った方がいい。
0179デフォルトの名無しさん
2008/03/03(月) 08:08:42> コンパイラの最適化阻害要因になるけどな。
それを理解できず、昔の最適化がトロいコンパイラの頃の知識のまま、
一次元に展開したほうがよいと言う、馬鹿の一つ覚え野郎がいて困る。
0180デフォルトの名無しさん
2008/03/03(月) 10:43:21kwsk.
>>179
代案を頼む。
配列のポインタ配列になっているプログラムを、所謂仮想二次元にしたらずっと速くなったって
実績があるのだけれど、偶偶だったのかなぁ。
0181デフォルトの名無しさん
2008/03/03(月) 14:47:10最適化が効けが、一次元配列の方が速いにきまってる。
ポインタのポインタはメモリアクセスが2回あるからな。
i*col+j
は、col幅の2次元配列だと明示的にコンパイに伝わらないってのが問題。
2次元的な差分をとるために、(i+1)*col+jとかi*col+j+1とかも同時にアクセスする時に上手く最適化してくれなかったりする。
0182180
2008/03/03(月) 14:53:59>>181
なるほど、隣接画素へのアクセスの問題ですね。私のところの仕事では、
そういうアクセスはないので問題にならなかったようです。情報THX。
0183デフォルトの名無しさん
2008/03/03(月) 15:47:00FORTRANのDOループに相当するものがない。
for(文1; 文2; 文3)
なんてのは、
文1; while(文2){ 文3;}
と全く等価で慣例的にカウンタの初期化、終了判定、カウントアップを置くにすぎないわけだし。
DO文はカウンタを使ったループだと明示的にわかる。
sin, cos等の数学関数もFORTRANではコマンドであるのに、C/C++はあくまで関数呼び出しであって、
本来コンパイラからはブラックボックス(最近は基本関数はコマンド同様に最適化するが)なので、
a[i] + sin(c)
なんてことをループ中でやると、
ポインタaがグローバル変数を差してるかもしれない
->sin(c)でa差す先の内容が変わるかもしれない
->ループ最適化中止
となる。
などなど。
FORTRAN並みの速さが欲しければFORTRANを使う方がよいかと。
0184デフォルトの名無しさん
2008/03/03(月) 16:42:09whileで書くとベクタ化しないループもforで書けばベクタ化してくれるし、
ポインタに依存関係がないことをrestrict修飾子で支持すればそれを利用するし、
標準関数は超越関数に限らずどんどんインライン化してしまうし。
0185デフォルトの名無しさん
2008/03/03(月) 16:49:28教えてやればそれくらいは理解するしな。
noaliasはC++の標準ではどうなったんだっけ？
0186デフォルトの名無しさん
2008/03/03(月) 19:24:04普通のコンパイラなら。
0187デフォルトの名無しさん
2008/03/03(月) 19:36:45ベクトル化に関して言えば、
class A{
public:
*a;
};
A foo;
for(i=0; i<1000;i++){
foo.a[i] = foo.a[i]*2+b[i]*c[i];
}
みたいなのをベクトル化されなかったことがある。
foo.a[i]に代入する時点でオブジェクトfoo自体が更新されるので、ループ間に依存関係があると認識されていた。
メンバ関数にやらせればこんなことにはならないんだろうけど。
0188デフォルトの名無しさん
2008/03/03(月) 23:47:33一回コンパイラが吐いたコード見てみろ
0189デフォルトの名無しさん
2008/03/04(火) 01:43:33藪から棒に何を言い出すのやら。誰がそんなこと言ってますかいな。
0190デフォルトの名無しさん
2008/03/04(火) 08:42:300191デフォルトの名無しさん
2008/06/08(日) 16:43:080192（居場所を奪わないであげなよ…。
2008/06/11(水) 13:01:53波動関数は波と無関係な事を理解してなかった人の作ｗ
勘違いを残した「歴史的」ネーミング、でも業績は不滅だ。
あえてＦＯＲＴＲＡＮネイティヴな環境と勝負も生き方？
近似については日進月歩だから勝てる可能性も※。
「わかってない」も時にはいいかもしれないよ…。
※きっと後で対応されるけど、短い間ならもしかして？
画期的な成果が出た直後、または「新しい数学」の類。
楕円積分、複雑系、ＮＰ完全問題への新アプローチ？
数学は天文学より桁数が大きいから、可能性はある。
0193初心者
2008/06/16(月) 19:21:06int a[255][255];
int i;
int j;
int count=0;
while(i<255){
while(j<255){
a[i][j]=count++;
}
i++;
}
とした場合と
int a[255*255];
int i;
int j;
int count=0;
while(i<255){
while(j<255){
a[i*255+j]=count++;
}
i++;
}
0194初心者
2008/06/16(月) 19:30:15二次元配列は確かに普通の配列より遅い
int a[255][255];
int i;
int j;
int count=0;
while(i<255){
while(j<255){
a[i][j]=count++;
j++;
}
i++;
}
とした場合と
int a[255*255];
int i;
int j;
int count=0;
while(i<255){
while(j<255){
a[i*255+j]=count++;
j++;
}
i++;
}
とした場合では3/4くらい処理速度に差が出る
ちなみにポインタを使うと１次元配列の2/3の処理時間ですむけど
アセンブラ的にも同じような操作なのになぜにこれほど佐が出るんですかね
0196デフォルトの名無しさん
2008/06/16(月) 21:06:360197デフォルトの名無しさん
2008/08/12(火) 20:53:45は本当に効率化できるのか？
0198デフォルトの名無しさん
2008/08/13(水) 13:14:24アセンブラコードで出力させれば、Cの２次元配列のしくみがわかるよ
と今頃言ってみる
0199デフォルトの名無しさん
2008/08/14(木) 11:01:39俺もそこに関心がある。
一時オブジェクトでも消滅前だったらconst参照はできるじゃなかったっけ？
例えばd=a*b*cの乗算の場合は、a*bの乗算結果を一時オブジェクト１に格納
しないと(a自身に格納したら)結果がおかしくなる。この一時オブジェクト1
とｃの乗算結果をまた別の一時オブジェクト2に格納して一時オブジェクト２
が管理している動的配列のアドレスをdのポインタにコピーできればokだと
思うけどけど。しかし z=(a+b)*(x*c+d)みたいな演算は大丈夫だろうか？
0200デフォルトの名無しさん
2008/08/14(木) 14:00:50その例だったら、一時オブジェクト1とcの乗算の結果は、
一時オブジェクト1自身に格納しても問題ないはず。
それをdに代入するようにすれば、一時オブジェクト2は要らなくなる。
行列演算固有の話ではないけど右辺値参照による効率化はこんな感じのはず。
0201デフォルトの名無しさん
2008/08/14(木) 17:46:08「お前ら一緒にサイト作ろうぜｗｗｗｗｗｗｗｗｗｗ」
「２ちゃん越えるサイト作ろうぜｗｗｗｗ」
「仕事無いんだ･･････」
「やろうぜ！」
「みんなでサイトつくろうぜｗｗｗｗｗｗｗｗｗｗ」
http://gacco.o0o0.jp/
http://yutori.2ch.net/test/read.cgi/news4vip/1218673130/
http://ex14.vip2ch.com/test/read.cgi/part4vip/1218612197/
興味沸いたらきてください！
======================!! 人材募集中 !!======================
■プログラムを組んでくれる人
＊サーバー側
言語はRubyかPerlの予定ですが、Perlが有力候補。
・チャット
定期的にクライアントから着信があり、それに対して更新されたチャットのメッセージを返信する程度の能力。じゃなくて機能。
通信するときのフォーマットは未定。
・ログイン・アカウント管理
ログイン認証、各アカウントの点数などの管理。データベースは未定。
・お絵描き
未定。とりあえず鯖に負担がかからない程度にたまに画像を送信してあげるって感じで
＊クライアント側
はっきり言って俺もわからね。Ajaxだとかflashだとかjavaだとか。
■機能提案(正しくは人材ではなく、意見?)
「こんな機能があったら良い!」「こうするともっと楽しくなる!」などの意見募集中。
挨拶とか気にせずスレにどんどん書き込んでくれればおk
■デザイン
サイトのデザインを考えてくれる人、作ってくれる人募集中。
できればphotoshop illustrator使える人(プロジェクト共有しやすいので)
0202デフォルトの名無しさん
2008/08/14(木) 23:41:24>一時オブジェクト1とcの乗算の結果は、
>一時オブジェクト1自身に格納しても問題ないはず。
いいや、
演算結果は狂ってしまうと思う
0203デフォルトの名無しさん
2008/08/15(金) 01:03:42やっぱり、だめだとおもうけどなぁ
0204デフォルトの名無しさん
2008/09/19(金) 06:23:310205デフォルトの名無しさん
2008/09/27(土) 16:42:300206デフォルトの名無しさん
2008/09/27(土) 17:08:27C/C++のポインタと配列にはエイリアスの問題があって最適化
が困難という事情があるのでFORTRANが有利
並列化(ベクトル化)のチューニングに対してもFORTRANの
方が枯れている
ただC99で restrict という予約語が正式になったからこれからは
どうなるかわからない
と言ってもCとFORTRANは行と列が逆、添え字の対応がCは
常に 0 から、とかいろいろ問題はあるけど
0207デフォルトの名無しさん
2008/09/27(土) 18:35:41最後の２行は速度と関係ないだろ
Ｃ＋＋からサブルーチンとして呼ぶときに面倒だってだけで
0208デフォルトの名無しさん
2008/09/27(土) 18:53:510209デフォルトの名無しさん
2009/03/14(土) 04:04:320210デフォルトの名無しさん
2009/06/10(水) 19:22:120211デフォルトの名無しさん
2009/06/20(土) 18:46:410212デフォルトの名無しさん
2009/06/22(月) 11:20:02エイリアスはオブジェクトをメモリーに配置するときにアクセスを効率良く出来るように
アドレスをデータバスの境界に合わせましょうということでポインターと関係ないのでは？
0213デフォルトの名無しさん
2009/06/22(月) 11:48:00forに的を絞って最適化するケースもあるし、whileでは更新部が判り難くて最適化し難いこともある。
従って、forの方が最適化される可能性が高いとはいえると思う。
時として、do-whileの方が効率いいコードになることもあるが。
0214デフォルトの名無しさん
2009/06/22(月) 11:52:51どこのURLか失念したがうまくまとめてあるページがあったんだけどな
例えば簡単な例で説明するとポインタaとポインタbが同じアドレスを
指しているとする
ポインタaがメモリの内容を書き換える可能性があるので面倒でも
ポインタbはいちいちメモリから内容をロードしてやらなければならない
restrictを付けるとそういう考慮がされなくなって速くなるんだよ
ごめんうまく説明できないや
0215デフォルトの名無しさん
2009/06/22(月) 11:56:52俺は>>206ではないが、エイリアスの意味が違うと思うぞ。
同じアドレスを複数のポインタが指し得るから、最適化や自動並列化が
難しくなるという有名な問題のことを指しているんだと思う。
その点、Fortranのポインタは制限があるから最適化の邪魔になりにくい
ということだったはず。
0216デフォルトの名無しさん
2009/06/22(月) 12:01:19>アドレスをデータバスの境界に合わせましょうということで
>>215 の言う通り、お前はエイリアスを理解していない。
ttp://seclan.dll.jp/c99d/c99d07.htm#dt19991018
0217デフォルトの名無しさん
2009/06/22(月) 12:07:05__restrictの予約語の所に「エイリアス」と書いてあるから
0218デフォルトの名無しさん
2009/06/22(月) 12:32:57それって参照にも当てはまるのかな？
参照って__restrict付けられないじゃない
これって、ポインタより参照の方が最適化
阻害されやすいのかな？
f( const A& a ); // こっちよりも
f( const A* __restrict a ); // こっちの方がいい？
0219デフォルトの名無しさん
2009/06/22(月) 23:23:48解ったけど、でもそれはポインターと関係ないよ。
複数のスレッドから同一メモリーにアクセスするのが問題であってポインターを使わなくても
問題が発生するんじゃないの？
0220デフォルトの名無しさん
2009/06/22(月) 23:37:360221デフォルトの名無しさん
2009/06/22(月) 23:38:15偉そうなことを言う割に馬鹿なこと言ってるな。
スレッドを使わなくても、コンパイラが最適化のためにコードの実行順序を
変更する時に問題が出るだろうが。そんな簡単なことも分からないか？
0222デフォルトの名無しさん
2009/06/23(火) 09:28:10ポインターを使って不具合がでるような実行順序の変更は、ポインターを使わないコードの
変更でもトラブルが出るだろ 馬鹿
0223デフォルトの名無しさん
2009/06/23(火) 10:29:070224デフォルトの名無しさん
2009/06/23(火) 10:36:52顔を真っ赤にして捨て台詞吐く暇があったらさっさと実例出せよ
まさか配列とか言うなよ？Cではポインタの構文糖に過ぎないからな
お前本当に何も知らないんだな
0225デフォルトの名無しさん
2009/06/23(火) 10:37:12CとFORTRANでは行と列(2次元の場合)が逆に、メモリ上に配置される。
0226デフォルトの名無しさん
2009/06/23(火) 11:01:12fortranの配列のアクセスを変数を使って行なうのとcでポインターを使って行なうのが
同じだと気がつかないなんてマヌケだね
ひょっとしてニートなの？
0227デフォルトの名無しさん
2009/06/23(火) 11:06:58気づいてないのはお前だろボケ
さっさと実例出せよ
0228デフォルトの名無しさん
2009/06/23(火) 11:09:55> ポインターを使わないコードの変更でもトラブルが出るだろ
おまいはさっさとこれを示せや
0229デフォルトの名無しさん
2009/06/23(火) 11:10:17自分が実例出せないもんだから相手に頼むなんて情けないよ。
そもそも最適化のために実行順序を変更するメリットを上げてみろよ。
それが出来ないようならお前の馬鹿が決定するよ。
ニートなんだから時間あるんだろ。じっくり考えろ ボケ！
0230デフォルトの名無しさん
2009/06/23(火) 11:13:59まずはそこからの説明がいるな
きっちり説明してね ニート君
0231デフォルトの名無しさん
2009/06/23(火) 11:18:58すげえ高圧的にお願いしてるw
0232デフォルトの名無しさん
2009/06/23(火) 11:26:40付けないでコンパイルした物のどこが変わるか見るだけでも
結構勉強になるだろ
0233デフォルトの名無しさん
2009/06/23(火) 11:28:08お前が狂った主張をし始めたのだからその根拠を示すのは当然だ
> そもそも最適化のために実行順序を変更するメリットを上げてみろよ。
どこまで馬鹿なんだよ。おまえ計算機アーキテクチャを全然知らないだろ
パイプラインをストールさせたくないからに決まってるだろうが
こんな最適化の基本テクニックすら知らずに偉そうなこと言ってるのか？
0234デフォルトの名無しさん
2009/06/23(火) 11:48:35あんまり知ったかぶりの知識をさらけだしてると墓穴をほるよ。
ニートはニートらしくしといたほうがいいよ。
実行順序の変更はパイプラインのストールの為だけじゃなく複数のパイプラインを
効率良く使うためなんだがな。
じゃぁ本題に入るけどcでポインターを使うとエイリアスの問題で最適化できないのに
同じような処理をしてるにもかかわらずfortranの場合
配列を変数でアクセスしても最適化ができるのは何故？
配列を変数でアクセスというのはA(I),A(J),A(K)とかを使ってアクセスすることなんだけどね。
0235デフォルトの名無しさん
2009/06/23(火) 12:03:23自分がそうだからって他までそうだと妄想するなよ
お前のような馬鹿のために単純化して言ってやっただけだから揚げ足取りするなよ
全然本題じゃないぞ。最初からそんな話はしてない。
Cのポインタエイリアスの話をしているんだろうが。
> ポインターを使って不具合がでるような実行順序の変更は、ポインターを使わないコードの
> 変更でもトラブルが出るだろ
これが本題だ。実例をさっさと挙げろよ
0236デフォルトの名無しさん
2009/06/23(火) 12:12:39>同じような処理をしてるにもかかわらずfortranの場合
>配列を変数でアクセスしても最適化ができるのは何故？
Cも配列の添字アクセスなら問題は出ない。
っていうか最低限MSDNの__restrictのページとか
読んでから来いよな。
0237デフォルトの名無しさん
2009/06/23(火) 12:28:22おまいら釣られすぎだろ
0238デフォルトの名無しさん
2009/06/23(火) 12:44:03よりも
a=array[index];
のほうがはやいの？
0239デフォルトの名無しさん
2009/06/23(火) 12:57:32K&Rにも書いてあるように一般的にはポインタ表現の方が
速いとされているが、今時そこまで気にすることもないだろう
0240デフォルトの名無しさん
2009/06/24(水) 02:32:020241デフォルトの名無しさん
2009/06/24(水) 02:37:05>>236が馬鹿だからニートになったって事？
0242デフォルトの名無しさん
2009/06/24(水) 02:47:22まるわかりだな。
Cのポインタエイリアスって何の事だろね。
限MSDNの__restrictのページとか読んでから来いよな。
ってお前読んでも理解できなかったんじゃないの？
Cも配列の添字アクセスなら問題は出ない。ってどういう根拠よ。 ニートは馬鹿決定だな
0243デフォルトの名無しさん
2009/06/24(水) 02:52:32少なくとも俺が使ってるコンバイラは同じようなコードが出るよ。
ニートが使ってるコンパイラはおそらく違うんだろうな。
っていうかオプティマイズのかけ方を知らないじゃないの？
0244デフォルトの名無しさん
2009/06/24(水) 03:03:18はっきりした根拠は無いようだな。
ニート君も以前に書かれた内容をコピペしただけではっきりとした根拠は何一つ示してないし
多分フォートランが速いのは別の理由なんだろな
0245デフォルトの名無しさん
2009/06/24(水) 03:10:44fortranコンパイラってスパコンメーカーが出してるじゃん。
だからベクトルプロセッサー周りのハードウェアに特化した最適化が可能なんじゃね？
文法が簡単な分他の言語よりコンパイラが作りやすいからそれぞれのCPUに特化した
コンパイラをリリースしやすいと思うしfortranが速いのは大方そんな理由だろ。
0246デフォルトの名無しさん
2009/06/24(水) 08:44:49ttp://seclan.dll.jp/c99d/c99d07.htm#dt19991018
あと、restrictの有り無しと言えばmemcpyとmemmoveの区別もそうでしょ。
memmoveは転送元・転送先に重なりがあってもよい(= restrictになっていなくても良い)の代わりに、memcpyより多少遅くても仕方がない。
memcpyは逆に重なりがあったときの保証がないけど、memmoveより早いと期待される。
もちろん、C99ではmemcpyにだけrestrictが付いている。
0247デフォルトの名無しさん
2009/06/24(水) 11:19:21ポインタエイリアスの事は大体理解できたけど
でも上の例ってCの場合だけじゃなくてfortranの場合でも普通におこるよね？
サブルーチンや関数の内部だと配列がエイリアスを持つ場合があるからね。
0248デフォルトの名無しさん
2009/06/24(水) 12:00:05Cの行列計算ルーチンと大差ない
GNU程度ではだめか
ちゃんとしたスパコンのFortranを解析しないとこの謎は
解けないかもしれん
0249デフォルトの名無しさん
2009/06/24(水) 12:01:01Fortranなど不要な時代だとも言える
C/C++で十分だ
0250デフォルトの名無しさん
2009/06/24(水) 12:05:26ttp://www.sgi.co.jp/origin/ODP/documents/programming/compiler/ap/html/chap_2.html
> Fortran はサブルーチンへの複数のパラメータは互いにエイリアスされていないと保証しますが、
> C と C++ では保証されていません。
って書いてあるが。
0251デフォルトの名無しさん
2009/06/24(水) 13:03:510252デフォルトの名無しさん
2009/06/24(水) 13:20:16Cのポインターエイリアスなんてわけ解らん事言ってたし
未だに最適化処理が出来ない理由が謎のままなんだけど
まぁ お前には誰も答えを期待してないようだがな。
0253デフォルトの名無しさん
2009/06/24(水) 13:24:39>複数のポインターを使うとメモリーのコヒーレンシーを保てないから最適化が難しいという事は
>解ったけど
全然解ってねぇｗﾊﾞｶｽ
0254デフォルトの名無しさん
2009/06/24(水) 13:29:50お前のような低脳には何を言っても理解不能なようだな
気違いはさっさと精神病院に入院しろよ
0255デフォルトの名無しさん
2009/06/24(水) 13:32:16ttp://en.wikipedia.org/wiki/Pointer_alias
をきっちり読んでこいや
0257デフォルトの名無しさん
2009/06/24(水) 13:39:19こいつウゼェー！
コピペするなら意味を理解しろボケ！
お前のようなスキル無しは派遣切られるの仕方が無いが、
キーキーわめくのはスキルが猿のモンキープログラマーじゃねぇの？
0258デフォルトの名無しさん
2009/06/24(水) 13:43:090260デフォルトの名無しさん
2009/06/24(水) 13:51:51In C++, pointer arguments are assumed not to alias if they point to fundamentally different types ("strict aliasing" rules). This allows more optimizations to be done than in C.
これ初めて知った
と言う事はC++は無条件でrestrictポインタと見なされているという事か？
0261デフォルトの名無しさん
2009/06/24(水) 13:54:08いやだからC++コンパイラは歴史が全然浅いからだよ
齢40年を超えるFORTRANコンパイラに比べれば
まだまだ最適化技術において劣るという事だろう
0262デフォルトの名無しさん
2009/06/24(水) 13:59:08条件も書いてあるだろ
0263デフォルトの名無しさん
2009/06/24(水) 14:04:380264デフォルトの名無しさん
2009/06/24(水) 14:06:22あ、本当だ
「違う型」を示してないとだめか
同じ配列では相変わらずか
__restrictキーワードはやっぱり必要だな
0266デフォルトの名無しさん
2009/06/24(水) 14:32:20結局ポインターエイリアスはCのようなポインターをプログラマーが操作出来る言語に
特有なモノじゃなくてフォートランでも起こりえることなんだよな。
でもフォートランの場合は配列のインデックスをチェックしてエイリアスかどうかを
チェックしてると書いてあったけどインデックスが同じ値かどうかは実行時でないとわかんないよな？
そうすると実行時に余計なチェックが入る分フォートランの方が遅くなるんじゃね？
こんな事を書くとニート訳解んなくなってウッキーになるんだろうな。
0267デフォルトの名無しさん
2009/06/24(水) 14:55:23配列演算文を使うことができる。
配列演算文の各要素は並列演算可能であることが決められているので
コンパイラは（何も考えずに）これを最適化する。
何せ、もともと並列処理を行うコンピュータに合わせて構文を決めたので。
0268デフォルトの名無しさん
2009/06/24(水) 14:59:03結局スカラープロセッサじゃ差が無いっちゅうことじゃんか。
0269デフォルトの名無しさん
2009/06/24(水) 15:06:42配列構文の時は配列のインデックスはチェックしないってだけ。
最初から並列演算可能と決め打ちしているから。
0270デフォルトの名無しさん
2009/06/24(水) 16:07:030271デフォルトの名無しさん
2009/06/24(水) 16:20:040272デフォルトの名無しさん
2009/06/24(水) 16:29:570273デフォルトの名無しさん
2009/06/24(水) 17:54:24これだけC/C++が広く使われてりゃFORTRANに計算速度で
追いつくのはもはや時間の問題でしかない
0274デフォルトの名無しさん
2009/06/24(水) 18:10:48俺はライブラリのチューニングの方が大きいと思うよ。
Cで書かれた数値計算ライブラリにしてもCPUにあわせてカリカリにチューニングしたら
コンパイルが終るまで３日くらいかかるライブラリもあるし、それ使ったら
フォートランよりCの方が速かったよ。
0275デフォルトの名無しさん
2009/06/24(水) 19:57:29当然ながら、これの最適化は__restrictポインタより
劣る。
参照使いながら、ポインタより劣るケースがあるってのは
何気に困るなぁ。
0276デフォルトの名無しさん
2009/06/24(水) 19:58:22＞コンパイルが終るまで３日
本当かよ。もしかして真空管の時代？
0277デフォルトの名無しさん
2009/06/25(木) 03:46:27言語というよりは, コンパイラの問題.
今のところは, FORTRAN がちょっぴり優勢.
って事でOK?
あぁ・・・.
スレタイの回答は誰も書いていないような・・・.
0278デフォルトの名無しさん
2009/06/25(木) 08:51:520279デフォルトの名無しさん
2009/06/25(木) 09:08:34オプティマイザの中にはフォートランやCのソースに手を加えるんじゃなくて
機械語のソースに手を加えて、しかも実際に走らせて実行時間を計測して
最適化の効果を確認しながら行なうやつがあるよ。
0280デフォルトの名無しさん
2009/06/25(木) 13:58:190281デフォルトの名無しさん
2009/06/25(木) 13:58:26言語による最適化の差が機械語レベルでの最適化で消せるわけでもないし。
0282デフォルトの名無しさん
2009/06/25(木) 14:03:55VC++の__restrictの場合、インライン関数のように
コンパイル時に中身いじれるケースだと、
__restrict無視して勝手に最適化するようだ。
0283デフォルトの名無しさん
2009/06/25(木) 14:16:55今はそれほど重要じゃない気がする。
0284デフォルトの名無しさん
2009/06/26(金) 01:11:38メモリーアクセスの順番を把握するために必要と書いてあったよね。
でもreorderingってスーパースカラー型のCPUじゃないと意味無いし
今のCPUの主流はパイプラインピッチを狭めたスーパーパイプライン型CPUを複数個
まとめた構造じゃん。
俺はrestrictなんて意味無いようなきがするよ。
0285デフォルトの名無しさん
2009/06/26(金) 03:33:32今はアーキテクチャーが変わってるだろうに
0286デフォルトの名無しさん
2009/06/26(金) 09:17:08最適化に役立つそうだけどね。
0287デフォルトの名無しさん
2009/06/26(金) 13:36:15別にお前のために用意されたキーワードではなく
「ベクトル演算が可能なプロセッサ用コンパイラ」を使い、なおかつ
「ベクトル演算を必要とするプログラマ」のためのものなので、
お前にとって意味があるかどうかなど、他の誰にとってもどうでもいい話だ。
0288デフォルトの名無しさん
2009/06/26(金) 14:07:10restrictはいろんな目的の為に重要で,自動並列化の為にも必要不可欠。
もちろんキャッシュ最適化の為にもね。
たとえば
for (i = 0; i < n; i++)
a[i] = b[i];
のような簡単なコードでもa,bの領域が重なっているか分からなければ並列化不可能。
今のところはキャッシュ最適化の方が重要だけど、じきに自動SIMD化や並列化の重要性が目立ってくると思う。
0289デフォルトの名無しさん
2009/06/26(金) 14:31:37見てたらわかるとおもう。
ただ、共有メモリーを複数のプロセッサーで処理する並列化はバスのボトルネックや
メモリーの排他的アクセスによるデッドロックの回避なんかの問題があるので
メッセージパッシングによる並列化が流行りそうだけどな。
0290デフォルトの名無しさん
2009/06/26(金) 14:37:01お前ひょっとして猿ニート？
スキルが無いのに態度がでかいからすぐ解るよ。
0291デフォルトの名無しさん
2009/06/26(金) 15:09:590292デフォルトの名無しさん
2009/06/26(金) 16:46:32反論でも言い訳でもないとは。
0293デフォルトの名無しさん
2009/06/26(金) 18:32:35Cでもポインタ解析ちゃんとやれば結構速くなるよって言う論文。
0294デフォルトの名無しさん
2009/06/26(金) 18:46:390295デフォルトの名無しさん
2009/06/26(金) 21:56:250296デフォルトの名無しさん
2009/06/26(金) 22:02:31Fortranにだってへっぽこなコンパイラもあるしな
たとえばg(ry
0297デフォルトの名無しさん
2009/06/27(土) 00:18:20それ以外はCとかの方が速いよ。
そもそもベクトル計算なんて処理がワンパターンだからどんな言語でも速いとおもうよ。
だってライブラリー化されてるから言語関係ないもん。
0298デフォルトの名無しさん
2009/06/27(土) 01:46:380299デフォルトの名無しさん
2009/06/27(土) 02:01:120300デフォルトの名無しさん
2009/06/27(土) 08:53:180301デフォルトの名無しさん
2009/06/27(土) 09:03:290302デフォルトの名無しさん
2009/06/27(土) 09:31:23愚かだなぁ俺(●^ｰ^●)
0303デフォルトの名無しさん
2009/09/20(日) 07:09:45PCでGPUついてんだったら
GpGPU gpu(・・・);//GPU初期化
GPU::Vector<double> vec1,vec2,vec3;
gpu(vec1=vec2*vec3);//式テンプレートで作成したGPUコードを送信
なんて式でFortranより高速に書けるんだがな。
ま、FORTRANがGpGPUサポートし始めたら知らんけど。
0304デフォルトの名無しさん
2009/10/16(金) 07:05:53定数の場合はどうなのでしょうか？
何度も呼び出す関数内の定数も関数内でローカルにした方がよいのでしょうか？
それともグローバルにした方が、キャッシュに残りやすいのでしょうか？
0305デフォルトの名無しさん
2009/10/16(金) 09:03:49アーキテクチャに因るとしか。
0306デフォルトの名無しさん
2009/10/16(金) 11:20:570307デフォルトの名無しさん
2010/01/16(土) 04:06:170308デフォルトの名無しさん
2010/01/16(土) 08:52:460309デフォルトの名無しさん
2010/01/18(月) 00:16:590310デフォルトの名無しさん
2010/05/28(金) 11:10:04どこか指南してくれるページはありませんか?
0311デフォルトの名無しさん
2010/05/28(金) 11:28:59・iccについてくるorWebで拾える最適化リファレンスマニュアル
・XLsoft主催の講習会
・ここ
0312デフォルトの名無しさん
2010/07/16(金) 13:41:06ベクトル化、自動並列化、アンローリング、等々・・・
0313デフォルトの名無しさん
2010/07/16(金) 14:17:05ただしFORTRANには今まで蓄積された豊富なライブラリ群がある
C系言語とFORTRANでは行列にした時に行と列が逆になるという問題がある
まあ転置して渡せばいいんだけど
0314デフォルトの名無しさん
2010/07/24(土) 02:45:440315デフォルトの名無しさん
2010/07/24(土) 07:29:110316デフォルトの名無しさん
2010/07/27(火) 19:30:41多分
0317デフォルトの名無しさん
2010/07/28(水) 00:15:38データ構造は配列だけあればよい。
分岐はなるたけなくして(したがって、差分プログラミング不要）
配列をindexアクセス、ループをブン回すだけというのが
数値計算やで
0318デフォルトの名無しさん
2010/07/28(水) 12:30:02科学系のガチな数値計算ならそうだな
■ このスレッドは過去ログ倉庫に格納されています