GNU make: จำนวนงานควรเท่ากับจำนวนแกน CPU ในระบบหรือไม่?


89

ดูเหมือนจะมีข้อโต้แย้งว่าจำนวนงานใน GNU ที่ทำควรจะเท่ากับจำนวนคอร์หรือถ้าคุณสามารถเพิ่มประสิทธิภาพเวลาในการสร้างโดยการเพิ่มงานพิเศษหนึ่งงานที่สามารถจัดคิวได้ในขณะที่งานอื่น ๆ "ทำงาน" .

จะดีกว่าที่จะใช้-j4หรือ-j5ในระบบ Quad Core หรือไม่?

คุณเคยเห็น (หรือทำ) การเปรียบเทียบใด ๆ ที่สนับสนุนอย่างใดอย่างหนึ่งหรือไม่?


8
สำหรับเคล็ดลับคุณสามารถใช้make `nproc`เพื่อสร้างสคริปต์ที่เป็นอิสระของ CPU ได้ :)
VivienG

หากคุณมีสูตรอาหารที่เชื่อมต่อกับ io-bound และ cpu-bound คุณอาจต้องการมากกว่า NCPU ลองเพิ่มตัวเลือก -lX ด้วย นี่ไม่ใช่คำถามที่ตอบได้จริงๆนอกจาก "ขึ้นอยู่กับฮาร์ดแวร์และการทำงานของคุณ"
James Moore

เป็นไปได้ในทางเทคนิคที่จะเห็นการปรับปรุง คุณต้องการดิสก์ที่ช้าแรมไม่เพียงพอและไฟล์ซอร์สโค้ดขนาดเล็กจำนวนมาก ง่ายขึ้นเมื่อทศวรรษที่แล้ว
Hans Passant

คำตอบ:


58

ฉันจะบอกว่าสิ่งที่ดีที่สุดที่ควรทำคือเปรียบเทียบกับสภาพแวดล้อมและภาระงานของคุณโดยเฉพาะ ดูเหมือนว่าจะมีตัวแปรมากเกินไป (ขนาด / จำนวนไฟล์ต้นฉบับหน่วยความจำที่มีอยู่การแคชดิสก์ไม่ว่าไดเรกทอรีต้นทางและส่วนหัวระบบของคุณจะอยู่บนดิสก์ที่แตกต่างกัน ฯลฯ ) สำหรับคำตอบขนาดเดียวที่เหมาะกับทุกคน

ประสบการณ์ส่วนตัวของฉัน (บน MacBook Pro 2 คอร์) คือ -j2 เร็วกว่า -j1 อย่างมาก แต่นอกเหนือจากนั้น (-j3, -j4 เป็นต้น) ไม่มีการเร่งความเร็วที่วัดได้ ดังนั้นสำหรับสภาพแวดล้อมของฉัน "งาน == จำนวนคอร์" ดูเหมือนจะเป็นคำตอบที่ดี (YMMV)


59

ฉันใช้งานโครงการบ้านบน 4 คอร์ด้วยแล็ปท็อปไฮเปอร์เธรดและบันทึกผลลัพธ์ นี่เป็นโปรเจ็กต์คอมไพเลอร์ที่ค่อนข้างหนัก แต่รวมถึงการทดสอบหน่วย 17.7 วินาทีในตอนท้าย การคอมไพล์นั้นไม่เข้มข้น IO มากนัก มีหน่วยความจำมากและหากไม่มีหน่วยความจำที่เหลืออยู่บน SSD ที่รวดเร็ว

1 job        real   2m27.929s    user   2m11.352s    sys    0m11.964s    
2 jobs       real   1m22.901s    user   2m13.800s    sys    0m9.532s
3 jobs       real   1m6.434s     user   2m29.024s    sys    0m10.532s
4 jobs       real   0m59.847s    user   2m50.336s    sys    0m12.656s
5 jobs       real   0m58.657s    user   3m24.384s    sys    0m14.112s
6 jobs       real   0m57.100s    user   3m51.776s    sys    0m16.128s
7 jobs       real   0m56.304s    user   4m15.500s    sys    0m16.992s
8 jobs       real   0m53.513s    user   4m38.456s    sys    0m17.724s
9 jobs       real   0m53.371s    user   4m37.344s    sys    0m17.676s
10 jobs      real   0m53.350s    user   4m37.384s    sys    0m17.752s
11 jobs      real   0m53.834s    user   4m43.644s    sys    0m18.568s
12 jobs      real   0m52.187s    user   4m32.400s    sys    0m17.476s
13 jobs      real   0m53.834s    user   4m40.900s    sys    0m17.660s
14 jobs      real   0m53.901s    user   4m37.076s    sys    0m17.408s
15 jobs      real   0m55.975s    user   4m43.588s    sys    0m18.504s
16 jobs      real   0m53.764s    user   4m40.856s    sys    0m18.244s
inf jobs     real   0m51.812s    user   4m21.200s    sys    0m16.812s

