C++でFORTRAN並みの実行速度を出すPGを組むスレ

C++でFORTRANに近い、より速い実行速度を出すプログラムを組むには、 
どういう技術を駆使したり、どういうことをすればいいか考えるスレです。 

C++で書いたプログラムを実行するマシンだけ
性能上げればいいんじゃね？

>>2
kwsk

むずむずしてきた

_asm使えば、FORTRANどころかアセンブラ並みの速度で動くぞ？

アセンブラ並で書いても、FORTRANには負けるぞ？

FORTRAN のコードを逆アセして
その全てを直接埋め込んでやればいいんじゃね？

っつーかFORTRANって単に古いPG言語だから
コンパイラメーカ側に最適化のノウハウが沢山あるってだけだろ？

C も相当古くなってきた上に、C 以前の最適化技術を取り込める上に、最近の CPU は
C のプログラムを動かす事を前提にチューニングされているという話もある上に…

>>8
ポインタの有無が最適化に大きく影響すると聞いた事があるよ。
あとは、並列化コンパイルのやりやすさとか。

>>1
具体的な実行環境と、それぞれのコンパイラは？
前提条件すら明示せずに、何を考えようと言うんだ？
頭が悪いにも程がある。

条件設定を行わずにいきなりこの手の話で喚き始める
他の奴らも無能の境地を極めてるな。

まぁそんなムキになんなよ。こんな2chのスレで。バカっぽいからさ。

火病の前提条件厨はスルー

>>10
あと、90以前のFORTRANは、変数が全てヒープ領域に置かれている点も特徴的だった。
今考えると、それ単体ではさほど速度的に有利になるとは思えないのだけど
データフロー解析がやりやすくなるとか、何かしらメリットがあったような気がする。

具体的な話をしなければ、適当なことをいっても誤魔化せるという利点は重要だよ。

>>12
バカっぽいというよりは、単なる異常者（東京在住４４歳）

みんなごめんね☆

何か寂しくなっちゃって全然関係ないこと書き込みしちゃいました。

反省したので明日ボウズにしてきます。

（；＿；）

結局オナニースレだからな。
自分の言いたいことを言ってりゃいいんだよ。
裏付けなんて必要ないし、ソースもいらない。

みんな本当にごめんね☆

何か寂しくなっちゃってまたまた全然関係ないこと書き込みしちゃいました。

反省したので一週間オナニーがまんします。

（；＿；）

カプサイシンは面白いな
煽ったり謝ったり、また煽ったり謝ったり
もしかして精神状態不安定か（ﾜﾛｽ

お前もカプサイシン取れば、少しは痩せるかもしれないよ？デブ。

見事な糞スレ

http://www.oonumerics.org/blitz/
これとか見ると、FORTRAN並のスピードを出すには、相当のチューニングが必要みたいだね

必要なところだけFORTRANで書いてリンクすればええやん。

ちなみにウチの学科は今期の授業ではFortranを学びます。敢えてFortranなんて始める聞くのを修得する必要ってあるんでしょうか？ 
ぶっちゃけこれはウチの先生が異常なんすよね…？

情報系でやってるのなら異常
他なら普通

情報系の学生ならFortranくらい「知ってて当然」だけどな
今からFortranで新たに何か作るのは正直お勧めしないが，
過去にジジイ達が書いてきたライブラリはそれなりにいい感じに枯れてるから
利用価値はあるわな

まあ、COBOL書いてるジジィどもに比べて、
FORTRAN書いてるジジィどもは圧倒的に社会的地位が上だけどな。

>>17
だったらマ板にでも逝けよ。

何だ、FORTRANてそんなに速いのか。
アセンブリとCの次にC++が速いのかと思ってた。

書きようによってどうにでもなるのがC++。

しかし、Cと同等の速度にまで上げられるC++が
FORTRANに勝てない状況が想像できない。
ベクトル化技術くらいじゃね？C++が劣ってるの。

なんだ負け犬がここでも暴れてるのか

C++ は C と同等の速度にはならねえ。ランタイムライブラリの差でどうしても無理。

>>32
C++のランタイムライブラリってどうせ糞だから、
C++のライブラリは使わないようにして
Cのランタイムライブラリをリンクをすればおｋ

CやC++でポインタを使うとコンパイラの最適化がきかなくなるし。

C++で演算子のオーバーロード使って行列演算なんかおこなうと
データコピーのしまくりで絶望的に遅くなる。

Fortranの数値計算ライブラリは枯れていて信頼性があるし、
アルゴリズムで対応できる限界まで高速に作られている。

自分も今ではFortranではなくC++を使っているが、残念ながら
実感としてFortranの実行速度の方がかなり速いと思う。

Fortranに匹敵する実行速度をC++で出すにはかなり難しい。
C言語的な使い方をするならそこそこ速いだろうけど。

>>34
Fortranにかなうかどうかはともかく、C++で無駄なコピーを減らすための
式テンプレート (Expression Template)は有名。
自分で実装するのは面倒だが。

でも、数式テンプレートは行列の乗算とかになると、複雑で呪文みたいな
コードになるでしょ。

それにサイズ固定だし、行列のサイズが1000×1000になるとコンパイル時間
が。。。

そもそも、コンパイラがテンプレート機能に完全に対応できてなくて、コン
パイルできないという事態も。。。

>>34
>データコピーのしまくりで絶望的に遅くなる。
作りがヘタクソだから、としか思えないんだが。つかオーバーロード関係ないし。

C言語でポインタを2つ以上関数に渡すと、それらが指すアドレスの
範囲が重なるものと見なされて最適化の妨げになる。(エイリアス問題。
最近のキャッシュを積んだCPUでコヒーレンシの問題になる)

そのためC99や一部のCコンパイラではrestrict修飾子をつけて、それら
のポインタの範囲が重ならないとコンパイラに知らせる事ができ、この
機能を使って書いた演算ライブラリはFORTRAN並みまでは行かないと
しても従来のCよりは早く動作すると期待できる。

