一番最適化能力の高いC/C++コンパイラはどれだ！？

このエントリーをはてなブックマークに追加
1 ：ピルゲイシ：
一番最適化能力の高いC/C++コンパイラはどれだろう？

VC++？BCC？ICC？VectorC++？
さぁどれだ？
2 ：仕様書無しさん：04/02/13 20:54
誤爆・・・・
3 ：仕様書無しさん：04/02/13 21:06
俺のお気に入りは

VC++
g++
bcc32

4 ：仕様書無しさん：04/02/13 21:08
いや、それだと19ﾏｿでいけないだろ
まあディスプレイが3ﾏｿ以下の奴買うならいいが・・

値段にこだわる訳じゃないが安い画面でデザインってのもなぁ・・・
5 ：仕様書無しさん：04/02/13 21:09
誤爆＿|￣|○
6 ：仕様書無しさん：04/02/13 21:11
漢ならdistcc
7 ：仕様書無しさん ：04/02/13 21:28
intelのやつ
8 ：仕様書無しさん：04/02/13 21:29
「C/C++」なんて書くと怒るチンカスがくるぞ。
9 ：仕様書無しさん：04/02/13 21:33
昔のMSCの最適化は”強烈”だった
10 ：仕様書無しさん：04/02/13 21:33
っていうか、Intelのやつが一番最適化能力高いんだっけ？
11 ：仕様書無しさん：04/02/13 21:43
>>9
どうせこんなのだろ。

　 　∧_∧
　　（o^ヮ^）　
　　 ﾟし-Jﾟ
12 ：仕様書無しさん：04/02/13 21:53
動かなく最適化してくれるコンパイラってのもありましたね。
13 ：仕様書無しさん：04/02/13 22:19
自分のバグなのに、最適化オプションを変えたら動かなくなった。
コンパイラが悪い。という奴もいたね。
14 ：仕様書無しさん：04/02/13 22:26
俺のような奴が他にもいたのか
15 ：仕様書無しさん：04/02/14 00:37
VectorCとIntelの奴が良いんだっけ？
どっちが良いの？
16 ：69式フリーPG：04/02/14 00:48
昔、OPT-Cつうのがあったな。
17 ：仕様書無しさん：04/02/14 00:49
Watcom
昔はIA32じゃ最強だったが今はどうなんだろう？
まあBCCには勝てるだろうが
18 ：69式フリーPG：04/02/14 00:55
watcomかあ。NetWareのNLMを組むのにつかったな。
良いコンパイラだった。今はフリーだっけ？
19 ：仕様書無しさん：04/02/14 01:14
>>17
最強だった頃のﾃｨｰﾑが移籍して出来たのがVC++2.0らしいぜ
20 ：仕様書無しさん：04/02/14 01:22
CodeWarrior(←綴りがわからない)どうだったんだろう

あと、Fortranのコンパイラ最強、とか昔聞いたけど本当かな
俺がだまされてただけ?
あるいは科学計算分野限定の話だったんだろうか
21 ：仕様書無しさん：04/02/14 01:33
>>20
>Fortranのコンパイラ最強
Watcomの話？
漏れにはWatcom最強時代=98全盛の頃
のPCでFORTRANやろうなんつー奇特なﾌﾚﾝﾄﾞはいないですｽﾏｿ

CodeWarriorは元来ﾏｯｷﾝ専科てイメージがあるのだが違うのかね
そういやMac系コンパイラの最適化性能どうこうて聞いたことないけど
どうなのかな
22 ：仕様書無しさん：04/02/14 02:00
WatcomのFORTRANは方言が強くて使いにくかった記憶があるが。

スーパーなコンピュータを使ってひたすら数値計算する分野では
CよりもFORTRANの方が歴史もあるしユーザーも多いので、
FORTRANの方が最適化されやすいということだろう。

パソコンレベルじゃCもFORTRANもたいして変わらんだろうけど。
23 ：20：04/02/14 02:01
あ、すまそ、Watcomとは関係ない話でした

さっきWikiPediaのFortranの項を見てみたら
> FORTRANは最近のC言語のように、スタック等を使わず、
> コンパイル時に静的に記憶領域を確保するのが基本である。
> そのため、コンパイラはコードを最適化しやすいという利点がある。
> 最近ではスタックとか動的な記憶領域を使えるようになっている。
だそうで。

