コンパイルされたLinuxディストリビューション/バイナリLinuxディストリビューション/パッケージのパフォーマンスの違い

私はインターネットでたくさん検索していましたが、正確な答えを見つけることができませんでした。

Gentoo（またはFreeBSD）のようなディストリビューションがあります。これはバイナリではなく、パッケージ（ポート）のソースコードのみが付属しています。

ディストリビューションの大部分は、バイナリバックグラウンド（debianなど）を使用しています。

最初の質問：コンパイルされたパッケージからどれくらいの速度の増加が期待できますか？apacheやmysqlのような実際のパッケージからどれくらいの速度の増加を得ることができますか？すなわち、毎秒のクエリですか？

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はいくつかの最適化を提供していますが、より多くの経営苦境、減少マインドシェア、減少ベンダーとドライバのサポート、安定性の問題、への扉を開くことが嘲笑し、潜在的なセキュリティ上の懸念。

高頻度の金融取引環境でGentooベースのサーバーを管理しました。Gentooではパフォーマンスに若干のメリットがありましたが、それでもRed HatとCentOSに移行しました。Gentooの紙上の利点は、よりスマートなハードウェアの選択、より良いサーバーメーカー/ハードウェア統合サポート、Red Hatエンジニアによるよりスマートなパッチ適用、カーネルバイパスなどの難解なテクノロジーによって簡単に克服されました...

一般的なアプリケーションスタック（LAMP）の効率が問題となる場合は、サーバーハードウェア（CPUタイプ、RAMレイアウト）、ネットワークインフラストラクチャ、監視システムを最適化し、システムのボトルネックを特定できるようにしてください。この道を行く。

今、パフォーマンスの制限に達している？

作成されたすべてのポイントはもちろん正しいです。特に最近のバージョンのGCCでは、5％-15％のパフォーマンスの向上は達成できないという考えで、CPUアーキテクチャと、ターゲットとして使用されるベースラインにどれだけ近いかによって問題を取りたいと思います。バイナリ配布用。GCC -march = nativeは、ISA拡張機能の使用に加えて、L1およびL2キャッシュ/ラインサイズも最適化します。（-CPUの）正しく整列されたコードは、特に-fltoが使用されている場合にはるかに高速になるため、コンパイラは考慮に入れる必要があるすべてのものを知ることができます。[残念ながら、一部のパッケージは現在LTOで壊れています]

さらに、march = nativeとLTOに加えて、-Ofastを使用して選択パッケージをコンパイルすると、大きな違いが生じます。

将来、GCC Graphiteインフラストラクチャが安定すると、さらに大きな利益が得られる可能性があります。

それはあなたがあなたのシステムに何を望んでいるかに依存します、そして本当にここには3つの考え方があります（そしてこれはハードウェアとソフトウェアの両方に当てはまります）

まず、SFの大部分の人々が主流になっているのは、自分が知っているものが機能すること、サポートが必要であること、そして今すぐ欲しいことです。この場合、redhatベースのシステムを使用します（RHELは優れたサポートを提供し、centosは十分にテストされたRHELディストリビューションのコミュニティ再構築です）。ただし、最新かつ最高のものを取得することはできません。多くの場合、これはハードウェアにも当てはまります。

2つ目は、「道路の中間」の視点です。これは、中間地点であり、ubuntuのようなものになります。新しいパッケージ（完全に安定した安定性をわずかに犠牲にして）、インストーラー、および素晴らしいものが必要です。

場合によっては、人々はトラブルに遭遇しますが、新しいパッケージがあり、物事は合理的にテストされます Ubuntuには多くの憎しみがありますが、セットアップの容易さと合理的に新しいパッケージとの間の良い妥協点です。Debianはおそらくもう少し保守的な選択でしょう。最近では、すぐに使用できる低レイテンシのカーネルでUbuntuをセットアップすることもできます。私はubuntuとdebianが私にとってはうまくいくと感じる傾向がありますが、ymmvです。facebookやgoogleのような多くのサーバーを展開する多くの場所がこのオプションを選択します。

最後に、ソースベースのディストリビューションがあります。ほとんどの場合の初期設定は、後部の完全な痛みです。カーネルのセットアップを間違えていますか？おっと、再コンパイルに数時間かかります。インストーラーも取得しません-n00bsの場合。多くの場合、最先端のアプリケーションと、必要に応じてコンパイルするオプション（速度やメモリの使用などの最適化を選択できることを含む）、およびローリングリリースがあります。非常に具体的で難解なニーズがある場合は、gentooが最適です。数十のシステムを展開し、それを自動化する必要がある場合は...幸運を祈ります。ソースベースのディストリビューションは、単にスケーリングもしません。パッケージベースのディストリビューションIMOと同じレベルでは、かなりの柔軟性、*いくらか**余分な速度が得られますが、保守性はありません。あなたはしているではありませんおそらく15％の余分な速度を得るために、あなたはおそらく、あなたのハードウェアのためにチューニングするためにコンパイルフラグをしようと無駄時間を終わるだろう、とあなたの混乱の何かアップし、どのようなワークアウトの時間を費やしている場合、正確に失敗しました。

BSDは、OSの別個のファミリーです。一部の人々は彼らに誓っています（少なくとも1つのコミュニケーションルームの常連は​​freebsdユーザーです）。異なるBSDは異なるフォーカスを持っています。たとえば、openbsdはセキュリティに取り付かれ、freebsdは「主流」です。Linuxがサポートするのと同じ種類のハードウェアサポートを持たない場合もありますが、それはかなりの数の要因に依存します。