Nu byter jag till AMD grafikkort (tack vare open source drivrutiner) och FX-8350 CPU

Permalänk
Medlem

Nu byter jag till AMD grafikkort (tack vare open source drivrutiner) och FX-8350 CPU

Har tidigare mest kört nvidia grafikkort och deras proprietära drivrutiner men vill gärna gynna open source. Kollade lite och såg att nu kan man till och med få hårdvaruaccelererad video med open source drivarna för AMD grafik och prestandan verkar hyfsad i övrigt. Noveau är väl inte så mycket att hänga i julgranen och nvidia supportar inte alls open source.

Test av open source AMD grafikdrivrutiner:
http://www.phoronix.com/scan.php?page=article&item=amd_hd6000...

Så mitt gamla nvidia 9600GT byts nu ut mot HD6670 och jag skippar de proprietära drivrutinerna om möjligt. Uppgraderar dessutom min Xeon X3350 till AMD FX-8350. AMD all the way liksom... Jag som egentligen hade tänkt skaffa intel Haswell Core i7 4770 med inbyggd grafik vid nästa uppgradering men så kom jag på att FX-8350 är tillräckligt bra för en billigare peng. Hittade prylarna begagnat så det blev inte jättedyrt. Men visst, intel har väl generellt bättre Linux-stöd. Bra eller dåligt beslut? Vi får se hur det funkar.

HD 6670 räcker och blir över, jag spelar sällan spel. Kör Arch Linux så jag lär väl få de senaste drivrutinerna så snart de släpps. Linuxkärnan 3.11 ska ju även ge strömsparlägen "out of the box" för AMD-grafik. Är trött på mitt gamla nvidiakort som låter som dammsugare innan xorg startar (sedan hörs det inte alls). Och med Linux kan man väl få det tämligen optimerat för AMD FX-8350.

Moderkortet har stöd för ECC-minnen och IOMMU (Gigabyte GA-970A-UD3), gav 300 kr för det begagnat. Kan man nog ha skoj med! FX-8350 gav jag 1089 kr + frakt för på Tradera. HD6770 hittade jag begagnat på marknaden för 360 kr + frakt. Samt 8 GB DDR3 (icke ECC) för 250 kr på sweclockers marknad. Känns prisvärt (om allt funkar nu då vill säga). Enda jag köpt nytt för denna uppgradering är CPU-kylare.

Permalänk
Medlem

har för mig att man måste lägga "radeon.dpm=1" till kernelns boot kommandorad

Permalänk
Medlem
Skrivet av sebmod:

har för mig att man måste lägga "radeon.dpm=1" till kernelns boot kommandorad

OK, det ska jag göra. Tack för tipset!
Något annat man ska tänka på?

Jag ska prova att köra linux-ck kerneln för piledriver och ställa in optimerade parametrar i gcc konfigurationen så jag kan kompilera om x264 och ffmpeg som jag använder en hel del när jag komprimerar video. Kul att se om det blir någon skillnad. Dessutom borde väl själva kompileringen gå något fortare med 8 kärnor?

Permalänk
Medlem
Skrivet av ronnylov:

OK, det ska jag göra. Tack för tipset!
Något annat man ska tänka på?

Jag ska prova att köra linux-ck kerneln för piledriver och ställa in optimerade parametrar i gcc konfigurationen så jag kan kompilera om x264 och ffmpeg som jag använder en hel del när jag komprimerar video. Kul att se om det blir någon skillnad. Dessutom borde väl själva kompileringen gå något fortare med 8 kärnor?

Kompilering skalar 100% med kärna så jag gissar att det blir avsevärt snabbare. Kan dock inte hitta informationen eller vart jag fick det från men du får väl testa =). Gå in i makepkg och ändra/lägg till MAKEFLAGS="" till MAKEFLAGS="-j4" för 4 kärnor och -j8 för 8 kärnor/threads.

Vissa program kan ha problem att kompileras med mer än 1-2 kärnor men oftast brukar PBKBUILD ha specifierat egna Makeflags för just antalet kärnor.

Jag är själv snart påväg mot en 8350 så det vore kul om du testade kompilera Wine-Multimedia med 8/4/2/1 kärnor och ta tid på detta.

Kommer dock hålla kvar mig till nVidia då deras drivrutiner presterar ut alla andra på Linux när det kommer till prestanda och support för spel. Phoronix är väldigt glada att ta upp nyheter och göra grafer men mycket glöms hur extremt dålig Catalyst faktiskt är på Linux med 50% prestandaförluster mot deras Windowsmotsvarighet i många scenarion.

Visa signatur

Arch - Makepkg, not war -||- Gigabyte X570 Aorus Master -||- GSkill 64GiB DDR4 14-14-15-35-1T 3600Mhz -||- AMD 5900x-||- Gigabyte RX6900XT -||- 2x Adata XPG sx8200 Pro 1TB -||- EVGA G2 750W -||- Corsair 570x -||- O2+ODAC-||- Sennheiser HD-650 -|| Boycott EA,2K,Activision,Ubisoft,WB,EGS
Arch Linux, one hell of a distribution.

Permalänk
Datavetare

Kompilering skalar väldigt bra och handlar det om C++, gärna med massor med templates, så kommer man nog väldigt nära 100% skalning. Andra saker som C, Java och kanske framförallt Go (som är gjort för att vara snabbt att kompilera) kommer ha något sämre skalning då det även finns I/O-overhead och seriella delar i make för att hålla ett visst antal jobb igång.

Men visst kommer FX-8350 8-kärnor till sin rätt vid kompilering, TomsHardware gjorde ett test på detta (Chrome är skrivet i C++)

