SMT, OOO op grote schaal

[justice strike]

ik had vandaag/gisteren een discussie over het implementeren van SMT op software schaal en hardware schaal (op tweakers natuurlijk) ik zal ff hier copieen en pasten

Er staat :"Het systeem met de Prescott - welke op 0,09 nanometer geproduceerd gaat worden - aan boord bewees zich door zich te onderscheiden van de Pentium tijdens het tegelijkertijd encoden van muziek en het afspelen van een videofragment."

Twee processen dus, waarvan er tenminste één 100% cpu voor zich kan opeisen. Dat het andere process dan nog vloeiend blijft draaien geen best wel iets aan. Niks quantitatiefs, maar het is daar ook nog wel wat vroeg voor.



Gepost door justice strike maandag 15 juli 2002 - 23:28 Score: 3 (Interessant)
ok laten we wel stellen dat cpu's alijd met timesplicing werken als we het over multiprocessen hebben. of dit nu door de cpu of door de software geregeld word wil niet zeggen dat het een beter is dan de ander.

ik kan een mp3 encoden en divx afspelen op een p4 mit's ik ze dezelfde prioriteit geef onder windows (linux of elk ander os) kan je heel makkelijk doen. dan neemt de divx alles wat hij nodig heeft om het af te spelen en de mp3 de rest.

laat mij nu maar eerst zien dat het encoden SNELLER gaat dan zonder hyperthreading. dan pas hebben ze wat bewezen. is dit niet het geval dan kan ik ook met een verbeterde versie van de pentium komen.
(ie. pentium 4 special windows editie met verbeterde drivers.!!)



Gepost door RickN maandag 15 juli 2002 - 23:56 Score: 3 (Inzichtvol)

ok laten we wel stellen dat cpu's alijd met timesplicing werken als we het over multiprocessen hebben.
Nee, laten we dat maar niet stellen, want dan sluit je technieken als Hyperthreading juist uit. Een proc met Simultanious Multi Threading (=Intels Hyperthreading) voert fysiek meerdere thread in parallel uit, er wordt daar niks meer gespliced. Je moet je inbeelden dat één proces gewoon de proc 100% bezet, en dat eventueel niet gevulde issuesloten (en dat zijn er vaak best veel) in de proc gevuld worden met instructies van een tweede thread. Dat is gewoon gratis extra performance, want zonder SMT zouden die issueslots verloren zijn gegaan. Die ene proc is dan dus op 1 moment 2 threads aan het executen. SMT probeert dus IPS te verhogen door gelijktijdig Thread en Instruction Level Parallellism uit te buiten.



Gepost door justice strike dinsdag 16 juli 2002 - 08:43 Score: 2 (Inzichtvol)
ja ga maar terug naar les 101 van computer architectuur cpu's maken altijd gebruik van timeslicing. wat er nu geintroduceerd wordt kan dan mischien multithreaded eruit zien maar het is gewoon een hardwarematige timemanager. IMHO is dit gewoon een deel van de software wat in de hardware word gezet (CISC).



Gepost door RickN dinsdag 16 juli 2002 - 10:04 Score: 2 (Informatief)
Nou ja, ik heb tenminste vakken computer architectuur gevolgd, wat ik van jou betwijfel, gezien je reacties. Weet je überhaupt wel wat SMT is? Ga er eerst maar eens een stukje over lezen voor je hier over irrelevante zaken als timesplicing komt blaten. SMT is niet iets wat je in software kunt oplossen omdat het (zoals ik al gezegd heb, betweter) controle vereist over de individuele issue slots van de proc. Dit staat weer helemaal los van de RISC, CISC discussie. Maar ja, van iemand die CISC bijna defineerd als het verschuiven van software taken naar hardware kan je ook niet meer verwachten... Doei!



Gepost door justice strike dinsdag 16 juli 2002 - 14:35 Score: 2
ik heb computer architectuur gevolgd en afgesloten met een 9. jij hebt het mischien gevolgd maar ik betwijfel of je er wat van opgestoken hebt. je zit je namelijk blind te staren op een ding (smt)

