GCC 4.4リリース 23
ストーリー by soara
更に磨きをかけました 部門より
更に磨きをかけました 部門より
hylom 曰く、
4月21日、GCC 4.4.0がリリースされた(マイコミジャーナル記事)。GCC 4.4.0での変更点や新機能、バグフィックスなどはChanges, New Features, and Fixesに挙げられている。
個人的に気になるのがGraphiteブランチの取り込みによる最適化の強化。コード中の多重ループの個所において、ループの順序を入れ替えることによってメモリアクセスの高速化などが期待できるようだ。また、GCC 4.2からOpenMPがサポートされているが、4.4.0からは最新のOpenMP 3.0が新たにサポートされるようになっている。
ポーティングガイドによると、プリプロセッサの条件評価も常に行われるように修正されたとのこと。
教育者泣かせ (スコア:3, おもしろおかしい)
> コード中の多重ループの個所において、ループの順序を入れ替える
> ことによってメモリアクセスの高速化などが期待できるようだ。
「ね、こういう順序でアクセスするようにコード書かなきゃ遅くなるでしょ」
っていう実例見せて授業してる私の立場は？
Re:教育者泣かせ (スコア:4, おもしろおかしい)
そして、授業の最後に最適化オプションの指定で自動でやってくれる事を伝え、
一言、「昔は、よかった。」といえばOKです。
Re: (スコア:0)
Re:教育者泣かせ (スコア:1, すばらしい洞察)
おもしろおかしいモデはおかしい。
完璧な回答だと思います。
いやいや、よく嫁。
「今は、よくなった」じゃなく
「昔は、よかった」だぞ。
Re:教育者泣かせ (スコア:1)
Re:教育者泣かせ (スコア:4, 興味深い)
まだ大学にsunosが山のようにあったころ。
課題をだしたら一部の人がlinux1.0やpanix(NEC PC98で動くUNIX)でgccで-Oしてきたのですが、運悪く-Oのバグに遭遇したようで他の人と実行結果が異なるレポートをだしてきた人が何名かいました。
アセンブリレベルで「私はこうやったからこうなった。コンパイラのバグだ」ってレポートに記載した強者が一人いました。
彼は6809の機械語を話せる強者でした。
教育現場なんですから、コンパイラが頑張ったのなら「なぜコンパイラはこんなに頑張って最適化ができるのか」を考えさせ、逆にコンパイラがタコなら「なぜコンパイラはこんなにタコなのか」を考えさせればよいのではないでしょうか。
まぁその水準に達する学生さんがどのくらいいるかは......
Re:教育者泣かせ (スコア:3, 興味深い)
Re: (スコア:0)
「考えさせ」るとなると、
学生さんの能力もさることながら、
そこまでうまく導く教師側の能力も重要になってきますね。
「考えてみよう」などと口先でいっただけでは、
実際考えてくれるのは一部の先進的な学生だけ、下手したらこの教室には一人も居ない、なんてなことになりますorz
うまくうまく誘導する(ファシリテートする？9ことが出来れば、
彼らの能力も5割増しになってくれたりするのでしょう、とは思います。
ただ、少なくとも私にはそれをどうやればいいのかはさっぱり判らなくて…
＃教室じゃなく職場での後輩の「指導」について同じような悩みを持つ低能"教育"者なのでAC
＃後輩の能力があがれば会社全体の生産性にも当然響くので、とても重要なことだと思うんだがなあ…
Re:教育者泣かせ (スコア:3, 興味深い)
レジスタ割り付けを重視しすぎて、アドレスを増やしながらアクセスすれば良いものを、むちゃくちゃな順でアクセスして、バースト転送、キャッシュラインフィルの特性を台無しにしていた。少しは改善されたのかな。
Re:教育者泣かせ (スコア:1)
GCC 4.4.0ではこうやって高速化してるよって教えれば良いだけでは。
Re:教育者泣かせ (スコア:1, おもしろおかしい)
>っていう実例見せて授業してる私の立場は？
objdump -S の結果(gcc -g でコンパイルが必要)、ソースコードとの対比が
とれない事をみせて、コンパイラにまけとるぞと教える。
Re:教育者泣かせ (スコア:1)
Re:教育者泣かせ (スコア:3, 興味深い)
組み込み系だと、本当にコンパイラのバグで最適化をすると動かなくなることが、
(PC上のプログラミングと比べると)結構発生します。
なので、
ではなく、「組み込み系だからこそ」かと。
まあ普通は、最適化オプションを切るよりは、
コンパイラのバグを避けるような記述に書き換えるんですが。
Re:教育者泣かせ (スコア:1, 興味深い)
> (PC上のプログラミングと比べると)結構発生します。
8-16bit時代には頻繁にあったのは事実だけど、それでもバグありコードが最適化を切るとたまたま動いていたということのほうが多かったと思うよ。
なので、なんでもかんでもコンパイラのせいにするの態度はどうかなあ。
Re:教育者泣かせ (スコア:1, 参考になる)
元コメの者ではありませんが具体例を挙げてみると、ルネサスの Mxx 利用のプロジェクトで、
C コンパイラが吐いた asm レベルで問題があったので、チーム内で参照する書いてはいけない
イディオム集とコードレビューで対応していました。
組み込みだと、怪しい振る舞いのコンパイラでも管理できるならそのまま使うので、
リビジョンアップもしないでプロジェクトを回すことは珍しくない。
なお、プロジェクト終わってから最新版に上げたら、修正されていたことは確認しました。
Re:教育者泣かせ (スコア:3, 興味深い)
gccの最適化のおかげで動かなくなった事例 [srad.jp]。#598754 [srad.jp]のリンク先にあるコミットログには「GCCのアグレッシブな最適化のおかげで壊れた」みたいなことが書いてあります。
むしろブートローダや組み込みのような制約の多い環境の方が、最適化の負の面(メモリ使用量の増加とか)の影響を受けやすいんじゃないですかね。
Re:教育者泣かせ (スコア:1)
今時はマシになった気がするけど、デバイスバシバシ叩く物だと下手な最適化するとご丁寧に叩く順番を変えたりキャッシュに入れたままで後の処理をしようとしてくれるものだから最適化やれませんよ。
# そのために__volatile__とか#pragmaがあるんだろ！と言われればそれまでですが。
そういうのは局地的に最適化禁止してやればいいのとどうしょうもない所はインラインアセンブラで対処すればいいんでしょうけど、コンパイラの挙動をきちんと把握するのは骨が折れる。と言うかコーディング規則の人がそういうあたり気をつかうのを嫌って一律にあーだこーだと言い出すから(以下自粛
# しかし、どれが使って大丈夫かくらいは覚えといて損はないのかも
Re: (スコア:0)
> ご丁寧に叩く順番を変えたりキャッシュに入れたままで後の処理をしようとしてくれるものだから
これが言語仕様に従った正しい動作ですから、ちゃんとvolatile入れて式の評価順序は手で強制してくださあい。
そうしなければ「間違ったプログラムがたまたま正しく動く」状態のままです。
Re:教育者泣かせ (スコア:1)
大昔は、ループ処理にしないで展開してベタ書きのほうが速かったんですが、
CPUが命令キャッシュなんてものを積むようになって、ループで書いてキャッ
シュに乗るようにしたほうが速くなりました。
例示がフルすぎてピンとこないヒトが多いかもしれませんが(^^;
特定の時代におけるテクニックは、その後のデバイス/ツール(コンパイラ等)
の進化で無用のものとなるんでしょうね。
と、考えると、教えるべきは『本当の根幹』部分と、それを『便利にする仕組
みたち』で、それらを理解したうえで、現状ではこんなテクニックがあります
よ、とするのがいいんじゃないでしょうか。
＃ 根っこがちゃんと分かっていれば、新しく便利にする仕組みが追加されて
＃ も、それに対するテクニックはおのずと付いてくるんじゃなかろうか、と
♪潔くカッコよく生きてゆこう
Re: (スコア:0)
そのレベルの教育をするのにGCCを使ってるのが驚きなんですが
こまめなギアコントロールで燃費向上って話をしながらAT車に乗るような感じ
Re: (スコア:0)
> そのレベルの教育をするのにGCCを使ってるのが驚きなんですが
あなたならどのコンパイラを使って教えるんですか?
Re: (スコア:0)
元ACの人じゃないけど
LSI C-86 試食版とか
Borland C++ Compiler 5.5 とかでは？
Re: (スコア:0)
GCCを使うならコンパイラは最適化をしてくれるという教え方をするべきだと思うけど
そうでなくても、単に最適化オプション切ればいいだけだし、元のコメントは意味不明すぎる