GCCについて part8

>>951
いやicc以外バグがあるってintelに指摘されてるでしょ

>>952
ソースは？

こういう嘘つき野郎って、やっぱり頭おかしいんだろうな

GCC以前に64bitの演算器が32bit未満の並列粒度しか保障してない
CPUもなかったっけ？

世の中にないと断言するのは難しいが。

プレスコは32bit演算器のパイプ2段で64bit命令実行している。
CoreMAは最初のころ命令デコーダがEM64Tの命令切りわけ時に
ペナルティがあった。

レジスタが増えた分と実行性能が落ちる分とがあるから、
64bitにしたら単純に性能が上がるとは言えない。

一般論で言えるわけではなく、そのCPUの出来が悪いってだけの話だな。

Athlon64は初期のころから性能上がるケースが多かったけど、
Intel は Core2 でもあまり性能上がらなかったからな。
ネハーレンでやっと最初から64bitをターゲットに設計したCPUになった。

そもそも、一般論で終わらない話題だろーが。
上のほうで「速くなる」とか「遅くなる」とか言ってるのがアホってだけで。
んなもん、CPUと対象のプログラムに依存するにきまってんだろ。

iccもvcもpgも速くなるのに
なぜかgccだけは64bitでもっさりするｗ

終わってるよな

vcは全然はやくなんねーけどな。

レジスタいるような計算ぶん回してるときって、
push/popが実質0クロックで終わるから、レジスタ増えたこと自体は
大した解決にならないんでないの。
push reg/pop regも1バイト命令だし、ALUがボトルネックになるだろうから
今時のx86デコーダの負荷にはならんだろうし。

レジスタリネーミングが無いプロセッサとか、
レジスタ割り当て問題にコンパイラが悩まされてるときなら
レジスタが多いのは役に立ったけど、今となっちゃあ
それだけでパフォーマンスアップしろってのは難しいでしょ。

スタックフレーム上のローカル変数(レジスタ割付できなかったもの)は
普通、push/popなんてしません。
毎回直接読み書きするし、
それがアドレスを示すものならば、必ずレジスタにロードしてから(アドレス先に)アクセスします。

>>963の内容は
「レジスタ変数に割り当て可能なレジスタ」が増えた場合の話だけね。
局所的な計算に用いる「レジスタの増加」とはあまり関係ない。

そういえば、レジスタが足りなくてpush/popするのは人間だけか。
でもやっぱりmovも0クロックじゃね？
ほとんどのケースで演算に隠れちゃいそうだけど。

たとえキャッシュに乗っていたとしても、
メモリの読み書きとレジスタじゃ速度が違うんだよ。
そうでなければレジスタの存在意義が半減する。

だからこそRISCとかは沢山のレジスタを持ってるし
x86だってレジスタリネーミングとかを駆使して補おうとしている。
補えないから、一時変数としてのメモリの読み書きが発生してるんだがね。

>>967
いや、だから今時のx64積んでるようなx86ってその「レジスタの存在意義が半減」してるから、
単にレジスタ増えただけじゃあんまり変らなくね？って話ですよ。
キャッシュアクセスのスループットがいくら悪くても、
前後の演算なりイテレーションなりに隠せないようなケースってのは
ほぼ無いと見ていいんじゃないかと。

もちろん、裏付けがあるわけではないので、
「んなわけねーよ、メモリ待ちでストールしまくりだよ」
と言われるとそれまでです。

>ほぼ無いと見ていいんじゃないかと。

これだけは絶対ありません。
そして、(対32bitにおけるデコーダ等の不利の無い場合)
64bitで再コンパイルしたコードの速度が実際に速くなっているという事実が
全てを物語っていますけど。

頼むからレジスタなんて多くても速くならないなんてスーパー馬鹿は放置してくれ

あちこちで同じような馬鹿が沸いてるな

レジスタの多かった下手なRISCよりもx86の方が早かったのも事実だが、
開発費を湯水のように使って高速なプロセッサの設計が出来、
開発費の回収も出来たからだろうな。