ผลลัพธ์พื้นฐาน:

  • การปรับขนาดเป็นจำนวนแกนจะเพิ่มประสิทธิภาพเกือบเป็นเส้นตรง เวลาจริงลดลงจาก 2.5 นาทีเป็น 1.0 นาที (เร็วที่สุด 2.5 เท่า) แต่เวลาที่ใช้ในระหว่างการคอมไพล์เพิ่มขึ้นจาก 2.11 เป็น 2.50 นาที ระบบสังเกตว่าแทบจะไม่มีโหลดเพิ่มเติมในบิตนี้
  • การปรับขนาดจากจำนวนแกนไปยังจำนวนเธรดช่วยเพิ่มการโหลดของผู้ใช้อย่างมากจาก 2.50 นาทีเป็น 4.38 นาที การเพิ่มขึ้นเกือบสองเท่านี้น่าจะเป็นเพราะอินสแตนซ์คอมไพลเลอร์อื่น ๆ ต้องการใช้ทรัพยากร CPU เดียวกันในเวลาเดียวกัน ระบบกำลังโหลดคำขอและการสลับงานเพิ่มขึ้นเล็กน้อยทำให้ใช้เวลาไป 17.7 วินาที ข้อดีคือประมาณ 6.5 วินาทีในเวลาคอมไพล์ 53.5 วินาทีทำให้ความเร็ว 12%
  • การปรับขนาดจากจำนวนเธรดไปจนถึงการนับเธรดคู่ทำให้ไม่มีการเร่งความเร็วที่มีนัยสำคัญ เวลาที่ 12 และ 15 มักเป็นความผิดปกติทางสถิติที่คุณสามารถเพิกเฉยได้ เวลาที่ใช้ทั้งหมดเพิ่มขึ้นเล็กน้อยเช่นเดียวกับเวลาของระบบ ทั้งสองอย่างมักเกิดจากการสลับงานที่เพิ่มขึ้น ไม่มีประโยชน์ต่อสิ่งนี้

ตอนนี้ฉันเดา: ถ้าคุณทำอย่างอื่นบนคอมพิวเตอร์ของคุณให้ใช้การนับหลัก ถ้าคุณไม่ใช้การนับเธรด มากเกินไปแสดงว่าไม่มีประโยชน์ เมื่อถึงจุดหนึ่งหน่วยความจำจะถูก จำกัด และล่มสลายเนื่องจากการคอมไพล์ช้าลงมาก มีการเพิ่มบรรทัด "inf" ในภายหลังทำให้ฉันสงสัยว่ามีการควบคุมอุณหภูมิสำหรับงาน 8+ รายการ สิ่งนี้แสดงให้เห็นว่าสำหรับขนาดโปรเจ็กต์นี้ไม่มีผลต่อการ จำกัด หน่วยความจำหรือปริมาณงาน แม้ว่าจะเป็นโครงการขนาดเล็ก แต่ได้รับหน่วยความจำ 8GB ในการคอมไพล์


ตามstackoverflow.com/questions/56272639/…คุณจะได้เปรียบในการทำงานมากกว่าที่คุณมีซีพียู แต่เฉพาะในกรณีที่งานของคุณใช้เวลาส่วนใหญ่ในการรอเครือข่าย I / O สำหรับงานคอมไพล์นี่ไม่ใช่กรณี
ivan_pozdeev

30

โดยส่วนตัวฉันใช้โดยmake -j nที่ n คือ "จำนวนคอร์" + 1

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

