OpenCLプログラミング#1

**a36** ◆K0BqlCB3.k · 2008/12/10(水) 15:38:25

さてついにOpenCLの仕様が公開されました。

http://www.khronos.org/opencl/

公式ページにはAPIのヘッダファイルが公開されており、
まだ実際に動かす事はできないもののプログラミングすることは可能となっています。
ということで、公開に先んじてプログラミングを始めてしまいましょう。

**デフォルトの名無しさん** · 2013/08/18(日) NY:AN:NY.AN

>>707
clCreateContext に渡した properties と同じもので GL context を1つに特定できるものを渡せって書いてあるだろうに
clGetGLContextInfoKHR で指定せずにエラーになるなら clCreateContext ではデフォルト値以外の cl_platform_id を指定したんだろう
gl_sharing が有効な CL context は作成済みなのになんで cl_platform_id だけ行方不明なんだよ
余所のライブラリが作った CL context に問い合わせたいなら clGetContextInfo で CL_CONTEXT_PROPERTIES

**デフォルトの名無しさん** · 2013/08/18(日) NY:AN:NY.AN

回答ありがとうございます。
ただ、clCreateContextはclGetGLContextInfoKHRでデバイスを得た後に呼ぶことに
なると思うのですが？
手順は以下で間違ってますかね？

GLコンテキスト(HGLRC)作成
→clGetGLContextInfoKHRで関連付けられているCLデバイスを取得
→clCreateContextでCLコンテキストを作成

いずれにしても、どのデバイスを使っているかがわからないとプラットフォームも
決まらないと思うのですが。

**デフォルトの名無しさん** · 2013/10/24(木) 01:02:02.86

vloadn ってあるけど、直接ポインタを p[i] するのと速度違ったりするのか？

**デフォルトの名無しさん** · 2013/10/24(木) 21:28:52.21

vloadはアラインメントの制約がゆるい。要素でそろってればOK。
速度は実装によるだろうけど同じか制約がゆるいvloadのほうが少し遅い。

**デフォルトの名無しさん** · 2013/10/24(木) 22:48:45.60

なるほど。

アラインメントの制約のせいで、ちょっと冗長になってたあのコードとかを小さく綺麗に書き直せるかも。
これは良いことを知った。サンクス。

**デフォルトの名無しさん** · 2013/11/22(金) 19:43:38.99

Khronos Groupが「OpenCL 2.0」を完成、コンピュータビジョン向け「OpenVX 1.0」の暫定仕様も発表
http://sourceforge.jp/magazine/13/11/22/095200
https://www.khronos.org/news/press/khronos-releases-opencl-2.0

**デフォルトの名無しさん** · 2013/11/22(金) 19:46:35.85

タラタラ完成してんじゃねーよ

**デフォルトの名無しさん** · 2013/11/22(金) 20:47:48.41

OpenVXってのが気になる

**デフォルトの名無しさん** · 2013/11/25(月) 08:28:25.60

JOCLも、早く OpenCL 2.0 に対応しろよ

**デフォルトの名無しさん** · 2013/11/30(土) 20:57:20.27

OpenCLって初期化とかやたら面倒なんですが、
OpenGL に対する glfw や GLUT みたいなライブラリはないんですか？

勉強してみたい（というか、勉強しかけた）のですが、
計算処理を楽しむ前に挫折しそうです。

**デフォルトの名無しさん** · 2013/11/30(土) 21:26:47.63

あるけどない
独自API、英語のみのマニュアル…

初期化なんて一度書けば使い回しだからとりあえずやってみるべき

**デフォルトの名無しさん** · 2013/11/30(土) 22:18:44.90

マニュアルが英語なのは全く問題ないので紹介していただけないでしょうか。

それでも枝葉末節の部分が面倒であれば、今はそういうものだと諦め、
コピペで使い回してかんばります。

ただ、私はたとえば OpenGL 入門者に対して、同じ理由
つまり「初期化なんて一度書けば使い回しだから」という理由で
ウィンドウ作らせたり、レンダリングコンテキストを作らせたりはしたくないです。
使い回し
幸い OpenGL にはユーティリティライブラリがあり、入門者にはありがたいです。
なので OpenCL にも入門者用にきっと何かあるだろうと思っていました。

**デフォルトの名無しさん** · 2013/11/30(土) 22:34:05.19

OpenGL ほど広く使われていたらあっただろうね。

