【PIE2009】
by 関根慎一@デジカメWatch

マルチコア対応ってコンパイルしなおすだけじゃないの？

>>1

はぁ？

なんのエセ知識を元にどっからそんな発想が生まれるんだ？

市川ソフトラボラトリーさん、最近特にMacユーザーに冷たいですね。
う〜んしょうがないか。でも必ず出してくださいね、Mac版。

それよりもボチボチ64bit版がほしいところ

どういうこと？今でも６４ｂｉｔで使えてるぞ・・・

64bitネイティブコードの必要性は感じないなあ。

それよかCよりjavaの方が速いって記事を発見して驚いた。

VMによる動的コンパイルってのが効くらしい。

http://dev.ariel-networks.com/Members/inoue/java-vs-c

静的コンパイルなら、インテルコンパイラですが。

http://sourceforge.jp/magazine/08/12/24/118252/5

自分のマシンで自分のマシン用にインラインアセンブラってのが
一番だとは思うんだけど、時代は変ったんですね。

あの程度の検証で白黒付けてる時点で何ともまあ、その、なんだ。

要するに速いマシンを使えばいいんだろ

>>6
> それよかCよりjavaの方が速いって記事を発見して驚いた。
> VMによる動的コンパイルってのが効くらしい。

その、動的コンパイルというのがくせ者みたいです。

Javaは、未使用の変数などを囲ったループ処理を、無駄なコードと判断し、コンパイル時の最適化の段階で、ゴッソリと削除しているみたいです。
これを 「デッドコード削除」 というのだとか。

したがって、 「デッドコード削除」 が働いているプログラムは、実際には繰りかえし処理を行っていないため、動作が速く見えてしまうとのこと。

以上のことは、tnanbaさんという方が、問題のブログのコメントで指摘していますね。
「デッドコード削除」 については、以下に説明があります。
http://www.ibm.com/developerworks/jp/java/library/j-jtp12214/#3.0

いよいよ来年は128bit版が登場するらしい。
技術の進歩は凄いなw

>>1
Intelコンパイラ辺りだと多少は自動でマルチコアに振ってくれるかもしれないが、基本はプログラマが並列処理できる部分に「ここからここまで並列化で」って印をつけないといけない。
一度出来上がった複雑なプログラムの場合、並列化できそうでも実は並列処理の中で互いに依存していて無駄に待ち時間がなんてこともあるので割と大変。

まあ現像ソフトならRAWからRGBに変換する処理とか、単純な行列処理で済むフィルタなんかは並列化しやすいとは思うけど。
（他の位置の処理済みデータが影響しないから）

>>9
そのくらいの最適化、Cのコンパイラでもやってるけどね。確かVer6くらいのMS-Cがそういうすごい最適化をやってて「やりすぎだろ」って評判になってたような

>10

でも、そのＣＰＵで１＋１を計算するには、命令と１と１で、１２８ｘ３＝３８４ビットも消費するぞ。燃費悪くないですか？燃費って言うか、エコじゃないよね。エコ用途は今でも８ビットですね。

G1は大変いいんだけど
現像がｼﾙﾋﾟｸなとこだけがアレソレだｗ