Har föreslagit att även SweC ska lägga till ett kompilator-benchmark till sina CPU-test + att föreslagit just jämförelse mellan använda 1 CPU-tråd, 2 CPU-trådar där båda ligger på samma "modul" (AMD) eller samma CPU-kärna (Intel med HT) samt fallet 2 CPU-trådar där de ligger på olika moduler/kärnor.

Om någon här har Linux installerad på ett system med Piledriver/Bulldozer så hjälper jag gärna till med att konstruera ett enkelt kompilator-benchmark som visar skalning över CPU-kärnor.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Datavetare

Vill gärna höra hur dina erfarenheter kring AMDs GPU på Linux. Vi körde tidigare väldigt mycket AMD på jobbet men vi undvek ATI/AMD-grafik som pesten då det var väldigt instabilt, de datorer som IT levererade med ATI/AMD-kort fick man byta ut det mot något cheapo-nVidia då det viktiga är att vanliga desktopen fungerar...

Numera kör vi Intels CPU med deras IGP (både på stationär och desktop) och det har fungerat klockrent, men det vore ju inte fel om AMDs öppna drivare närmade sig Intels vad det gäller kvalité på Linux så man har lite mer att välja på.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Jag bytte själv från nvidia till amds öppna drivrutiner för några år sedan. Nvidias drivrutiner var hyfsade egentligen men det fanns vissa buggar som var kvar år efter år. Amds drivrutiner har fler buggar överlag men de fixas mycket snabbare.

Skrivet av ronnylov:

Något annat man ska tänka på?

Nvidia har en kontrollpanel men amd kör med envvars i stället. Om du t.ex. vill tvinga på AA så anväder du __GL_FSAA_MODE=8. Om du vill disablela vsync, vilket är aktivt som default, använder du vblank_mode=0. Det finns många andra men tyvärr finns det ingen dokumentation för dom. Du måste greppa mesas kod för att hitta alla.

Det finns flera olika optimization backends och den som används som default är inget vidare. Exportera R600_DEBUG=sb för att använda den mest optimerade. Den kan ge upp mot dubbel frameraten i vissa program men runt 30% ökning är mer normalt.

Om du försöker göra performance tuning men spelet inte visar fps kan du enablea en hud som visar statistik med GALLIUM_HUD=fps;draw-calls;requested-VRAM. Det finns massa andra saker den kan visa men dokumentationen är dålig (genomgående tema för hela mesa).

Permalänk
Medlem

Jag är igång med FX-8350 men kör fortfarande på mitt gamla nvidia-kort (testar byta grafikkortet när jag har full koll på att processorn funkar). Hade först problem med att den throttlade efter en stund när jag körde mprime stresstest. Men det verkar ha löst sig nu med en fläkt som ger lite luftflöde över moderkortet (tydligen kan VRM överhettas på mitt moderkort).

En fråga: Jag får den inte att gå över 4 GHz trots att jag kör 1 tråd. Borde inte turbofunktionen köra upp den till 4,2 GHz när man kör fåtrådat? Eller funkar inte det i Linux? Den kör 4 GHz på belastade kärnor oavsett om jag kör 1, 2 eller 8 trådar i mprime. Jag försöker inte överklocka men jag vill ju att den ska fungera på avsett sätt vid originalklock.

Edit: Kanhända turbo core fungerar men att det inte syns när man läser av frekvenserna i linux? Ska kolla hur det blir om jag kör benchmark i mprime med och utan turbofunktionen aktiverad i bios (borde bli skillnad i resultatet om jag väljer få trådar). Kollar det i kväll.

Edit 2: Verkar vara ett indikeringsproblem. Min visar också 1400 MHz i idle och 4 GHz i load oavsett antal trådar.
http://www.phoronix.com/scan.php?page=article&item=amd_fx8150...

Citat:

When there's no load on the FX-8150 with Cool 'n' Quiet enabled, the frequency drops down to 1400MHz rather than running at the default 3600MHz. (Worth noting is that when Turbo Core is enabled, the higher CPU frequency doesn't seem to be indicated by any of the normal interfaces.)

Permalänk
Datavetare
Skrivet av ronnylov:

Jag är igång med FX-8350 men kör fortfarande på mitt gamla nvidia-kort (testar byta grafikkortet när jag har full koll på att processorn funkar). Hade först problem med att den throttlade efter en stund när jag körde mprime stresstest. Men det verkar ha löst sig nu med en fläkt som ger lite luftflöde över moderkortet (tydligen kan VRM överhettas på mitt moderkort).

En fråga: Jag får den inte att gå över 4 GHz trots att jag kör 1 tråd. Borde inte turbofunktionen köra upp den till 4,2 GHz när man kör fåtrådat? Eller funkar inte det i Linux? Den kör 4 GHz på belastade kärnor oavsett om jag kör 1, 2 eller 8 trådar i mprime. Jag försöker inte överklocka men jag vill ju att den ska fungera på avsett sätt vid originalklock.

Edit: Kanhända turbo core fungerar men att det inte syns när man läser av frekvenserna i linux? Ska kolla hur det blir om jag kör benchmark i mprime med och utan turbofunktionen aktiverad i bios (borde bli skillnad i resultatet om jag väljer få trådar). Kollar det i kväll.

Edit 2: Verkar vara ett indikeringsproblem. Min visar också 1400 MHz i idle och 4 GHz i load oavsett antal trådar.
http://www.phoronix.com/scan.php?page=article&item=amd_fx8150...

Dold text

Det är ett likande problem även på Intel, där ser man alla nivåer av "nominell frekvens" (eller vad man ska kalla det) men man ser inte "turbo frekvenserna". Men "turbo frekvenserna" används, det är något CPUn tar hand om automatiskt utan att OSet kan påverka det och använder man t.ex. Intel Performance Counter så ser man även turbo-frekvenserna (en annan kul egenskap med detta program är att den direkt visar saker som IPC, cache-hit-rate m.m, riktigt nörd info )