現状はレジスタ数を増やした方が早くなっているものの、早くなっていないアプリもある。
演算やポインタの単位が64ビットになって、キャッシュに対する影響が出ているのではないかと
思われるが、本当の理由についての解析は完璧に進んでいるのかな？
32bitでレジスタ増えるモードがあれば、相当に高速であるだろうとは思うが
そんな命令セットになってないし…

最低限このくらいは読まないと。
http://www.amazon.co.jp/Computer-Architecture-Quantitative-Approach-Kaufmann/dp/0123704901

テンプレートを使ったコードのコンパイルエラーがもっと見やすくならない
ものか。あれでSTLを使うのに恐れをなす初学者は多いだろうな。

conceptが完成の暁には〜

>>974
ttp://www.bdsoft.com/tools/stlfilt.html

>>976
おお？
何じゃこれは？

なつたん: STLFilt
ttp://natu.txt-nifty.com/natsutan/2007/08/stlfilt.html

あまり変わらないような気もするな。

>>976
一時期使ってたことあったのだが、何でやめたのか思い出せない。
また使ってみるか。

ActivePerlを入れるのが面倒なのとコマンドラインでしか
使えないので使い勝手が悪かったので俺はやめた

redhat linux 8.0 で自分のディレクトリにgccインストールしようとしたら

make[2]: *** [configure-stage1-target-libgcc] エラー 1
make[2]: 出ます ディレクトリ `/***/src/gcc-4.3.3'
make[1]: *** [stage1-bubble] エラー 2
make[1]: 出ます ディレクトリ `/***/src/gcc-4.3.3'
make: *** [all] エラー 2

てな エラーが出るんだが、これってどう意味？
ググったけどあんまり参考にならなかった。

もうちょっと上のほうのメッセージがないとなんとも

もうちょっと上のほうで xgcc だかなんだかがエラーはく
→ それを起動してた make がエラーになる
→ その make を起動してた make がエラーになる
って感じになってて、そのメッセージじゃその最後の2つだけしかわからないから、根本的な原因がわからない

make cleanして
もう一回makeしたらこういうのが出ました。

checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile

disk fullなんじゃねーの？

使っているgccが古すぎて新しいgccが正しく作れない。
なんて事もあったりする。

RH8じゃ元々入ってるのはかなり古くないかい？

>>984
diskはフルじゃないこと確認した。

>>985
調べてみたけどgcc バージョン 3.2だ。2002年だけど、これってかなり古い部類？

gmp,mpfrがらみ？

>>987
それは両方とも最新のをインストールしてあります。

上のエラーでググるとインストール先が変でxgccが起動してないってのがあった。

>>986
gcc-3.4.6でgcc-4.1.1のクロスコンパイラ作ろうとしたら、
libgcc作る所でxgccがInternal Error吐いたことがあった。

gcc-4.3.3にしたら問題なし。

configureの段階でバイナリ吐けないってlibcのヘッダが入ってないとかでないの？

config.logから関係ありそうな部分抜き出してみた。
configure:3251: checking whether the C compiler works
configure:3257: ./a.out
configure:3260: $? = 0
configure:3277: result: yes
configure:3284: checking whether we are cross compiling
configure:3286: result: no

configure:3630: gcc -c -g -O2 conftest.c >&5
conftest.c:2: parse error before "me"

configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
| exit (42);
| ;
| return 0;
| }

それはstage1のtarget-libgccのconfig.logなの？

いや、makeする前のconfigureのログだと思う。
>>983のエラーの後にfor more detail see cofig.logとか何とか書いてあったので見てみたわけです。

stage1-gcc/cc1 --help
とかやって、コンパイラ本体が動くか確認してみては？

>>995
すまん、それはそのまま
% stage1-gcc/cc1 --help
って打ち込めって事で合ってる？

もうだめかも分からんね

エラーをエラーと見抜けないと(gccを使うのは)難しい

999

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。