Làm thế nào để xác định số lượng tối đa để vượt qua tùy chọn make -j?


31

Tôi muốn biên dịch càng nhanh càng tốt. Đi hình. Và muốn tự động hóa việc lựa chọn số theo -jtùy chọn. Làm thế nào tôi có thể lập trình chọn giá trị đó, ví dụ như trong tập lệnh shell?

Là đầu ra nproctương đương với số lượng chủ đề tôi có sẵn để biên dịch với?

make -j1 make -j16

Câu trả lời:


34

nprocđưa ra số lượng lõi / luồng CPU có sẵn, ví dụ 8 trên CPU lõi tứ hỗ trợ SMT hai chiều.

Số lượng công việc bạn có thể chạy song song với makeviệc sử dụng -jtùy chọn phụ thuộc vào một số yếu tố:

  • dung lượng bộ nhớ khả dụng
  • dung lượng bộ nhớ được sử dụng bởi mỗi makecông việc
  • mức độ mà các makecông việc bị ràng buộc I / O- hoặc CPU

make -j$(nproc) là một nơi tốt để bắt đầu, nhưng bạn thường có thể sử dụng các giá trị cao hơn, miễn là bạn không làm cạn kiệt bộ nhớ khả dụng và bắt đầu đập.

Để xây dựng thực sự nhanh, nếu bạn có đủ bộ nhớ, tôi khuyên bạn nên sử dụng một tmpfs, theo cách đó, hầu hết các công việc sẽ được gắn kết với CPU và make -j$(nproc)sẽ hoạt động nhanh nhất có thể.


3
ccacheđể xây dựng lại sau này nhưng đây là OT
solsTiCe

1
Sử dụng một cái gì đó như GNU song song có giá trị ở đây?
terdon

Nếu tôi sử dụng a tmpfs, tôi sẽ bị giới hạn ở kích thước thư mục luôn nhỏ hơn kích thước RAM vật lý của mình chứ?
tarabyte

2
Đó không phải là một câu trả lời tuyệt vời, nhưng theo tinh thần nghiêm ngặt của câu hỏi về việc xác định bằng cách lập trình giá trị "j" nhanh nhất, bạn có thể lặp j từ 1 đến một giới hạn trên hợp lý (2x nproc ??) và thực hiện timecuộc gọi. Dọn dẹp kết quả, rửa lại lặp lại - và kết thúc việc sắp xếp các giá trị times / j.
Jeff Schaller

3
@terdon Số Make là tất cả về việc giải quyết các phụ thuộc, có nghĩa là các công việc vẫn phải được chạy theo một thứ tự nhất định. GNU song song không quan tâm đến điều đó. Mặt khác, việc quyết định công việc nào an toàn để chạy song song và công việc nào không phải là vấn đề khó. Tất cả các chương trình cung cấp các bản dựng song song phải mất nhiều năm cho đến khi chúng trở nên có thể sử dụng được.
lcd047

6

Thật không may, ngay cả các phần khác nhau của cùng một bản dựng có thể là tối ưu với các giá trị yếu tố j xung đột, tùy thuộc vào những gì được xây dựng, làm thế nào, tài nguyên hệ thống nào là nút cổ chai tại thời điểm đó, những gì khác đang xảy ra trên máy xây dựng, những gì đang xảy ra mạng (nếu sử dụng các kỹ thuật xây dựng phân tán), trạng thái / vị trí / hiệu suất của nhiều hệ thống bộ nhớ đệm liên quan đến một bản dựng, v.v.

Biên dịch 100 tệp C nhỏ có thể nhanh hơn so với biên dịch một tệp lớn hoặc ngược lại. Xây dựng mã nhỏ phức tạp cao có thể chậm hơn so với xây dựng số lượng lớn mã thẳng / tuyến tính.