Så är rätt säker på att din CPU aktiverar "turbo core" då det styrs av CPUn själv, men vill du verkligen se vilken frekvens den kör på behövs nog något likt programmet ovan fast för AMD.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Jag har hittat att man kan använda cpufreq-aperf för att undersöka aktuella frekvenser i turboläget. Kräver att man laddar modulen msr först. Enligt denna guide för debian: http://forums.debian.net/viewtopic.php?f=16&t=91770

watch -n 2 cpufreq-aperf -o

Ger kontinuerlig information med uppdateringsintervall 2 sekunder.

Ska testa det när jag kommer hem ikväll.

Programmet cpufreq-aperf verkar inte finnas till Arch Linux. Jag hittar det inte...

Edit: Arch kör cpupower istället. Finns ett kommando som heter cpupower monitor som kan användas på liknande sätt.

OK, efter många timmars pågående mprime torture test på alla 8 kärnorna:

[ronny@r1arch ~]$ sudo modprobe msr [ronny@r1arch ~]$ sudo cpupower monitor |Mperf || Idle_Stats CPU | C0 | Cx | Freq || POLL | C1 | C2 0| 99,91| 0,09| 3891|| 0,00| 0,00| 0,00 4| 99,91| 0,09| 3891|| 0,00| 0,00| 0,00 2| 99,90| 0,10| 3891|| 0,00| 0,00| 0,00 1| 99,90| 0,10| 3891|| 0,00| 0,00| 0,00 3| 99,90| 0,10| 3891|| 0,00| 0,00| 0,00 5| 99,90| 0,10| 3891|| 0,00| 0,00| 0,00 6| 99,90| 0,10| 3891|| 0,00| 0,00| 0,00 7| 99,90| 0,10| 3891|| 0,00| 0,00| 0,00

De traditionella verktygen säger att kärnorna ligger på 4 GHz men tydligen kör de bara i 3,9 GHz. Men det där är väl någon snittfart tror jag.

Citat:

Mperf shows the average frequency of a CPU, including boost frequencies, over a period of time. Additionally, it shows the percentage of time the CPU has been active (C0) or in any sleep state (Cx). The default sampling rate is 1 second and the values are read directly from the hardware registers. As the turbo states are managed by the BIOS, it is impossible to get the frequency values at a given instant. On modern processors with turbo features the Mperf monitor is the only way to find out about the frequency a certain CPU has been running in.

http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_dr...

Så jag testar torture test på bara 1 tråd:

|Mperf || Idle_Stats CPU | C0 | Cx | Freq || POLL | C1 | C2 0| 2,41| 97,59| 1399|| 0,00| 0,02| 97,62 4| 0,06| 99,94| 1391|| 0,00| 0,00| 99,95 2| 0,03| 99,97| 1386|| 0,00| 0,00| 99,97 1| 0,40| 99,60| 1396|| 0,00| 0,00| 99,61 3| 0,13| 99,87| 4159|| 0,00| 0,00| 99,88 5| 99,96| 0,04| 4195|| 0,00| 0,00| 0,00 6| 0,99| 99,01| 1403|| 0,00| 0,02| 99,02 7| 0,13| 99,87| 1825|| 0,00| 0,00| 99,89

Ja nu kör den i 4,2 GHz som den ska på turbo. Det ska funka på upp till 4 kärnor så jag testar 4 trådar:

|Mperf || Idle_Stats CPU | C0 | Cx | Freq || POLL | C1 | C2 0| 99,90| 0,10| 4022|| 0,00| 0,00| 0,00 4| 0,35| 99,65| 4026|| 0,00| 0,00| 99,70 2| 99,90| 0,10| 4022|| 0,00| 0,00| 0,00 1| 1,08| 98,92| 4024|| 0,00| 0,00| 98,96 3| 0,46| 99,54| 4008|| 0,00| 0,00| 99,60 5| 99,90| 0,10| 4022|| 0,00| 0,00| 0,00 6| 0,49| 99,51| 4021|| 0,00| 0,00| 99,55 7| 99,90| 0,10| 4022|| 0,00| 0,00| 0,00

Vad nu, den kör ju bara i 4,0 GHz? Fast på alla kärnor. Mysko. Jag testar 2 trådar.

|Mperf || Idle_Stats CPU | C0 | Cx | Freq || POLL | C1 | C2 0| 1,23| 98,77| 1398|| 0,00| 0,10| 98,74 4| 0,32| 99,68| 1397|| 0,00| 0,00| 99,70 2| 0,24| 99,76| 1691|| 0,00| 0,00| 99,77 1| 0,70| 99,30| 1401|| 0,00| 0,00| 99,32 3| 0,11| 99,89| 4148|| 0,00| 0,00| 99,91 5| 99,94| 0,06| 4191|| 0,00| 0,00| 0,00 6| 0,09| 99,91| 4121|| 0,00| 0,00| 99,92 7| 99,94| 0,06| 4191|| 0,00| 0,00| 0,00

Ja det blir 4,1 - 4,2 GHz sisådär. Min slutsats är att turbo core fungerar som det är tänkt och kanske går min processor lite väl varmt eftersom den inte gör 4,1 GHz utan snarare 3,9 GHz vid full load på alla kärnor. Å andra sidan är väl mprime torture test ganska tuff belastning så vid normal drift så ska det nog funka hyfsat.

Testar låta den svalna en stund och därefter mprime torture test med 8 trådar och snabbkoll av frekvenserna innan den blir varm:

