コンパイル済みとバイナリのLinuxディストリビューション/パッケージのパフォーマンスの違い
インターネットでたくさん検索していて、正確な答えが見つかりませんでした。
Gentoo（またはFreeBSD）のようなディストリビューションがあり、バイナリは含まれていませんが、パッケージ（ポート）のソースコードのみが含まれています。
ディストリビューションの大部分は、バイナリの裏付け（debianなど）を使用しています。
最初の質問：コンパイルされたパッケージからどのくらいの速度の向上が期待できますか？ Apacheやmysqlのような実際のパッケージからどれだけの速度向上が得られますか？つまり、1秒あたりのクエリ数？
2番目の質問：バイナリパッケージは、最初のAMD 64ビットCPUの後に導入されたCPU命令を使用しないことを意味しますか？ 32ビットパッケージでは、パッケージが386で実行され、基本的に最新のCPU命令のほとんどを使用しないことを意味しますか？
追加情報：
- 私はデスクトップではなく、サーバー環境について話している。
- コンパイル時間は気にしない
- サーバーが多いので、15％以上の速度向上はソースコードパッケージを使用する価値があります
- フレームウォーズをしないでください。
パフォーマンスの違いはほとんどすべての場合で最小限であり、価値はありません。 （gentooのbindistシステムが許可するように、独自のバイナリパッケージをローリングしながら）ソースディストリビューションを使用する正当な理由は次のとおりです。
- 独自のカスタムパッチを展開する
- カーネルを簡単にカスタマイズする
- 独自のアップデートをパッケージ化する
これらのことを何もしていないのであれば、ソース配布は必要ありません。個人で使用する場合、バイナリの互換性をあまり気にすることなく、必要に応じて段階的にアップグレードできるため、非常に便利です。これは、エンタープライズ環境でよく見られる問題ではありません。
独自のRPMパッケージなどを作成することにより、バイナリディストリビューションでもこれらのことを実行できることは注目に値します。管理オーバーヘッドも同様です。
ソースからコンパイルしても、基本的に15％の速度向上は見られません。合理的なケースでは5％と見積もるのは嫌です。ソースからコンパイルすると、いくつかのことがわかります。
- 好みのコンパイラバージョンを使用できます
- AESNIやAVXなどのバイナリディストリビューションのパッケージでは使用されないISA拡張機能から命令を生成するようにコンパイラーに指示できます
ただし、コンパイラが実際にこれらを生成することは非常にまれであり、アプリケーション全体のパフォーマンスを考慮した場合、それらを使用することによる全体的な節約は一般に非常にわずかです。 RAMアクセス（およびレイテンシ））やディスクとデバイスのレイテンシのようなものははるかに大きな要因であり、実際にそこから始める必要があります。
比較的最近のIntelコアi7またはi5でのみ実行されるカスタムコンパイルの恩恵を受ける可能性があるアプリケーションには、多数のベクトル計算を行うアプリケーションと、多数のAES暗号化および復号化を行うアプリケーションが含まれます。たくさんの乱数が必要です。 Intel DRBGを使用する場合は、現在、これも行う必要があります。
これらのいずれにも当てはまらない場合は、そこにあるdebianまたはRed Hatベースのディストリビューションに非常に満足し、メンテナンスのオーバーヘッドが大幅に少なくなります。
短い回答...多くの大規模で速度/遅延に敏感なアプリケーションは、標準のLinuxディストリビューションで実行されます。 Red Hat、CentOS、Debian、Ubuntu ...ほとんどの場合、これらはすべてうまく機能します。ほとんどのメリットは、アプリケーションのチューニング、標準のカーネルとOSの最適化、およびインフラストラクチャから得られます。
Gentoo はいくつかの最適化を提供しますが、より多くの管理上の困難、マインドシェアの減少、ベンダーとドライバーのサポートの低下、安定性の問題への扉を開きます ridicule および潜在的なセキュリティ上の懸念。
私は、高頻度の金融取引環境でGentooベースのサーバーを管理しました。 Gentooではパフォーマンスに若干のメリットがありましたが、私はまだRed HatとCentOSに移動しました。 Gentooの紙面での利点は、よりスマートなハードウェア選択、より優れたサーバーメーカー/ハードウェア統合サポート、Red Hatエンジニアによるよりスマートなパッチ適用、および kernel bypass ...
一般的なアプリケーションスタック（LAMP）の効率が問題となる場合は、サーバーハードウェア（CPUタイプ、RAMレイアウト）、ネットワークインフラストラクチャ、監視を最適化していることを確認してください。このパスに進む前にシステムのボトルネックを特定できます。
パフォーマンスの制限に達していますか今？
行われたすべてのポイントはもちろん正しいです。特に、GCCの最新バージョンでは、5％〜15％のパフォーマンスの向上は達成不可能であるという考えでいくつか問題を取り上げたいと思います。これは、CPUアーキテクチャと、ターゲットとして使用されるベースラインにどれだけ近いかによって異なります。バイナリ配布用。 GCC -march = nativeは、ISA拡張の使用に加えて、L1およびL2キャッシュ/ラインサイズも最適化します。正しく整列されたコード（CPUの場合）は、特に-fltoコンパイラーが考慮に入れる必要があるすべてを知ることができるようにも使用されます[残念ながら、一部のパッケージは現在LTOで壊れています]
さらに、-Ofastを使用して選択パッケージをコンパイルすると、march = nativeおよびLTOに加えて、大きな違いが生じる可能性があります。
将来、GCCのグラファイトインフラストラクチャが安定すると、さらに大きな利益が得られる可能性があります。
それはあなたがあなたのシステムで何を望んでいるかに依存し、実際にここには3つの考え方があります（そしてこれはハードウェアとソフトウェアの両方に当てはまります）
まず、SFのほとんどの人々が主流になっている限り、あなたは知っていることを望みますwill機能します、あなたは望みますsupportそしてあなたはそれを望みますnow 。この場合、redhatベースのシステムを使用します（RHELは優れたサポートを提供し、centosは十分にテストされたRHELディストリビューションのコミュニティ再構築です）。しかし、あなたは最新で最高のものを手に入れません。多くの場合、これはハードウェアにも当てはまります。
もう1つは「道の真ん中」の視点であり、ubuntuのようなものを使用する中盤です。新しいパッケージが必要です（完全な安定性を少し犠牲にして）、インストーラー、そして良い点が必要です。
場合によっては問題が発生することもありますが、新しいパッケージがあり、問題は十分にテストされていますです。ここにはUbuntuへの憎悪がたくさんありますが、セットアップの容易さと適度に新しいパッケージとの間の妥協案です。 Debianはおそらく少し保守的な選択です。最近では、低レイテンシのカーネルをそのまま使用してUbuntuをセットアップすることもできます。私はubuntuとdebianがうまく機能する傾向がありますが、ymmvです。 lotを展開する多くの場所で、facebookやgoogleのようなサーバーがこのオプションに対応しています。
最後に、ソースベースのディストリビューションがあります。ほとんどの場合、初期設定は後部の全くの痛みです。カーネルの設定を間違えましたか？おっと、数時間かけて再コンパイルします。あなたはインストーラーも取得しません-n00bsのためのそれ。 Edgeアプリケーション、そして必要に応じてそれらをコンパイルするオプション（たとえば、速度やメモリ使用量の最適化を選択できることを含む）、およびローリングリリースがよくあります。非常に具体的で難解なニーズがある場合は、gentooが最適です。数十のシステムをロールアウトする必要があり、それを自動化したい場合は...幸運を祈ります。ソースベースのディストリビューションも同様にスケーリングしません。柔軟性が大幅に向上し、速度がいくらか向上しますが、パッケージベースの配布IMOと同じレベルの保守性は得られません。あなたはnot 15％余分な速度を得る可能性が高く、ハードウェアのコンパイルフラグを調整するために時間を浪費することになり、何かをめちゃくちゃにすると、何をすることに時間を費やすことになります正確にが失敗しました。
BSDは、OSの個別のfamilyです。一部の人々は彼らに誓います（少なくとも1つの通常のコミュニケーションルームはfreebsdユーザーです）。異なるBSDは異なる焦点を持っています。たとえば、openbsdはセキュリティにこだわっており、freebsdは「主流」のものです。場合によっては、Linuxがサポートするのと同じ種類のハードウェアサポートがある場合もありますが、それはかなりの数の要因に依存します。