**デフォルトの名無しさん** · 2013/11/30(土) 22:53:53.35

NVIDIAやAMDのサンプルコードには簡単なユーティリティが入っているよ。
OpenGLみたいに糞面倒なわけじゃないから、わざわざGLUTみたいなものを
作ろうと思った人はいなかったんだろう。

**デフォルトの名無しさん** · 2013/12/01(日) 02:54:53.01

そんなに面倒か？
必要十分しかないと思うんだが

**デフォルトの名無しさん** · 2013/12/01(日) 03:12:45.40

CUDAの簡単さと比較すると面倒

**デフォルトの名無しさん** · 2013/12/01(日) 03:18:23.16

あほか

**デフォルトの名無しさん** · 2013/12/01(日) 03:47:08.42

c++binding使えば簡単じゃないか。
まあ、プラットフォーム選択する時点で
cudaには必要ない工程だが

**デフォルトの名無しさん** · 2013/12/01(日) 07:35:28.28

>>719
intelが最近OpenCLライブラリやGPU向けライブラリのプレビュー版を発表してる
ttp://software.intel.com/en-us/intel-ipp-preview
IPPはこれまで最適化済みCPUライブラリだったけど、それをGPUにも拡張しようとしてる模様

**デフォルトの名無しさん** · 2013/12/03(火) 07:13:40.30

>>726
ありがとうございます。

調べてみます。

**デフォルトの名無しさん** · 2013/12/03(火) 13:47:40.89

amd apu+linuxでaparapi経由で使ってみたんですが面白そうですね。
はるか昔に、javaで配列関係はどうしようかjniにでもしようかと悩んでたんですがこれでやっと悩みは解決できました。
java9.stream.parallelがopenclに対応してaparapiも不要になる（jvmと結合する)ようなので、openclを使えばjavaのままで配列のソリューションが得られるようです。
まだ触って4日ぐらいですが勉強がてらに、行列などの配列依存のライブラリを書き直してみようと思います。

**デフォルトの名無しさん** · 2013/12/30(月) 11:40:26.21

kaveriが販売される模様

**デフォルトの名無しさん** · 2014/01/11(土) 01:38:48.46

>>717
software.intel.com/en-us/vcsource/tools/opencl-sdk/clu-api
CLUとか
github.com/Computing-Language-Utility/CLU/blob/master/simple/simple.c
このぐらいに書ける。
使ったことはないので便利かどうかは知らない。

**デフォルトの名無しさん** · 2014/02/24(月) 15:19:36.59

Core iとグラボつんでグラボで画面表示しててもIntelHDでOpenCLの計算をさせることはできるのでしょうか

**デフォルトの名無しさん** · 2014/02/24(月) 16:36:29.14

遅くはなろうが計算は出来るでしょう

**デフォルトの名無しさん** · 2014/02/24(月) 17:04:11.19

あれ？遅くなる要因あるのでしょうか
使ってないIntelHDも使いたいというイメージだったのですが

**デフォルトの名無しさん** · 2014/02/24(月) 18:04:09.93

CPUでやったほうが速いってだけ

**デフォルトの名無しさん** · 2014/02/24(月) 18:14:29.38

CPUスレッドとは排他でしか使えないと言うことですか？

**デフォルトの名無しさん** · 2014/02/24(月) 18:17:43.70

732だけど、単純にIntelHDをグラボと取り違えただけだよ

**デフォルトの名無しさん** · 2014/02/24(月) 18:34:07.15

了解です

**デフォルトの名無しさん** · 2014/03/23(日) 07:57:03.89

Ubuntu用のSDKはDebian GNU/Linuxで使えますか？

**デフォルトの名無しさん** · 2014/03/24(月) 20:46:02.33

>>733
俺も今日勉強始めたばっかだから実態よく分からんが、
規格ミニマムだとGPUで実行するバイナリを、
プログラム実行時に動的にコンパイルしてマウントする場合があるらしく、
それだとコンパイルのオーバーヘッドで遅くなりそう。

実行時にコンパイルせず事前にコンパイルしたバイナリを使うこともできるそうで
NVidia, AMDあたりはLLVMで動いてるからまず大丈夫だろうけど、HD Graphicsはどうなるんだろうか？

**デフォルトの名無しさん** · 2014/04/04(金) 10:41:37.63

CentOSにAMDのドライバを入れることに成功したけど、Debianには入らなかった。