|Mperf || Idle_Stats CPU | C0 | Cx | Freq || POLL | C1 | C2 0| 99,86| 0,14| 3960|| 0,00| 0,00| 0,00 4| 99,87| 0,13| 3960|| 0,00| 0,00| 0,00 2| 99,86| 0,14| 3960|| 0,00| 0,00| 0,00 1| 99,86| 0,14| 3960|| 0,00| 0,00| 0,00 3| 99,86| 0,14| 3960|| 0,00| 0,00| 0,00 5| 99,86| 0,14| 3960|| 0,00| 0,00| 0,00 6| 99,86| 0,14| 3960|| 0,00| 0,00| 0,00 7| 99,86| 0,14| 3960|| 0,00| 0,00| 0,00

Nu ligger alla kärnorna på ungefär 4 GHz.

Efter ett par minuter:

|Mperf || Idle_Stats CPU | C0 | Cx | Freq || POLL | C1 | C2 0| 99,88| 0,12| 3845|| 0,00| 0,00| 0,00 4| 99,88| 0,12| 3845|| 0,00| 0,00| 0,00 2| 99,87| 0,13| 3845|| 0,00| 0,00| 0,00 1| 99,87| 0,13| 3845|| 0,00| 0,00| 0,00 3| 99,87| 0,13| 3845|| 0,00| 0,00| 0,00 5| 99,87| 0,13| 3845|| 0,00| 0,00| 0,00 6| 99,87| 0,13| 3845|| 0,00| 0,00| 0,00 7| 99,87| 0,13| 3845|| 0,00| 0,00| 0,00

Hmmm, kanske ska se över kylningen. Ser ut att throttla lite grann. Eller så varierar frekvensen naturligt beroende på varierande belastning?

Permalänk
Medlem

Liten uppdatering.

Nu har jag även bytt grafikkortet från nvidia 9600GT till Radeon HD6670. Nya grafikkortet har tyst fläkt även i BIOS så det känns inte så akut med power management och fläktstyrning. Men jag kör open source drivrutin för grafiken och har fått hårdvaruacceleration av video att fungera. Tydligen hade mesa precis uppdaterats till version 9.2 i Arch Linux så vdpau funkar med radeon öppna drivrutin. Får 0-1 % processoranvändning när jag kollar video.

Vet inte om det är inbillning men hela datorn känns snabbare med nya grafikkortet. Kanske detekteras det fortare så att bootningen går igång snabbare. Sedan känns det som 2D-grafiken är snabbare än innan. 3D har jag endast testat i extreme tux racer och det flöt förstås på jättebra (det är nog inte så krävande).

Ska jag köra tester med kompilering och olika antal kärnor?

Permalänk

Skulle vara kul om du kunde lägga upp tiden det tar att kompilera olika program!

Permalänk
Medlem
Skrivet av ronnylov:

Liten uppdatering.

Nu har jag även bytt grafikkortet från nvidia 9600GT till Radeon HD6670. Nya grafikkortet har tyst fläkt även i BIOS så det känns inte så akut med power management och fläktstyrning. Men jag kör open source drivrutin för grafiken och har fått hårdvaruacceleration av video att fungera. Tydligen hade mesa precis uppdaterats till version 9.2 i Arch Linux så vdpau funkar med radeon öppna drivrutin. Får 0-1 % processoranvändning när jag kollar video.

Vet inte om det är inbillning men hela datorn känns snabbare med nya grafikkortet. Kanske detekteras det fortare så att bootningen går igång snabbare. Sedan känns det som 2D-grafiken är snabbare än innan. 3D har jag endast testat i extreme tux racer och det flöt förstås på jättebra (det är nog inte så krävande).

Ska jag köra tester med kompilering och olika antal kärnor?

HD6670 är ungefär lika snabbt som GTS250, alltså en hel del bättre än 9600GT, dessutom med stöd för flera nya tekniker som saknas i 9600GT så visst bör du uppleva det som bättre.

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-DDR5-6400c32 MSI RTX4080 Ventus 3X OC || CORE i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 Gear1 TUF RTX3080 OC V2 || R7 5800X3D X570S CH8 Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super ||

Permalänk
Medlem

Angående throttling, de där sakerna blir varma och har dessutom en sjukt opålitlig tempsensor. Minns att när Bulldozer presenterades så spekulerades det i om AMD skulle skicka med vattenkylningskit eftersom presskitet innehöll en Antec 620 med AMD-logga på. Så blev det inte, till att börja med säljs de för billigt för det, men den där vattenkylningen behövs nog fortfarande.

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-DDR5-6400c32 MSI RTX4080 Ventus 3X OC || CORE i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 Gear1 TUF RTX3080 OC V2 || R7 5800X3D X570S CH8 Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super ||

Permalänk
Datavetare
Skrivet av ronnylov:

Liten uppdatering.

Nu har jag även bytt grafikkortet från nvidia 9600GT till Radeon HD6670. Nya grafikkortet har tyst fläkt även i BIOS så det känns inte så akut med power management och fläktstyrning. Men jag kör open source drivrutin för grafiken och har fått hårdvaruacceleration av video att fungera. Tydligen hade mesa precis uppdaterats till version 9.2 i Arch Linux så vdpau funkar med radeon öppna drivrutin. Får 0-1 % processoranvändning när jag kollar video.

Vet inte om det är inbillning men hela datorn känns snabbare med nya grafikkortet. Kanske detekteras det fortare så att bootningen går igång snabbare. Sedan känns det som 2D-grafiken är snabbare än innan. 3D har jag endast testat i extreme tux racer och det flöt förstås på jättebra (det är nog inte så krävande).

Ska jag köra tester med kompilering och olika antal kärnor?

Dold text