http://seclan.dll.jp/c99d/c99d07.htm

上の例はここら辺。

>>37

何いってんのさ。
行列の乗算に＊を使う限り、関係するよ。

お前が

C=prod(A,B)しか連想できないからだ。

よくわかりもしないくせに書くな。馬鹿が

つうか、何の速度なんだ?

もういい。よく読んでないな。馬鹿はほっとこ

戻り値構造体/クラス最適化くらいは知ってるよな？

#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(*)

戻り値最適化ぐらいわかってるわい。
つまらんコードをダラダラ書くな

大事なコレ入れるの忘れてた。
結果は同じだけど。

const A& operator=(const A&) { cout << "=" << endl; return *this; }

お前は誰だ？

↑匿名掲示板でバカな質問だと思った
いつも馴れ合ってるから見ず知らずの相手に弱いんだなｗ

なんという遅レス・・・

>>43
初期化シーケンスの一部ならそうだろうが、式の一部で使われたらどのみち
一時オブジェクトのコンストラクタと最終結果の operator=() 呼び出しは避けられんね。
まあ、そもそも operator*() 定義するならその前に operator*=() 定義すべきなんだが。

行列の *= の処理は最低でも作業用のベクトルが必要になるから微妙。
関数にした方がいい。

結局全部関数にすれば解決。
オーバーロードはあくまで可読性向上のためのものであって、
処理効率向上のためのものじゃない。

×オーバーロードは
○演算子オーバーロードは

略しすぎた。

C++コンパイラを使うだけでいいのか、
C++でオブジェクト指向プログラミングしてのことかわからんが、

前者ならそこそこの速度ものが作れんじぇね。
後者ならどう考えても無理だろ。

>>53
C++と言っている時点でオブジェクト指向プログラミングでの話でしょ。

C++はC言語のほかに、
動的型システム(仮想関数)を含むオブジェク指向、
テンプレート機構によるジェネリック・プログラミング
等々を取り入れたマルチパラダイム言語ですが、何か？

演算子オーバーロードを使わなくても
オブジェクト指向プログラミングは
オブジェクト指向プログラミングだろ。

まあ、演算子のオーバーロードならFortranにもあるしな。

なんだ繰言繰り返しているだけか

55は実際プログラムを組んだことがない希ガス

>>59は現実認識が曖昧になった統合失調症患者

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

いつのまにか実行速度関係なくなってんな。
速度で勝ち目がなさそうなC++厨がC++がいかにすばらしいかを語るってか。

>>61

何が言いたいんだ？
一方的にダラダラと書き込みやがって　馬鹿か

>>63
おちつけ
ただのマルチのコピペにマジ切れするな

>>55
「・・・マルチパラダイム言語ですが、何か？」
って、それと実行速度関係あんのか？

FORTRANの速度のこと調べてたら
「ベクトル化」って言葉が出てきたけど
イマイチよく分からん。誰か説明plzzzzzzzzzzzz

>>66
http://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

んーと…多CPUのスパコンがあったとしたら
Cで言えば

for(i=0; i<size; i++) {
　　ary1[i] = ary2[i] * 2;
}

って書いたら

CPU0で ary1[0] = ary2[0] * 2;
CPU1で ary1[1] = ary2[1] * 2;

みたいにコンパイラ側で展開してくれるってこと？

ふと思った。
もしかしてPS3のコアってFORTRANと相性が良いのか…

>>68
多 CPU や多コアの場合はベクトル化といわずに並列化と言う。
ベクトル化した場合は、CPU の一命令で複数の計算を同時に行う。

どうしてベクトル化にはFORTRANが向いているの？

ポインタがなく、ベクトル化しやすい配列という概念で抽象化されてるから

integer, pointer :: p => null()
integer, target :: n = 1
p => n
print *, p
n = 2
print *, p

配列の受け渡しにポインタを使わないという事だと思うぜ。

VC.net 2003 Visual C++で戻値最適化を期待して名前無し
コンストラクタをreturnしたんだが、コピーコンストラクタ
が呼ばれまくってた。

A*B*Cなどのような連続演算では最適化を期待する
こと自体が無理かな。やっぱり関数呼び出しで１回
ずつ処理するしかないか。

戻り値最適化は別に return でコンストラクトしなくても良かったと思うけど。

数値計算はやっぱり小手先のテクニックよりアルゴリズムだからね。

抽象化の度合いが適切だと最適化し易いから
コンパイラの最適化を必死でやってる人と、
末端で頑張るプログラマでは、やっぱり、そりゃ採用出来るアルゴリズムに差が出てしまうでしょ。

そりゃ、アルゴリズムが重要だということはわかってるけど、
小手先の実装技術が大きくものをいう場合もあるわけよ。

1000×1000の行列演算なんかちょっとしたテクニックで計算
時間が1/3以下になることだってざらだし。

ま、実装技術に凝りすぎると泥沼の世界にはまるのは確か
なんだけど。

行列積って、
畳み込みをＦＦＴでやると何桁も改善出来るような、そういう高速アルゴリズムは無いの？

おまいはいつもその例しか出さないな。それしか知らんのか、と。

↑もっとも簡単でポピュラーな例だからさ。
それよりおまいはその程度のレスしかできんのか、と。バーカｗ

キャッシュヒット率を上げるようなアルゴリズムはあったと思うけど。

>>81
お前は俺が教えた話を二ヶ月も引っ張るバカだという事を再確認した。

ここにはバカしか居ないからしようがない。

>>83

はいはい、と

タイトルと話題の乖離がひどいと思った。

>>86
「PGを組む」って辺りでもう駄目だと思ってたが。

ですよね
最初マかと思った

double a;
で
a=0;
としたばあい、
a=0.0;
よりもキャストの分だけ遅くなる可能性はありますか？