**デフォルトの名無しさん** · 2014/04/23(水) 21:27:46.80

質問スレってないかな？
Debian testing 64bit環境でbeignet 0.80をインストールしてclinfoしたら
GPU一個しか積んでないはずなのにPlatformが２個検出されるのですよ
これって正常なの？

**デフォルトの名無しさん** · 2014/04/23(水) 21:53:33.92

GPU持ってるCPUを使っているとか？

**741** · 2014/04/23(水) 22:38:07.40

はい、haswell(i7-4771)を使っています。
その他のグラフィックボードは積んでいません

**デフォルトの名無しさん** · 2014/04/23(水) 23:16:57.80

Platformの数とデバイスの数はイコールじゃない。
デバイスはCPUとGPUの2個見つかるはず。ちなみに内蔵かどうかは関係ない。
気になるならclGetPlatformIDs/clGetPlatformInfoで見てみりゃいい。

**741** · 2014/04/23(水) 23:39:22.71

はしょって書くと以下のように２回出力、Platform IDが一緒でプログラムなどでcl::Platform::getをすると
２個で返ってきます。(DeviceはALLで情報をとってもGPUしか返ってきません。CPUでDeviceをとろうとするとエラーが出ます)

Platform Name: Experiment Intel Gen OCL Driver
Platform ID: 0x7f6ee0ba1a40
Name: Intel(R) HD Graphics Haswell M
Vendor: Intel
Device OpenCL C version: OpenCL C 1.1 beignet 0.8.0
Driver version: 0.8.0
Profile: FULL_PROFILE
Version: OpenCL 1.1 beignet 0.8.0

Platform Name: Experiment Intel Gen OCL Driver
Platform ID: 0x7f6ee0ba1a40
Name: Intel(R) HD Graphics Haswell M
Vendor: Intel
Device OpenCL C version: OpenCL C 1.1 beignet 0.8.0
Driver version: 0.8.0
Profile: FULL_PROFILE
Version: OpenCL 1.1 beignet 0.8.0

**デフォルトの名無しさん** · 2014/04/23(水) 23:55:44.68

Platform数はドライバの数
汎用のドライバとIntelチューンのドライバの2つが入っていたら２つのプラットフォームが出てくる
少なくともWindowsだとそんな感じ

あと745の結果でPlatformIDが同じなのはおかしい
多分745のプログラムはバグってる

**741** · 2014/04/24(木) 00:06:20.94

ドライバの数ですか・・・Debianのパッケージを入れる時にたしかに
汎用ローダとか言うのとintelドライバを入れた記憶があります
それで２つ出ているのか、入れたのは以下のパッケージだったような

opencl-headers - OpenCL (Open Computing Language) header files
beignet - Intel OpenCL library
beignet-dev - Intel OpenCL library
ocl-icd-dev - Development files to build a ICD Loader
ocl-icd-libopencl1 - Generic OpenCL ICD Loader
clinfo - Query OpenCL system information

**デフォルトの名無しさん** · 2014/06/26(木) 07:45:11.00

>>717
cl.hpp使えばそんな難しくないだろ

http://qa.atmarkit.co.jp/q/2899

**デフォルトの名無しさん** · 2014/06/26(木) 08:39:51.72

デフォルトのコンテキストやキューが追加されたのはOpenCL1.2からだから
NVIDIAじゃ使えないことに注意な。

**デフォルトの名無しさん** · 2014/06/26(木) 12:05:53.66

>>748
// OpenCL側に結果を書き込む領域を作成する
const size_t
length = 0x10;
cl::Buffer
array( CL_MEM_READ_ONLY, length * sizeof( float ) );