この辺の話が変な風に俺に伝わったのかも。ごめんなちぃ
24 ：仕様書無しさん：04/02/14 09:23
>>11
これﾌｻﾌｻしてるの？
ﾅﾃﾞﾅﾃﾞしていい？
25 ：仕様書無しさん：04/02/14 17:24
って事は、
WatcomC＜VC++2.0って事？
26 ：仕様書無しさん：04/02/14 18:49
>>9はかじゅ猫らしい。
27 ：仕様書無しさん：04/02/14 18:57
SPECint2000では VC++ > OpenWatcom らしい
ttp://www.mtl.t.u-tokyo.ac.jp/~nminoru/programming/x86-cc.html

ていうか今ではGCCにも負けているのか・・・
28 ：仕様書無しさん：04/02/15 02:30
http://www.codeplay.com/vectorc/bench.html
これってどれくらい本当なの？

マジでこれくらい差が出るならVectorC最強じゃん
29 ：仕様書無しさん：04/02/16 04:08
age
30 ：仕様書無しさん：04/02/28 16:43

31 ：仕様書無しさん：04/03/01 12:48
最弱はLSI-C?
32 ：仕様書無しさん：04/03/02 15:29
>>31
最弱は Visual C ++ Standard だろ？
わざと無駄なコード入れているし・・・
33 ：仕様書無しさん：04/03/10 14:54
>>21
>そういやMac系コンパイラの最適化性能どうこうて聞いたことないけど
>どうなのかな