可能性がある処にはいつだって可能性はある。

ただ、今の多くの実装では定数はあらかじめ処理される。

>>89
それで遅くなるように実装する方がめんどくさい罠。

>>91
そうでもあんめー

多次元配列使うとやっぱ速度落ちるかな？
1次元を複数用意したほうがいいのかな？

Cに多次元配列などない！

fortranスレと間違えました。失礼しますた
c++も同じでしたっけ？

>>94
規格票にも普通に多次元配列とか書いてるんだけど・・・。

>>95
・ 何をやりたいのかが分からない
・ 何と比べたいのかが分からない

>>96
それは配列の配列を便宜的にそう呼んでいるだけだ。

>>98
自分の中の定義とか、C 以外における定義を
勝手に押しつけてるだけだよ、それは。
C では配列の配列 = 多次元配列だと規格票で認めてるんだから、
C においてはその定義を受け入れるべき。

分岐を分岐でないものに変換するテクニックとしてはどんなものがありますか？

スレ違い

配列の配列と多次元配列は別物だろ。
Cの多次元配列は多次元配列

6.5.2.1　配列の添字付け
・・・
連続した添字演算子は，多次元配列の要素を指し示す。Eが次元i×j×...×kをもつn次元配列（n≧2）
である場合，E（左辺値以外として用いた場合。）は，次元j×...×kをもつ（n-1）次元配列へのポインタ
に型変換する。
・・・
　　例　次の宣言で定義された配列オブジェクトを考える。
　　 int x[3][5];
　　ここでxは，intの3×5の配列である。より正確には，xは三つの要素オブジェクトの配列であ
　　り，その各要素は，五つのintの配列である。
・・・

＞より正確には，xは三つの要素オブジェクトの配列であり，その各要素は，五つのintの配列である。
どう読んでも配列の配列です。

>>104

>>99
>C では配列の配列 = 多次元配列だと規格票で認めてるんだから、
>C においてはその定義を受け入れるべき。

99の言うとおりでいいんじゃないの？

配列の配列ってのはargvみたいなことを言うんだよ

argvはポインタの配列だろ？

C言語はポインタと配列を意図的にごっちゃにしてる部分があるから鬱陶しいな

C言語の本質は上級アセンブラ。その直系派生言語であるC++も右に同じ。
あれ？　現代文章の場合左って書かないといけないんだっけ？
どうみても右じゃなくて左だもんなぁ。

>>107
そのポインタはcharの配列へのポインタですよね？

argvは配列の配列とは違うのですか？

>>110
>そのポインタはcharの配列へのポインタですよね？

そうだよ。

>argvは配列の配列とは違うのですか？

うん、違う。

>>110
int 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 };

がメモリ上でどうなってるか考えてみれ。

>>112
int a[3][3]　→　配列の配列（メモリ上でintが3つ並んでいるものが3つ並んでる）
int *a[3]　　→　ポインタの配列（メモリ上でintへのポインタが3つ並んでる）

このように考えると良いでしょうか？

そういうこと。

さらに、もし

int 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]　→　配列へのポインタの配列

ということですよねぇ。ややこしいなぁ。

ちょっと調べたのですが
仮引数で配列を宣言するとポインタになるそうです。

ということは、argvは正確には
ポインタの配列ではなくて
ポインタのポインタですよね？

そうだよ。

結局、C言語の多次元配列はどういうことなのでしょうか？

C言語が持っている機能は 配列の配列 なのに
C言語の規格では、なぜか
配列の配列 = 多次元配列 ということになっている。

というような感じですか？

なぜか、って、何でだ？
C だと「配列の配列 = 多次元配列」だ、という、ただそれだけの話。

>>119

>>99
>C では配列の配列 = 多次元配列だと規格票で認めてるんだから、
>C においてはその定義を受け入れるべき。

じゃぁ、やっぱり99の言うとおりでいいってことですよねぇ・・・。

>>120
基本的にはそうなんだが、Cの「多次元配列」が色々と不便なのでそういう話も
出てくるんだろ。
N×Mの2次元配列(N, Mは任意)を扱う関数を作りたい、といった
ニーズは普通にある訳だが、Cの多次元配列の仕様だと困ることになるので、
1次元配列を代わりに用いたり、特殊なメモリ割付をしたり、といったことが
必要になる。

多次元配列と、配列の配列の認識が逆だ>>111, 112

>>122
えっ？よく分かりません。

>>110の質問に対するレスが>>111と>>112なのですが
その中におかしいところがあるのですか？

>>122 がおかしいだけだと思うぜ。

gccでメモリからのプリフェッチをコントロールする方法はありませんか？

gcc自身にそういう機能があるかどうかは知りませんが、
ソース中にそういう処理を埋め込むことはできます。

つ __builtin_prefetch

配列
a[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]

>>128
>配列の配列
>d[0]=a
>d[1]=b
>d[2]=c

これは「配列の配列」ではなくて「ポインタの配列」だと思うのですが。

AMDの仕様に書いてあるのですが、ポインタではなく[xx]でアクセスしたほうが最適化されやすいのはなぜですか？

>>130
今のコンパイラにとって、違いがあるとは思えないのだが。
敢えて考えれば、ループ構造まで含めて考えたときにループアンロールやベクタ化しやすいとは言える。

いやあるだろ
ポインタ解析では完全な解析は不可能

最適化に聴くという参照渡しって何ですか？

最適化に聴いても何も答えてくれない。

>>133
つ[Google]

配列を0で初期化したいのですが、ループでまわすよりも高速な方法はありませんか？

>>136
memsetは？

>>136
適当なコンパイラを使えばループで回すだけでも充分速いコードを出力するのだが、
コンパイラオプションなどは適切に設定しているのか?

動的に多次元配列を作ってみればわかるべ

>>136
calloc
メモリを0クリアと胡散臭いことになるが、一応doubleでも0.0として利用可能