je kan het niet apart zien. smt is een soort ooo execution op grotere schaal. (das dan wel heel grof gezegd). ooo zou zoals je weet ook met goede compiler bouw software matig opgelost kunnen worden. Het zou zelfs na de compilerbouw kunnen worden aangepast. een goed voorbeeld is jvm en natuurlijk de codemorphing van de C3.

de ooo execution word toch helemaal software matig gedaan op de c3. smt zou ook softwarematig gedaan kunnen worden.

alles kan in software gedaan worden. in principe zit veel software op de processor geintegreerd. veel instructies zijn te doen met veel basischere functies (het principe van risc)

overigens hoeft smt niet eens sneller te zijn. er zijn genoeg voorbeelden te bedenken waarin smt juist langzamer is dan geen smt. zowel in dual als in single proc opstelling.

je zal gerust computerarchitectuur gedaan hebben maar een processor moet je als geheel zien. en je meot je niet blindstaren op afzonderlijke componenten.

in iedergeval vind ik de crusoe toch een vooraanstaand voorbeeld van het feit dat SMT en OOO toch in software gerealiseerd kan worden.

in principe kan alles gerealiseerd worden op software niveau. Het probleem is alleen hoe men dit wil realiseren aangezien het niet echt iets is waar men aan denkt.

wat is jullie mening hierover.

edit:

zo beter?? sorry voor het ongemak

[Grrrrrene]

Kun je ipv de layout te verneuken met code, niet beter [quote] tags gebruiken?

[CaineTanathos]

de-neuken, en dan zal ik er misschien aan uitkunnen

[justice strike]

de-neuken, en dan zal ik er misschien aan uitkunnen

wat bedoel je hermee??

[Olaf van der Spek]

Op dinsdag 16 juli 2002 15:08 schreef justice_strike het volgende:
ik had vandaag/gisteren een discussie over het implementeren van SMT op software schaal en hardware schaal (op tweakers natuurlijk) ik zal ff hier copieen en pasten

Dan zal ik dat ook even doen:

Het gaat hier over twee threads (van een of twee processen). Hoe kan de compiler nou weten welke twee threads er tegelijkertijd in de toekomst actief zullen zijn op elk systeem wereldwijd?
Dat kan de compiler helemaal niet weten, het moet real-time geinterleaved worden. En dat kan je niet softwarematig doen.

[RickN]

En ik ook maar dan

Met alle respect hoor, maar bij welke opleiding heb jij dan computer architectuur gevolgd, want dáár wil ik dan dus nooit terecht komen.

Ik wilde eigenlijk geen woorden meer aan deze thread vuil maken, maar jij blijft op de man spelen en dus zal ik even moeten reageren door elk punt dat je probeert te maken tot de grond toe af te branden.

je kan het niet apart zien. smt is een soort ooo execution op grotere schaal. (das dan wel heel grof gezegd).

Nee, het heeft niks met OOO te maken, het is hooguit Multiple Issue op grote schaal, maar dat is niet onlosmakelijk aan OOO verbonden.

ooo zou zoals je weet ook met goede compiler bouw software matig opgelost kunnen worden.

Zoals jij blijkbaar niet weet kan een compiler in principe geen OOO overnemen. Teneerste heb je het runtime aspect waar een compiler met wat profiling maar gedeeltelijk rekening kan houden. Veel belangrijker is (dit punt gaat aantonen dat jij totaal geen verstand van zaken hebt) is het feit dat een compiler naar een instructie set optimaliseert en niet naar een specifieke implementatie daarvan. Om OOO te kunnen heb je hele specifieke informatie nodig over de architectuur van de proc waar de code op wordt uitgevoerd, b.v. het aantal en de aard van de issue sloten, dit is informatie die een compiler niet heeft of geen gebruik van maakt omdat het nadelig zou zijn voor de performance op andere systemen. Wat een compiler hooguit kan doen is instructies iets anders ordenen in de hoop dat een proc hier gebruik van kan maken, maar dat kan nooooit op tegen hardwired OOO die is toegespits op één specifieke proc. Daarnaast, als een compiler de code anders gaat schedulen om die taak van de proc over te nemen spreek je per definitie natuurlijk niet meer van OOO omdat de proc alle (weliswaar anders dan normaal geschedulde) instructies dan gewoon In Order uitvoert.

