Förvillad: Intel eller inte?

Förresten, jag har också en fråga till dig AJ. Håller du med om följande?

I en superskalär processor startas exekvering av mer än en instruktion vid en ny klockcykel. Du skrev:

En enskild Processor kan fortfarande enbart exekvera en instruktion vid en tidpunkt t.
En instruktion tillhör 1 tråd.

Det stämmer att en given instruktion endast tillhör en tråd. En superskalär processor tar dock innan exekveringssteget och samlar ihop flera instruktioner från samma tråd och lägger dessa jämte varandra. När sedan nästa klockpuls kommer så skickas alla dessa instruktioner iväg på en och samma gång. Läsning av registren sker nämligen bara då en ny klockpuls kommer. Så långt gissar jag att du håller med, eftersom detta enkelt kan bekräftas av valfri bok i ämnet. Gissar därför att det är någonstans i den kommande texten som våra meningsskiljaktigheter finns:

Ovanstående betyder att vid en given tid t så propagerar fler en en instruktion samtidigt genom exekveringssteget. Visst, signalerna behöver inte nödvändigtvis ha hunnit exakt lika långt i ledningarna vid denna givna tid t, men fortfarande propagerar de så fort de bara kan och samtidigt genom ALU, FPU, o.s.v. När de väl lästs ur sina register så har de nämligen inget annat val än att fortplanta sig genom ledningarna fram till nästa "stopp" (villket sannolikt är pipelineregistren efter exekveringssteget). Det finns ingenting som hindrar en instruktion från att gå in i FPU:n, samtidigt som en annan redan är inne i ALU:n, eftersom dessa båda enheter ligger parallellt och inte känner av vad den andre håller på med. När sedan klockpulsen är till ända så måste tillräcklig tid ha gått för att resultaten för alla instruktioner/beräkningar skall ligga och vänta på att klockas in i registren på andra sidan (slutet av exekveringssteget). Alla instruktioner måste alltså ha haft tillräckligt med tid för att hinna propagera igenom exekveringssteget.

Nu vill jag veta exakt vad som inte stämmer med ovanstående (om du nu inte håller med, vill säga). Du behöver inte glida iväg på något sidospår, utan bara helt enkelt plocka ut de felaktiga bitarna och tala om hur det egentligen ligger till.

T.ex på ett AthlonXP/Pentium4 system så använder alla enheter i datorn sig av processorns FSB, dvs bussen mellan processorn och RAM. Ju mer bandbredd mellan processor och RAM, ju mer effektiv processor. Har man då en HTT bus (som Opteron/Athlon64 har) som avlastar FSB från all I/O och DMA genom RAM så får man bättre prestanda.

Du kan läsa mer om Hypertransport på:

http://www.hypertransport.org
http://www.hypertransport.org/products/productdetail.cfm?Reco...

Mikael till ditt inlägg #1: För att din beräkning skall stämma måste IPC och klockfrekvensen vara direkt beroende av pipelinen.

Mikael till ditt inlägg #2: Detta är inte parallelism. Nej och åter Nej. DU BLANDAR KORTEN.

Du sa att IPC:n för båda dina tänka processorer var lika. I så fall kan du glömma pipelinens utformning för tillfället. Om vi tänker oss att båda har en IPC på exempelvis 6, så betyder det att 6 instruktioner färdigställs varje klockcykel. IPC må vara beroende av pipelinen, men eftersom vi redan vet IPC i detta fall, så behöver vi inte oroa oss för hur pipelinen ser ut för att åstadkomma denna.

(6 instruktioner per klockcykel) x klockfrekvensen = antal instruktioner per sekund

Som du ser kommer två processorer med samma klockfrekvens och IPC att utföra samma mängd jobb under en given tid. Den med längre pipeline kommer ha större latency, men det gäller som sagt bara i startögonblicket.

Kalla det vad du vill, processorn jag beskrev ovan kan utföra beräkningar på mer än en instruktion samtidigt. Håller du med om detta? Du skrev ju nämligen tidigare att just detta inte är möjligt med någon processor.

Däremot har du ju naturligtvis rätt i att två trådar inte kan exekveras parallellt oberoende av varandra i en processor med SMT. För det krävs dubbla kärnor där varje tråd får sina egna resurser. När det gäller en enda tråd och dess instruktioner så kan dessa dock exekveras parallellt med varandra. Det hade liksom inte funnits någon anledning att exempelvis utrusta en processor med dubbla ALU, om de ändå inte användes samtidigt.