double a=10;
if (xx>10)a=20;
というコードは
double a;
if (xx>10)a=20;
else a=10;
というコードよりも速い？

>>141
恐らくは、最適化によって同じコードになります。そうでなかったとしても、問題になるほどの差は出ません。
安心して、他の問題点を探してください。

時系列データからLyapunove expornentを推計するとBorland C++5.5とg95で約3倍は時間が違うのですが。どうすればよいですか。

黄金分割探索法

volatileを使った最適化って具体的にはどーゆーの？

＞"volatileを使った最適化" に一致するページは見つかりませんでした。

volatile はむしろ最適化を阻害するために使うのだが。

Cで2次元配列は使わない方がいいの？

>>148
cには二次元配列というものが実はないので、(1次元)配列のオフセットを計算する形で実装する方が素直に扱えます。
# 例えばcの文脈上、array[x][y]とあってもそれが配列の配列なのか配列のポインタ配列なのか区別つきませんし。

は？

> # 例えばcの文脈上、array[x][y]とあってもそれが配列の配列なのか配列のポインタ配列なのか区別つきませんし。

だうと。次の(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};

何がダウトなんだろう。
Aの宣言の後にarray[0][0]と書いてある場合と、
Bの宣言の後にarray[0][0]と書いてある場合を較べると、
どちらも値0なことは判るが区別はつかないんだけど。

int foo(int array[][3]) {
　return array[1][1];
}

int bar(int *array[]) {
　return array[1][1];
}

アセンブラ出力を見てみそ

複数のポインタを配列で扱う場合に物理的にばらばらの位置にあるって話じゃない？

なんだか必死すぎて却って笑えないな。
「文脈上」区別できないと言っているのになんでそこまでして区別できると認めさせようとするのさ。
処で、>153の前者は固定長配列だから不便だし、後者は後者で一回余計なメモリアクセスが入るので
パフォーマンスが落ちるし、擬似二次元アクセスの方がいいという点は理解できているのかな?

アクセス回数よりもキャッシュラインが重要ってじっちゃんが言ってた

規格に多次元配列って書いてあるけどこれは如何に。

>>157
便宜上多次元配列と呼ばれているものは、その実態は配列の配列として実装されているんだから
他の言語にあるような多次元配列とは違うのよ。

>>158
他の言語にある多次元配列と違うことは別に重要じゃないだろ。

>>159
では、>149は理解できましたか?

「文脈上」をどういう意味で使ってるんだ？
内容からは「そこだけ見ると」という意味だとしか思えないが
だとすれば日本語としておかしいぞ

>>151 違う
>>149 が書いてるのは、その例で言うと
int array[2][3]; に対する array[1][1] と
int (*array)[3]; に対する array[1][1] が
同じものだ、ということだ。アセンブリ出力で確認してみろ。
あと「配列へのポインタ」でググる。

>>149 は見た目から区別できないって言ってるだけだろ？

>>148
> Cで2次元配列は使わない方がいいの？

スレタイに沿って答えるなら、
限界まで性能を叩き出すためなら、1次元に展開したほうが
うまいコードを書ける場合もある。

普通のコードなら普通に書いておいて、機械的なやって当たり前の
最適化はコンパイラに任せればいい。

>>160
＞cには二次元配列というものが実はないので
だからあるっていってるだろ。
C では 二次元配列＝配列の配列 と定義されてるだけであって。

んじゃ、多言語のようなまともな二次元配列ではない、
紛い物の二次元配列しかないと言い換えようw

多言語？

凄い嬉しそうな顔をして書き込んでいるのが目に浮かぶようだ。

言語論はスレ違い

int a[ raw * col ];
return a[ x * col + y ];

要はこうしろと。
・・・別に、これで不便はないね。

boost::multi_array 使えば？

最初以外の添字のサイズが動的に決まる多次元配列は
一次元配列を使って実装するしかない。
C++ ならクラスを使ってごまかせるし、
C でもインデックスを計算する関数かマクロでも用意しておけばいい。

テレ東見ろ

(n次元の)矩形にならないデータ構造は、
「配列」とは別の何かだろ。

「配列の配列」とか。

日本語で頼む。

>>170
コンパイラの最適化阻害要因になるけどな。

C++ならvector<vector> で何とかならないかな
効率は落ちるかもしれんけど柔軟性は増す

初期化が面倒だな。
boost::multi_array 使った方がいい。

>>176
> コンパイラの最適化阻害要因になるけどな。

それを理解できず、昔の最適化がトロいコンパイラの頃の知識のまま、
一次元に展開したほうがよいと言う、馬鹿の一つ覚え野郎がいて困る。

>>176
kwsk.

>>179
代案を頼む。

配列のポインタ配列になっているプログラムを、所謂仮想二次元にしたらずっと速くなったって
実績があるのだけれど、偶偶だったのかなぁ。

>>180
最適化が効けが、一次元配列の方が速いにきまってる。
ポインタのポインタはメモリアクセスが2回あるからな。
i*col+j
は、col幅の2次元配列だと明示的にコンパイに伝わらないってのが問題。
2次元的な差分をとるために、(i+1)*col+jとかi*col+j+1とかも同時にアクセスする時に上手く最適化してくれなかったりする。

おおう、"B"と"G"のtypoですな。

>>181
なるほど、隣接画素へのアクセスの問題ですね。私のところの仕事では、
そういうアクセスはないので問題にならなかったようです。情報THX。

そもそもC/C++は明示的にコンパイラに意図したことが伝わりにくいから最適化は期待しにくい。

FORTRANの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を使う方がよいかと。

それを踏まえると、今のCコンパイラは頑張ってるねぇ。
whileで書くとベクタ化しないループもforで書けばベクタ化してくれるし、
ポインタに依存関係がないことをrestrict修飾子で支持すればそれを利用するし、
標準関数は超越関数に限らずどんどんインライン化してしまうし。