อย่างไรก็ตามคุณต้องระวังเพราะ Make-chain บางตัวไม่เข้ากันได้กับ--jobsตัวเลือกนี้และอาจนำไปสู่ผลลัพธ์ที่ไม่คาดคิด หากคุณพบข้อผิดพลาดการพึ่งพาแปลกก็พยายามที่จะได้โดยไม่ต้องmake--jobs


19
คำอธิบาย (ไม่สามารถรับรองความเป็นวิทยาศาสตร์ได้) คือ "+ 1" ให้งานพิเศษที่ทำงานในขณะที่งานอื่น ๆ n กำลังทำ I / O
Laurynas Biveinis

@LaurynasBiveinis: แต่งานก็กำลังทำงานบนคอร์ที่แตกต่างกันตลอดเวลาอย่างน้อยก็บ่อยกว่าการตั้งค่าแบบอนุรักษ์นิยมมากกว่าที่งานจะได้รับโอกาสที่จะอยู่บนคอร์เดียวกันเป็นระยะเวลานานขึ้น มีข้อดีข้อเสียอยู่ที่นี่ ...
krlmlr

1
Number-of-cores + 1 เป็นค่าเริ่มต้นของฉันด้วย ปัญหาหนึ่งคือในระบบที่มีขนาดใหญ่พอสมควรดูเหมือนว่าจะทำให้การเชื่อมโยงล่าช้าและทำขั้นตอนการเชื่อมโยงทั้งหมดด้วยกัน ณ จุดนี้คุณไม่มีแรม บ๊ะ!
bobbogo

4
Make-chain บางตัวไม่สามารถใช้งานร่วมกับตัวเลือก --jobs -> ซึ่งหมายความว่าคุณขาดการอ้างอิง แก้ไข makefiles ของคุณหากคุณได้รับสิ่งนี้
dascandy

7

ท้ายที่สุดคุณจะต้องทำการเปรียบเทียบเพื่อกำหนดจำนวนที่ดีที่สุดที่จะใช้สำหรับงานสร้างของคุณ แต่อย่าลืมว่า CPU ไม่ใช่ทรัพยากรเดียวที่สำคัญ!

ตัวอย่างเช่นหากคุณมีงานสร้างที่ต้องอาศัยดิสก์เป็นจำนวนมากการสร้างงานจำนวนมากในระบบมัลติคอร์อาจช้าลงเนื่องจากดิสก์จะต้องทำงานพิเศษในการเคลื่อนย้ายหัวดิสก์ไปมาเพื่อให้บริการทั้งหมด งานที่แตกต่างกัน (ขึ้นอยู่กับปัจจัยหลายประการเช่นระบบปฏิบัติการจัดการกับดิสก์แคชได้ดีเพียงใดการสนับสนุนการจัดคิวคำสั่งดั้งเดิมโดยดิสก์เป็นต้น)

จากนั้นคุณก็มีคอร์ "จริง" เทียบกับไฮเปอร์เธรด คุณอาจได้รับประโยชน์หรือไม่ได้รับประโยชน์จากงานวางไข่สำหรับไฮเปอร์เธรดแต่ละรายการ อีกครั้งคุณจะต้องเปรียบเทียบเพื่อหาคำตอบ

ฉันไม่สามารถพูดได้ว่าฉันได้ลองใช้#cores + 1 เป็นพิเศษ แต่ในระบบของเรา (Intel i7 940, 4 ไฮเปอร์เธรดคอร์, RAM จำนวนมากและไดรฟ์ VelociRaptor) และบิลด์ของเรา ( บิลด์ C ++ ขนาดใหญ่ที่สลับ CPU และ I / O ที่ถูกผูกไว้) มีความแตกต่างกันเล็กน้อยระหว่าง -j4 และ -j8 (อาจจะดีกว่า 15% ... แต่ไม่มีที่ไหนที่ดีเป็นสองเท่า)

ถ้าฉันจะออกไปทานอาหารกลางวันฉันจะใช้ -j8 แต่ถ้าฉันต้องการใช้ระบบของฉันเพื่อสิ่งอื่นในขณะที่กำลังสร้างฉันจะใช้ตัวเลขที่ต่ำกว่า :)


1
ดูเหมือนจะดี แต่ฉันก็งงว่าทำไมคุณไม่ใช้แค่ + 15% ทุกครั้งโดยใช้-j 8
sg