（　´,_ゝ`）

**デフォルトの名無しさん** · 2014/06/26(木) 22:35:19.78

>>750
答えといてやれよ。

**デフォルトの名無しさん** · 2014/08/29(金) 13:36:44.60

AMDとMS，GPU演算用途向けのコンパイラ「C＋＋ AMP v1.2」を発表
http://www.4gamer.net/games/032/G003263/20140828031/
C＋＋ AMP v1.2は、C＋＋開発者が広範なハードウェア構成および
ソフトウェア構成でアプリケーションを高速化できるよう、
以下の3つのアウトプットをサポートしています。

・Khronos GroupのOpenCL：AMD CPU/APU/GPU、Intel CPU/APU、NVIDIA GPU、Apple Mac OS X、その他のOpenCLに準拠したプラットフォームをサポート
・Khronos GroupのSPIR：AMD CPU/APU/GPU、Intel CPU/APU、将来的なSPIRに準拠したプラットフォームをサポート
：HSA FoundationのHSAIL：AMD APU、将来的なヘテロジニアス・システム・アーキテクチャー（HSA）に準拠したプラットフォームをサポート

**デフォルトの名無しさん** · 2014/08/30(土) 20:21:59.78

ム板はしょっちゅう落ちるな。

**デフォルトの名無しさん** · 2014/08/30(土) 20:24:50.83

よく落ちるな‥

**デフォルトの名無しさん** · 2014/09/19(金) 08:34:07.91

OpenCL 1.2が現在のstableになるのかな？
1.1だとOpenCVは動かないですね

**デフォルトの名無しさん** · 2014/09/19(金) 23:42:34.05

NVIDIAが1.2に対応しないからうちは1.1縛りだな。
OpenCVみたいにCUDAと両方やるならいいんだろうけど。

**デフォルトの名無しさん** · 2014/10/15(水) 00:45:43.10

VBAで使いたいのですが、ラッパーDLL何か
ご存知ないでしょうか？
C#用のは幾つか見つかるのですが…

**デフォルトの名無しさん** · 2014/10/15(水) 01:04:21.97

質問あげ m(_ _)m

**デフォルトの名無しさん** · 2014/10/15(水) 10:11:05.56

>>757
C#でVBAとOpenCLの仲介DLLでも作ればいいんでないの?
Windows知らんけど。

**デフォルトの名無しさん** · 2014/10/15(水) 10:36:01.03

>>759
そうなんですけど、既にあるならそれ使いたいなと。

いま、ClooというC#用のラッパー使ったりソース見てるのですが、
ジェネリクスは使えないからどうするんだ？とか
DLL作ったことないのでチョット途方に暮れてます…
（シンプルなDLL作成サンプルは理解できますが、
openclを全てラップするのは無理…）

**デフォルトの名無しさん** · 2014/10/15(水) 19:03:22.75

既にあるもので使い方覚えるより
自分で造った方が早い場合も多い

**デフォルトの名無しさん** · 2014/10/15(水) 22:49:10.60

口だけ番長

**757** · 2014/10/16(木) 00:06:46.03

>>761
プラットフォームを返すところから少し作り始めてみましたが、
VBAのcollectionとして値を返すなら、
C#では何なの？ディクショナリ？ってとこで
早速つまづいてしまいました(;_;)

なので、VBAでラッパー作ろうかと迷走中…

**デフォルトの名無しさん** · 2014/10/16(木) 00:45:29.59

別に何しようと勝手だけど
VBAでOpenCL使う必要性って何？

非同期処理が苦手なVBAは「待ち」が生じるような複雑な計算は向かないし
計算速くするだけならDLLなりに入力投げて結果だけもらえばいいし
Officeとの連携ならVBA使う必要ないし
規定されたソフトウェア以外使用禁止だったらそもそもOpenCL使えそうにないし

**デフォルトの名無しさん** · 2014/10/16(木) 15:24:45.15

そもそもVBAに固執してる時点で視野狭窄。

**757** · 2014/10/16(木) 17:11:21.81

固執？( ´????×????` ) ﾌﾟｯ

**757** · 2014/10/16(木) 17:12:09.70

ありゃw

**デフォルトの名無しさん** · 2014/10/17(金) 13:05:53.28

あらあら可哀想なひとでしたか。

**デフォルトの名無しさん** · 2014/10/17(金) 16:09:50.28

こんなところにもシナが湧くようになったか

**デフォルトの名無しさん** · 2014/10/18(土) 01:23:16.18

そもそもそんな方法よりこうした方が・・とか
上流にまで遡って正そうとする奴がいるけど
余計なお世話なんじゃない？
VBAでOpenCLを使う方法を聞かれているんだから
答えがあるならそれに出せばいい。
無いならわからないと答えればいい。
見当違いのに話を捻じ曲げて、してやったりと
悦にはいるのか？

**デフォルトの名無しさん** · 2014/10/18(土) 13:19:15.72

余計なお世話だと感じたらスルーすればいいだけ
スルーも出来ないお子ちゃまが馬鹿にされるだけ

**デフォルトの名無しさん** · 2014/10/18(土) 15:49:20.82

>>770
あんた公務員やな