Skulle vara intressant att se utskriften från cat /proc/cpuinfo, där står bl.a. hur många fysiska kärnor (cpu cores), CPU-trådar (siblings) och hur dessa har numrerats. På en i7 2600 ser man att det finns 4 kärnor, 8 CPU-trådar och numreringen är C0T0,C1T0,C2T0,C3T0,C0T1,C1T1,C2T1,C3T1 (C=core, T=thread).

processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 microcode : 0x14 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6823.00 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 microcode : 0x14 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6822.89 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 microcode : 0x14 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6822.89 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 microcode : 0x14 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6822.89 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 4 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 microcode : 0x14 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6822.89 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 5 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 microcode : 0x14 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6822.89 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 6 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 microcode : 0x14 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 5 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6822.88 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping : 7 microcode : 0x14 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6822.88 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:

Dold text

Man kan då använda taskset med mask 0x1, 0x11 och 0x33 för att testa köra något med 1 CPU-kärna / 1 tråd, 1 CPU-kärna / båda trådarna respektive 2 kärnor / 1 tråd per kärna på detta sätt

$ time taskset 0x1 <det man vill mäta> $ time taskset 0x11 <det man vill mäta> $ time taskset 0x3 <det man vill mäta>

Ett lämpligt exempelprojekt kanske är gdb, inte allt för stort (att bygga t.ex. firefox eller chromium kommer säkert ta över en timme om man gör det med en CPU-kärna..).

Din maskin är nog inte uppsatt för att bygga gdb, men det är väldigt enkelt att fixa med apt-get.

$ sudo apt-get build-dep gdb $ mkdir <något dir> $ cd <något dir> $ apt-get source --compile gdb

Detta kommer ladda ner alla paket som krävs för att bygga gdb, skapa ett bibliotek där du kommer bygga, gå ner i biblioteket och sedan laddaer + kompilera gdb.

Låt det hela kompileras den första gången så allt hamnar i disk-cache, de mätningar man sedan gör får då samma förutsättningar. Min gissning är att det är samma numreing för moduler/trådar som för kärnor/trådar på Intel alt. så är det tråd0 sedan tråd1 på samma modul. Oavsett så ger mask 0x1, 0x11 samt 0x3 alla kombinationer och resultat lär visa när man kör på samma resp. olika moduler.

Kör testerna så här (versionsnummret på GDB kan skilja för dig, jag kör Ubuntu 12.04)

$ cd gdb-7.4-2012.04/build/objdir

Här ska det finnas en fil med namnet Makefile

Följande rad kompilerar en gång med mask 0x1, 0x11 samt 0x3 och skriver ner resultatet i result.txt

$ rm -f result.txt; for mask in 0x1 0x11 0x3; do make clean >/dev/null 2>/dev/null; echo "Mask $mask:" >> result.txt; /usr/bin/time -o result.txt -a taskset $mask make -j >/dev/null 2>/dev/null; done

På min i7-2600 blir resultatet

Mask 0x1: 39.46user 4.06system 0:49.63elapsed 87%CPU (0avgtext+0avgdata 340784maxresident)k 0inputs+690136outputs (0major+4824537minor)pagefaults 0swaps Mask 0x11: 65.04user 6.64system 0:40.71elapsed 176%CPU (0avgtext+0avgdata 340784maxresident)k 0inputs+690144outputs (0major+4823345minor)pagefaults 0swaps Mask 0x3: 40.58user 4.42system 0:26.90elapsed 167%CPU (0avgtext+0avgdata 340784maxresident)k 0inputs+690152outputs (0major+4823611minor)pagefaults 0swaps

Dold text

Det relevant är "elapsed". På en kärna tar det 49.6s, på en kärna två HT tar det 40.7s (22% snabbare) och på två "fysiska" kärnor tar det 26.9s (84% snabbare).

Att det inte skalar bättre beror på att gdb är skrivet i C och det tar väldigt lite tid att kompilera en C fil så man får en hel del "system" tid i form av att köra fork() för att starta nya gcc instanser som begränsar skalbarheten. Bygger man C++ projekt så tar det mycket längre tid att kompilera varje fil och skalningen blir då mycket mer linjär.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Jag har Arch Linux men ska nog klura ut det ändå. Normalt när jag installerar något från Arch User Repository så får jag kompilera programmet så datorn är redan konfigurerad att kompilera.

Paketet gdb finns ju:
https://www.archlinux.org/packages/extra/x86_64/gdb/

Kan kompileras så här:
https://wiki.archlinux.org/index.php/ABS

Jag kan ändra i /etc/makepkg.conf så att den använder endast 1 tråd eller 2 trådar (eller flera) med -j flaggan.

Skulle jag då kunna mäta på följande sätt

time makepkg -s

med olika inställningar på -j flaggan i makepkg.conf?
Jag kör först en gång men -j8 för att lagra filerna i filcachen?

Men det verkar gå att få mera kontroll på kärnor/trådar med ditt förslag virtual_void och så slipper jag hela tiden redigera makepkg.conf. Annars borde väl Linuxkärnan välja vilka kärnor den lägger trådarna på? Jag har sett att även om jag kör enkeltrådat så hoppar belastningen runt mellan olika kärnor hela tiden. Detta kanske görs av operativsystemet för att fördela värmen bättre i processorn? Eller så är det processorn själv som skickar runt trådarna till olika kärnor? Ja ni får ursäkta jag har dålig koll på moduler och kärnor. Är det 4 kärnor och 8 moduler? Som jag fattat det så kickar turbo in om man belastar max en modul per kärna så det borde bli snabbare om trådarna fördelas ut till olika kärnor i första hand innan den börjar använda båda modulerna i en kärna. Det är detta som schedulern i Linuxkärnan sköter om? Blir det inte fel då att tvinga trådarna till två moduler på en kärna, detta kanske är något som normalt inte inträffar om man kör färre än 4 trådar? Känns mest normalt att bara ange antalet trådar med -j flaggan så får resten bli som det blir? Kan kanske vara intressant att se hur det blir om man sätter 10 trådar eller 12 trådar?

