เป็นไปได้หรือไม่ที่จะเร่งความเร็ว / กำหนดค่า

เมื่อต้องการคอมไพล์แพคเกจซอฟต์แวร์บนเวิร์กสเตชันที่มีคอร์ CPU หลายตัว (เช่น 12), ขั้นตอนการกำหนดค่ามักใช้เวลานานกว่าสเตจรวบรวมจริงเนื่องจาก./configureทำการทดสอบทีละตัวในขณะที่make -jรันgccพร้อมกับคำสั่งอื่น ๆ แบบขนาน

ฉันรู้สึกว่าเป็นการสิ้นเปลืองทรัพยากรอย่างมากที่มี 11 คอร์ที่เหลือนั่งทำงานโดยส่วนใหญ่รอช้า./configureให้เสร็จสมบูรณ์ เหตุใดจึงต้องทำการทดสอบตามลำดับ การทดสอบแต่ละครั้งขึ้นอยู่กับแต่ละอื่น ๆ หรือไม่? ฉันเข้าใจผิด แต่ดูเหมือนว่าพวกเขาส่วนใหญ่มีความเป็นอิสระ

ที่สำคัญกว่านั้นมีวิธีใดบ้างในการเร่งความเร็ว./configure?

แก้ไข: เพื่อแสดงสถานการณ์นี่เป็นตัวอย่างของ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

ผล:

# 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

ด้วยcoreutils-8.9 , ./configureใช้เวลา 6 makeครั้งนานกว่า แม้ว่าจะ./configureใช้เวลา CPU น้อยลง (ดูที่ "ผู้ใช้" และ "sys" ครั้ง) แต่ใช้เวลานานกว่า ("จริง") เพราะไม่ได้ขนานกัน ฉันทำการทดสอบซ้ำสองสามครั้ง (ไฟล์ที่เกี่ยวข้องอาจยังอยู่ในแคชหน่วยความจำ) และเวลานั้นอยู่ภายใน 10%

ฉันจำการสนทนาในรายชื่อผู้รับจดหมาย Autoconf เกี่ยวกับปัญหานี้เมื่อประมาณ 10 ปีที่แล้วเมื่อคนส่วนใหญ่มี CPU แกนเดียวเท่านั้น แต่ไม่มีอะไรทำและฉันสงสัยว่าจะไม่มีอะไรเกิดขึ้น มันจะยากมากในการตั้งค่าการพึ่งพาทั้งหมดสำหรับการประมวลผลแบบขนานconfigureและทำในลักษณะที่พกพาและทนทาน

ขึ้นอยู่กับสถานการณ์เฉพาะของคุณอาจมีสองสามวิธีในการเร่งความเร็วในการกำหนดค่าที่จะทำงานต่อไป ตัวอย่างเช่น:

• ใช้กระสุนที่เร็วกว่า ยกตัวอย่างเช่นพิจารณาใช้dashแทนเป็นbash /bin/sh(หมายเหตุ: ภายใต้ Debian dashจะได้รับการติดตั้งเพื่อconfigureไม่ให้ใช้งานได้เนื่องจากการใช้งานแบ่งconfigureสคริปต์เป็นจำนวนมาก)
• หากคุณรัน builds แบบรีโมต (ผ่าน ssh เป็นต้น) จากนั้นฉันก็พบว่าเอาต์พุตคอนโซลนั้นค่อนข้างช้า configure -qพิจารณาเรียก
• หากคุณสร้างโครงการเดียวกันซ้ำ ๆ ให้ลองใช้ไฟล์แคช โทรconfigure -C. ดูเอกสารประกอบของ Autoconf สำหรับรายละเอียด
• หากคุณสร้างโครงการต่าง ๆ ให้พิจารณาใช้ไฟล์ไซต์ ( config.site) ดูเอกสารอีกครั้ง
• สร้างหลายโครงการในแบบคู่ขนาน

คุณฉลาดในการใช้ ramdrive เพื่อให้ sourcetree อยู่ แต่ลองคิดดูสองครั้ง - การกำหนดค่าทำอะไร มันทำงานได้โดยการตรวจสอบไม่เพียง แต่sourcetreeของคุณแต่ก็มักจะเป็นระบบสำหรับความพร้อมของไลบรารีคอมไพเลอร์และอื่น ๆ ในกรณีนี้ปัญหาการเข้าถึงบางครั้งอยู่ในการเข้าถึงดิสก์ - คุณจะทำให้มันเร็วขึ้นมากถ้าคุณ ตัวอย่างระบบไฟล์รูทที่ใช้ SSD