Het zou zelfs na de compilerbouw kunnen worden aangepast. een goed voorbeeld is jvm en natuurlijk de codemorphing van de C3.

Je bewering was al fout, dus je kunt er geen goede voorbeelden van geven. Overigens mag jij mij uitleggen wat jvm en codemorphing met OOO te maken heeft.

de ooo execution word toch helemaal software matig gedaan op de c3. smt zou ook softwarematig gedaan kunnen worden.

Je praat hier over een heel ander niveau van software. Er zijn inderdaad procs die je als het ware kunt herprogrammeren, en dat zou je software kunnen noemen. In de huidige context denk ik dat met software het OS en aanverwante zaken moet worden bedoelt. Als je b.v. een audio filter op een FPGA programmeerd, noem je het resulterende IC dan hardware of software (ga nu aub niet software zeggen, please....)

alles kan in software gedaan worden.

Hangt zoals ik al zei van je definitie van software af. Het kan als je software bedoelt die de functionaliteit van een chip beïnvloed/specificeerd, niet met software die van een chip gebruikmaakt.

in principe zit veel software op de processor geintegreerd. veel instructies zijn te doen met veel basischere functies (het principe van risc)

Ik neem aan dat je hier naar een microcode rom refereerd? Zo'n rom kun je idd software noemen ja, maar niet in de gebruikelijke context. Leuk dat je weer met een verwijzing naar RISC laat zien hoe weinig je er eigenlijk van weet. Microcode is typisch iets CISCs, in veel implementaties van een CISC ISA worden ingewikkelde instructies intern vertaald naar eenvoudigere instructies, maar deze eenvoudigere instructieset kun je geen volwaardige RISC ISA noemen.

overigens hoeft smt niet eens sneller te zijn. er zijn genoeg voorbeelden te bedenken waarin smt juist langzamer is dan geen smt. zowel in dual als in single proc opstelling.

Zulke voorbeelden zul je altijd houden ja, maar in theorie is SMT een techniek die tegen weinig extra kosten (hardware) een interesante performance winst kan opleveren, door performance die anders verloren zou gaan beter uit te buiten. Er een single/dual aspect bijhalen is je zoveelste irrelevante opmerking.

je zal gerust computerarchitectuur gedaan hebben maar een processor moet je als geheel zien. en je meot je niet blindstaren op afzonderlijke componenten.

Het component waar ik me zogenaamd op blindstaar is toevallig wel het onderwerp van deze discussie. Daarnaast is SMT een techniek die vrij goed te isoleren is en toepasbaar is op zeer uiteenlopende processor architecturen, zowel RISC als CISC, maar ook VLIW en SIMD.

Fijn met je gediscuseerd te hebben.

edit:
En hier wil ik nog aan toevoegen:
Je ging bij je eerste reactie al de fout in door met timeslicing aan te komen. Dit is een concept uit de hoek van Operating Systems en heeft helemaal niks met processor architecturen te maken. Je kunt dus niet zeggen dat een proc gebruik maakt van timeslicing. Daarnaast is het een feit dat een SMT enablede proc in staat is om meerdere threads fysiek in parallell uit te voeren. Als je hier commentaar op heb stel ik voor dat je er eerst wat over gaat lezen (net als ik) en er dan op terug komt.

[Olaf van der Spek]

Op dinsdag 16 juli 2002 19:27 schreef RickN het volgende:
Veel belangrijker is (dit punt gaat aantonen dat jij totaal geen verstand van zaken hebt) is het feit dat een compiler naar een instructie set optimaliseert en niet naar een specifieke implementatie daarvan.

Er zijn wel compilers die specifiek voor een bepaalde processor optimalisren.