Prollen kommer inte att initiera instruktionerna eller ta emot resultatet av dem under samma del av klockcyckeln, nöjd?
Förövrigt så beskriver definitionen av parallellism (Computer Science) att begreppet parallellism endast är tillämpningsbart om det inte föreligger någon övergripande systemklocka.
DVS Hyperthreading handlar inte om parallellism.

Din beskrivning av parallellism är ju lika tillämpbar på att prata i telefon och köra bil samtidigt.........inget görs de facto exakt samtidigt varför det blir så många telefonkrockar........

Jag skall skriva ut det du skrivit och ta med mig till min föreläsning på Chalmers i Göteborg imorgon. Där skall jag lämna över det till professor Jonas Vasell, som arbetar med och föreläser om om de saker vi diskuterar. Han om någon borde ju kunna bena ut det här. Känner att det mest är bortslösad tid att sitta och skriva saker, eftersom du ändå ignorerar de viktigaste delarna av vad jag skriver (som att processorn arbetar med flera instruktioner samtidigt).

Förresten är det inte jag som har dragit in ordet parallellism i den här diskussionen. Vet inte riktigt hur själva definitionen av parallellism lyder. Däremot vet jag, med full säkerhet, att en HyperThreading-processor kan låta en instruktion från en tråd vara inne i ALU:n, samtidigt som en instruktion från en annan tråd finns i FPU:n. Alltså i exakt samma ögonblick. Om detta sedan definieras som parallellism, det får någon annan svara på. Instruktionerna beräknas dock parallellt.

Du har dessutom fortfarande inte svarat på varför man har flera beräkningsenheter av samma sort (exempelvis två ALU) om de ändå inte används samtidigt. Om processorn ändå inte tillåter att två instruktioner är under beräkning i ett och samma ögonblick, så räcker det ju med en ALU.

EDIT: Din analogi med att köra bil och prata i telefon är förresten rätt bristfällig. En människa kan mycket riktigt inte utföra två saker samtidigt särskilt bra. Tar man ett exempel som att addera två heltal samtidigt som man dividerar två andra heltal, så klarar inte hjärnan att utföra de båda beräkningarna samtidigt. I fallet med processorn kan man dock se två parallellkopplade ALU som två "minihjärnor" (eller två likadana motsvarigheter av den del i vår hjärna som utför beräkningar). Så länge båda får information samtidigt, så har de heller inga som helst problem att utföra beräkningarna samtidigt (finns ingen logisk anledning till varför de skulle ha det). Sedan kanske som sagt signalerna för båda instruktionerna inte hunnit fortplanta sig exakt lika långt innuti respektive ALU vid en viss tidpunkt. Inget hindrar de dock från att vara innuti varsin ALU i exakt samma tidpunkt. Inget hindrar de heller från att teoretiskt sett vara exakt lika långt. Detta sker dock troligtvis inte i praktiken, eftersom, precis som du skrev innan, en viss tidpunkt kan delas in i oändligt många små intervall och vissa fördröjningar finns ju alltid i exempelvis ledningbanor.

Det viktiga att förstå är att även om signalerna inte hunnit propagera exakt lika långt, så kan ändå beräkning pågå på två instruktioner samtidigt. En instruktion kanske precis har kommit in i ALU:n, medans en annan precis är på väg ut ur FPU:n. Beräkning pågår i detta ögonblick på båda instruktionerna, men de har kommit olika långt.

Din idé verkar vara att alla de instruktioner som planeringsenheterna lagt ut för exekvering trots allt skickas iväg en och en, men att detta sker under olika stadier i samma klockcykel. Du menar att detta utifrån sett skulle få det att se ut som att beräkningar skedde parallellt under en klockcykel, trots att de egentligen utförs i serie. Har jag förstått dig korrekt?

Mikael jag tycker verkligen att du skall prata med din proffesor eller gärna någon expert inom områdena parallelfördelade processer, neurala nätverk och liknande.
De olika beräkningsenheter i en P4 arbetar inte parallelt, data/instruktioner sänds till dessa och mottages från dessa under olika delar av klockcyckeln.

En parallell process som kräver synkronisering är ej längre oberoende, är ej längre parallell, har inga parallella fördelar och kräver en systemklocka för synkroniseringen.
Ett annat tips till dig är att kolla in P4:an lite bättre. En P4 har nu 3 ALU:er som inte arbetar parallellt, alla dessa kan givetvis arbeta samtidigt (Ja samtidigt som FPU:n arbetar också), de kan dock inte få och sända data vid samma tillfälle på klockcyckeln.
(En annan intressant detalj är att P4: ALU:n arbetar 7,2 Ghz för en 3,2Ghz CPU dvs resultatet av vissa startade instruktioner kan returneras på samma klockcyckel).