1
@sg: j8 กำลังเก็บภาษีกับระบบที่ฉันอธิบายไว้ในโพสต์เดิมของฉัน ... เครื่องยังคงใช้งานได้แต่ก็ตอบสนองน้อยลงอย่างแน่นอน ดังนั้นหากฉันยังต้องการใช้มันแบบโต้ตอบกับงานอื่น ๆ (โดยปกติจะทำงานกับโค้ดอื่นและอาจจะเป็นบิลด์ DLL เดี่ยวเป็นครั้งคราว) ฉันจะสงวนสองคอร์สำหรับบิตโต้ตอบ
ijprest

@sg: นี่เป็นปัญหาน้อยกว่าในระบบใหม่ของเรา ... ฉันสงสัยว่าส่วนใหญ่เป็นเพราะเรากำลังใช้งาน SSD อยู่ในขณะนี้ (ฉันคิดว่าตอนนี้เราผูกพันกับ CPU โดยสิ้นเชิงที่เรากำลังจะไปที่ SSD ... เราพยายามสร้างทั้งหมดบนไดรฟ์ RAM โดยแทบไม่มีการปรับปรุงใด ๆ ) แต่ฉันจะยังคงปล่อยให้สองคอร์ว่างถ้าฉัน ทำอะไรก็ได้มากกว่าการแก้ไขข้อความธรรมดาในเบื้องหน้า
ijprest

5

ฉันเพิ่งได้รับ Athlon II X2 Regor proc พร้อม Foxconn M / B และหน่วยความจำ G-Skill 4GB

ฉันใส่ 'cat / proc / cpuinfo' และ 'free' ไว้ท้ายสิ่งนี้เพื่อให้คนอื่นเห็นสเป็คของฉัน เป็น Dual Core Athlon II x2 พร้อม RAM 4GB

uname -a on default slackware 14.0 kernel is 3.2.45.

ฉันดาวน์โหลดแหล่งเคอร์เนลขั้นตอนต่อไป (linux-3.2.46) ไปที่ / archive4;

สกัดมัน ( tar -xjvf linux-3.2.46.tar.bz2);

cd ลงในไดเร็กทอรี ( cd linux-3.2.46);

และคัดลอก config ของเคอร์เนลดีฟอลต์ over ( cp /usr/src/linux/.config .);

ใช้make oldconfigในการเตรียมการกำหนดค่าเคอร์เนล 3.2.46;

จากนั้นก็วิ่งด้วยคาถาต่างๆของ -jX

ฉันทดสอบการกำหนดเวลาของแต่ละรันโดยออก make หลังคำสั่ง time เช่น 'time make -j2' ระหว่างการรันแต่ละครั้งฉัน 'rm -rf' กับ linux-3.2.46 ทรีและดึงกลับใหม่คัดลอก /usr/src/linux/.config เริ่มต้นลงในไดเร็กทอรีรันสร้าง oldconfig จากนั้นทำการทดสอบ 'make -jX' อีกครั้ง .

"make" ธรรมดา:

real    51m47.510s
user    47m52.228s
sys     3m44.985s
bob@Moses:/archive4/linux-3.2.46$

ข้างต้น แต่มีการสร้าง -j2

real    27m3.194s
user    48m5.135s
sys     3m39.431s
bob@Moses:/archive4/linux-3.2.46$

ข้างต้น แต่มีการสร้าง -j3

real    27m30.203s
user    48m43.821s
sys     3m42.309s
bob@Moses:/archive4/linux-3.2.46$

ข้างต้น แต่มีการสร้าง -j4

real    27m32.023s
user    49m18.328s
sys     3m43.765s
bob@Moses:/archive4/linux-3.2.46$

ข้างต้น แต่มีการสร้าง -j8

real    28m28.112s
user    50m34.445s
sys     3m49.877s
bob@Moses:/archive4/linux-3.2.46$

'cat / proc / cpuinfo' ให้ผลตอบแทน:

bob@Moses:/archive4$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Athlon(tm) II X2 270 Processor
stepping        : 3
microcode       : 0x10000c8
cpu MHz         : 3399.957
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmo
v pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rd
tscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 p
opcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowpre
fetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips        : 6799.91
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Athlon(tm) II X2 270 Processor
stepping        : 3
microcode       : 0x10000c8
cpu MHz         : 3399.957
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmo
v pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rd
tscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 p
opcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowpre
fetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips        : 6799.94
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