Finns ju specialkärnor för Linux.
https://wiki.archlinux.org/index.php/Linux-ck
Brain Fuck Scheduler ska tydligen vara bra på desktop.
Detta kan också påverka prestandan någon procent:
http://repo-ck.com/bench/cpu_schedulers_compared.pdf
Kan ju vara kul att jämföra även om det inte gör så stor skillnad.
Verkar som BFS ger bäst prestanda vid kompilering om man anger -j till samma som antalet kärnor i processorn (eller antalet trådar som kan köras parallellt snarare).

Dessutom har vi det här med turbofunktionens påverkan. Kör jag bara 1 och 2 trådar så hamnar de båda på 4,2 GHz troligtvis. Kör jag 8 trådar så blir det 4 GHz. Däremellan finns också 4,1 GHz läget. Det är väl också något man ska ha i bakhuvudet när man jämför hur den skalar på flera trådar.

Permalänk
Datavetare

Du kommer inte kunna styra "make -j2" så att den alltid använder två CPU-trådar i samma modul, för det måste du köra med "taskset". Det blir också en skev jämförelse om man kör "make -j1" mot "make -j2", inte alls orimligt att "-j2" ger mer än dubbla prestanda om du har en CPU med fler än 2 CPU-kärnor...

För att se hur mycket en, två CPU-trådar samma modul samt två CPU-trådar olika moduler ger ska du köra t.ex.

$ time taskset 0x1 makepkg -s $ time taskset 0x11 makepkg -s $ time taskset 0x3 makepkg -s

Skicka sedan in "-j4" till make och inte "-j2" för att ge systemet lite "parallel slackness", i.e. det ska finns mer potentiell parallellism än det finns CPU-kärnor. Anledningen är att det ger OSet fler möjligheter att säkerställa att alla CPU-trådar man tillåter jobba jobbar på 100%.

Tror du inte kommer märka någon skillnad i praktiken med en annan scheduler. BFS gjordes mest för att författaren tyckte att schemaläggaren i Linux blivit så komplicerad och författaren menar att det kanske är vettigt på system med väldigt många kärnor (20-30st eller fler) men på "vanliga" datorer är det helt onödigt (<16 CPU-kärnor). BFS har visat sig fungera väldigt bra upp till just 12-16 CPU-kärnor trots en extremt simpel design.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

cat /proc/cpuinfo

processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.69 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 1 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 1 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.69 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 2 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.69 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 3 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 3 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.69 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 4 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 7 cpu cores : 4 apicid : 4 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.69 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 5 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 6 cpu cores : 4 apicid : 5 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.69 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 6 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 5 cpu cores : 4 apicid : 6 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.69 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 7 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 4 cpu cores : 4 apicid : 7 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.69 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

Dold text

Skrivet av Yoshman:

Du kommer inte kunna styra "make -j2" så att den alltid använder två CPU-trådar i samma modul, för det måste du köra med "taskset". Det blir också en skev jämförelse om man kör "make -j1" mot "make -j2", inte alls orimligt att "-j2" ger mer än dubbla prestanda om du har en CPU med fler än 2 CPU-kärnor...

För att se hur mycket en, två CPU-trådar samma modul samt två CPU-trådar olika moduler ger ska du köra t.ex.

$ time taskset 0x1 makepkg -s $ time taskset 0x11 makepkg -s $ time taskset 0x3 makepkg -s

Skicka sedan in "-j4" till make och inte "-j2" för att ge systemet lite "parallel slackness", i.e. det ska finns mer potentiell parallellism än det finns CPU-kärnor. Anledningen är att det ger OSet fler möjligheter att säkerställa att alla CPU-trådar man tillåter jobba jobbar på 100%.

Tror du inte kommer märka någon skillnad i praktiken med en annan scheduler. BFS gjordes mest för att författaren tyckte att schemaläggaren i Linux blivit så komplicerad och författaren menar att det kanske är vettigt på system med väldigt många kärnor (20-30st eller fler) men på "vanliga" datorer är det helt onödigt (<16 CPU-kärnor). BFS har visat sig fungera väldigt bra upp till just 12-16 CPU-kärnor trots en extremt simpel design.

$ time taskset 0x1 makepkg -f -s

gav följande:

real 2m48.349s user 2m18.513s sys 0m9.803s

$ time taskset 0x11 makepkg -f -s

gav följande:

real 1m38.688s user 1m57.070s sys 0m11.760s

$ time taskset 0x3 makepkg -f -s

gav följande:

real 1m38.688s user 1m56.787s sys 0m11.280s

Fast först packar den upp källfilen (enkeltrådat) gör massa "checking", också enkeltrådat och så småningom kompilerar den (multitrådat) och slutligen packar den ihop allting till en paketfil vilket återigen är enkeltrådat. Eftersom gdb är ganska snabbkompilerat blir den multitrådade andelen i skapandet av paketet ganska kort. Men det märktes rejäl skillnad på den multitrådade delen när man kör fullt ös (med -j 8 och alla kärnor):

real 1m10.543s user 2m23.657s sys 0m14.367s

Verkar inte tjäna något på att öka till -j10, det blev långsammare:

real 1m12.894s user 2m23.793s sys 0m15.110s

Är nog intressantare jämföra något som tar längre tid att kompilera så att den multitrådade kompileringen får en större andel av totala tiden. Så jag kompilerar gtk3 istället...
Med -j 8 och alltså fullt ös:

real 2m41.540s user 5m40.847s sys 0m39.063s

Fasen också det går ju också fort... Jaja men vi testar det ändå.

Ändrar till -j4 i makepkg.conf och kör