gccでさえ__attribute__((pure))で副作用のない関数です、ってコンパイラに
教えてやればそれくらいは理解するしな。

noaliasはC++の標準ではどうなったんだっけ？

sin は流石に組み込み化してるだろう。
普通のコンパイラなら。

仕様としては決まってないけどね。
ベクトル化に関して言えば、
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自体が更新されるので、ループ間に依存関係があると認識されていた。
メンバ関数にやらせればこんなことにはならないんだろうけど。

しかし今でもＣの二次元配列がポインタの配列だと思ってるヤツがいたとは
一回コンパイラが吐いたコード見てみろ

>>188
藪から棒に何を言い出すのやら。誰がそんなこと言ってますかいな。

いや、混同してた奴が議論に加わっていた数人の中に一人いるぞ。

あげ

（禿しくガイシュツ内容は略。　数学の土俵で勝負だよね？）
波動関数は波と無関係な事を理解してなかった人の作ｗ
勘違いを残した「歴史的」ネーミング、でも業績は不滅だ。
あえてＦＯＲＴＲＡＮネイティヴな環境と勝負も生き方？
近似については日進月歩だから勝てる可能性も※。
「わかってない」も時にはいいかもしれないよ…。

※きっと後で対応されるけど、短い間ならもしかして？
画期的な成果が出た直後、または「新しい数学」の類。
楕円積分、複雑系、ＮＰ完全問題への新アプローチ？
数学は天文学より桁数が大きいから、可能性はある。

二次元配列は確かに普通の配列より遅い
int 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++;
}

>>193間違って書いた

二次元配列は確かに普通の配列より遅い
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の処理時間ですむけど
アセンブラ的にも同じような操作なのになぜにこれほど佐が出るんですかね

>>194また間違えた…
int i;→int i=0;
int j;→int j=0;

icc使えばぁ

double&&使うと、a*b*cみたいな行列演算の演算子オーバーロード
は本当に効率化できるのか？

>>194
アセンブラコードで出力させれば、Cの２次元配列のしくみがわかるよ
と今頃言ってみる

>>197
俺もそこに関心がある。

一時オブジェクトでも消滅前だったらconst参照はできるじゃなかったっけ？
例えばd=a*b*cの乗算の場合は、a*bの乗算結果を一時オブジェクト１に格納
しないと(a自身に格納したら)結果がおかしくなる。この一時オブジェクト1
とｃの乗算結果をまた別の一時オブジェクト2に格納して一時オブジェクト２
が管理している動的配列のアドレスをdのポインタにコピーできればokだと
思うけどけど。しかし　z=(a+b)*(x*c+d)みたいな演算は大丈夫だろうか？

>>199
その例だったら、一時オブジェクト1とcの乗算の結果は、
一時オブジェクト1自身に格納しても問題ないはず。
それをdに代入するようにすれば、一時オブジェクト2は要らなくなる。

行列演算固有の話ではないけど右辺値参照による効率化はこんな感じのはず。

■■みんなでサイトつくろうぜｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ■■
「お前ら一緒にサイト作ろうぜｗｗｗｗｗｗｗｗｗｗ」
「２ちゃん越えるサイト作ろうぜｗｗｗｗ」
「仕事無いんだ･･････」
「やろうぜ！」
「みんなでサイトつくろうぜｗｗｗｗｗｗｗｗｗｗ」
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使える人(プロジェクト共有しやすいので)

>>199

>一時オブジェクト1とcの乗算の結果は、
>一時オブジェクト1自身に格納しても問題ないはず。

いいや、
演算結果は狂ってしまうと思う

↑ごめん、>>200 の間違いでした。
やっぱり、だめだとおもうけどなぁ

fortranて早いの？ねぇ

大学でTSSって入力して使ってたような

>>204
C/C++のポインタと配列にはエイリアスの問題があって最適化
が困難という事情があるのでFORTRANが有利

並列化(ベクトル化)のチューニングに対してもFORTRANの
方が枯れている

ただC99で restrict という予約語が正式になったからこれからは
どうなるかわからない

と言ってもCとFORTRANは行と列が逆、添え字の対応がCは
常に 0 から、とかいろいろ問題はあるけど

>>206
最後の２行は速度と関係ないだろ

Ｃ＋＋からサブルーチンとして呼ぶときに面倒だってだけで

配列操作で行順と列順を間違えて遅くしちゃうとか

はいはい

ポインタには速度的なデメリットが出る時もあるんだな

whileよりもforの方が最適化されやすいのですか？

ポインターはエイリアスの問題があって最適化は無理っていう意味がわからんよ。
エイリアスはオブジェクトをメモリーに配置するときにアクセスを効率良く出来るように
アドレスをデータバスの境界に合わせましょうということでポインターと関係ないのでは？

>>211
forに的を絞って最適化するケースもあるし、whileでは更新部が判り難くて最適化し難いこともある。
従って、forの方が最適化される可能性が高いとはいえると思う。
時として、do-whileの方が効率いいコードになることもあるが。

>>212
どこのURLか失念したがうまくまとめてあるページがあったんだけどな

例えば簡単な例で説明するとポインタaとポインタbが同じアドレスを
指しているとする

ポインタaがメモリの内容を書き換える可能性があるので面倒でも
ポインタbはいちいちメモリから内容をロードしてやらなければならない

restrictを付けるとそういう考慮がされなくなって速くなるんだよ

ごめんうまく説明できないや

>>212
俺は>>206ではないが、エイリアスの意味が違うと思うぞ。
同じアドレスを複数のポインタが指し得るから、最適化や自動並列化が
難しくなるという有名な問題のことを指しているんだと思う。
その点、Fortranのポインタは制限があるから最適化の邪魔になりにくい
ということだったはず。

>>212
>アドレスをデータバスの境界に合わせましょうということで
>>215 の言う通り、お前はエイリアスを理解していない。
ttp://seclan.dll.jp/c99d/c99d07.htm#dt19991018