ผลตอบแทน 'ฟรี':

bob@Moses:/archive4$ free
             total       used       free     shared    buffers     cached
Mem:       3991304    3834564     156740          0     519220    2515308

1
สิ่งที่make -jทำในระบบนั้น? Make ควรตรวจสอบโหลดและปรับขนาดจำนวนกระบวนการตามโหลด
docwhat

1
make -jไม่ จำกัด จำนวนงานเลย โดยปกติจะเป็นหายนะในโปรเจ็กต์ขนาดกลางหรือขนาดใหญ่เนื่องจากมีการแยกงานเร็วกว่าที่ RAM รองรับ ตัวเลือกที่คุณต้อง จำกัด โดยการโหลด-l [load]ร่วมกับ-j
Matt G

5

ทั้งสองอย่างไม่ผิด เพื่อความสงบสุขกับตัวคุณเองและกับผู้เขียนซอฟต์แวร์ที่คุณกำลังรวบรวม (ข้อ จำกัด แบบมัลติเธรด / เธรดเดียวที่แตกต่างกันมีผลบังคับใช้ในระดับซอฟต์แวร์เอง) ฉันขอแนะนำให้คุณใช้:

make -j`nproc`

หมายเหตุ: nprocเป็นคำสั่ง linux ที่จะส่งคืนจำนวนคอร์ / เธรด (CPU สมัยใหม่) ที่มีอยู่ในระบบ การวางไว้ใต้เครื่องหมาย `เช่นด้านบนจะส่งผ่านหมายเลขไปยังคำสั่ง make

ข้อมูลเพิ่มเติม: ตามที่มีคนกล่าวถึงการใช้คอร์ / เธรดทั้งหมดในการคอมไพล์ซอฟต์แวร์สามารถทำให้กล่องของคุณหายใจไม่ออกจนใกล้ตาย (ไม่ตอบสนอง) และอาจใช้เวลานานกว่าการใช้คอร์น้อยลง อย่างที่ฉันเห็นผู้ใช้ Slackware คนหนึ่งที่นี่โพสต์ว่าเขามีซีพียูแบบดูอัลคอร์ แต่ยังคงทดสอบได้ถึง j 8 ซึ่งหยุดการแตกต่างกันที่ j 2 (มีเพียง 2 แกนฮาร์ดแวร์ที่ CPU สามารถใช้ได้) ดังนั้นเพื่อหลีกเลี่ยงกล่องที่ไม่ตอบสนองฉันขอแนะนำให้คุณเรียกใช้เช่นนี้:

make -j`nproc --ignore=2`

สิ่งนี้จะส่งผ่านเอาต์พุตของnprocถึงmakeและลบ 2 คอร์จากผลลัพธ์


3

เช่นเดียวกับการอ้างอิง:

จากSpawning Multiple Build Jobsส่วนในLKD :

โดยที่ n คือจำนวนงานที่จะวางไข่ การปฏิบัติตามปกติคือการวางไข่หนึ่งหรือสองงานต่อโปรเซสเซอร์ ตัวอย่างเช่นบนเครื่องโปรเซสเซอร์คู่อาจมีคนทำ

$ ให้ j4


ลิงค์เสียคำพูดนี้มาจาก Linux Kernel Development โดย Robert Love หรือไม่?
Behrooz

ใช่มันมาจากหนังสือเล่มนั้น
Nan Xiao

1

จากประสบการณ์ของฉันต้องมีประโยชน์ด้านประสิทธิภาพเมื่อเพิ่มงานพิเศษ เป็นเพราะดิสก์ I / O เป็นหนึ่งในคอขวดนอกเหนือจาก CPU อย่างไรก็ตามไม่ใช่เรื่องง่ายที่จะตัดสินใจเกี่ยวกับจำนวนงานพิเศษเนื่องจากมีการเชื่อมต่อระหว่างกันอย่างมากด้วยจำนวนแกนและประเภทของดิสก์ที่ใช้


1

หลายปีต่อมาคำตอบส่วนใหญ่ยังคงถูกต้อง อย่างไรก็ตามมีการเปลี่ยนแปลงเล็กน้อย: การใช้งานมากกว่าที่คุณมีคอร์ทางกายภาพตอนนี้ให้ความเร็วที่สำคัญอย่างแท้จริง ในฐานะที่เป็นภาคผนวกของตาราง Dascandy นี่คือเวลาของฉันในการรวบรวมโปรเจ็กต์บน AMD Ryzen 5 3600X บน linux (ของเล่นแป้งกระทำ c6f653ac3cef03acfbc44e8f29f11e1b301f1ca2)

ฉันแนะนำให้ตรวจสอบตัวเอง แต่ฉันพบว่ามีข้อมูลจากผู้อื่นว่าการใช้การนับคอร์เชิงตรรกะของคุณในการนับจำนวนงานทำงานได้ดีบน Zen นอกจากนั้นระบบจะไม่สูญเสียการตอบสนอง ฉันคิดว่าสิ่งนี้ใช้ได้กับซีพียู Intel รุ่นล่าสุดเช่นกัน โปรดทราบว่าฉันมี SSD ด้วยดังนั้นจึงอาจคุ้มค่าที่จะทดสอบ CPU ของคุณด้วยตัวเอง

scons -j1 --release --native  120.68s user 9.78s system 99% cpu 2:10.60 total
scons -j2 --release --native  122.96s user 9.59s system 197% cpu 1:07.15 total
scons -j3 --release --native  125.62s user 9.75s system 292% cpu 46.291 total
scons -j4 --release --native  128.26s user 10.41s system 385% cpu 35.971 total
scons -j5 --release --native  133.73s user 10.33s system 476% cpu 30.241 total
scons -j6 --release --native  144.10s user 11.24s system 564% cpu 27.510 total
scons -j7 --release --native  153.64s user 11.61s system 653% cpu 25.297 total
scons -j8 --release --native  161.91s user 12.04s system 742% cpu 23.440 total
scons -j9 --release --native  169.09s user 12.38s system 827% cpu 21.923 total
scons -j10 --release --native  176.63s user 12.70s system 910% cpu 20.788 total
scons -j11 --release --native  184.57s user 13.18s system 989% cpu 19.976 total
scons -j12 --release --native  192.13s user 14.33s system 1055% cpu 19.553 total
scons -j13 --release --native  193.27s user 14.01s system 1052% cpu 19.698 total
scons -j14 --release --native  193.62s user 13.85s system 1076% cpu 19.270 total
scons -j15 --release --native  195.20s user 13.53s system 1056% cpu 19.755 total
scons -j16 --release --native  195.11s user 13.81s system 1060% cpu 19.692 total
( -jinf test not included, as it is not supported by scons.)

การทดสอบที่ทำบน Ubuntu 19.10 พร้อม Ryzen 5 3600X, Samsung 860 Evo SSD (SATA) และ RAM 32GB

หมายเหตุสุดท้าย: คนอื่น ๆ ที่มี 3600X อาจได้รับเวลาที่ดีกว่าฉัน เมื่อทำการทดสอบนี้ฉันได้เปิดใช้งานโหมด Eco ซึ่งจะลดความเร็วของ CPU ลงเล็กน้อย


0

ใช่! บน 3950x ของฉันฉันรัน -j32 และช่วยประหยัดเวลาในการคอมไพล์ได้หลายชั่วโมง! ฉันยังสามารถดู youtube ท่องเว็บ ฯลฯ ระหว่างการคอมไพล์ได้โดยไม่มีความแตกต่าง โปรเซสเซอร์ไม่ได้ถูกตรึงไว้เสมอแม้จะมี 1TB 970 PRO nvme หรือ 1TB Auros Gen4 nvme และ 64GB ที่ 3200C14 แม้ว่าจะเป็นเช่นนั้นฉันก็ไม่สังเกตเห็น UI ที่ชาญฉลาด ฉันวางแผนที่จะทดสอบกับ -j48 ในอนาคตอันใกล้สำหรับโครงการใหญ่ ๆ ที่กำลังจะเกิดขึ้น ฉันคาดหวังว่าคุณจะเห็นพัฒนาการที่น่าประทับใจบางอย่าง ผู้ที่ยังมี Quad-Core อาจไม่ได้รับผลตอบแทนเท่าเดิม ....

Linus เองเพิ่งอัพเกรดเป็น 3970x และคุณสามารถเดิมพันเงินต่ำสุดของคุณได้เขาก็วิ่ง -j64 เป็นอย่างน้อย

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.