Có thể tăng tốc ./mình?

Để biên dịch gói phần mềm trên máy trạm có nhiều lõi CPU (giả sử 12), giai đoạn cấu hình thường mất nhiều thời gian hơn so với giai đoạn biên dịch thực tế vì ./configurethực hiện kiểm tra từng cái một, trong khi make -jchạy gccsong song các lệnh khác.

Tôi cảm thấy thật lãng phí tài nguyên khi có 11 lõi còn lại hầu hết thời gian chờ đợi ./configuređể hoàn thành chậm . Tại sao nó cần phải làm các bài kiểm tra tuần tự? Có phải mỗi bài kiểm tra phụ thuộc vào nhau? Tôi có thể bị nhầm lẫn, nhưng có vẻ như phần lớn trong số họ là độc lập.

Quan trọng hơn, có cách nào để tăng tốc ./configure?

Chỉnh sửa: Để minh họa tình huống, đây là một ví dụ với GNU Coreutils

cd /dev/shm
rm -rf coreutils-8.9
tar -xzf coreutils-8.9.tar.gz
cd coreutils-8.9
time ./configure
time make -j24

Các kết quả:

# For `time ./configure`
real    4m39.662s
user    0m26.670s
sys     4m30.495s
# For `time make -j24`
real    0m42.085s
user    2m35.113s
sys     6m15.050s

Với coreutils-8,9 , ./configuremất nhiều thời gian hơn 6 lần make. Mặc dù ./configuresử dụng ít thời gian CPU hơn (nhìn vào thời gian "người dùng" và "sys"), nhưng sẽ mất nhiều thời gian hơn ("thực") vì nó không song song. Tôi đã lặp lại thử nghiệm một vài lần (với các tệp có liên quan có thể nằm trong bộ nhớ cache) và thời gian trong vòng 10%.

Tôi nhớ lại các cuộc thảo luận trong danh sách gửi thư Autoconf về vấn đề này từ khoảng 10 năm trước, khi hầu hết mọi người thực sự chỉ có một lõi CPU. Nhưng không có gì đã được thực hiện, và tôi nghi ngờ sẽ không có gì được thực hiện. Sẽ rất khó để thiết lập tất cả các phụ thuộc để xử lý song song configurevà thực hiện theo cách có thể di động và mạnh mẽ.

Tùy thuộc vào kịch bản cụ thể của bạn, có thể có một vài cách để tăng tốc độ cấu hình chạy. Ví dụ:

• Sử dụng vỏ nhanh hơn. Ví dụ, xem xét sử dụng dashthay vì bashnhư /bin/sh. (Lưu ý: Trong Debian, dashđược vá để configurekhông sử dụng nó, vì sử dụng nó sẽ phá vỡ rất nhiều configuretập lệnh.)
• Nếu bạn chạy các bản dựng từ xa (chẳng hạn như thông qua ssh), thì tôi đã thấy rằng đầu ra của bàn điều khiển có thể khá chậm. Hãy xem xét việc gọi configure -q.
• Nếu bạn liên tục xây dựng cùng một dự án, hãy xem xét sử dụng tệp bộ đệm. Gọi configure -C. Xem tài liệu Autoconf để biết chi tiết.
• Nếu bạn xây dựng nhiều dự án khác nhau, hãy xem xét sử dụng tệp trang web ( config.site). Một lần nữa, xem tài liệu.
• Xây dựng một số dự án song song.

Bạn đã thông minh trong việc sử dụng ramdrive cho sourcetree để cư trú, nhưng hãy nghĩ về nó hai lần - cấu hình làm gì? Nó thực hiện công việc của mình bằng cách kiểm tra không chỉ của bạn sourcetree , nhưng khá thường xuyên cũng là hệ thống cho availabilities của thư viện, trình biên dịch, vv Trong trường hợp này, vấn đề truy cập đôi khi nằm trong quyền truy cập đĩa - Bạn sẽ có nó được thực hiện nhanh hơn nhiều nếu bạn có cho ví dụ một hệ thống tập tin gốc dựa trên SSD.