[RickN]

Op dinsdag 16 juli 2002 20:08 schreef OlafvdSpek het volgende:

[..]

Er zijn wel compilers die specifiek voor een bepaalde processor optimalisren.

Ja, vast wel. Ik zeg ook dat de compiler de informatie niet heeft OF er geen gebruik van maakt. Er zullen altijd uitzonderingen zijn op die regel. Als een of ander bedrijf een berg servers heeft staan met UltraSparc III erin zal het misschien best nut hebben om applicaties daarvoor speciaal te compileren en er zullen best softwarehuizen zijn die dat voor hun klanten doen. Maar de over grote meerderheid van de software, ook die voor bedrijven zal toch naar een ISA gecompileerd worden en niet naar een implementatie daarvan, omdat er anders performance verlies (en misschien zelfs functionele incorrectheid) op andere machines kan optreden. Het punt dat ik probeer te maken is dat een compiler slecht in uitzonderlijke gevallen voor implementatie specifieke optimalisaties (b.v. om OOO over te nemen ) gebruikt kunnen worden.

[justice strike]

ik denk dat we de hele tijd langs elkaar gepraat hebben. Ik refereerde namelijk naar ooo omdat die de code zodanig door elkaar husselt dat er zoveel mogelijk berekeningen naast elkaar gedaan kunnen worden (zonder natuurlijk het programma te veranderen)

op zich lijkt het op smt aangezien smt 2 processen zodanig door elkaar weeft dat zoveel mogelijk berekeningen gedaan kunnen worden.

Aangezien ooo in software gedaan kan worden (kijk naar de c3) is dit ook te doen met smt.

dat jij codemorphing niet als software ziet en ik wel, das een misverstand.

ik haalde compilerbouw erbij omdat:
1 tegenwoordig de efficientie ook in de compiler zit. aangezien je slecht assembler en goede assembler uit kan spugen. dit heeft dan ook voornamelijk met de volgorde te maken. (en natuurlijk andere kleine elementen)

2 ooo lijkt natuurlijk ook heel erg op de jit en laten we wel wezen jvm is toch ook gewoon software of reken je dat ook tot de hardware?

edit:

ik heb trouwens nog eens even opgezocht in mijn literatuur hoe dat zit met compilers en superscalar procs en ik heb inderdaad gelijk dat compilers daadwerkelijk een rol spelen in het paralel laten lopen van instructies. zonder een goede compiler bouw zou de ooo op de cpu niet goed zijn taak kunnen doen


welk boek:

titel: Computer Systems Architecture.
Auteur: Rob Williams
Uitgeverij: Addison-Wesley
ISBN 0-201-64859-8

waar in het boek:

hoofdstuk 21: risc processors
blz 534
paragraaf 3 superscalar methods - parallel parallelism

[RickN]

Aangezien ik GoT toch wel een betere discussie plaats vind dat de FP zal ik me niet laten kennen toch maar weer reageren. Als we allebei ons ego een beetje in bedwang houden is dit een erg interessante discussie, al denk ik dat we er zo ongeveer wel uit zijn.

Op dinsdag 16 juli 2002 23:34 schreef justice_strike het volgende:
ik denk dat we de hele tijd langs elkaar gepraat hebben.

Dat zie je vaak in discussies die een beetje oververhit raken

Ik refereerde namelijk naar ooo omdat die de code zodanig door elkaar husselt dat er zoveel mogelijk berekeningen naast elkaar gedaan kunnen worden (zonder natuurlijk het programma te veranderen)

op zich lijkt het op smt aangezien smt 2 processen zodanig door elkaar weeft dat zoveel mogelijk berekeningen gedaan kunnen worden.

Dit kan ik wel volgen, alleen denk ik dat je voor SMT niet persee OOO nodig hebt. Twee threads kunnen ook gewoon In Order in parallel uitgevoerd worden. Aan de andere kant vereist SMT wel een vorm van Multiple Issue, anders valt er niks parallel te doen, vandaar dat ik het liever daarmee vergelijk.

