2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :ピルゲイシ:04/02/13 20:54
一番最適化能力の高い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
YBBを脅した人物名でググると・・・衝撃の新展開
http://society.2ch.net/test/read.cgi/koumei/1077620009/l50

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
>>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


14 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)