アカウント名:
パスワード:
ビルドプロセスのボトルネックはプロセッサかメモリかストレージか
私の場合はストレージでした
一般論として,LinuxのカーネルソースはC言語でシンプルに書かれているので,コンパイラはメモリをあまり必要としません.またコードの大半は,デバイスドライバ(Linux用語でいうモジュール)なのでソースコード間の依存関係が少ないです.そのためコア数が多いCPUでは,容易に並列ビルドできます.
しかしカーネルコードは比較的小さいファイルが多いため,ビルドすると小さい中間ファイルがたくさんできます結果,I/O,ファイルシステムやその背後にあるストレージがボトルネックになります.
私の環境(intelで16コア.メモリは32GB)でも,perf コマンドで分析したら,ストレージがボトルネックになっていました.HDDは当然ですが,安物のSSDでもボトルネックになります.
あとC++ & boost で書いている別ソースコードだと,メモリ消費量が激しく,1コアあたり1.5GBぐらいは必要になります.
ということで,私が調べた感じではC/C++での開発用PCだと,S-ATA接続のSSDや,コア数*2GB以下のメモリを使っていると,それがボトルネックになりCPUの稼働率が低下します.
あとファイルシステムはベンチマークしたら判りますが,なぜか ext4 が最速になります.別ファイルシステム,例えばF2FSはファイルシステムレベルでボトルネック解消を目指してるはずですが,C/C++のビルドではext4の方が早いです.もしかしたら F2FSは ext4 ほどにはチューニングできてないのかも知れません.あまり詳しくみてないですが,ベンチマーク上は ext4が最速です.
ということで,現時点で開発用のPCを組むなら- メモリはコア数*2GB以上- ストレージは NVMe- ファイルシステムは ext4が良いと私は考えています.
# あと,Spectra / Meltdown 対策をoffにするともっと早くなります.
tmpfs 上でコンパイル && gcc に -pipe オプションてのは効きませんか?
QEMUとかFFMPEGとかJavaScript製PCエミュレータとかTCCとか作ってるヤベー人が作ったTCCBOOT https://bellard.org/tcc/tccboot.html [bellard.org] とかだとブートローダとしてその場でカーネルをビルドしているのに、Pen4でもたった15秒でビルドが終わるそうな。
最適化が弱いから速度面の検証とかは期待できないけど、未だにビルド速度で悩むようなら機能面での検証はTCCBOOTみたいなので済ますほうが生産性良かったりして。
一つじゃないだろうね。
ボトルネックは一つだろ
ボトルネックを解消したら新たなボトルネックが見つかるまでが前提。さらにallmodconfigのビルドというならやっぱり一つじゃないだろ。
>ボトルネックを解消したら新たなボトルネックが見つかるまでが前提。なんやねんその屁理屈。極限まで解消すれば最終的にビルド速度ゼロやん。
そうはならないでしょう。これ以上高速化できなくなったらボトルネック無しだし。
速度がゼロにならない限りそこがボトルネックじゃね?きみが満足できる速度になったらボトルネックとは呼ばなくなるってもんではないですよ。
最後のボトルネックは光速度ですかね、だれか突破してくれないかなw
最終的に、臨んだ操作を「人が行う」前に完了させてくれればボトルネックなし。#この議論がボトルネックだ(笑
ボトルネックってそこが細い(遅い)せいで他の部分は余裕があるのにスループットが上がらない状態なんだから、バランス良くどこも足を引っ張らない状態なら、爆速じゃなくてもボトルネックはないんじゃないの?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
ボトルネックは? (スコア:0)
ビルドプロセスのボトルネックはプロセッサかメモリかストレージか
Re:ボトルネックは? (スコア:5, 参考になる)
私の場合はストレージでした
一般論として,LinuxのカーネルソースはC言語でシンプルに書かれているので,コンパイラはメモリをあまり必要としません.
またコードの大半は,デバイスドライバ(Linux用語でいうモジュール)なのでソースコード間の依存関係が少ないです.
そのためコア数が多いCPUでは,容易に並列ビルドできます.
しかしカーネルコードは比較的小さいファイルが多いため,ビルドすると小さい中間ファイルがたくさんできます
結果,I/O,ファイルシステムやその背後にあるストレージがボトルネックになります.
私の環境(intelで16コア.メモリは32GB)でも,perf コマンドで分析したら,ストレージがボトルネックになっていました.
HDDは当然ですが,安物のSSDでもボトルネックになります.
あとC++ & boost で書いている別ソースコードだと,メモリ消費量が激しく,1コアあたり1.5GBぐらいは必要になります.
ということで,私が調べた感じでは
C/C++での開発用PCだと,S-ATA接続のSSDや,コア数*2GB以下のメモリを使っていると,それがボトルネックになりCPUの稼働率が低下します.
あとファイルシステムはベンチマークしたら判りますが,なぜか ext4 が最速になります.
別ファイルシステム,例えばF2FSはファイルシステムレベルでボトルネック解消を目指してるはずですが,C/C++のビルドではext4の方が早いです.
もしかしたら F2FSは ext4 ほどにはチューニングできてないのかも知れません.あまり詳しくみてないですが,ベンチマーク上は ext4が最速です.
ということで,現時点で開発用のPCを組むなら
- メモリはコア数*2GB以上
- ストレージは NVMe
- ファイルシステムは ext4
が良いと私は考えています.
# あと,Spectra / Meltdown 対策をoffにするともっと早くなります.
Re:ボトルネックは? (スコア:1)
tmpfs 上でコンパイル && gcc に -pipe オプションてのは効きませんか?
Re: (スコア:0)
QEMUとかFFMPEGとかJavaScript製PCエミュレータとかTCCとか作ってるヤベー人が作った
TCCBOOT https://bellard.org/tcc/tccboot.html [bellard.org] とかだと
ブートローダとしてその場でカーネルをビルドしているのに、
Pen4でもたった15秒でビルドが終わるそうな。
最適化が弱いから速度面の検証とかは期待できないけど、
未だにビルド速度で悩むようなら機能面での検証はTCCBOOTみたいなので済ますほうが生産性良かったりして。
Re: (スコア:0)
一つじゃないだろうね。
Re: (スコア:0)
ボトルネックは一つだろ
Re: (スコア:0)
ボトルネックを解消したら新たなボトルネックが見つかるまでが前提。
さらにallmodconfigのビルドというならやっぱり一つじゃないだろ。
Re: (スコア:0)
>ボトルネックを解消したら新たなボトルネックが見つかるまでが前提。
なんやねんその屁理屈。
極限まで解消すれば最終的にビルド速度ゼロやん。
Re: (スコア:0)
そうはならないでしょう。
これ以上高速化できなくなったらボトルネック無しだし。
Re: (スコア:0)
速度がゼロにならない限りそこがボトルネックじゃね?
きみが満足できる速度になったらボトルネックとは呼ばなくなるってもんではないですよ。
Re:ボトルネックは? (スコア:1)
最後のボトルネックは光速度ですかね、だれか突破してくれないかなw
Re: (スコア:0)
最終的に、臨んだ操作を「人が行う」前に完了させてくれればボトルネックなし。
#この議論がボトルネックだ(笑
Re: (スコア:0)
ボトルネックってそこが細い(遅い)せいで他の部分は余裕があるのにスループットが上がらない状態なんだから、
バランス良くどこも足を引っ張らない状態なら、爆速じゃなくてもボトルネックはないんじゃないの?