**デフォルトの名無しさん** · 2014/10/18(土) 19:40:45.23

余計な世話しなきゃいい

**デフォルトの名無しさん** · 2014/10/19(日) 02:01:55.89

まあ、余計なお世話なやつは
わかってない（解決策はわからない）
ってことだから

解決策以外はただの雑談
スルーするかしないかなんて、
どうでもいいこと

**デフォルトの名無しさん** · 2015/01/12(月) 09:09:09.30

OpenCLとCUDAの相互運用について情報を探していたらCUDAカーネルを
OpenCLランタイムから実行できると書いてある記事を見つけたんだが、
本当にそんなんできるんだっけ？
http://www.4gamer.net/games/032/G003263/20091104040/

**デフォルトの名無しさん** · 2015/02/04(水) 08:37:05.19

いままでコンスタントに500[ms]程度でkernel処理が終わってたのが、
１分以上kernel処理が終了しない異常が、
処理２回目とあと不定期に発生するようになりました。
処理の内部のループカウントを数えたら正常なときと大差なく、
重い処理をしてはいないようです。やはりハードの不具合でしょうか？

**デフォルトの名無しさん** · 2015/02/04(水) 11:47:15.88

windows update

**デフォルトの名無しさん** · 2015/02/08(日) 04:16:42.58

モバイルだと、GPU性能とCPU性能あんま大差ないからな。CPUだと4コアでNEON使えば最大性能で60GFLOPSぐらい？最新のTegraX1とかだと300GFLOPSオーバーするかもしれんが
現行のAdreno330ぐらいだと150GFLOPSくらい？

**デフォルトの名無しさん** · 2015/02/08(日) 04:19:43.86

だからNEONのコードをわざわざ書き直す必要まだないかな？メモリアクセスのほうがボトルネックになってるっぽいのもあるし。まぁ、CPUとGPU実行じゃ消費電力ちがうかもしれんが。

**デフォルトの名無しさん** · 2015/02/15(日) 00:22:26.32

個人的にはこの言語産廃な気がするけどどうなんだろう
手続きの多さはさすがにちょっと…

CUDA←AMDも似たもの作るorライセンス料払ってでも統一しろ（最良）
C++AMPとOpenACC←そのレベルの抽象言語ぐらい統一しろ（次善）
OpenCL←やめて

**デフォルトの名無しさん** · 2015/02/15(日) 10:01:14.87

OpenCLはハード非依存のGPGPUプラットフォームとして用意され、
その上にライブラリを構築してユーザーはそれを使うのが本来意図してたこと。
残念ながらそういうライブラリがあまり出てきていないのが現実かな。

**デフォルトの名無しさん** · 2015/02/15(日) 12:56:46.74

OpenCLはDSPとかFPGAとかGPU以外もターゲットに入っているから
下手に統合しない方がいいと思う

**デフォルトの名無しさん** · 2015/02/15(日) 20:42:11.90

とか言いながら、触ればわかるが単なるCUDAの焼き直しなんだよな、これ

**デフォルトの名無しさん** · 2015/02/15(日) 21:52:13.56

nvidiaのquadro K620Mか
インテルグラフィックHD5500にしようと思うんだけど
openclとか数値計算の初歩の練習としてはどっちがいいよ

**デフォルトの名無しさん** · 2015/02/15(日) 22:09:31.75

>>784
IntelのOpenCLドライバって糞だって印象しかない。
AMDやNVIDIAで動いてたコードが通らなかったりするし。

**デフォルトの名無しさん** · 2015/02/15(日) 22:20:29.24

>>785
ありがとうございます

**デフォルトの名無しさん** · 2015/02/15(日) 22:26:41.71

実は正しくないコードが他の環境ではたまたま通っていただけ、てのはよくある。
たしかにIntelのコンパイラは厳しいから、普段の開発は他のGPUでやっていても
IntelのKernel Builderでカーネルのチェックしたりするな。

**デフォルトの名無しさん** · 2015/02/16(月) 00:42:06.13

>>787
コードそのものに問題はなかったよ。
カーネルが複雑になりすぎるとIntelのコンパイラは落ちるから論外。

**デフォルトの名無しさん** · 2015/02/16(月) 00:55:29.94

IntelはGlobalWorkingGroupとLocalWGのサイズがN倍じゃないと動かないんだけどAMDは変な比率でも動く
原因調べるのの時間かかったよ