MSDN見てみろや
__restrictの予約語の所に「エイリアス」と書いてあるから

ポインタのエイリアス問題はわかるんだけど
それって参照にも当てはまるのかな？
参照って__restrict付けられないじゃない
これって、ポインタより参照の方が最適化
阻害されやすいのかな？

f( const A& a ); // こっちよりも
f( const A* __restrict a ); // こっちの方がいい？

複数のポインターを使うとメモリーのコヒーレンシーを保てないから最適化が難しいという事は
解ったけど、でもそれはポインターと関係ないよ。
複数のスレッドから同一メモリーにアクセスするのが問題であってポインターを使わなくても
問題が発生するんじゃないの？

スッドレ関係ねえ

>>219
偉そうなことを言う割に馬鹿なこと言ってるな。
スレッドを使わなくても、コンパイラが最適化のためにコードの実行順序を
変更する時に問題が出るだろうが。そんな簡単なことも分からないか？

>>221
ポインターを使って不具合がでるような実行順序の変更は、ポインターを使わないコードの
変更でもトラブルが出るだろ 馬鹿

Cの２次元配列と、他言語の２次元配列ってどこがちがうの？

>>222
顔を真っ赤にして捨て台詞吐く暇があったらさっさと実例出せよ
まさか配列とか言うなよ？Cではポインタの構文糖に過ぎないからな

お前本当に何も知らないんだな

スレタイにFORTRANがあるのでFORTRANの話をすると、
CとFORTRANでは行と列(2次元の場合)が逆に、メモリ上に配置される。

>>224って馬鹿なの？
fortranの配列のアクセスを変数を使って行なうのとcでポインターを使って行なうのが
同じだと気がつかないなんてマヌケだね
ひょっとしてニートなの？

はぁ？Cのポインタエイリアスの話してんだろうが
気づいてないのはお前だろボケ
さっさと実例出せよ

>>226
> ポインターを使わないコードの変更でもトラブルが出るだろ
おまいはさっさとこれを示せや

>>224の無知ぶりは確かに痛いな。
自分が実例出せないもんだから相手に頼むなんて情けないよ。
そもそも最適化のために実行順序を変更するメリットを上げてみろよ。
それが出来ないようならお前の馬鹿が決定するよ。

ニートなんだから時間あるんだろ。じっくり考えろ ボケ！

Cのポインタエイリアスって何の事？
まずはそこからの説明がいるな
きっちり説明してね ニート君

>>229-230
すげえ高圧的にお願いしてるw

だからVC9ででも__restrict付けてコンパイルした物と
付けないでコンパイルした物のどこが変わるか見るだけでも
結構勉強になるだろ

>>229
お前が狂った主張をし始めたのだからその根拠を示すのは当然だ

> そもそも最適化のために実行順序を変更するメリットを上げてみろよ。
どこまで馬鹿なんだよ。おまえ計算機アーキテクチャを全然知らないだろ
パイプラインをストールさせたくないからに決まってるだろうが
こんな最適化の基本テクニックすら知らずに偉そうなこと言ってるのか？

なんか荒れてるのが１人いるなぁ。
あんまり知ったかぶりの知識をさらけだしてると墓穴をほるよ。
ニートはニートらしくしといたほうがいいよ。
実行順序の変更はパイプラインのストールの為だけじゃなく複数のパイプラインを
効率良く使うためなんだがな。

じゃぁ本題に入るけどcでポインターを使うとエイリアスの問題で最適化できないのに
同じような処理をしてるにもかかわらずfortranの場合
配列を変数でアクセスしても最適化ができるのは何故？
配列を変数でアクセスというのはA(I),A(J),A(K)とかを使ってアクセスすることなんだけどね。

お前はどれだけニート好きなんだ？
自分がそうだからって他までそうだと妄想するなよ

お前のような馬鹿のために単純化して言ってやっただけだから揚げ足取りするなよ

全然本題じゃないぞ。最初からそんな話はしてない。
Cのポインタエイリアスの話をしているんだろうが。

> ポインターを使って不具合がでるような実行順序の変更は、ポインターを使わないコードの
> 変更でもトラブルが出るだろ
これが本題だ。実例をさっさと挙げろよ

>じゃぁ本題に入るけどcでポインターを使うとエイリアスの問題で最適化できないのに
>同じような処理をしてるにもかかわらずfortranの場合
>配列を変数でアクセスしても最適化ができるのは何故？
Cも配列の添字アクセスなら問題は出ない。
っていうか最低限MSDNの__restrictのページとか
読んでから来いよな。

荒らしはageるもの
おまいら釣られすぎだろ

a=*(array+index);
よりも
a=array[index];
のほうがはやいの？

>>238
K&Rにも書いてあるように一般的にはポインタ表現の方が
速いとされているが、今時そこまで気にすることもないだろう

馬鹿ニートはやっぱり馬鹿っていう結論で落ち着いたようだな。

Cのポインタエイリアスの事を聞かれて説明出来ないで結局
>>236が馬鹿だからニートになったって事？

>>236は意味が理解できないままインターネットで調べた内容をそのままコピペしたのが
まるわかりだな。
Cのポインタエイリアスって何の事だろね。

限MSDNの__restrictのページとか読んでから来いよな。
ってお前読んでも理解できなかったんじゃないの？

Cも配列の添字アクセスなら問題は出ない。ってどういう根拠よ。 ニートは馬鹿決定だな

>>238
少なくとも俺が使ってるコンバイラは同じようなコードが出るよ。

ニートが使ってるコンパイラはおそらく違うんだろうな。
っていうかオプティマイズのかけ方を知らないじゃないの？

結局ポインターが使えないフォートランの方がCより最適化しやすいので処理が速いっていう
はっきりした根拠は無いようだな。
ニート君も以前に書かれた内容をコピペしただけではっきりとした根拠は何一つ示してないし
多分フォートランが速いのは別の理由なんだろな

