一番最適化能力の高いC/C++コンパイラはどれだ!?
一番最適化能力の高いC/C++コンパイラはどれだろう?
VC++?BCC?ICC?VectorC++?
さぁどれだ?
誤爆・・・・
俺のお気に入りは
VC++
g++
bcc32
いや、それだと19マソでいけないだろ
まあディスプレイが3マソ以下の奴買うならいいが・・
値段にこだわる訳じゃないが安い画面でデザインってのもなぁ・・・
誤爆_| ̄|○
漢ならdistcc
intelのやつ
8 :
仕様書無しさん:04/02/13 21:29
「C/C++」なんて書くと怒るチンカスがくるぞ。
昔のMSCの最適化は”強烈”だった
っていうか、Intelのやつが一番最適化能力高いんだっけ?
11 :
仕様書無しさん:04/02/13 21:43
>>9 どうせこんなのだろ。
∧_∧
(o^ヮ^)
゚し-J゚
動かなく最適化してくれるコンパイラってのもありましたね。
自分のバグなのに、最適化オプションを変えたら動かなくなった。
コンパイラが悪い。という奴もいたね。
俺のような奴が他にもいたのか
15 :
仕様書無しさん:04/02/14 00:37
VectorCとIntelの奴が良いんだっけ?
どっちが良いの?
16 :
69式フリーPG:04/02/14 00:48
昔、OPT-Cつうのがあったな。
Watcom
昔はIA32じゃ最強だったが今はどうなんだろう?
まあBCCには勝てるだろうが
18 :
69式フリーPG:04/02/14 00:55
watcomかあ。NetWareのNLMを組むのにつかったな。
良いコンパイラだった。今はフリーだっけ?
>>17 最強だった頃のティームが移籍して出来たのがVC++2.0らしいぜ
CodeWarrior(←綴りがわからない)どうだったんだろう
あと、Fortranのコンパイラ最強、とか昔聞いたけど本当かな
俺がだまされてただけ?
あるいは科学計算分野限定の話だったんだろうか
>>20 >Fortranのコンパイラ最強
Watcomの話?
漏れにはWatcom最強時代=98全盛の頃
のPCでFORTRANやろうなんつー奇特なフレンドはいないですスマソ
CodeWarriorは元来マッキン専科てイメージがあるのだが違うのかね
そういやMac系コンパイラの最適化性能どうこうて聞いたことないけど
どうなのかな
WatcomのFORTRANは方言が強くて使いにくかった記憶があるが。
スーパーなコンピュータを使ってひたすら数値計算する分野では
CよりもFORTRANの方が歴史もあるしユーザーも多いので、
FORTRANの方が最適化されやすいということだろう。
パソコンレベルじゃCもFORTRANもたいして変わらんだろうけど。
あ、すまそ、Watcomとは関係ない話でした
さっきWikiPediaのFortranの項を見てみたら
> FORTRANは最近のC言語のように、スタック等を使わず、
> コンパイル時に静的に記憶領域を確保するのが基本である。
> そのため、コンパイラはコードを最適化しやすいという利点がある。
> 最近ではスタックとか動的な記憶領域を使えるようになっている。
だそうで。
この辺の話が変な風に俺に伝わったのかも。ごめんなちぃ
>>11 これフサフサしてるの?
ナデナデしていい?
25 :
仕様書無しさん:04/02/14 17:24
って事は、
WatcomC<VC++2.0って事?
28 :
仕様書無しさん:04/02/15 02:30
29 :
仕様書無しさん:04/02/16 04:08
age
30 :
仕様書無しさん:04/02/28 16:43
最弱はLSI-C?
>>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の最適化が
有効になると思っていいんですか?
俺様が最高に決まってるだろ。
所詮コンパイラプログラム如きが俺様が書いた機械語コードに
勝てるものを吐けるはずがない。
36 :
仕様書無しさん:04/03/10 16:41
>>35 ソース希望。「機械に勝つ」コードなら、見てみたい。
>35はOSカーネルからソフトウェアツールまで、全部バイナリコード直打ちで書けるらしい。
スゲェ!まるでコンパイラの出る幕無しだ!
38 :
仕様書無しさん:04/03/10 19:20
彼のコードはまるで詩のようだよ。彼は歌うようにコードを叩き込んでいくのさ。
39 :
仕様書無しさん:04/03/10 19:24
40 :
仕様書無しさん:04/03/10 19:30
DM。DM最強。
41 :
仕様書無しさん:04/03/10 19:38
MicrosoftC Compiler Ver5.1 最適化オプション指定
ICCってdouble型の変数を使う場合は速いけど
それ以外だとあんまメリット無いような。
44 :
名無し@沢村:04/03/10 21:14
>>37 バイナリコード直打ちは無理だよ。
C言語の入門書にあるサンプル程度のプログラムなら、C言語書くのと、そう変わらない時間でバイナリコード直打ちできる。
だがコード数が多くなってくると、かかる時間はとてつもないものになる。
コード数が倍になると、バイナリコード直打ちにかかる時間は10倍になるといってもいいだろう。
2倍ごとに10倍ずつ増えるから、コード数が8倍になったときは1000倍、32倍になったときは10万倍になる。
つまり最初のC言語のサンプルプログラムを書くのにかかった時間が1分だとすると、その32倍のコード数のプログラムをバイナリ直打ちするのに要する時間は10万分、つまり約69日間かかることになる。
C言語で書けば32分で済むのにだ。
何故か?一番大きな問題は、バイナリ直打ちの場合、参照するアドレスを全部実際のアドレスの数値で書かなければならないためだ。
だから参照する変数や関数がある場合、そこまでのオフセットを1つずつ指で辿って数えていかなければならない。
またコードの挿入や削除が1つでもあると、それまでのアドレスを全部書き直さなければならないからだ。
よってバイナリ直打ちで、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
エディタ云々以前に・・・
人間がバイナリコードで書かれたプログラムを直接理解するのは困難。
アセンブリ言語?バイナリコードを言葉に置き換えただけでしょ。
アルゴリズムが複雑になればなるほどJUMP JUMPでわけわかんなくなる。
それを理路整然とした記号に置き換えて人間のアタマで編集可能にするための高級言語・・・
アセンブラでシコシコすることもたまにあるが、それは本当に速度が問われる部分を局地的に行う程度。
じゃなければ、何のためのコンパイラですか?
沢村にマジレスしてもなぁ・・・
沢村にマジレスカコワルイ
52 :
名無し@沢村:04/03/11 21:13
おまいらよ、いまのマシンの性能で最適化なんていらないよ。
おまいらは、最適化という言葉を使うと「ツウ」みたいでかっこいいから使ってるだけだよ。
最適化なんて全々しなくても何の影響もない。
最適化どころか多少「邪魔化」してちょうどいいくらいだよ。
>最適化どころか多少「邪魔化」してちょうどいいくらいだよ。
プログラムを遅くすることで得られるメリットの具体例(実話)とソースをきぼんぬ。
そのような前例がないのだとしたら、理論的に穴のない技術的解説きぼんぬ。
と言うかまず、>44と>52で言ってることが食い違ってる点についての理由説明きぼんぬ。
55 :
仕様書無しさん:04/03/11 22:54
早すぎて着いていけないゲームなんかは遅くする方が良いと。
ハッブル望遠鏡もCPUが早すぎると困るから
386にしたらしいな。
プログラムも早ければ良いとも思えないが。
57 :
仕様書無しさん:04/03/11 23:05
沢村君は、どういう仕事をしているのか興味がわいてきたよ
ぼくはどうすれば自分のスキルを現在の仕事に最も高度に最適化出来るかに興味があります
どのコンパイラを使えば良いのでしょう?
59 :
仕様書無しさん:04/03/11 23:14
最適化しすぎのコンパイラは組込みでは逆に使いづらい
デバッグコードをどう書いても消されて、キーッとなる
かといって最適化オプションはずすと動作が変わるわけだし
>>56 宇宙で使うには素子の多きめで動作速度遅めのほうが宇宙線で暴走する事が少ないらしいね。
>>59 > かといって最適化オプションはずすと動作が変わるわけだし
それは藻前のプログラムがヘボだから。
>>54 I/O周りのテクニックだな>邪魔化
CPUのアウトオブオーダー実行を抑制する。
メモリマップトI/Oを使う糞デバイスに必要。
63 :
仕様書無しさん:04/03/12 00:42
誤魔化オプションはありませんか?
64 :
仕様書無しさん:04/03/12 09:38
>>61 フォローするわけではないが、動作未定義のコードであったとしても、
同一のコンパイラの中では定義して欲しいと思うのは、まずいですか?
デバッグバージョンとリリースバージョンで動作が異なるとなると
デバッグバージョンの意味がなくなる気がしますが。
そうでなければ、X3J16では動作未定義です!みたいな警告を出して
ほしいっす。
動作未定義のコードなんか使わないんだから
エラーになってほしい。
>>54 JAVAの逆コンパイル抑制(名前忘れた)はたぶんその例ではないだろうか。
>>44 頑張った末にアセンブラが出来上がる予感。
沢村を知らん奴がいるのか。
沢村といえばム板のヒーローだぞ。
皆々様方〜♪
68 :
ブッシュ大統領:04/03/15 11:03
三大悪の枢軸国の紹介
C++帝國(北朝鮮) ← C++厨代表の正体は、何と! 金正日だった!
VB帝國(イラン) ← VB厨代表はイランに潜伏していいた!
Perl帝國(イラク) ← Perl厨代表フセインがついに逮捕された!
69 :
仕様書無しさん:04/03/16 06:05
>>34 インテルは現行の32bitのを拡張して64bitにするってだけで
それがAMDのIA32-64と似てるからそう言われてるだけで
実際には別物っしょ?
72 :
仕様書無しさん:04/04/28 22:48
74 :
仕様書無しさん:04/07/16 11:41
ヘ_ヘ
ミ・・ ミ ということにしたいのですね?
( ° )〜
最強のコンパイラはVC++でしょう。
なにせ動かなくなるまで最適化するからねっ
volatileをシコシコ書くべきか、いっそ最適化をやめるべきか。
それが問題だ。
ICC > VC++7.1 > gcc3.3 > CodeWariror > OpenWatcom > DigitalMars >>>>>>>>>(越えられない壁)>bcc5.6.4>最適化無
77 :
仕様書無しさん:04/09/11 21:57:56
age
>>75 おれの持ってる、なんでも1byteに圧縮してくれるソフトと、どちらが
素晴らしいだろうか?
79 :
仕様書無しさん:04/09/11 23:00:12
>>78 解凍できるんかい?
Gccが、一番かな Vcは微妙
>>78 俺もそれもってる。
辞書のサイズが元バイナリと同サイズになるやつだよね。
81 :
仕様書無しさん:04/09/12 12:21:41
>>79 gccを誉める根拠は何?
キモイUnix信者ですか?
83 :
いなむらきよし:04/09/12 21:00:30
奇形++(^^)
ところでさ、VC++のリリースモードでコンパイルしたら
動かなくなるプログラムってどう思うよ?
おいっす!
変数初期化したか?
>>84 そのコードを書いた奴は無能だな、と思う。
早い段階からデバッグモード開発をやめる。これ常識。
90 :
仕様書無しさん:04/09/26 23:46:19
VC++ は Lattice C++ の OEM だからな。そりゃ最適化めちゃくちゃいいわ。
そりゃMS-Cの4.0あたりじゃないんか。。。
VC++はWatcomの開発チームを引き抜きますたw
92 :
仕様書無しさん:04/10/24 00:58:53
VCのバグで最適化すると正常に動かなくなったプログラムが前あった。VCのパッチを当てたら
直ったけど。
そういうコンパイラのバグが時々あるから最適化は怖い。まあVCの世界では使う人が山ほど
いるからバグも見つかって修正されるけど、組み込み用のコンパイラだとバグが残っている
ことがよくある。
で、volatile忘れなのか、コンパイラのバグなのかが分からず、アセンブラとCソースを
見比べながら動作を追いかけるのは大分疲れる。
バブルソートのプログラムを入れるとクイックソートに成って出力されたりするコンパイラーって無いかなー?
もちろんこういう処理が全てのアルゴリズムについて行えるやつ。
此だとオーダーが下がるから最強…ってなものが出来たら自分が失業してしまうw
逆にクイックソートを書いたつもりがいつの間にかバブルソートに(ry
>>94 qsort関数がバブルソートで書かれたcコンパイラとか有ったらやだなー。
そういえばクイックソートは安定じゃない故にバブルソート->クイックソート変換等やるなら
その辺も考慮しないといけないから相当複雑なロジックが必要そうだなー。
std::stable_sort()は、バブルソートじゃないけど現在オーダーを維持したソートをしてくれる。
97 :
仕様書無しさん:04/12/28 15:17:22
コンパイラの最適化などで上がる速度など微々たる物。
アルゴリズムそのものを最適化汁!
アルゴリズムを解析して勝手に速度オーダーを下げてくれる素敵な最適化ツールって
あったら良いけど、
あり得ないね
99 :
仕様書無しさん:04/12/28 19:59:37
DEV C++
実際速度に大きな影響を及ぼすのは、
大きな単位でのロジックフローやデータフローだよね。
この辺の設計を自動解析して、実装目的に関連しない程度で構わないから
改善案を提示してくれるコンパイラの方がいい。
細かい実装をしてなくても、大体の感じで提案してくれるとか。
夢物語っぷりはアルゴリズム置き換えコンパイラと大差無いかもしれないけど、
実現した場合の失業者増加っぷりはこっちの方がひどそうだな……
アルゴリズムを解析して、翻訳を拒否するCコンパイラ。
エラーコード:けっ
warning:ダイクストラを読んだことありますか?
設計を解析して提案してくれるコンパイラ
warning: お前仕事辞めろ
-money=単価
--help
--autodebug
もし演算速度無限大の電算機があったなら、
全部スクリプト言語や中間言語系でやった方が便利なんだろうけど。
アルゴリズムのオーダーとか関係ないし。
可読性最優先で書ける。
>107
「このアルゴリズムの方が早い」が
「このアルゴリズムの方が発熱を抑えられる」とか
「このアルゴリズムの方がコードサイズが小さい」とかに
変わるだけだったりして。