Apakah ada sistem build yang memasukkan waktu tugas yang diperkirakan relatif ke dalam jadwal?

Inilah ilustrasi kecil dari pertanyaan saya:

Asumsikan sebuah pekerjaan build yang terdiri dari 4 tugas independen bernama AD. D membutuhkan waktu lebih lama daripada AC.

Sistem build yang tidak dapat menggabungkan waktu tugas relatif mungkin menjadwalkan tugas-tugas seperti ini:

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

Sebaliknya, jika penjadwal mengetahui perbedaan waktu tugas, itu bisa muncul dengan jadwal yang jauh lebih pendek ini:

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

Pertanyaan saya:

Apakah ada sistem build yang memasukkan waktu tugas yang diperkirakan relatif ke dalam jadwal?
Penelitian akademis apa yang membangun sistem semacam ini ada?
Di mana sistem pembangunan ini (jika ada) mengambil informasi waktu? Heuristik, timing yang dikumpulkan selama build sebelumnya?
Jika sistem pembangunan seperti itu tidak ada, mengapa? Apakah ada gotcha yang akan membuat mereka kurang berharga daripada yang terlihat pada pandangan pertama?

scheduling research build-system

— sjakobi
sumber

Sebagian besar pertanyaan untuk sumber daya atau alat pihak ketiga ditutup dengan cepat sebagai "di luar topik", tapi saya kira yang satu ini bisa menjadi kasus tepi yang tampaknya cocok dengan ruang lingkup situs ini.

— Doc Brown

Saya pikir ini didasarkan pada asumsi yang salah bahwa "membangun" tugas adalah tidak paralel.

— dagnelies

Dalam kebanyakan kasus, membangun tugas memang tidak paralel, tetapi ya, mis. Pengujian unit dalam aplikasi multi-utas memang bisa paralel. Sebenarnya, dalam proyek tempat saya bekerja, kita selalu harus memanggil "make" dengan "-j1" untuk uji coba unit, karena jika tidak, tes multicore unit terkait dengan kinerja gagal.

— juhist

@ juhist Jika Anda tertarik untuk beralih ke sistem build yang lebih ekspresif, shake memiliki konsep sumber daya di mana Anda dapat, misalnya, menentukan berapa banyak inti CPU yang harus disediakan untuk pengujian unit Anda.

— sjakobi

Jawaban:

Microsoft Visual Studio Team System (sebelumnya TFS) tidak mempertimbangkan waktu tindakan build dan build paralel; dibutuhkan data dari riwayat build sebelumnya; dan sementara saya tidak percaya Anda bisa mendapatkan perilaku yang Anda inginkan di luar kotak, Anda mungkin dapat menyesuaikannya.

Contoh beberapa tugas khusus untuk mengoptimalkan kinerja

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

— Bruno Guardia
sumber

Jika saya memahami jawaban Anda dan tautan Anda dengan benar, waktu tindakan build dilaporkan (yang merupakan fitur yang agak umum) tetapi tidak jelas apakah atau bagaimana timing ini dapat digunakan untuk meningkatkan jadwal pembuatan. Ini sepertinya tidak benar-benar menjawab pertanyaan awal saya, jadi saya tidak akan memberikan hadiah untuk jawaban Anda.

— sjakobi

Tidak masalah, yang mungkin Anda lewatkan adalah bahwa Anda dapat menyesuaikan aksi build dan proses build, melalui pemrograman. Sampel melaporkan, tetapi seperti yang disebutkan, riwayat diambil untuk optimisasi otomatis. Perhatikan juga bahwa Anda dapat mengonfigurasi pembuatan paralel. Namun untuk memastikan mereka diparalelkan mengikuti algoritme Anda, Anda mungkin perlu menyesuaikan dengan kode. Beberapa referensi tambahan: dotnetcurry.com/visualstudio/1177/…

— Bruno Guardia