>>244
fortranコンパイラってスパコンメーカーが出してるじゃん。
だからベクトルプロセッサー周りのハードウェアに特化した最適化が可能なんじゃね？
文法が簡単な分他の言語よりコンパイラが作りやすいからそれぞれのCPUに特化した
コンパイラをリリースしやすいと思うしfortranが速いのは大方そんな理由だろ。

こっちのほうが日本語での説明があっていいんじゃないの？
ttp://seclan.dll.jp/c99d/c99d07.htm#dt19991018

あと、restrictの有り無しと言えばmemcpyとmemmoveの区別もそうでしょ。
memmoveは転送元・転送先に重なりがあってもよい(= restrictになっていなくても良い)の代わりに、memcpyより多少遅くても仕方がない。
memcpyは逆に重なりがあったときの保証がないけど、memmoveより早いと期待される。
もちろん、C99ではmemcpyにだけrestrictが付いている。

>>246のおかげで
ポインタエイリアスの事は大体理解できたけど
でも上の例ってCの場合だけじゃなくてfortranの場合でも普通におこるよね？
サブルーチンや関数の内部だと配列がエイリアスを持つ場合があるからね。

GNUのFortranが吐いたバイナリを逆アセしてみたが
Cの行列計算ルーチンと大差ない
GNU程度ではだめか

ちゃんとしたスパコンのFortranを解析しないとこの謎は
解けないかもしれん

逆に言うとパソコン程度で科学技術計算をやらせるのなら
Fortranなど不要な時代だとも言える

C/C++で十分だ

>>247
ttp://www.sgi.co.jp/origin/ODP/documents/programming/compiler/ap/html/chap_2.html
> Fortran はサブルーチンへの複数のパラメータは互いにエイリアスされていないと保証しますが、
> C と C++ では保証されていません。

って書いてあるが。

ポインタエイリアスのことも知らずに騒いでたのか、気違い荒らしは

お前もしらなかったんじゃないの？ お馬鹿ニート君
Cのポインターエイリアスなんてわけ解らん事言ってたし
未だに最適化処理が出来ない理由が謎のままなんだけど

まぁ お前には誰も答えを期待してないようだがな。

>>219
>複数のポインターを使うとメモリーのコヒーレンシーを保てないから最適化が難しいという事は
>解ったけど
全然解ってねぇｗﾊﾞｶｽ

> 未だに最適化処理が出来ない理由が謎のままなんだけど
お前のような低脳には何を言っても理解不能なようだな
気違いはさっさと精神病院に入院しろよ

糞age土方野郎は
ttp://en.wikipedia.org/wiki/Pointer_alias
をきっちり読んでこいや

だれか >>30 に反論してくれ。

>>253,>>254
こいつウゼェー！
コピペするなら意味を理解しろボケ！
お前のようなスキル無しは派遣切られるの仕方が無いが、
キーキーわめくのはスキルが猿のモンキープログラマーじゃねぇの？

ちなみに土方野郎は猿ニートのことな

>>258
お ま え の こ と だ

さっさと読んでこいよ。それとも英語が難しくて読めないか？

>>255
In 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ポインタと見なされているという事か？

>>256
いやだからC++コンパイラは歴史が全然浅いからだよ
齢40年を超えるFORTRANコンパイラに比べれば
まだまだ最適化技術において劣るという事だろう

>>260
条件も書いてあるだろ

猿ニートってどんな言語でプログラム作ってんの？

>>262
あ、本当だ
「違う型」を示してないとだめか
同じ配列では相変わらずか
__restrictキーワードはやっぱり必要だな

>>261
>>30 の最後の行は無視か。却下。

>>255が上げた英文を読んだらますます訳が解らんようになったよ。
結局ポインターエイリアスはCのようなポインターをプログラマーが操作出来る言語に
特有なモノじゃなくてフォートランでも起こりえることなんだよな。
でもフォートランの場合は配列のインデックスをチェックしてエイリアスかどうかを
チェックしてると書いてあったけどインデックスが同じ値かどうかは実行時でないとわかんないよな？
そうすると実行時に余計なチェックが入る分フォートランの方が遅くなるんじゃね？

こんな事を書くとニート訳解んなくなってウッキーになるんだろうな。

FortranはそもそもCライクな配列やループを使わず、
配列演算文を使うことができる。
配列演算文の各要素は並列演算可能であることが決められているので
コンパイラは（何も考えずに）これを最適化する。

何せ、もともと並列処理を行うコンピュータに合わせて構文を決めたので。

>>267
結局スカラープロセッサじゃ差が無いっちゅうことじゃんか。

別に自分はスカラーとかベクトルとか計算機を限定した話はしてないよ。
配列構文の時は配列のインデックスはチェックしないってだけ。
最初から並列演算可能と決め打ちしているから。

猿ニートは英文読めたの？

配列演算文なんていかにもベクトル計算に特化した構文じゃん

おまいら、荒らしは放置しろよ

C/C++にもOpenMPあるじゃん
これだけC/C++が広く使われてりゃFORTRANに計算速度で
追いつくのはもはや時間の問題でしかない

フォートランの計算速度って言語による速度の差なのかな？
俺はライブラリのチューニングの方が大きいと思うよ。
Cで書かれた数値計算ライブラリにしてもCPUにあわせてカリカリにチューニングしたら
コンパイルが終るまで３日くらいかかるライブラリもあるし、それ使ったら
フォートランよりCの方が速かったよ。

void copy( const char (&src)[256], char (&dst)[256] );
当然ながら、これの最適化は__restrictポインタより
劣る。
参照使いながら、ポインタより劣るケースがあるってのは
何気に困るなぁ。

>>274
＞コンパイルが終るまで３日
本当かよ。もしかして真空管の時代？