time taskset 0x1 makepkg -f -s

real 5m22.016s user 4m25.687s sys 0m26.360s

time taskset 0x11 makepkg -f -s

real 3m50.981s user 4m39.567s sys 0m31.843s

time taskset 0x3 makepkg -f -s

real 3m50.517s user 4m38.527s sys 0m31.883s

Slutsatsen verkar vara att det skalar lika bra att köra två trådar på två moduler i en kärna som det gör att köra två trådar i varsin kärna. Det syntes skillnad i staplarna i min panelplugin att med 0x3 så kördes två staplar tätt intill varandra och med 0x11 var de två staplarna mera utspridda. Tyvärr är det inte allt som körs multitådat när man bygger ett paket men de delar när den kompilerar många små filer på följd verkar skala bra till flera kärnor.

Permalänk
Datavetare

cat /proc/cpuinfo ger förklaringen till varför mask 0x11 och 0x3 ger samma resultat, det var en väldigt skum ordning på (logiska) kärnorna... Ordningen är 0,3,1,2,7,6,5,4

Mask 0x1 kommer använda kärna 0
Mask 0x3 kommer använda kärna 0 och 3 och de lär ligga på olika moduler
Mask 0x11 kommer använda kärna 0 och 7 vilket också lär ligga på olika moduler och förklara varför resultatet blir det samma som mask 0x3.

De CPU-trådar som ligger på samma modul lär endera vara 0 och 1 eller 0 och 4, så testa mask 0x5 (kärna 0 och 1) samt mask 0x81 (kärna 0 och 4).

Precis som du beskriver så händer massa saker som bara kan köra på en tråd (köra configure), var därför min beskrivning bara körde den första vändan med apt-get source --build gdb men lät alla tester göra make clean och make -j i det färdigkonfigurerade trädet, då ha man plockat bort den seriella delen som ställer till det om man bara vill se hur mycket effekt man får på själva kompileringen.

Man märker att även Linux-kärnan har svårt att bestämma sig om moduler är "riktiga" kärnor eller ej. Antal kärnor rapporterade via /proc/cpuinfo är "cpu cores: 4 ", men man har ändå 8 unika "physical id". På Intel med HT är det lika många unika "physical id" som det är "cpu cores" så det är väldigt enkelt att lura ut vilka CPU-trådar som delar fysisk CPU-kärna, den informationen var inte lika självklar på AMD...

Edit: och så gäller det att översätta en binär mask rätt till hex... kärna 0 + 4 har naturligtvis mask 0x81 och inte 0x18 då minst signifikanta bit står till höger...

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

cat /proc/cpuinfo ger förklaringen till varför mask 0x11 och 0x3 ger samma resultat, det var en väldigt skum ordning på (logiska) kärnorna... Ordningen är 0,3,1,2,7,6,5,4

Mask 0x1 kommer använda kärna 0
Mask 0x3 kommer använda kärna 0 och 3 och de lär ligga på olika moduler
Mask 0x11 kommer använda kärna 0 och 7 vilket också lär ligga på olika moduler och förklara varför resultatet blir det samma som mask 0x3.

De CPU-trådar som ligger på samma modul lär endera vara 0 och 1 eller 0 och 4, så testa mask 0x5 (kärna 0 och 1) samt mask 0x81 (kärna 0 och 4).

Precis som du beskriver så händer massa saker som bara kan köra på en tråd (köra configure), var därför min beskrivning bara körde den första vändan med apt-get source --build gdb men lät alla tester göra make clean och make -j i det färdigkonfigurerade trädet, då ha man plockat bort den seriella delen som ställer till det om man bara vill se hur mycket effekt man får på själva kompileringen.

Man märker att även Linux-kärnan har svårt att bestämma sig om moduler är "riktiga" kärnor eller ej. Antal kärnor rapporterade via /proc/cpuinfo är "cpu cores: 4 ", men man har ändå 8 unika "physical id". På Intel med HT är det lika många unika "physical id" som det är "cpu cores" så det är väldigt enkelt att lura ut vilka CPU-trådar som delar fysisk CPU-kärna, den informationen var inte lika självklar på AMD...

Edit: och så gäller det att översätta en binär mask rätt till hex... kärna 0 + 4 har naturligtvis mask 0x81 och inte 0x18 då minst signifikanta bit står till höger...

Aha, nu förstår jag masken. Så vill jag välja kärna 2 + 3 så blir det 0x50 som mask.
Det är alltså ordningen av core id som man sedan maskar ut.

Men idag har ordningen ändrat sig...
cat /proc/cpuinfo

processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.29 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 1 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 1 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.29 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 2 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 6 cpu cores : 4 apicid : 2 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.29 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 3 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 7 cpu cores : 4 apicid : 3 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.29 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 4 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 5 cpu cores : 4 apicid : 4 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.29 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 5 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 4 cpu cores : 4 apicid : 5 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.29 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 6 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 6 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.29 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 7 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-8350 Eight-Core Processor stepping : 0 microcode : 0x6000822 cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 7 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bmi1 bogomips : 8003.29 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

Dold text

Så dagens ordning är 0, 3, 6, 7, 5, 4, 2, 1
Men hur ser du vilka moduler kärnorna ligger på?
Jag förstår inte hur du kom fram till att antingen 0 och 1 eller 0 och 4 ligger på samma modul?
För mig känns det som att de som ligger på samma modul är intill varandra. Så 0 och 1 ja, men varför 0 och 4?

Permalänk
Datavetare
Skrivet av ronnylov:

ASå dagens ordning är 0, 3, 6, 7, 5, 4, 2, 1
Men hur ser du vilka moduler kärnorna ligger på?
Jag förstår inte hur du kom fram till att antingen 0 och 1 eller 0 och 4 ligger på samma modul?
För mig känns det som att de som ligger på samma modul är intill varandra. Så 0 och 1 ja, men varför 0 och 4?