@BrunoGuardia: dapatkah Anda menjelaskan di mana di artikel tautan Anda itu ada opsi penyesuaian yang disebutkan yang dapat membantu memanfaatkan waktu tugas yang diharapkan dari tindakan pembangunan?

— Doc Brown

Ini didasarkan pada asumsi yang salah bahwa "membangun" suatu tugas adalah tidak paralel.

Banyak kompiler bekerja multi-threaded, jadi satu tugas A akan menggunakan semua CPU. Oleh karena itu, pesanannya tidak masalah. Untuk tugas-tugas terikat I / O, terutama yang melibatkan jaringan, lebih baik memulai semuanya secara paralel dari awal juga: sebagian besar waktu akan dihabiskan menunggu jawaban.

Dengan kata lain, pemesanan tidak menjadi masalah karena tugas-tugas individu biasanya diparalelkan (seperti mengkompilasi misalnya)

Edit:

Sebenarnya, konsep "Tugas A pada CPU 1" ini juga cacat. Bahkan untuk tugas berulir tunggal, penjadwalan OS proses / utas dapat melompat dari CPU ke CPU pada setiap konteks switch. Saya kira kebanyakan sistem build hanya akan menjalankan semua tugas secara paralel dan membiarkan OS melakukan penjadwalan. Tugas yang lebih lama akan memakan waktu lebih lama dan itu saja.

Dengan asumsi Anda memiliki tugas ulir tunggal berjalan lama yang tidak terikat I / O , akan lebih mudah bagi sistem build untuk menetapkan prioritas / kepentingan daripada mencoba untuk menunda tugas yang lebih kecil untuk mengurangi konteks switch dari OS.

Sekalipun Anda memiliki tugas aneh seperti itu , yang jarang terjadi dalam praktiknya, dan memiliki sistem pembuatan penjadwalan mewah yang bekerja berdasarkan heuristik berdasarkan proses sebelumnya (satu-satunya cara untuk mengetahui), manfaat yang Anda dapatkan dari itu mungkin agak kecil .. . Bagaimanapun Anda mendapatkan banyak kerumitan tambahan untuk dipelihara.

— dagnelies
sumber

Paralelisme "dalam-tugas" adalah aspek yang menarik dan tentu saja menawarkan potensi tambahan untuk optimasi, tetapi saya tidak berpikir bahwa dengan asumsi bahwa setiap tugas yang diberikan akan menskalakan secara efisien ke jumlah CPU yang sewenang-wenang lebih baik daripada mengasumsikan bahwa setiap tugas harus dijalankan pada satu inti.

— sjakobi

@sjakobi: baik, dalam praktiknya cukup penting bahwa kompiler efisien. Dapatkah Anda bayangkan bahwa Anda menunggu waktu yang lama untuk kompilasi karena hanya 1 dari 16 core Anda yang digunakan? Itu tidak perlu. Dengan semua teori, Anda tampaknya mengabaikan kenyataan. Penjadwalan adalah topik yang sangat menarik dan sangat bermakna. Hanya saja IMHO relatif tidak berguna dalam konteks membangun sistem. Sekali lagi, sebagian besar kompiler saat ini adalah multithreaded ... dan jika tidak, usaha lebih baik dimasukkan ke dalam ini daripada sistem pembangunan penjadwalan.

— dagnelies

Semua kompiler perangkat lunak gratis ( GCC & Dentang ...) untuk C ++ atau C atau Fortran atau Ada adalah mono-threaded. Build system ( make -j) dapat meluncurkan beberapa proses kompilasi secara paralel.

— Basile Starynkevitch

@ BasileStarynkevitch: ... memang. Pada dasarnya, semua orang menggunakan waras -j <nb-cores>tetapi sayangnya standarnya masih "1" ... Saya masih terkejut itu tidak pernah berubah.

— dagnelies

@dagnelies: Ada sejumlah besar Makefile yang melewatkan beberapa dependensi kritis dan karenanya tidak berfungsi (atau mungkin tidak bekerja) dengan -jN di mana N> 1.

— juhist