とりあえず, 最適化し易い死にくいはあるが,
言語というよりは, コンパイラの問題.
今のところは, FORTRAN がちょっぴり優勢.

って事でOK?

あぁ・・・.
スレタイの回答は誰も書いていないような・・・.

猿ニート以下の突っ込みだな。

>>277
オプティマイザの中にはフォートランやCのソースに手を加えるんじゃなくて
機械語のソースに手を加えて、しかも実際に走らせて実行時間を計測して
最適化の効果を確認しながら行なうやつがあるよ。

restrictってだんだん無意味に思えて来た

機械語の最適化はどうでもいいでしょ。言語と関係ないんだから。

言語による最適化の差が機械語レベルでの最適化で消せるわけでもないし。

実際restrictってヒントでしかないし
VC++の__restrictの場合、インライン関数のように
コンパイル時に中身いじれるケースだと、
__restrict無視して勝手に最適化するようだ。

自動並列化とかがもっと実用的になってきたらrestrict絶対必要になるね〜

今はそれほど重要じゃない気がする。

restrictって並列化の為に必要なんじゃなくてreorderingを使って最適化するために
メモリーアクセスの順番を把握するために必要と書いてあったよね。
でもreorderingってスーパースカラー型のCPUじゃないと意味無いし
今のCPUの主流はパイプラインピッチを狭めたスーパーパイプライン型CPUを複数個
まとめた構造じゃん。
俺はrestrictなんて意味無いようなきがするよ。

スーパーパイプラインってPen4だろ
今はアーキテクチャーが変わってるだろうに

まぁiccにも-restrictオプションがあるし、Intelの資料に拠れば
最適化に役立つそうだけどね。

>>284
別にお前のために用意されたキーワードではなく
「ベクトル演算が可能なプロセッサ用コンパイラ」を使い、なおかつ
「ベクトル演算を必要とするプログラマ」のためのものなので、
お前にとって意味があるかどうかなど、他の誰にとってもどうでもいい話だ。

>>284
restrictはいろんな目的の為に重要で,自動並列化の為にも必要不可欠。
もちろんキャッシュ最適化の為にもね。

たとえば
for (i = 0; i < n; i++)
a[i] = b[i];
のような簡単なコードでもa,bの領域が重なっているか分からなければ並列化不可能。

今のところはキャッシュ最適化の方が重要だけど、じきに自動SIMD化や並列化の重要性が目立ってくると思う。

必要かどうかは、ここで結論を出さなくても今後の開発されるコンパイラの動向を
見てたらわかるとおもう。

ただ、共有メモリーを複数のプロセッサーで処理する並列化はバスのボトルネックや
メモリーの排他的アクセスによるデッドロックの回避なんかの問題があるので
メッセージパッシングによる並列化が流行りそうだけどな。

>>287
お前ひょっとして猿ニート？
スキルが無いのに態度がでかいからすぐ解るよ。

エスパー参上プゲラ

>>290
反論でも言い訳でもないとは。

http://www.kasahara.elec.waseda.ac.jp/achieve/pdf/mase080513arc.pdf

Cでもポインタ解析ちゃんとやれば結構速くなるよって言う論文。

てかさ、Fortranでいいじゃん。

結局Fortranだと何％位速いの？

そんなもん、環境によりけりだろ
Fortranにだってへっぽこなコンパイラもあるしな
たとえばg(ry

フォートランが速いのはベクトル計算だけ。
それ以外はCとかの方が速いよ。
そもそもベクトル計算なんて処理がワンパターンだからどんな言語でも速いとおもうよ。
だってライブラリー化されてるから言語関係ないもん。

C＋＋のこのインタビューは本当なの？http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

最後まで読めやカスが

>>299ジョーク記事だったわカスが

URL見てきづけよな

URL…あぁ

愚かだなぁ俺(●^ｰ^●)

ExpressionTemplateの話題少ないな。
PCでGPUついてんだったら

GpGPU gpu(・・・);//GPU初期化
GPU::Vector<double> vec1,vec2,vec3;
gpu(vec1=vec2*vec3);//式テンプレートで作成したGPUコードを送信

なんて式でFortranより高速に書けるんだがな。
ま、FORTRANがGpGPUサポートし始めたら知らんけど。

ローカル変数の方がコンパイラが最適化しやすいといわれますが、
定数の場合はどうなのでしょうか？
何度も呼び出す関数内の定数も関数内でローカルにした方がよいのでしょうか？
それともグローバルにした方が、キャッシュに残りやすいのでしょうか？

整数なら即値命令に落とされるかも知れんし
アーキテクチャに因るとしか。

定数ならコンパイラが良きに計らってくれるのでどこにあっても大差ない。

PGってなんだよ！

P&G

プロフェッサーギル

Intel C++のベクトル化で苦労しています。
どこか指南してくれるページはありませんか?

>>310
・iccについてくるorWebで拾える最適化リファレンスマニュアル
・XLsoft主催の講習会
・ここ

演算子定義って、最適化には問題ないの？
ベクトル化、自動並列化、アンローリング、等々・・・

restrictポインタを使えばC++に対するFORTRANの優位性は無くなるな
ただしFORTRANには今まで蓄積された豊富なライブラリ群がある

C系言語とFORTRANでは行列にした時に行と列が逆になるという問題がある
まあ転置して渡せばいいんだけど

行と列入れ替えてもうまくやってくれる賢いCコンパイラが出てきたような。

C++で extern "FORTRAN" がまともに使えればいいんだよな

Fortranはコンパイラ作る側もプログラム作る側も楽なんじゃないの？
多分

C++難しいし、OOPなんて数値計算には不要。
データ構造は配列だけあればよい。

分岐はなるたけなくして(したがって、差分プログラミング不要）
配列をindexアクセス、ループをブン回すだけというのが
数値計算やで

まぁ数値計算つっても色々あるだろうけど
科学系のガチな数値計算ならそうだな