Windows用のgccであるMinGWを使用しています。私のプログラムには、複数のウィンドウ、2つの異なるメインスレッド、および重複するネットワークI/O用のスレッドプール内のいくつかのワーカースレッドが含まれます。
コンパイラを最適化しなくても完全に正常に動作します。
A）コンパイラの最適化も必要ですか？私のプログラムはすでに非常に高速です。それが大幅な改善をもたらす可能性は非常に高いでしょうか？
B）コンパイラの最適化がその仕事をすることができるようにマルチスレッドプログラムを適切に構築する方法に関する記事はありますか？
「積極的に実装」は少し奇妙です（あなたのプログラムは核分裂爆弾のコントローラーですか？）が、あなたのプログラムはコンパイラーの最適化なしで、そしてコンパイラーの最適化で不思議なことに動作したことを理解しています。
このための専門用語は、プログラムにバグがあるということです。
マルチスレッドプログラミングは本質的に困難です。スレッドがメモリを共有する場合のマルチスレッドプログラミングは非常に困難です。これは並行プログラミングのマゾヒストな方法です（メッセージパッシングは正しく行うのがはるかに簡単です）。記事を1、2冊読むだけでなく、数冊の本を読んで、数年のプログラミング経験を積む必要があります。
プログラムが最適化なしで機能しているように見えたのは不運でした。タイミングが少し異なる別のマシン、別のコンパイラ、または別のオペレーティングシステムでも、おそらく機能しません。そのため、プログラムが機能したと考えて時間を無駄にすることになりました。しかし、そうではありません。コンパイラは、選択した最適化レベルに関係なく、正しいソースコードを正しい実行可能ファイルに変換します。¹
¹コンパイラのバグを除けば、確かに。しかし、オッズはあなたに対して非常に強く積み重なっています。
ある最適化モードでのすべての家庭の失敗の99.9％は、深刻なバグが原因です。マルチスレッドレースなどは、コードのパフォーマンスに非常に敏感です。命令の並べ替えまたはループショートカットは、テストパスをデバッグの悪夢に変える可能性があります。
サーバーは正常に動作し、負荷がかかった状態で明らかに異なる場所で爆発すると想定しているので、従来のデバッグは役に立たないのでしょうか。
点火点を絞り込むには、ログ記録とテスト条件の変更に依存する必要があります。私の推測では、これはコード、最適化、オプション、負荷プロファイル、バッファサイズなどの変更で変化するHeisenbugになるでしょう。
問題を修正しないことは、より多くのコアなどを備えた来年のボックスに別の形で表示されるため、良い計画ではありません。最適化をオフにしても、それはまだそこにあり、潜んでいて、ストライキの機会を待っています。
私は私がいくつかの快適さを提供していることを願っています。
真剣に-優れたロガーで可能な限りすべてをログに記録します-ディスクの待ち時間をメインアプリから遠ざけるためにログをキューに入れます。状況を変えて、バグを変化させ、最適化されていないビルドにも表示されるようにします。良いか悪いかにかかわらず、変更後に何が起こるかをすべて書き留めてください（入力してください）。バグを悪化させることは、その症状を解消するよりも実際には優れています（正確な理由はわかりません）。可能であれば、さまざまなハードウェア構成でサーバーを試してください。
最終的に、あなたはバグを見つけるでしょう！
問題を確実に再現できるようです。それ自体、大きなプラスです。
尋ねるのを忘れた-核爆発の比喩は別として、主な症状は何ですか？それはあちこちでAV'ing/ segfaultingですか、それともロックまたはライブロックされていますか？
質問のパート「A」に答えるために、最適化されていないバージョンのコードにはまだ並行性のバグがありますが、スレッドの実行タイミングは、バグがテストワークロードでまだ公開されていないようなものです。最適化されていないプログラムの現在のバージョンは最終的に使用に失敗するため、プログラムを実際の作業に使用する前に、同時実行のバグを修正する必要があります。