># あと GPGPU 関連は全然知らない。CUDA の文法は C っぽかったような記憶がおぼろげに。
ああ、すいません。CUDA を勝手に C 言語にカウントしてました。
でもほぼ C 言語だからいいですよね(^^;
ちなみに CUDA は C++ の構文も受け付けます。
実は、私の頭にあったのは OpenCL の方なんですけどね。
こちらは、C 言語(C++でもOK)と C 言語の亜種の2つで書きます。
あと、AMD の Brook+ という GPGPU用言語もありますね。
これも C 言語の亜種です。
高速化手法にはCが必要 (スコア:2, 参考になる)
現実的な解は C ってことになるんでないの?
FORTRAN とかでも出来るかもしれないけど。
素人でも手に入る入門書は C を前提にしてるよね。
そんなこんなで、まだまだ C は必要だと思う。
Re:高速化手法にはCが必要 (スコア:1)
OpenMP や MPI なんかは Fortran でも使えますし、実際に使われてます。
SSE/AVX は明示的に使ったことはないけど、コンパイラ任せでも使われてるげ
なので Fortran でも多分イケます。
んで、C で使えるものはまぁ C++ でも使えるので、高速化手法でも純粋な C は
廃れる方向にあるんじゃないかなぁ…。かわりに C++ が増えてる気がする。
正直、歴史的な理由とかを除けばわざわざ C を選ぶメリットってほとんど無いと思う。
とはいえ、C++ や Fortran が良いか、といわれればそれはそれでどうかと思ったりもする。
# ちなみに個人的には C/C++/Fortran の中で C が一番イヤだ。
# あと GPGPU 関連は全然知らない。CUDA の文法は C っぽかったような記憶がおぼろげに。
入門書はたしかに C が多いかも。
Re: (スコア:0)
ああ、すいません。CUDA を勝手に C 言語にカウントしてました。
でもほぼ C 言語だからいいですよね(^^;
ちなみに CUDA は C++ の構文も受け付けます。
実は、私の頭にあったのは OpenCL の方なんですけどね。
こちらは、C 言語(C++でもOK)と C 言語の亜種の2つで書きます。
あと、AMD の Brook+ という GPGPU用言語もありますね。
これも C 言語の亜種です。
Re: (スコア:0)
ポインタが自由過ぎてコンパイラによる最適化が難しかったり
Cを使ってる理由は、今現在使ってる人が多いから以上のものは無いんじゃないかな
Re: (スコア:0)
言語を使う要因としては最大級に重要なことですよね。使ってる人が多いって。
現実的な解とはそういうつもりで書きました。
あと、マシン語で書いたルーチンを呼び出すにも C 言語が便利って側面ありますよね。
インラインアセンブラみたいな仕組みって他の言語ではあまり聞かない気がします。
#まあ、私が無知なだけで他の言語でもできるのかもしれないけど。
Re:高速化手法にはCが必要 (スコア:1)
大昔のBASICで、DATA文とかを使って、メモリーにバイナリーデータを書き込んで、そこにjumpは、良く使われたけど、さすがにインラインアセンブラーというより、インラインバイナリーだな、こりゃ。(笑)
turbo pascalの16bit版には、インラインアセンブラの機能があった記憶が。FTL-Modula2もアセンブラで書かれたモジュールをリンク出来たような、なかったような。間違っていたらごめんなさい。
Hi tech-Cにもインラインアセンブラがあった記憶があるけど、こっちはCだ。^-^;;
vyama 「バグ取れワンワン」
Re: (スコア:0)
インラインでもない。
実装はDATA文、初期化処理がREAD文/POKE文、呼び出しがUSR文/CALL文。