Aangezien ooo in software gedaan kan worden (kijk naar de c3) is dit ook te doen met smt.

dat jij codemorphing niet als software ziet en ik wel, das een misverstand.

Ik heb voor de zekerheid maar weer een keertje wat over de crusoe gelezen en ik kan moeilijk ontkennen dat wat daar gebeurt toch wel erg dicht bij software in de buurt komt. Wat ze min of meer doen is een "software" compiler draaien op de echte hardware, die ix86 instructies vertaalt naar de eigenlijke ISA en die instructies dan parallel met de compiler op de echte hardware draait. De grens is hier wat vager dan bij b.v. een microcode rom, maar toch blijf ik vinden dat het hier een ander niveau van software betreft dan applicatie software.

1. Je kunt deze software nauwelijks los zien van de processor. In ieder geval niet op de manier waarop je b.v. Word los kunt zien van een pentium
2. De software is volledig met het oog op de crusoe ontwikkeld en de instructieset van de crusoe heeft zelfs voorzieningen om de code morphing software extra goed te kunnen draaien; voorzieningen die in reguliere software geen functie hebben.
3. De code morphing software heeft veel lower level access tot de hardware dan welke applicatie software (incl. bios en OS) dan ook.

ik haalde compilerbouw erbij omdat:
1 tegenwoordig de efficientie ook in de compiler zit. aangezien je slecht assembler en goede assembler uit kan spugen. dit heeft dan ook voornamelijk met de volgorde te maken. (en natuurlijk andere kleine elementen)

edit:

ik heb trouwens nog eens even opgezocht in mijn literatuur hoe dat zit met compilers en superscalar procs en ik heb inderdaad gelijk dat compilers daadwerkelijk een rol spelen in het paralel laten lopen van instructies. zonder een goede compiler bouw zou de ooo op de cpu niet goed zijn taak kunnen doen
[..]

Ik heb ook gezegd dat een compiler best wel wat aan de volgorde van instructies kan doen, maar omdat een compiler alleen met wat profiling een idee kan krijgen van de daadwerkelijk instructie stroom die in een typisch geval uitgevoerd zal worden en omdat er van één ISA vaak meerdere implementaties zijn kan een compiler deze optimalisaties nooit zo goed doen als dedicated hardware. Dit is ook één van de aanmerkingen die iemand als Paul Demone heeft op intels EPIC. Hier zitten ook alle scheduling optimalisaties in de compiler en dat haalt het gewoon niet bij OOO hardware. Tja, en crusoe is wat dat betreft een vreemde eend in de bijt omdat ze daar een compiler hebben die wel zicht heeft op de daadwerkelijke instructie stroom en maar naar één specifieke microarchitectuur hoeft te compileren. Op dezelfde manier als crusoe OOO "in software" doet zou ook SMT "in software" gedaan kunnen worden.

2 ooo lijkt natuurlijk ook heel erg op de jit en laten we wel wezen jvm is toch ook gewoon software of reken je dat ook tot de hardware?

Vind ik eigenlijk best een moeilijke vraag Je kunt de jvm zien als hardware die op andere hardware gesimuleert wordt; maar dit is een hele andere discussie, laten we daar (nu) niet verder op in gaan.

Ik denk dat we nu toch even een paar conclusies moeten trekken. Met name op het punt waar de discussie eigenlijk over begon zijn nog wel wat dingen te zeggen.

1. SMT is een nieuwe (in de praktijk, oud in de theorie) techniek die niks met timeslicing te maken heeft en die dus ook niet van software naar hardware is verhuist. Timeslicing is een OS concept dat samenhangt met multitasking en context switches. Een conventionele processor heeft helemaal geen weet van threads, hij voert gewoon instructies uit die het OS hem aanbiedt. Een SMT proc heeft wel weet van meerdere threads, maar hij gaat die niet hardwarematig timeslicen, maar hardwarematig parallel uitvoeren. Als je SMT tenopzichte van timeslicing wilt positioneren zou ik zeggen dat TS taken interleaved in time en SMT taken interleaved in space. Omdat je uit de instrucities van meerdere threads meer instrution level parallellisme kunt halen dan uit de instructies van 1 thread zorgt SMT ervoor dat de pipeline en de issueslots van de proc (de ruimte) beter gevuld kunnen worden wat zorgt voor extra performance. SMT verhoogt zo niet de performance van één enkele taak (in de tijd), maar wel de doorloop tijd van een groepje van taken. Je moet er echt eens iets over lezen, het is echt een prachtige techniek (in theorie )

