Skrivet av star-affinity:
@Yoshman:
Ursäkta min okunskap, men är inte detta med att lägga ut en applikations CPU-användning på flera processortrådar något som skulle kunna hanteras mer eller mindre automatiskt av operativsystemet? Eller är det alltid något som programmeraren måste "be om"?
(Något förenklat) Varje tråd i program kan automatisk hanteras av operativsystemet. Det är dock den triviala biten att hantera i ett parallellt program...
Det långt mer komplicerade är hur data delas mellan trådar samt hur man väljer att dela upp arbetet. Mycket av best-practices som lärts ut i programmering genom åren är bra idéer, om man skriver sekventiella program... När man skriver parallella program (vilket rätt få gör, servers kör nästan alltid många sekventiella program samtidigt men kör alltså inte parallella program) så är det helt kritisk hur man väljer att representera sin data. OO idiom som "gömma data och dess representation" gör vettig parallellprogrammering omöjlig.
Rent naivt kan det t.ex. verka vara en väldigt vettig idé att man en nätverksapplikation hanterar varje session i en separat tråd. Måste ju vara super då OS tar hand om att sprida lasten över alla CPU-trådar? Fungerar halvhyfsat i leksaksprogram, fallerar brutalt (kommer bli långsammare än om man bara hade kör med en tråd) om man skalar upp det hela till väldigt många samtida sessioner.
Och för att konkretisera lite skillnaden mellan att köra flera sekventiella program parallellt (som alltså skalar fint med kärnor) och ett parallellt program (som sällan skalar till speciellt många kärnor, men finns en del fall som är dataparallella och kan med fördel skalas primärt med SIMD men ibland även kärnor)
spel: man kör normalt ett spel i taget, så för att skala detta över kärnor måste man göra just parallellprogrammering och spel är inte speciellt dataparallella utanför grafiken som körs på GPU
Cinebench: är i.o.f.s. ett program man är trivialt att dela upp skärmen i totalt oberoende delar, så detta skalar perfekt då varje ruta som renderas är ett enkeltrådat fall och man har massor med sådana att sprida över kärnor
Matlab: vid matrismultiplikation kan varje cell beräknas oberoende av alla andra celler. Så som Cinebench då, bara hantera varje cell på en egen tråd? Det skulle ge direkt katastrofal prestanda + 100 % CPU-last på alla kärnor... Orsaken är att det är en kostnad associerad med att sprida beräkningar, för att sprida över kärnor är den på ~mikrosekundnivå, så länge har mindre än 10000x10000 tar det mindre än en mikrosekund att räkna ut en cell. Tar däremot ~nanosekund lägga ut data i ett SIMD spår (något förenklat det som GPUer kallar CUDA-core eller stream-core) och sedan använda SSE/AVX (eller motsvarande på andra CPU-arch). Så detta är ett enormt parallellt problem som ändå inte kan hanteras vettig med många CPU-kärnor (går om man har väldigt stora matriser), men är trivialt att hantera med SIMD (vilket också görs i praktiken idag).
Skrivet av anon159643:
För att nämna några applikationer som skalar bra om windows hade haft en bättre schemaläggare så Excel, word, OneNote, Autocad, typ alla cadprogram jag vet.
Excel är utanför några enstaka specialfall som Monte Carlo simulering (som väldigt få använder och som ändå är det som brukar testas då det råkar skala med CPU-kärnor) dataparallellt, inte uppgiftsparallellt. Dock är det nog väldigt få kalkylblad som Excel ser som är stora och komplicerade nog för att det ska vara värt SIMD. Finns absolut sådana problem, men de som har dessa använder vettigare verktyg som R, Matlab, NumPy eller liknande (som alla är SIMD optimerade och numera även GPGPU optimerade i vissa fall).
Word, OneNote och Autocad har garanterat delar som kan köras parallellt. Problemet är att majoriteten av alla dessa delar tar var för sig alldeles för liten tid att beräkna så om man spred ut det över flera kärnor (något som kostar någon mikrosekund per jobb) skulle man äta upp CPU-resurser och få ett program som kör långsammare. Inte riktigt önskvärt kanske?
Skrivet av anon159643:
Att utnyttja kraften för flera kärnor inom produktivitet handlar till stor del på användarens kunskaper och inte brister i de program som användaren ska köra. Visst om man har ett enkelt problem och vill få det löst på så kort tid som möjligt så är det ofta svårt att få det skala med antal kärnor, men ett fysisk problem kan bestå i hur många delmoment som helst, där varje delmoment kan ses som självständig och skulle kunna lösas på fysisk helt isolerade datorer.
Att inte kunna springa snabbare än Usain Bolt är enbart en effekt av för lite träning, fel kost och för dålig motivation...
Du missar att även om det finns massor med delmoment som rent logisk skulle kunna köras separat så finns det en kostnad med att köra något parallellt. Kostnaden är på mikrosekundnivå för att sprida över kärnor, det är på nanosekundnivå att sprida över SIMD. Problemet med SIMD är att vad man kan göra är mer restriktivt, flera kärnor är rent logiskt MIMD (SIMD: samma instruktionsström appliceras på olika data, MIMD: olika instruktionsströmmar appliceras på "sin" data)
Den kostnaden dikteras av fysikens lagar och forskarna har så här långt inte hittat något sätt vi kan skriva program så att den undviks.
Skrivet av anon159643:
Och för att få en uppfattning om hur slöa gpuer är för fel uppgift, så får dubbla 1180Ti spö av ett 600kr värmeelementet se nedan för fel typ av problem, dvs värma upp en lokal: https://www.clasohlson.com/se/Oljefyllt-element-med-hjul/36-5...
Min poäng är flyttal är en ovanlig last, den börjar så smått bli vanligare men ofta skickar man då den massiva lasten till en datacenter, detta av flera anledningar som förutom massivdatakraft så världsledande mjukvara för analys m.m.
Angående SIMD så kan applikationer använda detta även man själv. Men oftast har man redan alla applikationer och man kan ej ändra dem. SIMD löser egentligen inget problem, jag ser det mer som ökad datakraft.
SIMD har inget med flyttal vs heltal att göra. SIMD (vilket även är vad GPUer rent tekniskt använder) fungerar mycket bättre än multipla kärnor på dataparallella program, men fungerar inte speciellt bra på uppgiftsparallella problem.
Tar vi heltal så räcker inte GTX 1050 för att matcha TR 2990X i ett dataparallellt problem, man måste upp till ett GTX 1060...
Dataparallella program är väldigt ofta "embarrassingly parallel" och om de är tillräckligt stora kan ofta skalas med kärnor. Åtta kärnor med fixerad frekvens drar rätt mycket åtta gånger så mycket ström för att ge åtta gånger högre kapacitet. Helt OK, eller? Tja det är ju definitivt bra med högre total kraft.
Grejen är att SIMD kostar typiskt <50 % mer ström för att ge x10 bättre prestanda.
Dessa två saker komplettera varandra. Många kärnor är optimalt för uppgiftsparallella problem medan SIMD är optimalt för dataparallella problem. Uppgiftsparallella problem är dock inte speciellt vanliga på skrivbordet! (Men de är väldigt vanliga på servers).
Skrivet av anon159643:
Ofta har kund ett önskemål som ej är möjligt att uppnå. Med de begränsningar som dagens teknik har inkl kostnaden, så kommer man en lösning som går att utföra och man får nöja sig med den. Inte ens om dagens cpuer skulle få 50 gånger så hög IPS, så är det för många inga större skillnader i arbetssättet, det kund önskar går ej uppnå och man får begränsa sig.
Så högre IPC, klockfrekvenser är skitbra, men när dessa blir högre ställer man bara högre krav och man är tillbaka och får skaffa fler beräkningsenheter. Detta gäller självklart inte i all evighet, men vi är så långt ifrån så man kan räkna med att det ej ändras under vår livstid.
Finns väldigt mycket roliga saker vi skulle kunna göra om det bara vore möjligt att mångdubbla enkeltrådprestanda. Tyvärr går inte det.
Det pragmatiska förhållningssättet blir då att försöka se vad man kan göra givet restriktionen att vi bara kan signifikant öka kapaciteten för uppgiftsparallella problem och dataparallella problem. Rätt strategi där är nog att leta efter nya saker som folk ännu inte fattat att de behöver som råkar passa. Vi förstår de flesta av dagens problem rätt bra och ofta har de fel process för att hanteras parallellt.
