Hvorfor er ytelsen pr. kjerne høyere ved single threading enn ved multi threading?

[Ernie]

Jeg har et program som er svært parallelliserbar. Det er snakk om ren tallknusing, så IO er ikke-eksisterende og RAM er knapt i bruk. I det heltatt, dette kan i prinsippet kjøres rett på CPUen med cache som eneste lagring. Multi threading er et åpenlyst valg, spesielt siden kalkuleringene ikke er avhengig av hverandre utover at det trengs en permutasjonsmotor som holder orden på trådene slik at de ikke forsøker å regne på samme data. Med andre ord, det bør skalere direkte med antall CPU-kjerner tilgjengelig.

Det jeg derimot ser er at ytelsen pr. kjerne reduseres med ca 10% når jeg går fra å bare bruke 1 tråd (+ main-tråden) til 2 stk. Med 2 tråder har jeg altså 180% ytelse i forhold til 1 tråd. Har noen en teori om hvorfor det skjer? CPUen min har tross alt 8 kjerner og det er ingen annen last å snakk om på systemet. Splitter jeg ut 8 tråder får jeg ca 720% ytelse i forhold til 1 tråd.

 

Jeg har en mistanke om at det er scheduling av trådene som slår inn her. Jeg måtte blant annet sette affinity på hver tråd slik at de låses til hver sin kjerne, ellers mistet jeg praktisk talt all fordelen med å tråde ut ting. Har det allikevel fortsatt så mye å si når man setter affinity til en enkelt kjerne pr. tråd? Jeg har også prøvd å gi trådene en mye større mengde data hver gang de ber om mer data siden dette er eneste stedet hvor det potensielt kan oppstå venting for tråden, og dette ser heller ikke ut til å ha innvirkning.

 

Lokalt kjøres dette forøvrig på Fedora 20, og jeg bruker C++11 tråder.

[Emancipate]

En ting er at det er alltids endel overhead av OS-kode. Når du kjører en tråd kan OSet kjøre på den andre kjernen, men når du kjører på alle kjernene må OS-et ta av kaka.

 

En annen ting er turbo-modusen på core i3/5/7-cpuene. Der klokkefrekvensen på en kjerne skrus opp dersom de andre ikke er i bruk.

 

En annen ting er task switching overhead. Dette kan reduseres ved å øke størrelsen på en "time slice"/"tick". (Jeg vet ikke hvordan det gjøres på linux.) + Prøv å slå av/på tickless kernel.

 

Jeg har en mistanke om at det er scheduling av trådene som slår inn her. Jeg måtte blant annet sette affinity på hver tråd slik at de låses til hver sin kjerne, ellers mistet jeg praktisk talt all fordelen med å tråde ut ting.

Det høres ut som noe aldeles forferdelig gæli et sted i scheduler eller annet. Det er merkelig at affinity skulle gi så stor forskjell.

 

C++11 tråder.

Hva slags tråder er det implementert som dypere i systemet?

 

Til sist kan du kanskje spørre han som lagde signaturen din? («The first 90% of the job takes 90% of the time, the last 10% takes the other 90%») Han burde ha en forklaring på dette også.

[Emancipate]

Ekstra forslag: Se om du får den samme forskjellen på single/multi-threading hvis du kompilerer uten mmx/sse og lignende, kun for 486.

 

Enda ekstra forslag: Er det mulig at selve målingen ødelegger?

[torbjørn marø]

Kontrollspørsmål: Har du konstanter at de ulike trådene eksekveres på ulike kjerner?

[Lycantrophe]

Hva slags tråder er det implementert som dypere i systemet?

pthreads