Lite annat läsvärt:
http://pds.twi.tudelft.nl/~reeuwijk/parguide/perfmeas.html

http://www.google.se/search?hl=sv&lr=&client=firefox-a&rls=or...

http://onlinedictionary.datasegment.com/word/parallel+process...

http://onlinedictionary.datasegment.com/word/parallel+process...

Lite tyngre saker om du kan läsa sådant:

ftp://ftp.sas.com/pub/neural/FAQ.html#A2

Amdahls law:
http://home.wlu.edu/~whaleyt/classes/parallel/topics/amdahl.h...

Närliggande forskning som redan har misslyckats med det du tror på trots införsel av miljarder och åter miljarder:
http://www.scism.sbu.ac.uk/inmandw/tutorials/pdp/pdpintro.htm...

AJ, nu är din argumentation mest inne på vad som är "parallellt" och vad som är "samtidigt"
för min del så får det gärna vara "samtidigt" så länge den kan hålla på med mer än en beräkning per klockcykel (och givetvis ju fler desto bättre)

err, jo, göra många samtidiga processer har fortfarande en stor fördel mot att göra dom en efter en i samma takt: det går fortare (förutsatt att synk-tiden inte blir extremt överdriven givetvis)
jag skulle nog spontant påstå att jag skulle kalla scenariot för "parallella processer" också... en systemklocka för synkroniseringen är något som inte bör vara särskilt svårt att hitta i processorn

Du glömde nog att titta på Amdahls lag........

Ett litet exempel:

P4:ans FPU:

klockcyckel #1,(1/2): start instruktion FPU1, mottag instruktion FPU2
klockcyckel #1, (2/2): mottag instruktion FPU1, start instruktion FPU2
osv osv......
Nu är ju detta optimalt, inte parallelt och inträffar jävligt sällan i verklig kod, i verkligheten så blir det bara start FPU1, därefter mottag från FPU1 vänta(inget arbete) 4 klockcyckler dra igång FPU1 igen , vänta 8 klockcyckler dra igån FPU1 igen osv osv osv...........

det är snarare du som glömde läsa igenom den ordentligt :/
länken du ger handlar om seriell (singel-thread) kod på multippla processorer, inte om multippla beräkningsenheter i samma processor

Har nu diskuterat vårt lilla dilemma med de som håller i kursen på Chalmers. Så här är det:

- En processor kan hålla på med flera beräkningar samtidigt. Två beräkningar kan mycket väl överlappa varandra i tid, så länge vi har flera beräkningseneheter.

- Så länge vi har separata bussar och separata läs/skriv-register för enskilda beräkningsenheter så kan dessa dessutom påbörja och avsluta sina beräkningar oberoende av de andra beräkningsenheterna. Vi kan då sända iväg flera instruktioner precis samtidigt från deras instruction slots, utan att de kommer att påverka varandras exekvering.

- Enligt den information jag fick skulle man även kunna tänka sig en issue-enhet som sände iväg instruktioner flera gånger under samma klockcykel. Detta vore dock inte optimalt om man som ovan har separata bussar och register för beräkningsenheterna, eftersom det då inte finns någon anledning att inte starta beräkningarna samtidigt. Att starta beräkningarna så fort som möjligt leder ju nämligen till att de blir klara så snart som möjligt.

- Sammanfattat: Vi kan starta flera beräkningar i precis samma ögonblick. Dessa kan sedan befinna sig innuti beräkningsenheterna samtidigt vid en viss tidpunkt, utan att det orsakar några problem. P.g.a. olika latency så kan beräkningarna dock bli klara vid olika tidpunkter. Skulle de (åtminstone teoretiskt sett) bli klara vid samma tidpunkt och skrivas vid samma tidpunkt så går detta också bra, så länge de skriver resultaten till olika platser.

Vi pratade inte så mycket P4-specifikt. Flera av de saker som jag skriver om ovan är dock saker som du AJ, om jag förstått dig rätt, påstått är omöjliga i dagens processorer.

EDIT: De kunde förresten också bekräfta att min tidigare pipelineberäkning var korrekt.

EDIT2: Kommer sannolikt inte svara mer i tråden, då jag nöjer mig med att själv veta att jag har förstått principerna för detta korrekt.

