Overleg:Superscalaire processor

Pagina-inhoud wordt niet ondersteund in andere talen.
Onderwerp toevoegen
Uit Wikipedia, de vrije encyclopedie

Gecopieerd uit de kroeg[brontekst bewerken]

Onderstaande bijdrage is gecopieerd uit de wikikroeg: Wikipedia:De_kroeg#Superscalaire_professor, n.a.v. een vraag gesteld door Gebruiker:Art_Unbound op 13 aug 2007 19:32. Informatie uit deze tekst kan wellicht naar behoeven ingevoegd worden in het artikel.

Ik heb het artikel verbeterd. Groet, Rudolphous 13 aug 2007 20:53 (CEST)
Dank je wel, Rudolphous. De Engelse versie suggereert dat het niet zozeer om een 'mechanische' splitsing van de processor zou gaan, maar om een 'wiskundige' splitsing van het data-aanbod, althans voorzover ik het als leek begrijp. Ik heb bijvoorbeeld voor m'n ADSL-verbinding een splitter aangebracht, die telefonie- en internet-signalen van elkaar scheidt (zoiets als: de ene helft van de koperdraadjes doet de telefonie, de andere helft doet internet). Een pipeline schijnt te suggereren, dat een stroom van digitale signalen zodanig wiskundig wordt verwerkt, dat hieruit meerdere opdrachten zijn te distilleren, terwijl dat (voor scalaire instructies) eigenlijk niet zou mogen kunnen. Is een superscalaire processor net zoiets als een splitter, of is het een wiskundige abstractie? - Art Unbound 13 aug 2007 21:57 (CEST)
Hallo Art Unbound, Met een superscalaire processor is het mogelijk om wiskundige vectorberekeningen uit te voeren. Dit verloopt sneller dan bij een klassieke processor (waar wiskundige dan weer blij mee zijn). Intern worden de instructies wel "gesplit", maar dit is m.i. niet te vergelijken met een wiskundige splitsing, maar meer een procesmatige splitsing. Groet, Rudolphous 13 aug 2007 22:25 (CEST)
(na bwc) Het is vooral een "processorarchitectuur". Je laat een processor iets doen wat-ie eigenlijk niet kan, namelijk alvast aan de volgende opdracht beginnen terwijl de vorige nog niet was afgerond. Vergelijk het met een kantoor waar de verzendbonnen alvast in orde worden gemaakt voordat 100% zeker is dat de adressen correct zijn, omdat de administratie nog bezig is om de mutaties van de afgelopen weken te verwerken. Dat gaat vaak goed, maar soms gaat het fout, en dan moet je alsnog dingen corrigeren; vandaar dat er een limiet is aan hoe ver je kunt "parallelliseren". Er moet namelijk wel op de een of andere manier worden gecontroleerd of verschillende opdrachten elkaar niet in de wielen rijden.
Meer op "processor"-niveau: als ik de processor twee getallen laat optellen en het resultaat op een bepaalde plek in het geheugen laat zetten, en daarna de inhoud van diezelfde geheugenplaats ergens anders voor wil gebruiken, kan ik die dingen niet tegelijk doen, en moet ik wachten tot de berekening is afgerond (ik kan wel alvast wat dingen "klaarzetten", en dat noemen we "pipelining"). Maar als de volgende opdracht helemaal niets te maken heeft met de uitkomst van de berekening, maar bijvoorbeeld alleen een ander getal ergens verplaatst in het geheugen omdat ik het daar wil hebben, kan ik dat prima tegelijkertijd doen.
Voor "voorwaardelijke sprongen" zijn er andere trucs. Stel dat ik "A" of "B" moet doen, afhankelijk van de uitkomst van een berekening. Dan doe ik het (voorzover mogelijk) gewoon allebei, en als ik weet wat ik had moeten doen, gooi ik de uitkomst die ik niet nodig had gewoon weg. In kantoor-analogie: ik ga nu naar de klantenserviceafdeling om de klachtenbus te legen; als er geen klachten zijn, gaat er een jubelende brief naar het hoofdkantoor, als ze er wel zijn, gaat er een "mea culpa"-achtig iets heen. Dan schrijft iemand anders dus alvast allebei de brieven, en zodra we weten wat er nodig is, gooi je de verkeerde brief weg en kan de goede meteen naar het hoofdkantoor. Dat vereist wel twee of drie medewerkers ipv één, en een chef die weet wat-ie aan het doen is. Een processor heeft dan ook meerdere rekeneenheden nodig om dingen tegelijkertijd te kunnen doen, en een complexere architectuur om alles in goede banen te leiden. Dat soort "trucs" liggen aan de basis van superscalaire processoren.
Een superscalaire architectuur is geen vectorarchitectuur: daarbij kunnen berekeningen sneller worden uitgevoerd omdat je dezelfde opdracht moet uitvoeren voor verschillende data: als ik alleen maar dat ene rapport hoef te kopiëren, geef ik iedereen een paar pagina's, en dan zijn we heel snel klaar. Die opdrachten kunnen elkaar niet in de wielen rijden, omdat ze elkaar niet beïnvloeden.
Dit is ongeveer het niveau waarop ik het als betrekkelijke leek kan "begrijpen" ;-) Ik hoop dat ik de boel niet ingewikkelder maak dan nodig (of dat ik het zelfs helemaal fout heb...) Paul B 13 aug 2007 22:35 (CEST)