**デフォルトの名無しさん** · 2015/02/16(月) 02:05:22.57

>>789
そりゃ動くほうが不思議だｗ自分の場合はカーネルを小さくしたら
普通に通ったからそういう問題はなかったはず。

**デフォルトの名無しさん** · 2015/02/16(月) 07:56:11.60

>>785
同意

**デフォルトの名無しさん** · 2015/02/16(月) 13:24:15.63

AMDのコンパイラも最適化オンにしたらコンパイル終わらなかった事あったので、結構怪しい。(2011年ぐらいの話だけど)

**デフォルトの名無しさん** · 2015/02/16(月) 13:44:20.54

>>792
確かにAMDのコンパイラの最適化は完全に地雷だったｗ

**デフォルトの名無しさん** · 2015/02/16(月) 21:40:57.33

>>784
初心者がこれからOpenCLを始めるのにどの環境を選ぶか、という話なら
NVIDIAは避けるのが無難だな。デバッガやオフラインコンパイラなんかの
ツールが皆無に等しい。
CUDAもやりたいとかいうなら別だが。

**デフォルトの名無しさん** · 2015/02/16(月) 22:38:07.54

>>794
多くの奴はGPGPUするぞ、じゃメジャーなCUDAで良いやだからな
OpenCL使ってIntel,Nv,AMD(あとFPGAとか?)でちゃんと動くものを作らなければいけないってあんまりないだろからな

**デフォルトの名無しさん** · 2015/02/17(火) 02:24:50.68

OpenCL使ったところで、同じコードでどんなCPU/GPUでも効率よく動くとかレアケースだしなぁ。

**デフォルトの名無しさん** · 2015/02/17(火) 08:22:15.68

最高のパフォーマンスを引き出すチューニングというなら別だが、どれかGPUを想定した
コードならそこそこの速度で動くだろ。たいてい、従来のCPUより速けりゃ十分だろうし。
FPGAだけは別格で、GPUと同じコードじゃぜんぜん速度が出ないだろうが。

**デフォルトの名無しさん** · 2015/02/18(水) 10:38:35.72

SSEレジスタに乗ること期待して書いたchar16とかGPUに食わせたら憤死するで。

**デフォルトの名無しさん** · 2015/02/18(水) 16:12:46.20

アーキテクチャ毎に最適化しないと、
OpenCLで性能なんか出せないよ。

**デフォルトの名無しさん** · 2015/02/18(水) 22:51:48.89

>>798
ベクタ型は想定するターゲットで効果が見込まれる場合に使うべきで、そういう意味では
どっちかというとチューニングの範疇だろう。
そもそも、インテルのコンパイラならベクタ型使わずに普通に書いてSSE/AVXを
使ってくれるんだが。CL_DEVICE_PREFERRED_VECTOR_WIDTH_CHAR=1だしな。
下手に最適化しようとして却って駄目にしているように思える。

**デフォルトの名無しさん** · 2015/02/19(木) 01:05:51.96

かたやGPUになるとパイプラインのスカスカ具合見ながら
int2とかint4とか使って依存関係のない演算で埋めていかないとお話にならんしなぁ。

**デフォルトの名無しさん** · 2015/02/19(木) 02:14:32.89

アーキテクチャごとの最適化は、まだコンパイラとかの成長中の部分もあるだろうしなぁ

そのうち改善はしてくれるような気がするけど

**デフォルトの名無しさん** · 2015/02/19(木) 22:30:01.89

そうは言っても今のアーキが向かってる方向ってコンパイラ実装の難易度上がってるから
コンパイラの苦手な部分を補填してやらにゃ速くならないってのは改善される事はないと思う

むしろそこまで賢いコンパイラとか使いたくない

**デフォルトの名無しさん** · 2015/02/19(木) 23:19:07.50

技術的側面もあるが
それ以上にIA64がコケたことが
コンパイラを賢くしてプロセッサを脳筋にする道を
決定的に閉ざした

コンパイラの賢さに関して言えば
足並みがそろってない事の方が問題だと思う

**デフォルトの名無しさん** · 2015/02/26(木) 07:17:19.04

クロノスってなんかのアニメであったような

**デフォルトの名無しさん** · 2015/02/26(木) 14:44:53.01

クロノスはゼウスのお父さん

**デフォルトの名無しさん** · 2015/02/26(木) 20:31:41.27

マッシーンロボッ！
お前には、敵はない！