Ur min synvinkel handlade disskussionen om P4, Hyperthreading och parallellism.

1 klockcyckel är för andra gången inte lika med 1 tidpunkt t, 1 klockcyckel har flera tidpunkter t.

Du verkar ha glömt att verkligheten kräver att registrena förändras, dvs att något placeras i registrena från början.
Rent teoretiskt skulle det du beskriver kunna fungera dock kommer de inte att starta vid samma tidpunkt t pga latency (Vad är en klockpuls igentligen, värt att tänka på).

Samma principer gäller för parallellkoplade beräkningsenheter som för parallellkoplade processorer.

Teori och verklighet är 2 skillda saker Mikael.
Rent teoretiskt kunde VASA skeppet dominera haven, rent teoretiskt skulle inte challenger ha störtat.....

Mvh

Och du verkar ha glömt att data som krävs i ett pipelinesteg färdigställs i en tidigare klockcykel (alltså ett tidigare pipelinesteg). När klockcykeln i exekveringssteget påbörjas vet vi alltså att issueslotsen innehåller varsin instruktion och därför kan vi läsa dem samtidigt (i teorin i alla fall, se nedan).

Vad jag försöker säga är mycket riktigt att processorn kan vara byggd så att det är meningen att läsning av registren skall ske samtidigt. P.g.a. fysiska begränsningar så lär det alltid bli en liten tidsskillnad, om än aldrig så liten. Det har du rätt i. Det jag också gång på gång försökt att säga är att om det i teorin skulle gå att få båda läsningarna att ske exakt samtidigt, så hade det också fungerat bra! Själva designen av processorn har alltså ingen begränsning som hindrar dylik operation från att inträffa i teorin.

Man skulle kunna säga så här att: Att få två saker att starta EXAKT samtidigt är omöjligt, p.g.a. att ett givet tidsintervall kan delas in i oändligt antal mindre intervall. Att däremot få två processer som pågår under en viss tid att ske parallellt är inte omöjligt. Att få processerna att starta och sluta samtidigt är vad som är omöjligt. Man kan se det som att om läraren i en klass delar ut en uppgift till varje elev så är det omöjligt att få dem att starta samtidigt på uppgiften. Däremot är det sannolikt att alla efter en viss tid kommer att syssla med själva beräkningen samtidigt. Detta tror jag faktiskt att vi är överens om.

Mitt ursprungliga påstående var inte att processorn nödvändigtvis startar ett antal beräkningar exakt samtidigt, för det är som sagt inte möjligt. Trots det tillåts det alltså dock i teorin av designen. Däremot påstod jag att beräkningar kan pågå samtidigt i en viss tidpunkt, något som flera här påstod var felaktigt.

Jag tror dock kanske att vi missförstod varandra lite från början. Jag pratade om att två beräkningar kan pågå samtidigt (exempelvis att en ALU kan arbeta med en instruktion från en tråd, samtidigt som en annan ALU kan arbeta med en instruktion från en annan tråd) och du menade nog snarare att två beräkningar inte kan starta och sluta samtidigt, vilket också är korrekt.

Är vi kanske äntligen på någorlunda samma våglängd?

Nej jag tycker fortfarande inte att det är parallellism vi talar om utan 2 seriella beräkningar som alltid startas vid olika tidpunkter och vars resultat alltid anländer vid olika tidpunkter.
Rent tekniskt så förflyttar sig elektronerna i de två seriella beräkningsenheterna samtidigt, ja men beräkningsenheterna arbetar inte parallellt.
Skillnaden kan säkert tyckas vara hårklyveri av de flesta dock så har en massa enorma beräkningstekniska fördelar förutspåtts genom parallellism, vilket givetvis är en anledning till att vråla/marknadsföra parallellism.
Dessa fördelar försvinner dock om synkronisering inträffar eller om den parallellism som teoremen beskriver ej föreligger.

Mvh

Och allt det här har fulständigt lämnat det realistiska, AJ pratar om en teoretisk aldrig existerande möjlighet, nånting som inte sker i en dual cpu, eller en dual core, så varför i hela fridens **** är det ett krav att det ska hända i en HT cpu?

Im man förutsätter att realistiska gränser gäller, innebär det att jämförelsen "parallelt" arbetandes, får göras med exempelvis en dual moderkortskonfig, med 2 cpu'er, eller med en dual core, och i det läget uppfyller HTcpu'n kravet på paralellt arbete, doch inte 100% av tiden för uppenbara anledningar, då det helt enkelt ingår i logiken som styr den att den ska vara så "smart" som möjligt.

