相対的な予想タスク時間をスケジュールに組み込むビルドシステムはありますか？

これが私の質問の小さな図です：

ADという名前の4つの独立したタスクで構成されるビルドジョブを想定します。DはACよりも時間がかかります。

相対的なタスク時間を組み込むことができないビルドシステムは、次のようにタスクをスケジュールする場合があります。

---------------------------------------
CPU1: A  |    C   |
---------------------------------------
CPU2: B    | D                        |
---------------------------------------

対照的に、スケジューラがタスクの時間差を認識している場合、次のようなはるかに短いスケジュールが考えられます。

---------------------------------------
CPU1: A  |  B    |   C   |
---------------------------------------
CPU2: D                        |
---------------------------------------

私の質問：

1. 相対的な予想タスク時間をスケジュールに組み込むビルドシステムはありますか？
2. この種の構築システムに関する学術研究は何ですか？
3. これらのビルドシステム（存在する場合）はどこから時間情報を取得しますか？ヒューリスティック、以前のビルド中に収集されたタイミング？
4. そのようなビルドシステムが存在しない場合、なぜですか？一見しただけで価値がなくなるような落とし穴はありますか？

Microsoft Visual Studio Team System（以前のTFS）は、ビルドアクション時間と並列ビルドを考慮します。以前のビルド履歴からデータを取得します。必要な動作をすぐに使用できるとは思いませんが、カスタマイズできる場合があります。

パフォーマンスの最適化に取り組むカスタムタスクの例

https://veegens.wordpress.com/2013/03/26/tfs-2010-build-performance-report/

これは、タスクの「構築」が非並行であるという誤った仮定に基づいています。

多くのコンパイラはマルチスレッドで動作するため、1つのタスクAはすべてのCPUを使用します。したがって、順序は関係ありません。I / Oにバインドされたタスク、特にネットワークに関連するタスクの場合、最初からすべて並列に開始することをお勧めします。ほとんどの時間は回答を待つことに費やされます。

言い換えれば、個々のタスクは通常並列化されるため（たとえばコンパイルのように）順序は重要ではありません。

編集：

実際、「CPU 1のタスクA」というこの概念にも欠陥があります。シングルスレッドタスクの場合でも、プロセス/スレッドをスケジューリングするOSは、各コンテキストスイッチでCPUからCPUにホップする場合があります。ほとんどのビルドシステムはすべてのタスクを並行して実行し、OSにスケジューリングを行わせるだけだと思います。長いタスクには時間がかかりますが、それだけです。

I / Oバウンドではない長時間実行されるシングルスレッドタスクがあると仮定すると、ビルドシステムが優先度/重要性を割り当てる方が簡単です。OSからのコンテキストスイッチを減らすために、より小さなタスクを遅延させようとするよりも。

実際には非常にまれなそのような奇妙なタスクがあり、以前の実行に基づいてヒューリスティックに基づいて動作する派手なスケジューリングビルドシステムを持っている場合でも（知る唯一の方法）、そこから得られるメリットはかなり小さいかもしれません。しかし、維持するために追加の複雑さの束を取得します。