Concurrency

Tags:    programmering

Hej.

Jeg er gået i gang med at lære scala, og en af fordelene skulle være rigtig god understøtelse af concurrency.

Jeg er dog ikke helt med på hvordan man bedst udnytter det at have flere threads/actors kørende.

Gælder det om bare at spawne så mange threads som man overhovedet kan komme til, eller er det idealle antal threads samme antal som der er kerner i proccessoren på den computer programmet bliver afviklet på? (Set fra et performance synspunkt. Jeg er med på at man også kan bruge flere threads, kun for at få flere ting til at ske på samme tid)

Mere specifikt har jeg en masse objekter(lige nu 8, måske flere, men lad os bare sige 8), der hver har to lister med rigtig mange(10000, måske flere, per liste) boolske værdier.

programmet køre så gennem de to lister, og skaber én ny, baseret på værdierne i de to originale lister.

Er det en god ide at smide en ny thread efter hver af de 8*10000 simple operationer der skal laves, eller skal man bruge 8 threads, der hver køre 10000 operationer.

Eller er der noget med, at man kan bruge en thread pool, der laver et ideaelt antal threads, som så giver en ny thread til den næste operation i køen hver gang der er en ledig.

Som man måske kan høre er jeg ikke 100% inde i hvordan man bruger threads (eller actors, som er scalas threads++ eller noget i den stil) rent praktisk endnu, men jeg vil gerne vide hvordan man bedst udnytter concurrency, før jeg går i gang med at kode.

Så kort sagt er spørgsmålet: Er flere threads = et hurtigere program? Hvis ikke, hvor mange threads skal man så lave?



4 svar postet i denne tråd vises herunder
2 indlæg har modtaget i alt 2 karma
Sorter efter stemmer Sorter efter dato
Hvorfor vil du have mange tråde?



en thread pool er sådan set bare et abstraktionsniveau over hvordan du starter dine tråde og tildeler arbejde til dem. Hvis du ved præcis hvor meget arbejde du har fra starten (fx dine 8) og når du har bestemt dig for hvor mange tråde du vil have, så kan du jo på forhånd dele arbejdet op i de rigtige størrelser og specifikt tildele en bid til en ny tråd. Da opdelingen af arbejdet nok foregår på en enkelt tråd er det dumt at spilde tid på at dele det op i alt for små bidder og lade hver tråd tage mere end en bid. Så er det ikke nødvendigt at bruge thread pool abstraktionen. Men hvis der kommer mere arbejde hen ad vejen som programmet kører kan en thread pool bruges til at genbruge en tråd der allerede er færdig i stedet for at skulle starte en ny, som tager tid.

Som sagt før afhænger det optimale antal tråde af mange ting, herunder programmets struktur. Hvis operation 2 skal kende resultatet af operation 1 og operation 3 skal kende resultatet af operation 2, hjælper det ikke noget at kører 1, 2 og 3 i hver deres tråd, da du bare vil spilde tid på at oprette trådene og på synkronisering. Er de derimod uafhængige kan hastigheden måske forøges ved at placere dem i hver deres tråd. Det er ikke til at sige generelt, men jeg vil gætte på at få logik-programmer kan parallelliseres mens mange grafikprogrammer kan.



Nej. Det er en afbalancering.

Flere tråde har fordelen at du kan få udnyttet alle CPU-kernerne, hvis du gør det rigtigt. Det kan også være at flere tråde end CPU-kerner kan få det til at gå endnu hurtigere, da en enkelt tråd ikke kan bruge CPU'en og hukommelsen på samme tid, så flere tråde på samme CPU kan skiftes til at bruge CPU'en og hukommelsen.

Men når ressourcerne er fuldt udnyttet, vil tilføjelse af flere tråde sløve programmet ned, da der skal bruges tid på at oprette trådene og tid på kommunikation mellem dem.

Hvor grænsen ligger afhænger af programmet der køres, antal CPU-kerner, hastigheden af CPU og hukommelse, osv. Den eneste måde at finde det optimale på er at teste hvad der er hurtigst.



Hvorfor vil du have mange tråde?

For at udnytte alle kernerne i CPU'en.

Som sagt sidder jeg og leger lidt med scala, og det fede ved scala skulle være at det er meget godt til at skalere. Derfor vil jeg gerne vide hvordan man får et program til bedst at udnytte flere CPU kerner.

Jesper Kristensen: Tak for svaret. Vil det optimale så være at have en form for thread pool, der styre hvor mange threads der skal være(kunne forestille mig, at der måske er noget i den stil, i standard biblioteket).

Jeg er også blevet lidt i tvivl om, om man kun bør anvende flere threads til systemer der har gavn af at køre på samme tid, foreksempel logik og render systemet i et spil. Eller er det også godt at have X antal threads til at køre en masse krævende operationer(der egentlig sagtens ville kunne køre efter hindanden istedet for på samme tid) istedet for kun én.



t