Ngay cả bối cảnh của vấn đề xây dựng - sử dụng yếu tố aj được tối ưu hóa cho các bản dựng trên các máy chủ chuyên dụng được tinh chỉnh cho các bản dựng độc quyền, không chồng chéo có thể mang lại kết quả rất đáng thất vọng khi các nhà phát triển xây dựng song song trên cùng một máy chủ dùng chung (mỗi bản dựng như vậy có thể mất nhiều hơn thời gian hơn tất cả chúng kết hợp nếu được tuần tự hóa) hoặc trên các máy chủ có cấu hình phần cứng hoặc ảo hóa khác nhau.

Ngoài ra còn có khía cạnh về tính chính xác của đặc tả kỹ thuật xây dựng. Các bản dựng rất phức tạp có thể có các điều kiện chủng tộc gây ra các lỗi xây dựng không liên tục với tỷ lệ xuất hiện có thể thay đổi dữ dội với sự tăng hoặc giảm của hệ số j.

Tôi có thể đi và về. Vấn đề là bạn phải thực sự đánh giá bản dựng của mình trong chính bối cảnh mà bạn muốn yếu tố j được tối ưu hóa. Nhận xét @Jeff Schaller áp dụng: lặp đi lặp lại cho đến khi bạn tìm thấy sự phù hợp nhất của mình. Cá nhân tôi sẽ bắt đầu từ giá trị nproc, thử lên trước và xuống chỉ khi các nỗ lực đi lên cho thấy sự xuống cấp ngay lập tức.

Có thể là một ý tưởng tốt để đầu tiên đo lường một số bản dựng giống hệt nhau trong các bối cảnh được cho là giống hệt nhau chỉ để có ý tưởng về tính biến thiên của các phép đo của bạn - nếu quá cao, nó có thể gây nguy hiểm cho toàn bộ nỗ lực tối ưu hóa của bạn (độ biến thiên 20% sẽ làm lu mờ hoàn toàn 10% / suy thoái đọc trong tìm kiếm yếu tố j).

Cuối cùng, IMHO nó tốt hơn để sử dụng một (adaptive) jobserver nếu được hỗ trợ và có sẵn thay vì một yếu tố j cố định - nó liên tục cung cấp một xây dựng hiệu suất tốt hơn qua các phạm vi rộng lớn hơn của bối cảnh.


cũng đặt liên quan đến các phụ thuộc của xây dựng cơ bản. Bạn có thể nhận xét về việc không có số cố định với -jtham số? ví dụmake -j
tarabyte

4
make -jsẽ sinh ra nhiều công việc như những người phụ thuộc cho phép như một quả bom ngã ba ( superuser.com/questions/927836/ mẹo ); bản dựng sẽ thu thập dữ liệu tốt nhất dành hầu hết CPU cho việc quản lý các quy trình hơn là chạy chúng ( superuser.com/questions/934685/ mẹo ) và trong các bản dựng song song cao, hệ thống sẽ hết bộ nhớ / trao đổi hoặc pid #s và quá trình xây dựng sẽ thất bại .
Dan Cornilescu

3

Cách đơn giản nhất là sử dụng nprocnhư vậy:

make -j`nproc`

Lệnh nprocsẽ trả về số lượng lõi trên máy của bạn. Bằng cách gói nó trong tích tắc, nproclệnh sẽ thực thi trước, trả về một số và số đó sẽ được chuyển vào make.

Bạn có thể có một số kinh nghiệm giai thoại khi thực hiện đếm lõi + 1 trong thời gian biên dịch nhanh hơn. Điều này có liên quan nhiều hơn đến các yếu tố như độ trễ I / O, độ trễ tài nguyên khác và các hạn chế tài nguyên khác.

Để làm điều này với nproc+1, hãy thử điều này:

make -j$((`nproc`+1))

0

Nếu bạn muốn viết makelệnh để sử dụng nhiều nhân viên song song như bạn có CPU ảo, tôi khuyên bạn nên sử dụng:

nproc | xargs -I % make -j%

Có thể được viết dưới dạng một lệnh độc lập hoặc là một lệnh RUNtrong Dockerfile(vì Docker không hỗ trợ các lệnh lồng nhau)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.