GCC3.3に、G5は最適化されているらしいよ
34 ：仕様書無しさん：04/03/10 15:33
すいません、インテルがAMD64互換にするとかいうニュースがちょっと前に
出ましたが、とういうことは今後出るICCではAMD64にもICCの最適化が
有効になると思っていいんですか？
35 ：仕様書無しさん：04/03/10 16:00
俺様が最高に決まってるだろ。
所詮コンパイラプログラム如きが俺様が書いた機械語コードに
勝てるものを吐けるはずがない。
36 ：仕様書無しさん：04/03/10 16:41
>>35
ソース希望。「機械に勝つ」コードなら、見てみたい。
37 ：仕様書無しさん：04/03/10 16:47
>35はOSカーネルからソフトウェアツールまで、全部バイナリコード直打ちで書けるらしい。
スゲェ！まるでコンパイラの出る幕無しだ！
38 ：仕様書無しさん：04/03/10 19:20
彼のコードはまるで詩のようだよ。彼は歌うようにコードを叩き込んでいくのさ。
39 ：仕様書無しさん：04/03/10 19:24
>>1
インテルのコンパイラが一番だろう
40 ：仕様書無しさん：04/03/10 19:30
DM。DM最強。
41 ：仕様書無しさん：04/03/10 19:38
MicrosoftC Compiler Ver5.1 最適化オプション指定
42 ：仕様書無しさん：04/03/10 19:39
ICCってdouble型の変数を使う場合は速いけど
それ以外だとあんまメリット無いような。
43 ：仕様書無しさん：04/03/10 19:59
ＹＢＢを脅した人物名でググると･･･衝撃の新展開
http://society.2ch.net/test/read.cgi/koumei/1077620009/l50
44 ：名無し＠沢村：04/03/10 21:14
>>37
バイナリコード直打ちは無理だよ。
Ｃ言語の入門書にあるサンプル程度のプログラムなら、Ｃ言語書くのと、そう変わらない時間でバイナリコード直打ちできる。
だがコード数が多くなってくると、かかる時間はとてつもないものになる。
コード数が倍になると、バイナリコード直打ちにかかる時間は10倍になるといってもいいだろう。
2倍ごとに10倍ずつ増えるから、コード数が8倍になったときは1000倍、32倍になったときは10万倍になる。
つまり最初のＣ言語のサンプルプログラムを書くのにかかった時間が1分だとすると、その32倍のコード数のプログラムをバイナリ直打ちするのに要する時間は10万分、つまり約69日間かかることになる。
Ｃ言語で書けば32分で済むのにだ。
何故か？一番大きな問題は、バイナリ直打ちの場合、参照するアドレスを全部実際のアドレスの数値で書かなければならないためだ。
だから参照する変数や関数がある場合、そこまでのオフセットを１つずつ指で辿って数えていかなければならない。
またコードの挿入や削除が１つでもあると、それまでのアドレスを全部書き直さなければならないからだ。
よってバイナリ直打ちで、32bitプログラムをつくるのは、絶対に不可能といえるだろう。
だが待て、それはバイナリエディタでバイナリ直打ちをする場合の話だ。
おれはいまバイナリ直打ちのための超便利エディタをつくっているから、しばし待て！！
これができれば、アセンブリ言語とそう変わらない開発時間でプログラムが作成できるぞ！！
しばし待たれよ♪
45 ：仕様書無しさん：04/03/10 23:10
>>44
沢村よ。
使いどころに悩む中途半端なツールを作って、
時事問題の渦中にある法人に募金させるという
極めて退廃的な習慣を直すつもりはないのか？
46 ：仕様書無しさん：04/03/11 01:15
最適化能力ってなんですか？
47 ：仕様書無しさん：04/03/11 01:35
>>44
>おれはいまバイナリ直打ちのための超便利エディタをつくっているから、しばし待て！！
それってOPTASMじゃん(w

>>46
マシンをリプレースできない貧乏人がギリギリまで機械の性能を搾り出す方法とその能力のことだ。
48 ：仕様書無しさん：04/03/11 01:40
>>47

意味がよくﾜｶﾝﾈｯｽ。
49 ：仕様書無しさん：04/03/11 08:39
エディタ云々以前に・・・
人間がバイナリコードで書かれたプログラムを直接理解するのは困難。
アセンブリ言語？バイナリコードを言葉に置き換えただけでしょ。
アルゴリズムが複雑になればなるほどJUMP JUMPでわけわかんなくなる。
それを理路整然とした記号に置き換えて人間のアタマで編集可能にするための高級言語・・・
アセンブラでシコシコすることもたまにあるが、それは本当に速度が問われる部分を局地的に行う程度。



じゃなければ、何のためのコンパイラですか？
50 ：仕様書無しさん：04/03/11 10:06
沢村にマジレスしてもなぁ・・・
51 ：仕様書無しさん：04/03/11 21:11
沢村にマジレスｶｺﾜﾙｲ
52 ：名無し＠沢村：04/03/11 21:13
おまいらよ、いまのマシンの性能で最適化なんていらないよ。
おまいらは、最適化という言葉を使うと「ツウ」みたいでかっこいいから使ってるだけだよ。
最適化なんて全々しなくても何の影響もない。
最適化どころか多少「邪魔化」してちょうどいいくらいだよ。
53 ：仕様書無しさん：04/03/11 21:28
>>52
釣れるか？
54 ：仕様書無しさん：04/03/11 21:39
>最適化どころか多少「邪魔化」してちょうどいいくらいだよ。
プログラムを遅くすることで得られるメリットの具体例(実話)とソースをきぼんぬ。
そのような前例がないのだとしたら、理論的に穴のない技術的解説きぼんぬ。

と言うかまず、>44と>52で言ってることが食い違ってる点についての理由説明きぼんぬ。
55 ：仕様書無しさん：04/03/11 22:54
早すぎて着いていけないゲームなんかは遅くする方が良いと。
56 ：仕様書無しさん：04/03/11 23:03
ハッブル望遠鏡もCPUが早すぎると困るから
386にしたらしいな。
プログラムも早ければ良いとも思えないが。
57 ：仕様書無しさん：04/03/11 23:05
沢村君は、どういう仕事をしているのか興味がわいてきたよ
58 ：仕様書無しさん：04/03/11 23:13
ぼくはどうすれば自分のスキルを現在の仕事に最も高度に最適化出来るかに興味があります
どのコンパイラを使えば良いのでしょう？
59 ：仕様書無しさん：04/03/11 23:14
最適化しすぎのコンパイラは組込みでは逆に使いづらい
デバッグコードをどう書いても消されて、キーッとなる

かといって最適化オプションはずすと動作が変わるわけだし
60 ：仕様書無しさん：04/03/11 23:19
>>56
宇宙で使うには素子の多きめで動作速度遅めのほうが宇宙線で暴走する事が少ないらしいね。
61 ：仕様書無しさん：04/03/11 23:45
>>59
> かといって最適化オプションはずすと動作が変わるわけだし
それは藻前のプログラムがヘボだから。
62 ：仕様書無しさん：04/03/12 00:07
>>54
I/O周りのテクニックだな＞邪魔化
CPUのアウトオブオーダー実行を抑制する。
メモリマップトI/Oを使う糞デバイスに必要。
63 ：仕様書無しさん：04/03/12 00:42
誤魔化オプションはありませんか?
64 ：仕様書無しさん：04/03/12 09:38
>>61

フォローするわけではないが、動作未定義のコードであったとしても、
同一のコンパイラの中では定義して欲しいと思うのは、まずいですか？

デバッグバージョンとリリースバージョンで動作が異なるとなると
デバッグバージョンの意味がなくなる気がしますが。

そうでなければ、X3J16では動作未定義です！みたいな警告を出して
ほしいっす。
65 ：仕様書無しさん：04/03/12 09:44
動作未定義のコードなんか使わないんだから
エラーになってほしい。
66 ：仕様書無しさん：04/03/12 16:29
>>54 JAVAの逆コンパイル抑制（名前忘れた）はたぶんその例ではないだろうか。

>>44 頑張った末にアセンブラが出来上がる予感。
67 ：仕様書無しさん：04/03/13 12:42
沢村を知らん奴がいるのか。
沢村といえばム板のヒーローだぞ。
皆々様方〜♪
68 ：ブッシュ大統領：04/03/15 11:03
三大悪の枢軸国の紹介
　C++帝國(北朝鮮)　← C++厨代表の正体は、何と！　金正日だった！
　VB帝國(イラン)　←　VB厨代表はイランに潜伏していいた！
　Perl帝國(イラク)　← Perl厨代表フセインがついに逮捕された！
69 ：仕様書無しさん：04/03/16 06:05
>>34
インテルは現行の32bitのを拡張して64bitにするってだけで
それがAMDのIA32-64と似てるからそう言われてるだけで
実際には別物っしょ？
70 ：仕様書無しさん：04/03/16 07:26
>>69
http://slashdot.jp/article.pl?sid=04/02/17/2130231
71 ：仕様書無しさん：04/04/28 21:34
>>56
それはプログラムがヘボイ顕著な例
72 ：仕様書無しさん：04/04/28 22:48
http://page4.auctions.yahoo.co.jp/jp/auction/d47227135
73 ：仕様書無しさん：04/04/30 09:58
>>56
486ベースに置き換えられたようだ。（この記事には日付けが入ってない）
http://www.chron.com/content/interactive/space/missions/sts-103/eva/computer.html

まあ古い世代のチップを使うのは、「実行速度が早すぎて困る」というよりは
・動作クロックが上がると、ノイズや消費電力の点で不利
・かといってクロックを下げすぎると動かなかったりするんで、古いチップを使う
・ハード・ソフトともに十分枯れた技術で作りたい
といった理由ではないかと
74 ：仕様書無しさん：04/07/16 11:41
ヘ_ヘ
ミ・・ ミ　ということにしたいのですね？
( ° )〜
75 ：仕様書無しさん：04/08/04 18:09
最強のコンパイラはVC++でしょう。

なにせ動かなくなるまで最適化するからねっ

volatileをシコシコ書くべきか、いっそ最適化をやめるべきか。
それが問題だ。
76 ：仕様書無しさん：04/09/11 21:56:53
ICC > VC++7.1 > gcc3.3 > CodeWariror > OpenWatcom > DigitalMars >>>>>>>>>(越えられない壁)>bcc5.6.4>最適化無
77 ：仕様書無しさん：04/09/11 21:57:56
age
78 ：仕様書無しさん：04/09/11 22:01:54
>>75
おれの持ってる、なんでも1byteに圧縮してくれるソフトと、どちらが
素晴らしいだろうか?
79 ：仕様書無しさん：04/09/11 23:00:12
>>78
解凍できるんかい？

Ｇｃｃが、一番かな　Ｖｃは微妙
80 ：仕様書無しさん：04/09/11 23:13:22
>>78
俺もそれもってる。
辞書のサイズが元バイナリと同サイズになるやつだよね。
81 ：仕様書無しさん：04/09/12 12:21:41
>>78
ソフト名希望
82 ：仕様書無しさん：04/09/12 14:06:55
>>79
gccを誉める根拠は何？
キモイUnix信者ですか？
83 ：いなむらきよし：04/09/12 21:00:30
奇形＋＋（＾＾）
84 ：仕様書無しさん：04/09/12 23:22:10
ところでさ、VC++のリリースモードでコンパイルしたら
動かなくなるプログラムってどう思うよ？
85 ：69式フリーPG ◆hND3Lufios ：04/09/13 00:28:41
おいっす！
変数初期化したか？
86 ：仕様書無しさん：04/09/13 02:24:47
>>81
今の香具師は例のアレも知らないんだな
87 ：仕様書無しさん：04/09/14 19:48:28
>>84
そのコードを書いた奴は無能だな、と思う。
88 ：仕様書無しさん：04/09/14 23:05:46
早い段階からデバッグモード開発をやめる。これ常識。
89 ：仕様書無しさん：04/09/15 15:11:39
>>76が一番合ってると思うな
90 ：仕様書無しさん：04/09/26 23:46:19
VC++ は Lattice C++ の OEM だからな。そりゃ最適化めちゃくちゃいいわ。
91 ：仕様書無しさん：04/10/21 20:15:40
そりゃMS-Cの4.0あたりじゃないんか。。。




VC++はWatcomの開発チームを引き抜きますたｗ
92 ：仕様書無しさん：04/10/24 00:58:53
VCのバグで最適化すると正常に動かなくなったプログラムが前あった。VCのパッチを当てたら
直ったけど。

そういうコンパイラのバグが時々あるから最適化は怖い。まあVCの世界では使う人が山ほど
いるからバグも見つかって修正されるけど、組み込み用のコンパイラだとバグが残っている
ことがよくある。
で、volatile忘れなのか、コンパイラのバグなのかが分からず、アセンブラとＣソースを
見比べながら動作を追いかけるのは大分疲れる。
93 ：仕様書無しさん：04/10/24 16:34:54
バブルソートのプログラムを入れるとクイックソートに成って出力されたりするコンパイラーって無いかなー?
もちろんこういう処理が全てのアルゴリズムについて行えるやつ。
此だとオーダーが下がるから最強…ってなものが出来たら自分が失業してしまうw
94 ：仕様書無しさん：04/10/24 19:48:58
逆にクイックソートを書いたつもりがいつの間にかバブルソートに(ry
95 ：仕様書無しさん：04/10/24 21:28:01
>>94
qsort関数がバブルソートで書かれたcコンパイラとか有ったらやだなー。

そういえばクイックソートは安定じゃない故にバブルソート->クイックソート変換等やるなら
その辺も考慮しないといけないから相当複雑なロジックが必要そうだなー。
96 ：仕様書無しさん：04/10/24 23:42:11
std::stable_sort()は、バブルソートじゃないけど現在オーダーを維持したソートをしてくれる。
97 ：仕様書無しさん：04/12/28 15:17:22
コンパイラの最適化などで上がる速度など微々たる物。
アルゴリズムそのものを最適化汁！
98 ：仕様書無しさん：04/12/28 19:06:29
アルゴリズムを解析して勝手に速度オーダーを下げてくれる素敵な最適化ツールって
あったら良いけど、
あり得ないね
99 ：仕様書無しさん：04/12/28 19:59:37
DEV C++
100 ：仕様書無しさん：04/12/28 20:07:45
実際速度に大きな影響を及ぼすのは、
大きな単位でのロジックフローやデータフローだよね。
この辺の設計を自動解析して、実装目的に関連しない程度で構わないから
改善案を提示してくれるコンパイラの方がいい。
細かい実装をしてなくても、大体の感じで提案してくれるとか。

夢物語っぷりはアルゴリズム置き換えコンパイラと大差無いかもしれないけど、
実現した場合の失業者増加っぷりはこっちの方がひどそうだな……
101 ：仕様書無しさん：04/12/28 20:21:30
アルゴリズムを解析して、翻訳を拒否するＣコンパイラ。

エラーコード：けっ
102 ：仕様書無しさん：04/12/28 20:23:29
warning:ダイクストラを読んだことありますか？
103 ：仕様書無しさん：04/12/28 20:30:14
設計を解析して提案してくれるコンパイラ

warning: お前仕事辞めろ
104 ：仕様書無しさん：04/12/28 20:31:36
-money=単価
105 ：仕様書無しさん：04/12/28 20:34:30
--help
106 ：仕様書無しさん：04/12/28 22:14:47
--autodebug
107 ：仕様書無しさん：05/01/10 22:10:17
もし演算速度無限大の電算機があったなら、
全部スクリプト言語や中間言語系でやった方が便利なんだろうけど。
アルゴリズムのオーダーとか関係ないし。
可読性最優先で書ける。
108 ：仕様書無しさん：
>107
「このアルゴリズムの方が早い」が
「このアルゴリズムの方が発熱を抑えられる」とか
「このアルゴリズムの方がコードサイズが小さい」とかに
変わるだけだったりして。