2. Compilers spelen een belangrijke (om niet te zeggen crusiale) rol in de performance van hedendaagse processoren. In mijn zoektocht naar een promotieplaats ben ik erachter gekomen dat hier ook zeer veel onderzoek naar wordt gedaan en wat dat betreft zullen compilers ook een steeds belangrijkere rol gaan spelen. Maar toch kun je stellen dat een statisch compiler nooit zo goed zal kunnen optimaliseren als hard/software die runtime informatie en architectuur details tot z'n beschikking heeft.

Zo, denk je dat hiermee alle losse eindjes in de discussie zijn afgesloten?

[justice strike]

tja vrijwel alles ja hier kan ik het wel mee vinden. feit blijft natuurlijk dat alles in software gedaan kan worden. mischien niet zo effiecient maar het kan wel. vms is een voorbeeld erop. die zorgt ervoor dat 2 pc's geemuleert worden op een pc(zelfde geld voor jvm. als je dat meeneemt in de beredenering kan smt gewoon in software gedaan worden. is alleen heel erg moeilijk voor programeurs om dat te doen.

Als windows alle threads zouden "hercompileren" zodat het als een thread aan de processor gevoerd kan worden, zou het de programeurs jaren werk kosten om dat goed en efficient te programmeren.

maarja zoals ik al eerder zei ik vind de demo niet echt iets voorstellen aangezien (en daarom begon ik over timeslicing) een thread dezelfde prioriteit kan geven als de andere thread. Het mp3 en de video afspelen kan dan gewoon gebeuren zonder dat de video happert.

als ik een p4 neem en die threads dezelfde prioriteit geef dan happert de video ook niet. hoe weet ik nu dat de xeon nou daadwerkelijk smt gebruik? kan ik dan alleen zien aan het feit dat de xeon sneller zou moeten zijn

dus om mijn eerste post wat duidelijker te maken. ik veronderstelde dus niet dat smt niet bestaat maar stel ik heb een processor die alleen met timeslicing werkt dan kan ik die zodanig instellen dat alle processen vloeiend verlopen en niet zo een vertekende demo als intel heeft gegeven.

[Olaf van der Spek]

Op woensdag 17 juli 2002 11:59 schreef RickN het volgende:
Dit kan ik wel volgen, alleen denk ik dat je voor SMT niet persee OOO nodig hebt. Twee threads kunnen ook gewoon In Order in parallel uitgevoerd worden. Aan de andere kant vereist SMT wel een vorm van Multiple Issue, anders valt er niks parallel te doen, vandaar dat ik het liever daarmee vergelijk.

Volgens mij is OoO onafhankelijk van SMT. Bovendien hebben beide geen multiple-issue nodig. Van OoO heb je namelijk zonder multiple-issue voordeel als er een leeg slot is (data dependency, data/memory delay).

Ik heb voor de zekerheid maar weer een keertje wat over de crusoe gelezen en ik kan moeilijk ontkennen dat wat daar gebeurt toch wel erg dicht bij software in de buurt komt. Wat ze min of meer doen is een "software" compiler draaien op de echte hardware, die ix86 instructies vertaalt naar de eigenlijke ISA en die instructies dan parallel met de compiler op de echte hardware draait. De grens is hier wat vager dan bij b.v. een microcode rom, maar toch blijf ik vinden dat het hier een ander niveau van software betreft dan applicatie software.

De P4 decodeert de instructies ook en de gedecodeerde instructies komen in de instructie cache. Maar die vertaling is niet te 'customisen'.