หากคุณใช้ตัวควบคุมซีพียู ondemand ให้ลองใช้ตัวควบคุมประสิทธิภาพ สิ่งนี้จะช่วยใน i7 และ a8-3850 โดย 40-50% ไม่ได้สร้างความแตกต่างอย่างมากกับ q9300

ในซีพียู quad core คุณอาจจะทำ

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

(ตัวเลือก -r ควรทำเพื่อให้คุณไม่ต้องทำ cpufreq-set สำหรับแต่ละคอร์ แต่ในคอมพิวเตอร์ของฉันมันไม่ทำงาน)

ตัวเลือกแคชช่วยได้มากขึ้น

./configureสคริปต์มีหลายประเภท มีเครื่องมือยอดนิยม ( autconfเป็นหนึ่งในนั้น) เพื่อช่วยนักพัฒนาในการสร้าง./configureสคริปต์ แต่ไม่มีกฎที่บอกว่านักพัฒนาทุกคนจะต้องใช้เครื่องมือเหล่านี้และจากนั้นในบรรดาเครื่องมือเหล่านี้ ถูกสร้างขึ้น

ฉันไม่ทราบถึง./configureสคริปต์ยอดนิยมใด ๆที่สามารถทำงานแบบขนานได้ สคริปต์ส่วนใหญ่ที่สร้างโดยเครื่องมือที่ได้รับความนิยมจะทำแคชผลลัพธ์บางส่วนหรือทั้งหมดอย่างน้อยดังนั้นหากคุณเรียกใช้อีกครั้ง (โดยไม่ต้องทำmake cleanก่อน) ก็จะทำงานได้เร็วขึ้นเป็นครั้งที่สอง

ไม่ได้หมายความว่ามันไม่สามารถทำได้ ... แต่ฉันสงสัยว่ามีแรงจูงใจเล็กน้อยสำหรับคนที่ทำงานautoconfเช่นทำเช่นนั้นเนื่องจากแพ็คเกจส่วนใหญ่ขั้นตอนการกำหนดค่านั้นค่อนข้างเร็วเมื่อเทียบกับการรวบรวมและการเชื่อมโยงที่เกิดขึ้นจริง ขั้นตอน

ฮาร์ดไดรฟ์เป็นคอขวดในกรณีนี้ หากต้องการเร่งความเร็วการสร้างให้สร้างระบบที่มีไดรฟ์เร็ว (อ่าน: เวลาเข้าถึงต่ำ) มีความยุ่งยากมากมายเกี่ยวกับแผ่นดิสก์ SSD แต่มีบางคนวิจารณ์ว่าพวกเขาไม่ได้ส่งผลกระทบต่อเวลาการรวบรวมในทางบวก กล่าวคือการสร้าง SSD นั้นไม่เร็วกว่าไดรฟ์ SATA ที่เหมาะสม ฉันจำไม่ได้ว่าอ่านบทความนี้ที่ไหนเพราะบทความนี้มีอายุสองสามปี

ยังไงก็ตาม ... ไม่เคย ram และสร้างจากตรงนั้น

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

คำถามของคุณอาจมีความเกี่ยวข้องมากขึ้นในวันนี้เนื่องจากเรามีซีพียูหลายสิบคอร์พร้อมกับประสิทธิภาพการทำงานของแกนเดี่ยวต่ำ (สวย) การสร้างอัตโนมัติสำหรับการรวมอย่างต่อเนื่อง (CI) ทำให้เสียเวลา / พลังงานของ CPU มากสำหรับทุกการกระทำ เช่นเดียวกันกับการกระโดดระหว่างสาขา

ดังนั้นการตรวจสอบ / อ่านคำแนะนำของฉันเกี่ยวกับการเร่งขึ้นสิ่งที่https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain

"ทำไมจึงต้องทำการทดสอบตามลำดับ? ... " ในความเป็นจริงมีบางสิ่งที่สามารถทำแบบขนานในขณะที่คนอื่นต้องเรียงตามลำดับ มีหลายสิ่งขึ้นอยู่กับสภาพแวดล้อมการสร้าง - และสคริปต์กำหนดค่าเองนั้นเป็นระบบที่ไม่ขึ้นกับใคร มันไม่ได้มี bashisms ดังนั้นจึงใช้งานได้กับ POSIX เชลล์บริสุทธิ์

ถ้าคุณต้องการเขียนซอฟต์แวร์พกพาไม่มีระบบบิลด์อื่น ๆ เช่น autotools แต่ถ้าคุณไม่คำนึงถึงการพกพา (กว้าง) หลีกเลี่ยงการใช้เครื่องมืออัตโนมัติ - มีเครื่องมือสร้างที่รวดเร็วและดีเพียงพอ