den stora förtjänsten i paralelism, som AJ beskriver den måste ligga i nånting annat än att arbetet utförs exakt samtidigt... det bör ligga i att som AJ beskriver händelseförloppet, förflyter det ingen tid för att utföra arbetet, nånting in, och det trillar ut bearbetat i andra ändan, utan tidsåtgång... "kommer aldrig att hända" är min första tanke, men de exprimenteras med startrek teknik som jag inte heller tror kommer hända, så det får tiden utvisa, de gör en dator av ett svart hål, eller nått, bara för att jäklas med mig.

Kontentan av det hela är att AJ's protest inte ligger i att HT presenteras som en primitiv funktion för att tjäna något av de fördelar smp ger, utan bara att han inte erkänner det som en paralell beräkningsform. Helt utanför trådens frågeställning.
B!

Rätt bra skrivet, Mr_B.

Vad du säger, AJ, är alltså att två personer som arbetar med varsin beräkning samtidigt (exempelvis två elever som i klassrummet utför varsin beräkning), egentligen heller aldrig kan arbeta parallellt. På något sätt så kommer alltid den ena eleven att utföra sin uppgift innan den andra startar. Jag hoppas att du själv förstår hur fruktansvärt vansinnigt det här låter. Du måste grovt ha rört ihop de avancerade teorier du beskriver, för i verkligheten är det inga som helst problem att få två oberoende händelser, som pågår under ett visst tidsintervall, att överlappa varandra.

Jag tror helt enkelt skillnaden ligger i hur vi definierar parallellt. Du anser att beräkningsenheterna måste börja, utföra beräkningen och också sluta samtidigt. Detta är inte möjligt. Det finns dock inga hinder för följande:

1. Beräkningsenhet 1 börjar arbeta.
2. Beräkningsenhet 2 börjar arbeta.
3. Beräkningsenhet 2 blir klar.
4. Beräkningsenhet 1 blir klar.

Det finns absolut ingen anledning att detta inte skulle kunna ske (och sker gör det också i verkliga processorer enligt, killarna på Chalmers).

Mikael du har precis beskrivit det jag skrev i ett tidigare inlägg, detta är inte parallellt arbete.

MR_B du har vänt på korten, missat caset.

Jag tror att vi härmed alla är överäns om att vi aldrig kommer att bli överäns. Ovan beskrivna förlop är exakt samma som sker i multi cpu system, dual core, och HT cpu'er, bara i olika frekvent utstreckning. Branchen anser att det är parallelt arbete, Personligen tycker jag det kvalificerar som sådant, avikande åsikter får gärna existera, men det kommer sanolikt aldrig ändra branchens åsikt, eller gemene mans.

Uh, här måste jag erkänna att jag inte förstår språkbruket.
B!

Okej, vi gör så här då: Den matematiska definitionen av ordet parallell lyder:

"Något som ligger perfekt jämsides med något annat och aldrig vidrör det."

I processorn kan det då sägas att arbetet inte utförs perfekt jämsides, eftersom beräkningarna inte startar och avslutas samtidigt, även om de kan pågå samtidigt.

Vad kan vi då mer dra för slutsatser av detta? Jo, att jag kanske slängde mig med uttrycket "parallell" lite oförsiktigt när jag påstod att beräkningar i en processor pågår parallellt. Om man skall vara strikt matematiskt korrekt så kanske det riktiga hade vara att säga:

1. Ingen enskild processor och inget system av processorer kan arbeta med beräkningar parallellt.

2. Båda dessa nämnda system kan dock arbeta med olika beräkningar samtidigt, eftersom detta inte förutsätter parallell exekvering utan enbart att en beräkning någonstans överlappar en annan.

3. Anledningen till att ovanstående gäller är inte att själva designidén inte kan åstadkomma parallell exekvering, utan snarare att tiden inte är av diskret natur.

Nu måste vi väl ändå vara överens?

Till viss del

Dock så vill jag bara påpeka att tidens kontinuerliga natur gör synkronisering nödvändig samt att systemklockans natur även gör parallellt arbete omöjligt inom en processor.
En grundläggande förutsättning blir givetvis att det inte existerar en gemensam systemklocka för parallellt arbetande enheter.

System som arbetar parallellt med skilda systemklockor måste givetvis synkroniseras på något vis.....iallafall i elektronikens vilda värld av elektroner.