Nếu bạn đang sử dụng bộ điều chỉnh cpu ondemand, hãy thử sử dụng hiệu suất. Điều này giúp trên i7 và a8-3850 khoảng 40-50%. Không tạo ra nhiều khác biệt trên q9300.

Trên một cpu lõi tứ, bạn có thể làm

for cpu in `seq 0 3`; do sudo cpufreq-set -g performance -c $cpu; done

(Tùy chọn -r sẽ làm cho nó để bạn không phải thực hiện cpufreq-set cho từng lõi, nhưng trên máy tính của tôi thì nó không hoạt động.)

Tùy chọn bộ nhớ cache thậm chí còn giúp nhiều hơn.

Có nhiều loại ./configurekịch bản. Có các công cụ phổ biến ( tự động là một trong số chúng) để hỗ trợ nhà phát triển tạo ./configuretập lệnh, nhưng không có quy tắc nào nói rằng mọi nhà phát triển phải sử dụng các công cụ này, và ngay cả trong số các công cụ này, có thể có nhiều biến thể theo cách các tập lệnh này Được xây dựng.

Tôi không biết bất kỳ ./configuretập lệnh phổ biến nào có thể chạy song song. Hầu hết các tập lệnh được xây dựng bởi các công cụ phổ biến ít nhất lưu trữ một số hoặc tất cả các kết quả của chúng, vì vậy nếu bạn chạy lại nó (dù không thực hiện make cleanlần đầu tiên), nó sẽ chạy nhanh hơn lần thứ hai.

Điều đó không có nghĩa là không thể thực hiện được ... nhưng tôi nghi ngờ có rất ít động lực cho những người làm việc autoconf, ví dụ, để làm điều đó, vì đối với hầu hết các gói, giai đoạn cấu hình rất nhanh so với việc biên dịch và liên kết thực tế các giai đoạn.

Ổ cứng là nút cổ chai trong trường hợp này. Để tăng tốc độ xây dựng, hãy xây dựng trên một hệ thống có ổ đĩa nhanh (đọc: thời gian truy cập thấp). Có rất nhiều sự ồn ào về đĩa SSD, nhưng đã có một số lời chỉ trích liên quan đến việc chúng không ảnh hưởng đến thời gian biên dịch theo hướng tích cực. Điều đó có nghĩa là việc xây dựng trên SSD không nhanh hơn nhiều so với trên một ổ đĩa sata phong nha. Tôi không thể nhớ lại nơi tôi đã đọc bài viết này vì bài báo này đã được vài năm tuổi.

Dù sao ... Unar để ram và xây dựng từ đó.

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2

Câu hỏi của bạn thậm chí có thể phù hợp hơn ngày hôm nay vì chúng tôi có CPU hàng chục lõi với hiệu năng lõi đơn (khá) thấp. Các bản dựng tự động cho Tích hợp liên tục (CI) thực sự lãng phí rất nhiều thời gian / năng lượng của CPU cho mỗi lần xác nhận. Tương tự với nhảy giữa các nhánh.

Vì vậy, hãy xem lại / đọc các gợi ý của tôi về việc tăng tốc mọi thứ tại https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain .

"Tại sao nó cần phải thực hiện các bài kiểm tra một cách tuần tự? ..." Thực tế có một vài điều có thể được thực hiện song song, trong khi những việc khác phải tuần tự. Một số thứ phụ thuộc vào môi trường xây dựng - và chính tập lệnh cấu hình là độc lập với hệ thống. Nó thậm chí không chứa bashism, vì vậy nó hoạt động với lớp vỏ POSIX thuần túy.

Nếu bạn muốn viết phần mềm di động, không có hệ thống xây dựng nào khác như autotools. Nhưng nếu bạn không quan tâm đến tính di động (rộng), hãy tránh tự động - có rất nhiều công cụ xây dựng nhanh và đủ tốt.