Có bao nhiêu chủ đề để sử dụng?


11

Khi tôi (tái) xây dựng các hệ thống lớn trên máy tính để bàn / máy tính xách tay, tôi bảo makesử dụng nhiều hơn một luồng để tăng tốc độ biên dịch, như sau:

$ make -j$[ $K * $C ]

Trong trường hợp $Ccó nghĩa vụ phải chỉ ra số lượng lõi (mà chúng ta có thể giả định là một số với một chữ số) máy có, trong khi $Klà một cái gì đó tôi thay đổi từ 2tới 4, tùy thuộc vào tâm trạng của tôi.

Vì vậy, ví dụ, tôi có thể nói make -j12nếu tôi có 4 lõi, biểu thị makesẽ sử dụng tối đa 12 luồng.


Lý do của tôi là, nếu tôi chỉ sử dụng các $Cluồng, các lõi sẽ không hoạt động trong khi các quá trình đang bận tìm nạp dữ liệu từ các ổ đĩa. Nhưng nếu tôi không giới hạn số lượng chủ đề (nghĩa là make -j) tôi sẽ gặp rủi ro lãng phí thời gian chuyển đổi bối cảnh, hết bộ nhớ hoặc tệ hơn . Giả sử máy có nhiều $Mhợp đồng bộ nhớ ( $Mtheo thứ tự 10).

Vì vậy, tôi đã tự hỏi nếu có một chiến lược được thiết lập để chọn số lượng luồng hiệu quả nhất để chạy.


Trong nhiều trường hợp, câu trả lời đúng cho số lượng luồng sẽ là số lõi. Nhưng cách duy nhất để biết chắc chắn là chạy một số thử nghiệm, thay đổi số lượng chủ đề cho đến khi bạn tìm thấy điểm ngọt ngào.
Robert Harvey

@RobertHarvey: Vâng, có lẽ tôi sẽ đi và có một kịch bản shell được biên dịch với tất cả các loại cài đặt qua đêm, nhưng tôi nghĩ tôi sẽ hỏi nếu có một số kiến ​​thức về điều này ngoài kia.
bitmask

4
nhiều người cũng đề xuất $ lõi + 1, vì vậy 1 quá trình biên dịch đọc từ đĩa trong khi 4 biên dịch. Một đề xuất chung là khó, cũng phụ thuộc vào cơ sở mã (lạm dụng mẫu C ++ so với các đơn vị biên dịch nhỏ với một vài hàm C), chuỗi trình biên dịch (các tiêu đề được biên dịch trước, v.v.) và cấu trúc xây dựng (có phải liên kết chỉ là một điều lớn trong kết thúc hoặc nhiều thứ nhỏ hơn ở giữa)
johannes

1
Nếu bạn nghiêm túc tìm kiếm hiệu suất, tôi khuyên bạn nên xem xét việc thiết lập đĩa RAM hoặc một số phương pháp khác để giảm bớt I / O của bạn. Tôi không nghĩ việc sử dụng CPU là điểm nóng của bạn.
TMN

@TMN: Đĩa RAM giúp như thế nào? Linux là khá tốt tại bộ nhớ đệm thứ (bạn làm có nghĩa là các tập tin tiêu đề, phải không?), Chưa kể đến bộ nhớ cache ổ đĩa. Tôi sẽ phải tải mọi thứ vào shm trước, bằng tay hoặc bằng cách thay đổi tập lệnh xây dựng (sẽ hoàn toàn quá mức cần thiết).
bitmask

Câu trả lời:


15

Tôi đã chạy một loạt các thử nghiệm, xây dựng llvm (ở chế độ Gỡ lỗi + Xác nhận) trên một máy có hai lõi và 8 GB RAM:

biên dịch thời gian llvm tùy thuộc vào số lượng công việc

Thật kỳ lạ, nó dường như leo lên đến 10 và sau đó đột nhiên giảm xuống dưới thời gian cần thiết để xây dựng với hai công việc (một công việc mất khoảng thời gian gấp đôi, không bao gồm trong biểu đồ).

Tối thiểu dường như là 7*$corestrong trường hợp này.


1
+1 để thử nghiệm thực tế và không đầu cơ.
Martin Wickman

3

Tôi đang chạy Gentoo Linux (phân phối dựa trên nguồn) và từ kinh nghiệm của tôi, tôi có thể nói rằng (với phần cứng gần đây hoặc ít hơn) n*2 + xlà giá trị tốt nhất. Hãy để tôi giải thích điều này:

  • n*2: Ngay cả CPU chậm hơn cũng có đủ năng lượng để chạy 2 tác vụ cùng một lúc. hầu hết các nhiệm vụ biên dịch được hoàn thành rất nhanh.
  • +xcon số này phụ thuộc vào hệ thống của bạn (chủ yếu là bộ nhớ và đĩa). Nếu bạn có đủ RAM và đĩa nhanh, hãy đặt x=n. Tuy nhiên, điều này phụ thuộc vào mã nguồn (Open Office, tôi đang nhìn bạn!) Và ngôn ngữ được sử dụng (biên dịch C / C ++ rất tốn bộ nhớ).

Tuy nhiên, bạn phải chạy một số thử nghiệm với một số -jgiá trị để có được số tốt nhất. Ngoài ra, hãy cố gắng song song các bước khác của quá trình xây dựng: giải nén, chạy configure, v.v.


Hiện tại tôi rất quan tâm đến C ++ và các đĩa của tôi không phải là nhanh nhất, tôi đoán vậy.
bitmask

Sau đó bắt đầu với n * 1.5 và tăng cho đến khi thời gian biên dịch ngừng giảm (đảm bảo bạn dọn sạch bộ đệm / biên dịch bộ đệm mỗi lần). Ngoài ra, hãy nghĩ đến việc sử dụng ccache ( ccache.samba.org ) để tăng tốc độ biên dịch.
ercpe
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.