Its a electronic thing not a mathematic! + även om det faktiskt är möjligt att starta 2 beräkningar vid 2 olika tidpunkter och ha dessa "färdiga" vid samma tidpunkt så kommer inte registren att uppdateras vid exakt samma tid iallafall!

Mvh

Eftersom en klockpuls är ett kontinuerligt tidsintervall så kan fortfarande olika händelser överlappa varandra under denna tid. I min klassrumsanalogi skulle man kunna tänka sig varje klockpuls som en lektion och när denna är slut går eleverna vidare till nästa lektionssal (lektionssalarna skulle då kunna tänkas vara de olika pipelinestegen i processorn). Eleverna kommer inte att gå från ett klassrum till ett annat exakt samtidigt och inte heller kommer de börja räkna exakt samtidigt under en ny påbörjad lektion. Däremot kan beräkningar överlappa varandra trots att de inte börjar samtidigt.

I en processor är alltså ett visst tidsinterval "upphackat" i korta nanosekundlånga intervall (precis som elevens dag är upphackad i timslånga lektioner). Under ett sådant intervall är det inte mer osannolikt att processorn har flera beräkningar pågående än att två elever kan jobba på något samtidigt under en lektion i skolan (vilket vi alla vet är möjligt, hoppas jag ).

Jag förstår inte vad skillnaden på det du säger och jag säger är undantaget att det du beskriver inte är parallellism.

Under en klockpuls kan flera händelser inträffa, dock aldrig vid samma tidpunkt t.

Om du aggregerar flera tidpunkter t kan detta leda till att man kan inbilla sig att man har parallellism, detta har man dock inte.

Mvh

Okej, läs då nedanstående mycket enkla scenario och besvara sedan frågan:

Scenario: Två bilar rör sig under ett visst intervall T framåt på en väg. Förutsätt att båda rör sig framåt under hela intervallet. Välj ut en tidpunkt t som ligger någonstans i intervallet T.

Fråga: Rör sig båda bilarna framåt samtidigt i denna tidpunkt?

Svara ja eller nej på frågan (och utveckla sedan gärna om du vill).

Svarar du nej så kan vi nog lägga ner diskussionen direkt, då chanserna att vi skall kunna komma överens om något här i så fall är extremt små.

Tycker det är kul att ni håller på ännu, har inte läst alla sidorna så jag kan ha missat något men tänkte hoppa in i matchen ändå.

Säg att du har sex tidpunkter, t1,t2,...,t6 och t1<t2<...<t6

Om då;

t1, Instuktion 1 börjar
t2, Instruktion 2 börjar
t3,
t4,
t5, Instruktion 2 slutar
t6, Instruktion 1 slutar

Under tidsrymden t (t3<t<t4) inträffar/utförs intruktion 1 och 2 samtidigt, dock uppfyller de inte definitionen av att vara parallella. Har jag förstått er alla rätt?

Mev du har förstått!

Mvh

Härligt, precis vad jag pratat om de senaste inläggen.

Verkar som AJ och jag är rätt överens nu då!

ok, kan du då förklara till vilken nytta denna tråd blev minst 1 sida längre?
om det är "samtidigt" eller "parallellt" rent definitionsmässigt har vad jag vet ingen betydelse då det är en egenskap alla dagens processorer har gemensamt

Frosty, jag tror att tråden blir längre o längre, för att anti Intel killarna ska ha nått o läsa...
B!

Ja, nu orkar nog inte jag mer i alla fall...

Mikael, taget!

MR_B+Frostyfrog:

Betydelsen av äkta kontra oäkta parallellism är givetvis stor, se de tidigare refererade dokumenten.
Äkta parallellism skall i teorin innebära stora prestandavinster, oäkta parallellism innebär inga prestandavinster utan är endast en nytolkning i syfte att luras att man har något nytt, därmed inte sagt att det nya inte behöver vara bra till något!

Som noteras innebär synkroniseringslatensen mellan 2 processorer oftast att mellan 100-10000 beräkningar hinner göras av vardera processorn.
Överföringslatensen skall vi inte tala om eftersom den förjävligt dålig.
Lite av detta botas dock av dubbelkärnor som istället får synkroniseringsproblem mot bussen, vilket dock har löst även om lösningarna innebär att bandbredd och prestanda begränsas, återigen synkronisering.

Det roligaste med synkroniseringsproblemet är att ju snabbare prollarna blir desto värre blir problemet!

MVH (Jag skall erkänna att jag är förjävligt trött på denna disskussion också!)