web-dev-qa-db-ja.com

./configureを高速化することは可能ですか？

多くのCPUコアを備えたワークステーション（12など）でソフトウェアパッケージをコンパイルする場合、./configureはテストを1つずつ行い、make -jはgccおよびその他のコマンドを並列で実行します。

残りの11個のコアを低速で待機するためにほとんどの時間アイドル状態にしておくのは、リソースの無駄遣いだと思います./configure完了します。なぜ順次テストを行う必要があるのですか？各テストは互いに依存していますか？誤解されるかもしれませんが、大多数は独立しているようです。

さらに重要なことに、スピードアップする方法はありますか./configure？

編集：状況を説明するために、ここに GNU Coreutils の例があります

cd /dev/shm
rm -rf coreutils-8.9
tar -xzf coreutils-8.9.tar.gz
cd coreutils-8.9
time ./configure
time make -j24

結果：

# For `time ./configure`
real    4m39.662s
user    0m26.670s
sys     4m30.495s
# For `time make -j24`
real    0m42.085s
user    2m35.113s
sys     6m15.050s

coreutils-8.9 の場合、./configureはmakeの6倍の時間がかかります。 ./configureより少ないCPU時間を使用し（「user」と「sys」の時間を見てください）、並列化されていないため、はるかに長く（「実際」）かかります。テストを数回繰り返しましたが（関連するファイルはおそらくメモリキャッシュに残っています）、その時間は10％以内です。

linuxinstallationpackagesautoconf
32
netvope

Autoconfメーリングリストでこの問題について話し合ったのは、ほとんどの人が実際にはCPUコアを1つしか持っていなかった約10年前のことを思い出します。しかし、何も行われておらず、何も行われないと思います。 configureで並列処理のすべての依存関係を設定し、移植可能で堅牢な方法で設定することは非常に困難です。

特定のシナリオによっては、構成の実行を高速化する方法がいくつかある場合があります。例えば：

  • より高速なシェルを使用してください。たとえば、/bin/shとしてdashではなくbashを使用することを検討してください。 （注：Debianでは、dashにパッチが適用され、configureが使用しないようになっています。これを使用すると、多くのconfigureスクリプトが破損するためです。）
  • ビルドをリモートで（たとえば、sshを介して）実行すると、コンソールの出力がかなり遅くなる可能性があることがわかりました。 configure -qの呼び出しを検討してください。
  • 同じプロジェクトを繰り返しビルドする場合は、キャッシュファイルの使用を検討してください。 configure -Cに電話してください。詳細については、Autoconfのドキュメントを参照してください。
  • さまざまなプロジェクトを多数作成する場合は、サイトファイル（config.site）の使用を検討してください。再度、ドキュメントを参照してください。
  • 複数のプロジェクトを並行して構築します。
14
Peter Eisentraut

./configureスクリプトには多くの種類があります。開発者が./configureスクリプトを作成するのを支援するための人気のあるツール（ autconf それらの1つ）がありますが、すべての開発者がこれらのツールを使用する必要があるという規則はありません。ツールの場合、これらのスクリプトの構築方法にはさまざまなバリエーションがあります。

並行して実行できる一般的な./configureスクリプトを知りません。一般的なツールで作成されたスクリプトのほとんどは、少なくとも結果の一部またはすべてをキャッシュするため、（とにかく最初にmake cleanを実行せずに）再度実行すると、2回目ははるかに高速に実行されます。

それができなかったというわけではありません...しかし、たとえば、autoconfに取り組んでいる人々には、ほとんどの場合、そうする動機がほとんどないのではないかと思います。 パッケージ、構成フェーズは、実際のコンパイルおよびリンクフェーズに比べて非常に高速です。

4
Flimzy

ソースツリーを常駐させるためにramdriveを使用するのは賢明でしたが、2回考えてみてください-configureは何をしますか？ sourcetreeだけでなく、systemのライブラリやコンパイラなどの可用性をチェックすることで、その役割を果たします。この場合、アクセスの問題は次の場所にあることがあります。ディスクアクセス-たとえばSSDベースのルートファイルシステムがある場合は、はるかに高速に実行できます。

4
bubu

オンデマンドCPUガバナーを使用している場合は、パフォーマンスガバナーを使用してみてください。これは、i7およびa8-3850で40〜50％役立ちます。 q9300では大きな違いはありません。

クアッドコアCPUでは、

for cpu in `seq 0 3`; do Sudo cpufreq-set -g performance -c $cpu; done

（-rオプションは、コアごとにcpufreq-setを実行する必要がないようにする必要がありますが、私のコンピューターでは機能しません。）

ただし、キャッシュオプションはさらに役立ちます。

3
Dan Kegel

この場合、ハードドライブがボトルネックになります。ビルドを高速化するには、高速ドライブを備えたシステムでビルドします（読み取り：アクセス時間の短縮）。 SSDディスクについては多くの混乱がありますが、SSDディスクがコンパイル時間に良い影響を与えていないという批判がありました。つまり、SSDでのビルドは、まともなsataドライブでのビルドよりもそれほど速くはありませんでした。記事が2年前なので、どこで読んだか思い出せません。

とにかく...解凍してそこからビルドします。

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2
2
Ярослав Рахматуллин

シングルコアのパフォーマンスが（かなり）低いダースコアCPUがあるため、今日の質問はさらに関連性が高いかもしれません。継続的インテグレーション（CI）の自動ビルドは、コミットごとに多くのCPU時間/エネルギーを実際に浪費します。ブランチ間のホッピングと同じです。

だから、 https://gitlab.com/gnuwget/wget2/wikis/D​​eveloper-hints:-Increasing-speed-of-GNU-toolchain で物事をスピードアップすることについての私のヒントを確認/読んでください。

「なぜテストを順次実行する必要があるのですか？...」実際には、並行して実行できることがいくつかありますが、他のことは順次実行する必要があります。いくつかのことがビルド環境に依存します-そしてconfigureスクリプト自体はシステムに依存しません。バシズムすら含まれていないため、純粋なPOSIXシェルで動作します。

ポータブルソフトウェアを作成する場合、autotoolsのような他のビルドシステムはありません。しかし、（広い）移植性を気にしない場合は、autotoolsを避けてください-高速で十分なビルドツールがたくさんあります。

2
Tim Ruehsen rockdaboot