スレッド: [cppll:12883] gcc環境でのリンク高速化

森野です。

gcc環境で、久しぶりにテンプレートごりごりのC++プログラムをコンパイルし
ていたのですが、リンクが異常に重いことに気づきました。

かなわんなぁ...と思い、ソースをあたったところ、比較的簡単に改善できま
した。
手元のプログラムでは、リンクに2分かかるプログラムが、15秒程度でリンク
できるようになりました。ほぼ90%の高速化。(^^

パッチを作ったので、おいておきます。
# http://akaxiso.sourceforge.jp/elf.c.diff.gz
# binutils/bfd/elf.cへのパッチです。

本パッチ、FC5のbinutils-2.16.91.0.6-5を元に作成しましたが、GNUの最新
バージョンでも使用可能です。

このパッチは、多くのシンボルを持つオブジェクトファイルやスタティックラ
イブラリをリンクする際に効果があるようです。
C++で言えば、テンプレートを多用したプログラムなど、多くの関数/クラス/
メンバがテンプレートの実体化により生成されているため、シンボルの突合せ
量が多くなり、リンク時間が異常に長くなっているようです。

リンカへのパッチなので、C++(g++)に限らず、gcc/gcjのリンクが激しく重く
なる環境に効果があるはずです。

# 落ち着いたら、ご本家にパッチ投げとこ...(^^

oki です。

森野さん、ちーす！

> gcc環境で、久しぶりにテンプレートごりごりのC++プログラムをコンパイルし
> ていたのですが、リンクが異常に重いことに気づきました。
>
> かなわんなぁ...と思い、ソースをあたったところ、比較的簡単に改善できま
> した。
> 手元のプログラムでは、リンクに2分かかるプログラムが、15秒程度でリンク
> できるようになりました。ほぼ90%の高速化。(^^
>
> パッチを作ったので、おいておきます。
> # http://akaxiso.sourceforge.jp/elf.c.diff.gz
> # binutils/bfd/elf.cへのパッチです。
>
　赤紫蘇のページを久しぶりに見たら、プロファイラを
使って速度を改善した旨の事が書かれてあったので、
きっと森野さんのマイブームは、プロファイラで分析くんに
違いない…と、勝手に想像しとります。

　にしても、90%の高速化に繋がるパートが、たった
これっぽちのパッチに集約されているなんて、プロファイラを
使った事なかったけど（実行速度に困る事って無いし、
そんなに効果があるとも思えないと考えてた）、ちょっと
考え直しちゃいますね。

＃あ、プロファイラを使った事を前提に会話しちゃってるよ…
＃使ってなかったら、どうしよ(^^;

森野です。

OKI Miyuki wrote:
>   oki です。
> 森野さん、ちーす！
おひさでーす。ちーすちーす。(^^

> 　にしても、90%の高速化に繋がるパートが、たった
> これっぽちのパッチに集約されているなんて、
今回は、極端に効きました。(^^
gnu-ld(リンカ)の内部でシンボル名のqsortかましている部分があったんです
が、その部分にボトルネックあり。

普通にプログラムをリンクする場合、ほとんど時間がかからない部分のようで
す。僕が使っている限り、問題になったことはありません。
今回の事例では、シンボル数、セクション数の増加とともに、急激に処理時間
が増えたんでしょう。
どこぞの方で、リンクが異常に重い症状（ldが延々とうごいている）に悩んで
いる方がおられれば、お役にたてるかも。

> プロファイラを使った事なかったけど（実行速度に困る事って無いし、
> そんなに効果があるとも思えないと考えてた）、ちょっと
> 考え直しちゃいますね。
> ＃あ、プロファイラを使った事を前提に会話しちゃってるよ…
> ＃使ってなかったら、どうしよ(^^;
いーえ、okiさんっ。
ごそーぞーのとーり、gccのプロファイラを使いました。
ただし、今回、プロファイラの結果のみではボトルネックが特定できず。
# 呼び出し先のライブラリ中の実行時間なんかがわからないんです。

そこで、モンテカルロ法的プロファイル(と勝手に命名)を行いました。
デバッガ上で実行して、適当にブレーク。どこの関数で停止するかを調べま
す。そして、何度か試行します。
結果、ボトルネックが判明して、件のパッチとなりました。

多分、プロファイルをかけないと困るプログラムって少ないと思います。
けど「なぜか遅い」というときには、ききます。

<余談>
このパッチ、赤紫蘇君のリンクの高速化のために作りました。
昔はリンクがこんなに遅くなかったんだもんっ。
バイナリ一本リンクするのに２分待つのやだもんっ。(^^;;

C++のライブラリ作るのにCのパッチ作ってるってのも...不思議な世界に入っ
てきちゃいました。
僕的には、"オムレツ"作るために、"ケチャップ用のトマト"作ってる気分で
す。卵はあるんだってば。ないのはケチャップなのなのー。
</余談>

　okiです。

> おひさでーす。ちーすちーす。(^^
はいー、おひさです。

> ただし、今回、プロファイラの結果のみではボトルネックが特定できず。
> # 呼び出し先のライブラリ中の実行時間なんかがわからないんです。

　使ったことないので勉強になります…。メモメモ…

> そこで、モンテカルロ法的プロファイル(と勝手に命名)を行いました。
> デバッガ上で実行して、適当にブレーク。どこの関数で停止するかを調べま
> す。そして、何度か試行します。
> 結果、ボトルネックが判明して、件のパッチとなりました。

　おおーっ、結構力技というか、デバッグで悪いところ探しに
近いものがあるのでしょうか？

> <余談>
> このパッチ、赤紫蘇君のリンクの高速化のために作りました。
> 昔はリンクがこんなに遅くなかったんだもんっ。
> バイナリ一本リンクするのに２分待つのやだもんっ。(^^;;
>
　私も最近の悩みは、コンパイル時間が膨大なところですねー。
コンパイル時間とかも考慮してシステム（パッケージ）の構成を
考えなきゃいかんなーと思ってます。逆に、どのように分離でけるか？
ってところなのかも…。

> C++のライブラリ作るのにCのパッチ作ってるってのも...不思議な世界に入っ
> てきちゃいました。
> 僕的には、"オムレツ"作るために、"ケチャップ用のトマト"作ってる気分で
> す。卵はあるんだってば。ないのはケチャップなのなのー。
> </余談>

　あーそれ、すげーわかります。
オムレツを作ろう思ったら、ケチャップが必要なんだけど、
ケチャップも無くて、じゃーケチャップをこさえようと思ったら
トマトも無かった！
　トマトからかよ！って、突っ込み入れるパターンですね。
で、よくよく見たら、ハーブも無かった…orz

森野です。

OKI Miyuki wrote:
> 　okiです。
はいなっ。

>> ただし、今回、プロファイラの結果のみではボトルネックが特定できず。
>> # 呼び出し先のライブラリ中の実行時間なんかがわからないんです。
> 　使ったことないので勉強になります…。メモメモ…
gccで使うgprofはこういう動作です。
ほかのプロファイラはどうなんしょうか。まじめに使ったことないんです。

> 　私も最近の悩みは、コンパイル時間が膨大なところですねー。
インクルードファイルを最適化するだけでも結構早くはなるんですけど、その
ために使う時間が結構な量になっちゃうんですよね。
変更があると、だんだんコンパイルが遅くなっていくんです。

<余談>
> 　トマトからかよ！って、突っ込み入れるパターンですね。
> で、よくよく見たら、ハーブも無かった…orz
んはは。(^^
で、よーく考えてみたら、ケチャップもハーブも必要ないんじゃないかと思い
出して..."オムレツ"作るはずが、"ゆで卵"になっちゃった。
確かに、おなかはいっぱいになるんですー。
だけど、こんなはずじゃなかったんですー。
"ゆで卵"でも足りるんだけど、ホントに食べたかったのは"オムレツ"なのっ。
</余談>

Message-Id: <46281795.7090105@d1.dion.ne.jp>
 Date:       Fri, 20 Apr 2007 10:29:57 +0900
 From:       "Shin'ya MORINO" <smorino@...>
 Subject:    [cppll:12889] Re: gcc環境でのリンク高速化

 | >> ただし、今回、プロファイラの結果のみではボトルネックが特定できず。
 | >> # 呼び出し先のライブラリ中の実行時間なんかがわからないんです。
 | > 　使ったことないので勉強になります…。メモメモ…
 | gccで使うgprofはこういう動作です。

ライブラリをつくるときにも gcc -pg をつけていれば
ライブラリ内のプロファイルもとれるとおもいます。

--
鯉江英隆 <hide@...>

森野です。

KOIE Hidetaka (鯉江英隆) wrote:
>   | gccで使うgprofはこういう動作です。
>
> ライブラリをつくるときにも gcc -pg をつけていれば
> ライブラリ内のプロファイルもとれるとおもいます。
すんません。
おっしゃるとおりです。

# 今回、ライブラリ内部というのが、glibcで、これをgcc -pgで
# コンパイルしなおす気力がなかったのです。(^^;

Message-Id: <20070420.103908.164110740.koie@sakura.suri.co.jp>
 Date:       Fri, 20 Apr 2007 10:39:08 +0900 (JST)
 From:       KOIE Hidetaka (鯉江英隆) <hide@...>
 Subject:    [cppll:12890] Re: gcc環境でのリンク高速化

 |   | >> ただし、今回、プロファイラの結果のみではボトルネックが特定できず。
 |   | >> # 呼び出し先のライブラリ中の実行時間なんかがわからないんです。
 |   | > 　使ったことないので勉強になります…。メモメモ…
 |   | gccで使うgprofはこういう動作です。
 |
 | ライブラリをつくるときにも gcc -pg をつけていれば
 | ライブラリ内のプロファイルもとれるとおもいます。

すみません、ぼけてました。とれませんでした。
理由は(想像ですが)
ダイナミックリンクされているライブラリは
実行時に関数のアドレスが決定されるので
gprofからするとアドレスと関数の対応がわからなくて
どの関数が呼ばれたか分らないということではないかとおもいます。

--
鯉江英隆 <hide@...>

森野です。

KOIE Hidetaka (鯉江英隆) wrote:
> ダイナミックリンクされているライブラリは
> 実行時に関数のアドレスが決定されるので
> gprofからするとアドレスと関数の対応がわからなくて
> どの関数が呼ばれたか分らないということではないかとおもいます。

共有オブジェクトについては、僕も確認していません。

だけど、glibcを含むLinux上のライブラリ、ほとんど完全に、staticリンクで
きます。共有オブジェクトへの呼び出しのオーバーヘッドを無視することにな
りますが、プロファイル可能です。

kosakiです

共有ライブラリはOProfileつかっちゃったほうが
早いんじゃないかしら？

Linux限定だけどね


> 森野です。
>
> KOIE Hidetaka (鯉江英隆) wrote:
> > ダイナミックリンクされているライブラリは
> > 実行時に関数のアドレスが決定されるので
> > gprofからするとアドレスと関数の対応がわからなくて
> > どの関数が呼ばれたか分らないということではないかとおもいます。
>
> 共有オブジェクトについては、僕も確認していません。
>
> だけど、glibcを含むLinux上のライブラリ、ほとんど完全に、staticリンクで
> きます。共有オブジェクトへの呼び出しのオーバーヘッドを無視することにな
> りますが、プロファイル可能です。
>
>
>
>
> --[PR]------------------------------------------------------------------
> 　☆━┳━┳━┳━┳━┳━┳━┳━┳━┳━┳━☆　 現金１０万円！
> 　┃冬┃の┃Ｂ┃Ｉ┃Ｇ┃キ┃ャ┃ン┃ペ┃ー┃ン┃★—★—★—★—★
> 　☆━┻━┻━┻━┻━┻━┻━┻━┻━┻━┻━☆　 豪華賞品満載！
> 　　　　　　　合計２０４名様にプレゼント！！！
>  http://popot.jp/lbu/member/RegistForm1View.do?ref=6000106
> ------------------------------------------------------------------[PR]--
> ■GMO INTERNET GROUP■ GMO INTERNET www.gmo.jp
>

--
kosaki <m-kosaki@...>

森野です。

kosaki wrote:
> kosakiです
こんちわ。

> 共有ライブラリはOProfileつかっちゃったほうが
> 早いんじゃないかしら？
...ですね。(^^;;
# こんど機会があればやってみます。