Grejen är att det inte är uppenbart vilka CPU-trådar som sitter i samma modul. På Intel har jag aldrig sett en CPU där CPU-tråd n och CPU-tråd n+C (C=antal fysiska kärnor) inte ligger på samma fysiska kärna. Men även detta är bara en konversion, på Windows verkar i stället alla Intel CPUer numrera trådarna som 0,1 ligger på kärna #0, tråd 2,3 ligger på kärna #1 osv.

Så min gissning är att numreringen på AMD är endera lika som på Intel, vilket betyder att CPU-tråd 0 och 4 ligger i samma modul eller så är det CPU-tråd 0 och 1 som ligger på samma modul. Vet helt enkelt inte och inget annat sätt att numrera verkar vettig.

Frågan är varför numreringen av CPU-trådar inte är den samma vid omstart...

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Ny omstart. Nu är CPU-ordningen 0, 3, 7, 2, 5, 4, 6, 1

Mask 0x81 blir 0 och 1
Mask 0x84 blir 0 och 4

Jag hade tidigare missat installera programmet time så därför funkade inte /usr/bin/time. När jag körde manuellt så var det troligen någon funktion time i skalet som användes istället. Nu har jag installerat time och kompilerar gdb version 7.6.1 manuellt med denna kommandorad:

rm -f result.txt; for mask in 0x1 0x81 0x84 0x3; do make clean >/dev/null 2>/dev/null; echo "Mask $mask:" >> result.txt; /usr/bin/time -o result.txt -a taskset $mask make -j >/dev/null 2>/dev/null; done

result.txt

Mask 0x1: 115.89user 7.23system 2:11.86elapsed 93%CPU (0avgtext+0avgdata 106352maxresident)k 56inputs+69664outputs (1major+6351055minor)pagefaults 0swaps Mask 0x81: 147.49user 9.72system 1:25.09elapsed 184%CPU (0avgtext+0avgdata 106244maxresident)k 0inputs+69600outputs (0major+6369003minor)pagefaults 0swaps Mask 0x84: 116.13user 8.14system 1:09.40elapsed 179%CPU (0avgtext+0avgdata 106176maxresident)k 0inputs+69608outputs (0major+6361817minor)pagefaults 0swaps Mask 0x3: 117.95user 8.17system 1:10.30elapsed 179%CPU (0avgtext+0avgdata 106372maxresident)k 0inputs+69600outputs (0major+6358300minor)pagefaults 0swaps

Dold text

1 tråd: 2:12
2 trådar i samma modul (kärna 0 och 1): 1:25
2 trådar i olika moduler (kärna 0 och 4 samt kärna 1 och 6): 1:10

Jag antar modulerna har kärnorna i följd, alltså (0+1) (2+3) (4+5) (6+7).
Så 4 trådar i 4 olika moduler borde i så fall vara exempelvis 0, 2, 4, 6 vilket ger mask 0x96
4 trådar i 2 moduler: 0, 1, 2, 3 vilket ger mask 0xD1

Kör test på kompilering av GTK3+ version 3.8.4:

rm -f result.txt; for mask in 0x1 0x81 0x84 0x96 0xD1 0x0; do make clean >/dev/null 2>/dev/null; echo "Mask $mask:" >> result.txt; /usr/bin/time -o result.txt -a taskset $mask make -j >/dev/null 2>/dev/null; done

Mask 0x1: 238.25user 22.80system 4:41.43elapsed 92%CPU (0avgtext+0avgdata 185316maxresident)k 0inputs+150136outputs (0major+18424505minor)pagefaults 0swaps Mask 0x81: 294.51user 28.04system 3:13.24elapsed 166%CPU (0avgtext+0avgdata 186524maxresident)k 0inputs+150128outputs (0major+18391730minor)pagefaults 0swaps Mask 0x84: 242.66user 24.20system 2:45.46elapsed 161%CPU (0avgtext+0avgdata 187112maxresident)k 0inputs+150128outputs (0major+18426492minor)pagefaults 0swaps Mask 0x96: 243.29user 26.12system 1:47.71elapsed 250%CPU (0avgtext+0avgdata 185304maxresident)k 0inputs+150128outputs (0major+18417525minor)pagefaults 0swaps Mask 0xD1: 269.05user 27.74system 1:54.62elapsed 258%CPU (0avgtext+0avgdata 185424maxresident)k 0inputs+150128outputs (0major+18405390minor)pagefaults 0swaps Mask 0x0: Command exited with non-zero status 1 0.00user 0.00system 0:00.00elapsed 50%CPU (0avgtext+0avgdata 956maxresident)k 0inputs+0outputs (0major+290minor)pagefaults 0swaps

Dold text

Mask 0x0 funkade inte, jag trodde jag skulle få 8 trådar då.
Testar 8 trådar separat då.

make clean >/dev/null 2>/dev/null; /usr/bin/time -o result8.txt -a make -j >/dev/null 2>/dev/null

result8.txt

309.30user 31.40system 1:28.48elapsed 385%CPU (0avgtext+0avgdata 186828maxresident)k 0inputs+150128outputs (0major+18405208minor)pagefaults 0swaps

Dold text

Sammanfattning kompilation gtk3+:
1 tråd: 4:41
2 trådar 1 modul: 3:13
2 trådar 2 moduler: 2:45
4 trådar 2 moduler: 1:55
4 trådar 4 moduler: 1:48
8 trådar: 1:28

Vet inte om jag gjort rätt nu men det känns lite vettigare den här gången.

Edit: Skulle väl haft mask 0xFF för alla kärnorna förstås...