De zin en onzin van 'omgekeerde HyperThreading'

Het 'geheime wapen'

Er zijn de laatste tijd een aantal geruchten voorbij gekomen over een 'geheim wapen' van AMD, een feature die bij gebrek aan een (code)naam 'omgekeerde HyperThreading' wordt genoemd, refererend aan de marketingterm voor Intels implementatie van SMT in de Pentium 4. Uit de vage omschrijvingen die uit de geruchtenmolen zijn komen rollen kunnen we alleen het globale idee opmaken: het zou er op neerkomen dat twee (of zelfs meer) cores tegelijkertijd aan dezelfde thread kunnen werken. Hierdoor zou software die helemaal niet geoptimaliseerd is voor dual- of quadcoreprocessors toch sneller kunnen draaien op zulke chips. Er zijn verschillende manieren waarop zoiets in theorie bereikt kan worden. Een populaire - maar onwaarschijnlijke - verklaring is dat cores elkaars execution units kunnen gebruiken, met andere woorden: dat instructies naar een andere core geschoven kunnen worden op het moment dat het te druk wordt. In technische termen heet dat concept Cluster Multithreading.

Er zijn verschillende redenen waarom deze aanpak een onwaarschijnlijke is: ten eerste komt het niet vaak voor dat de prestaties van een core daadwerkelijk beperkt worden door een tekort aan execution units. De Athlon 64 heeft er bijvoorbeeld maar liefst negen aan boord: drie voor floating point (FPU), drie voor integers (ALU) en drie voor geheugenadressen (AGU). In totaal kan de processor dus aan negen opdrachten tegelijk werken. Helaas wordt dat in de praktijk vrijwel nooit gehaald: zo kan de architectuur bijvoorbeeld maar drie instructies tegelijk de pipeline ingooien en ook maar drie resultaten tegelijk wegschrijven. Verder is het zo dat de meeste software die drie nog niet eens haalt: het gemiddelde IPC (instructions per cycle) van x86-processors in de bekende benchmark SPECint2000 ligt in de praktijk maar net boven de één.

Meer parallellisme is zeker niet onmogelijk: een academisch onderzoek heeft aangetoond dat de Itanium met een geniale compiler richting de vijf kan gaan in dezelfde benchmark. We hebben het dan echter over een EPIC-systeem, waarbij al het mogelijke parallellisme per definitie al in de code zelf verwerkt zit. De processor hoeft dus niets anders te doen dan 'dom' het programma uitvoeren. x86 kent zoiets niet: de processor moet tijdens het uitvoeren van de instructies helemaal zelf uitzoeken welke opdrachten eventueel tegelijk kunnen draaien. Als een programmeur een halfuur moet wachten op zijn compilatie vindt hij het misschien wel veel, maar voor een processor is een microseconde al een eeuwigheid. Iemand met een praktisch idee dat kan helpen om de gemiddelde IPC met een tiende te verhogen kan goud geld verdienen bij Intel of AMD. De kern van het verhaal is dat het toevoegen van een paar extra eenheden veel makkelijker is dan het vullen ervan.

Waarom worden er dan toch negen execution units in de Athlon 64 gebakken? Ten eerste werkt een processor intern niet echt met x86-instructies, maar worden die vertaald naar een interne instructieset, zogenaamde micro-ops. Soms gaat die vertaling één op één, maar vaak heeft een x86-instructie ook twee of drie micro-ops nodig. In zeldzame gevallen kunnen het er zelfs honderden zijn, maar moderne software loopt daar met een grote boog omheen. Een instructie kan in sommige gevallen dus wel meerdere eenheden bezighouden. Dit komt bijvoorbeeld voor in code die geen registers gebruikt, maar een berekening rechtstreeks op een geheugenlocatie uit wil voeren. In dat geval moet een AGU eerst het fysieke adres berekenen voor een ALU of FPU de som kan uitvoeren. Verder hebben veel instructies meerdere kloktikken nodig, waardoor een eenheid een tijdje bezig kan blijven terwijl er geen nieuwe invoer binnenkomt. Ook hebben de eenheden verschillende specialismes: één van de floating point-eenheden kan bijvoorbeeld vermenigvuldigen, terwijl de ander kan delen.

Er zijn dus wel scenarios te bedenken waar extra eenheden kunnen helpen om de prestaties te verbeteren: als er bijvoorbeeld twee dezelfde instructies tegelijk uitgevoerd kunnen worden terwijl er maar één eenheid beschikbaar is om die specifieke instructie te verwerken. Dus waarom zou er dan niet even een tweede eenheid 'geleend' kunnen worden van een andere core? Het antwoord daarop is de latency: als de twee instructies op dezelfde core uitgevoerd worden gaat eerst de eerste instructie de pipeline in, en vervolgens de tweede. De vertraging is in dat geval maar één tik. Met een techniek als Cluster Multithreading zou de instructie eerst naar een andere core gestuurd moeten worden. Vervolgens moet die andere core de data krijgen waar mee gewerkt moet worden, en na de berekening moet het resultaat ook nog worden teruggestuurd. Dit alles kost een hoop tijd: de Athlon 64 heeft naar zijn eigen L1-cache al een latency van drie kloktikken, dus het zal niet sneller zijn om een andere core te bereiken. Al met al zal er dus een hoop tijd worden verspeeld puur aan communicatie, terwijl de tweede instructie anders gewoon vlak na de eerste had kunnen starten.

Raadselachtige techniek

We hebben nu nog maar één scenario over waarin Cluster Multithreading veel zin heeft: als een core een continue stroom van dezelfde instructies voor zijn kiezen krijgt, niet beperkt wordt door andere factoren zoals vertakkingen in de code, onderlinge afhankelijkheden, latency en bandbreedte, en ook niet genoeg eenheden heeft om deze af te handelen. Dit komt op zich wel voor, maar vooral in het soort applicaties (zoals encryptie, renderen en videobewerking) dat van nature al makkelijk over meerdere threads te verdelen is. Voor zover dat op dit moment nog niet gebeurt, zal het niet lang meer duren voor dat verandert: in een tijdperk waarin dualcores zo ongeveer de standaard zijn geworden kan een zichzelf serieus nemende ontwikkelaar het niet meer maken om zulke grote potentiële winsten links te laten liggen.

De vraag is dus of het de moeite waard is om voor de 'oude' software en andere speciale gevallen de hardware zo drastisch aan te passen als voor Cluster Multithreading nodig is. Deze vorm van samenwerking vereist namelijk een enorme complexiteit: niet alleen moet de communicatie op zich mogelijk gemaakt worden, maar ook moet de - toch al complexe - logica die omgaat met dingen als exceptions, interrupts, context switches, prefetching en branch mispredictions aangepast worden om rekening te houden met het feit dat 'lokale' instructies op een andere core kunnen zijn, en dat er ondertussen ook instructies van andere cores lokaal kunnen draaien. Het aantal combinaties van omstandigheden stijgt explosief en het zou een monumentale onderneming zijn om dat goed te ontwerpen en uit te testen. AMD heeft zelf geschat dat een core met Cluster Multithreading de helft groter zou zijn dan één zonder. Meer logica betekent niet alleen meer ontwerp- en testwerk, maar ook meer warmte-ontwikkeling, lagere yields, hogere kosten per chip en een grotere kans dat de maximale kloksnelheid beperkt wordt. Is het nou werkelijk verstandiger om dat allemaal te riskeren, in plaats van simpelweg een paar extra functionele eenheden toe te voegen en/of te wachten tot programmeurs meerdere cores gaan gebruiken?

Hoe dan ook: op de plaatjes die zijn vrijgegeven van het in 2007 verwachte K8L-ontwerp is geen spoor te bekennen van de complexiteit die nodig is om aan Cluster Multithreading te kunnen doen. Als AMD daadwerkelijk aan zoiets revolutionairs werkt zou het op zijn vroegst in de K10-processor verwacht kunnen worden. De recente geruchten suggereren echter een hele andere planning: de 'omgekeerde HyperThreading' zou zelfs met de huidige AM2-processors mogelijk zijn, en niet meer dan een update van Windows en de processordriver vereisen.

Hier is dus iets vreemds aan de hand: een zeer ingrijpende nieuwe feature verschijnt niet zomaar in een al drie jaar lang praktisch ongewijzigde processor, en al helemaal niet door een software-update. Hoewel er genoeg voorbeelden zijn van processors die een tijdje door het leven zijn gegaan met uitgeschakelde features, was dat bij écht belangrijke dingen (zoals bijvoorbeeld 64-bit op de Prescott) duidelijk zichtbaar voor een getraind oog, en het heeft nooit vele jaren en verschillende transistorgeneraties geduurd voor ze ingeschakeld werden. Bovendien had AMD tijdens het ontwerpen van de K8 al meer dan genoeg hooi op zijn vork genomen (zoals het invoeren van AMD64, het integreren van de geheugencontroller en HyperTransport), waardoor het onwaarschijnlijk lijkt dat men destijds mankracht overhad om zo'n radicale vernieuwing in te bouwen.

Pixel-expert Hans de Vries vond geen verbeteringen in de AM2-versie van de K8

Waar rook is, is vuur. Dat blijkt vaak het geval te zijn met dit soort geruchten. We willen dan ook niet uitsluiten dat AMD iets achter de hand houdt wat op 'omgekeerde HyperThreading' lijkt. Een techniek die bijvoorbeeld al vaak bestudeerd is, is om een tweede core precies dezelfde instructies te voeden als de eerste core, maar ze alleen te bekijken in plaats van ze daadwerkelijk uit te voeren. De tweede core loopt als het ware vooruit op de eerste en kan alvast gegevens klaarzetten in het cache. Ook zou deze 'scout' andere informatie kunnen verzamelen, bijvoorbeeld om beter te kunnen voorspellen welke kant van een vertakking genomen zal worden. Dit is een minder radicale wijziging, maar het probleem hierbij is wel dat het alleen kan werken als de cores tenminste één niveau van cache delen. Toekomstige Opterons en Athlon FX-modellen krijgen een gedeeld L3-cache, maar de huidige processors hebben dat niet, waardoor ook deze verklaring in het water valt.

Wat er dan wel gaat gebeuren is een raadsel, maar mogelijk is het iets meer softwarematigs. In dat geval zou het wellicht ook bij Intel kunnen werken, en vreemd genoeg zijn ook daar hints voor te vinden: in de nieuwste BIOS-versie voor de 975X-moederborden is vlak onder HyperThreading een nieuwe optie verschenen die 'Core Multiplexing' genoemd wordt. Intel kon ons nog niet vertellen waar deze functie voor dient. Toeval of niet? Zoals altijd zal de tijd het moeten leren.

Reacties (98)

[Guru Evi]

Core multiplexing, vanuit een elektronisch standpunt zou het er op neer komen dat met een schakelaartje 2 opeenvolgende instructies van een thread simultaan door de pipelines processor laten lopen en dat er aan het einde dan gewoon een schakelaartje staat die de 2 waarden uitleest. Als dat schakelaartje dan kwadratisch sneller per kloktik van de cores (4x bij 2 cores) omschakelt dan worden de 2 waarden snel genoeg uitgelezen om bruikbaar te zijn.

Instructies uitwisselen is te duur voor zulke dingen en is sub-optimaal zoals bij sommige grote rekenclusters het ook sub-optimaal is om programmatuur te gebruiken die pakketjes (threads of instructies) random of round robbin naar een node stuurt en die dan niet kan afhandelen omdat ie te druk bezig is. De instructie moet toch afgehandeld worden en komt gewoon in een andere queue terecht terwijl er kosten zijn om die dingen af te handelen (uit queue nemen, kopieren, naar queue schrijven).

Tegenwoordig is elke processor reeds RISC-based. CISC is een oud systeem vanuit de jaren 80 die vanwege legacy besturingssystemen (lees: Windows) nog steeds aanwezig is in desktop computers in de vorm van CISC -> RISC vertaling. Energie wordt dan ook verspild aan het CISC-emuleren van de processor terwijl alle moderne OS'en op RISC processoren kunnen draaien mits een andere kernel. Natuurlijk is het ook enorm duur om een volledig nieuwe processorarchitectuur uit te vinden en te ondersteunen (Power, Itanium) maar eenmaal je de consument kunt laten overschakelen is het toch een goede stap (zie Apple).

[Wouter Tinus]

Natuurlijk is het ook enorm duur om een volledig nieuwe processorarchitectuur uit te vinden en te ondersteunen (Power, Itanium) maar eenmaal je de consument kunt laten overschakelen is het toch een goede stap (zie Apple).

Het probleem is dat nieuwe of alternatieve architecturen - ondanks wat voor theoretische voordelen dan ook - er in de praktijk nog nooit in geslaagd zijn om x86 in de praktijk voorbij te streven (althans voor consumenten). Er worden jaarlijks honderden miljoenen dollars in x86 geïnvesteerd, waardoor er een gigantische schat aan informatie en ervaring is opgebouwd over hoe het optimaal geïmplementeerd en gebruikt kan worden. Men heeft ieder rariteitje grondig bestudeerd en weet dus precies hoe er omheen gewerkt moet worden. Verder heeft x86 veruit de best ontwikkelde compilers en productietechnieken aan zijn kant staan. Het is erg moeilijk om daar tegenop te boksen met een nieuw idee, hoe goed dan ook. De investeringen die nodig zijn om een succesvolle architectuur neer te zetten kunnen eigenlijk alleen maar betaald worden door grote aantallen chips te verkopen, en dat is een kip-ei probleem. Het komt er op neer dat x86 zichzelf in stand houdt.

Er zijn mensen die voorspellen dat x86 door zijn steeds maar groeiende complexiteit uiteindelijk de strijd tegen een simpele core zoals die van de Itanium gaat verliezen. De hele CISC-RISC-conversie en ingewikkelde OOOE-mechanismes zijn voor IA-64 namelijk helemaal niet nodig, waardoor het in theorie allemaal zuiniger en sneller zou moeten kunnen. Helaas is de Itanium tot nu toe altijd één of twee transistorgeneraties achter blijven lopen op x86, en krijgt het bij Intel gewoon een minder grof ontwikkelbudget. Dat het zelfs in die benadeelde positie af en toe dikke winsten neerzet tegenover x86-chips is een teken dat er veel potentieel is, maar om echt een vervanger te worden is dat niet genoeg.

[Verwijderd]

Vandaar dat ik het AMD ten zeerste kwalijk neem dat zij de AMD64 hebben gebracht.
Dit kost ons zeker nog 10 jaar R&D in de bodemloze put die x86 heet.

Intel was al compleet ingesteld op de overgang naar de Itanium... De Pentium 4 zou de laatste x86 zijn, en dan over naar de Itanium. Microsoft was ook al helemaal voorbereid, met Windows XP en Server voor Itanium, en het .NET-framework om ervoor te zorgen dat nieuw ontwikkelde software zonder problemen op zowel x86 als Itanium te gebruiken was (waarbij Itanium waarschijnlijk een voordeel zou hebben van JIT-compilatie, vanwege de simpele architectuur, zoals we dat ook zien bij bv PowerPC en Alpha).

Maar door het succes van de Athlon64 zal de Itanium het waarschijnlijk nooit halen... en intussen heeft Intel de volgende x86 alweer klaar.
We kunnen alleen hopen dat de Core 2 dermate goed is dat AMD failliet gaat, waardoor Intel alsnog de x86 vaarwel kan zeggen, en de Itanium kan brengen.
Of een nieuwe architectuur, want tegen die tijd zal Itanium ook niet optimaal meer zijn... De beste architectuur is altijd zeer tijdgebonden, en hangt nauw samen met de beschikbare productiemethoden en andere technologie zoals bv geheugen.

Wanneer we eenmaal losgeweekt zijn van de x86-architectuur, en liefst op een platform-onafhankelijk systeem werken als .NET, dan zal het ook veel makkelijker worden om nieuwe architecturen in de praktijk te brengen. Backward-compatibility wordt dan impliciet verzorgd door de JIT-compiler.
Dat zou wel eens een revolutie kunnen zijn in computerland. De ontwerpers krijgen dan veel meer vrijheid om nieuwe technologien te implementeren, in plaats van dat ze zoals nu alles moeten zien in te passen in de x86-architectuur.

[needless to say]

Verder vind ik systeembeheerders die zich zo slecht op vernieuwingen voorbereiden eigenlijk gewoon incompetent, en hebben het aan zichzelf te wijten dat ze de overstap niet kunnen maken.

Het is maar hoe je het bekijkt. Vooral ivm kritische applicaties: Ofwel blijf je software gebruiken die jaren aan een stuk gedebugged en geoptimaliseerd is, en die nog maar weinig geheimen kent voor de systeembeheerder, ofwel kom je af met een totaal nieuw product dat heel dat debug- en optimalisaite-proces nog moet doorlopen. Een proces dat gemakkelijk 10 jaar kan innemen om weer op hetzelfde niveau te komen.

Als er geen noodzaak is om over te stappen, waarom dan overstappen op een product waarvan je weet dat het nog lang gaat duren eer het hetzelfde niveau haalt?

In het begin heb je vooral mensen die naar 64-bit MOETEN overstappen.

Ach ja, dit is toch ook redelijk rooskleurig. Kijk, Itanium wordt momenteel enkel in high-end servers gebruikt. In high-end servers kun je je perfect veroorloven om al je software volledig custom te schrijven (dat gebeurt ook in 99% van de gevallen). In lagere segmenten breekt de itanium gewoon niet door wegens te hoge softwarekosten. Programmeurs zijn gewoon om x86-code te schrijven en optimaliseren. Een x86 32-bit programma porten naar een programma die de AMD64-instructies gebruikt is een pak gemakkelijker en minder kostelijk dan te porten naar een volledig verschillende architectuur. En daar zit het grote probleem.
Softwarehuizen kunnen de vraag naar 64-bits applicaties niet volgen + moeten producten afleveren waarvan ze op voorhand weten dat die waarschijnlijk meer bugged gaat zijn. Veel kans dat ze een hogere kostprijs doorrekenen naar de klant. Bij grote problemen in de nieuwe software riskeer je ook nog eens dat je een hele userbase verliest omdat je imago geschaad is. En we spreken dan nog niet eens over servers die gecombineerd 32-bit en 64-bit services moeten draaien, wat een sterk argument is tijdens een overgangsperiode tussen 32- en 64-bit.

Dat lijkt me niet. De AMD64 is slechts een kleine aanpassing aan de Athlon-architectuur. Een Itanium-kloon ontwerpen zou veel meer tijd kosten en veel duurder zijn dan AMD64. AMD heeft wel x86-expertise en x86-ontwerpen om op voort te bouwen, maar van Itanium weten ze nog niks.
Ze konden dus eigenlijk niets anders dan AMD64.

Tja, dat is inderdaad waar, AMD64 is veel makkelijker te ontwikkelen dan een itanium-kloon. Als je dan nog even al mijn argumenten samenneemt, dan snap je hun keus toch wel hé?

Kijk, in een ideale wereld zou ik je gelijk willen geven. De techniek moet vooruit en we moeten af van de oude x86 CISC architectuur. Het is echter gewoon geen realistische visie. Je kunt niet van je klanten eisen dat ze al hun softwarepakketten opnieuw moeten kopen/ontwikkelen met het risico dat het slechter werkt + dat hun softwarepakketten mogelijks duurder worden + de opleiding van een heleboel programmeurs en gebruikers. We leven in een markteconomie. Het heeft zowel voor- als nadelen. Er wordt zowel innovatie in de hand gewerkt (om beter te presteren dan je concurrent) als tegengewerkt (je kan je wil niet opdringen op je klant).

We zullen nog even opgescheept blijven met x86 totdat er een nieuwe processor à la itanium uitkomt die x86-code sneller kan emuleren dan x86-processoren native kunnen uitvoeren.

[Verwijderd]

Je maakt het jezelf hier te gemakkelijk, ten eerste ga je er vanuit (of is dat ook zo?), dat bytecode zo is opgezet dat het alle benodigde informatie voor het efficient omzetten naar native Itanium code bevat (zeg maar de interne state van een compiler).

Dat heb je goed gezien. Een systeem als Java en .NET is eigenlijk een conventionele compiler, die in twee stukken is geknipt op het punt waar de interne syntaxtree geoptimaliseerd is, en vertaald gaat worden naar native code.
Je hebt dus een compleet overzicht van de gebruikte variabelen, functies, branches, loops etc.
En je kunt het ook redelijk makkelijk uitbreiden met extra hints in de bytecode, die door oudere systemen genegeerd kan worden, zodat je nieuwere systemen effcienter kunt maken zonder compatibiliteit op te geven.
In feite is het hetzelfde als wat men nu al doet bij x86-code in hardware. Alleen is software flexibeler. En het voordeel is dat de complexiteit niet meer in hardware zit, zodat je een veel groter transistorbudget overhoudt om de hardware sneller en efficienter te maken.

Maar wel op het nivo van de instructies, de bundeling ervan en de afhankelijkheden tussen bundels. Allen niet op het nivo van de bytecode dus, waardoor de optimalisaties op runtime zullen moeten gebeuren. Tenzij je in iedere instructie bundel maar 1 of 2 effectieve instructies plaatst en de itanium core degradeerd to een implentatie ala pentium 60 met meer MHz en cache.

Maar dit is redelijk triviaal. Natuurlijk is Intel niet dom, en heeft men de bundles zodanig ontworpen dat ze simpel en efficient samengesteld kunnen worden. Ik beweer dat deze bundles makkelijker te vullen zijn dan dat je x86-code kunt genereren met een vergelijkbare efficientie.

Het goed bundelen van de instructies en bepalen of 'likely taken' en 'likely not taken' branches beide uitgevoerd moeten worden en het toepassen van predication, software register renaming en dat soort zaken zijn verre van eenvoudig.

Bundelen en register renaming zijn triviaal.
Branch predication hoeft niet at runtime gedaan te worden. Dat is een statisch gebeuren, onafhankelijk van de native code. Ook JIT-code kun je natuurlijk tijdens het ontwikkelen al profilen. Daar verandert at runtime niets meer aan.

Als je daarbij in ogenschouw neemt dat een JIT niet meteen in de eerste run zo ver optimaliseerd als een reguliere compiler zou doen, dan zie je dat het probleem alleen maar groter wordt i.p.v. kleiner dus....niet vrij triviaal dus om het goed te doen.

Dit is redeneren vanuit de x86-wereld. Bij x86 is het inderdaad bijzonder lastig om efficiente code te krijgen, en daarom wil je dat beperken tot de bottlenecks.
Bij een moderne orthogonale architectuur valt de code bijna als vanzelf op z'n plaats, omdat de instructieset als zodanig ontworpen is. In dat geval is optimaliseren op instructieniveau WEL triviaal. En dat is dus precies het punt dat ik probeer te maken.

Voor x86 is het een stuk eenvoudiger wat betreft instructie selectie, register gebruik en optimalisaties (minder noodzakelijk door aggressive OOOE). Het enige waar ik je gelijk in geef is dat de x86 instructies complexer gecodeerd zijn. Niet iets waar volgens mij de echte bottleneck zit bij JIT code generatie (tenzij je verre van optimale code genereerd).

Dat is de omgekeerde wereld. Juist omdat x86 zo complex is, is de behoefte aan OOO zo groot. OOO is nu op een punt dat de compiler niet zo heel hard meer hoeft te werken (mits deze zich aan een beperkte subset van instructies houdt). Ook mede doordat geheugen en cache dermate ver achterop zijn geraakt dat de CPU sowieso minder efficient hoeft te zijn, en kan zijn, en er dus meer ruimte is voor OOO en dergelijke.
Toen de Itanium ontwikkeld werd, was men nog niet op dat punt aanbeland.
Maar je zit bij x86 nog steeds met bepaalde rare problemen met codegeneratie die je bij andere architecturen niet hebt. Zoals het tekort aan registers, waardoor je veel registers moet spillen op de stack... en de vreemde instructieencoding mede door variabele instructielengte, waardoor je dus per instructie redelijk veel tijd kwijt bent om deze op te bouwen.
Dan zijn er ook nog rare dingen zoals shifts of rotates met een variabele, die alleen in het cl-register kan. Dus moet je daarvoor altijd code schrijven die op dat moment het cl-register met de juiste variabele geladen heeft... etc etc.
Conclusie: x86 is lastiger.
En als je een betere processor had, had je heel die OOO-logica niet nodig, of die enorme instructiedecoders... Denk je eens in hoeveel effcienter een x86 al kan worden als je de code gewoon als micro-ops aan de pipeline kunt aanleveren, ipv verpakt in rare x86-instructies met virtuele registers die weer gerenamed moeten worden naar de registers in de hardware etc.

En ja, er zijn rare regeltjes, maar voor zover ik ze nog ken uit mijn 286 assembler tijdperk bestaan deze voornamelijk op het nivo van de instructies zelf en zijn daardoor minder van belang.

Ik snap deze conclusie niet. De JIT-compiler doet JUIST alleen dingen op het niveau van de instructies zelf. Het compilen en optimaliseren op het hogere niveau is immers al gedaan voordat de bytecode gegenereerd werd.

Abstractie is vaak handig...maar abstractie om de abstractie is dat niet. Wat maakt de bytecode van (.NET / java, etc) zoveel beter dan welke native ISA dan ook, en is dat dan voor alle type software zo?

Zoals ik al zei, door de complexiteit van hardware naar software te verplaatsen, kun je veel efficientere hardware ontwerpen.
We zijn toch al lang op het punt aangekomen dat we de hardware eigenlijk optimaliseren aan de hand van onze compilers, en niet zozeer andersom.
Bijkomende voordelen zijn oa dat je platform-onafhankelijke code kunt maken zonder dat daarvoor de sourcecode verspreid hoeft te worden, en op iedere machine door de gebruiker gecompileerd moet worden... En dat je bepaalde optimalisaties kunt uitvoeren die met een statische compiler onmogelijk zijn. Denk bv aan het inlinen van DLL-functies, of het uitrollen van loops met constanten die pas tijdens runtime bekend zijn.

En als er morgen een radicaale betere architectuur gevonden wordt, is de vertaalslag van bytecode naar die nu nog onbekende architectuur dan niet juist de killer?

Dat is moeilijk te zeggen zonder te weten wat die radicale beter architectuur is. Het is echter wel aannemelijk dat we onze huidige programmeertalen aan willen houden, dus dat we in ieder geval op een dergelijke nieuwe architectuur ook C++, C#, Delphi, VB en vergelijkbare talen willen gebruiken.
Aangezien de bytecode in feite een afspiegeling is van deze talen en hun mogelijkheden (een abstractie lager, halverwege programmeertalen en native machines), is het waarschijnlijk dat deze bytecode bruikbaar blijft zolang we op deze manier willen blijven programmeren.
Bytecode is immers een representatie van deze sourcecode in een voor de machine handig te bewerken formaat met de variabelen en constanten alvast in tabellen opgeslagen, en operaties gecodeerd in een enkele byte, zodat simpele lookuptables en switch-statements genoeg zijn om vertalingen uit te voeren. De overhead hiervan is verwaarloosbaar.

Kijk, alles wat in software gedaan kan worden kan in princiepe ook in hardware en dan sneller.

Dat klopt, en dat is ook het punt... Zodra je los komt van x86, en een abstracte bytecode gaat gebruiken, kun je hardware gaan ontwikkelen die deze bytecode zo efficient mogelijk uitvoert. Je krijgt dan hardware die veel beter aansluit op de populaire programmeertalen dan onze huidige x86-hardware, die ontworpen is in de tijd dat programmeertalen nog te veel overhead hadden, en men met de hand code schreef. Dat is een heel ander type code, en vereist een heel ander type processor. Vandaar dus dat ik de x86 zo'n enorme handrem op de ontwikkelingen vind. We zitten allang in een ander tijdperk qua software-ontwikkeling, maar we hebben de hardware nog steeds niet.

Wat bepaald of een architectuur interesant is voor JIT? Is dat iets persoonlijks?

Denk eens logisch na... Wat moet een JIT-compiler doen?
Die moet bytecode omzetten naar machinecode, en liefst code die zo efficient mogelijk is.
Wat wil je dan dus van je architectuur? Daar wil je dat ten eerste de instructieset logisch in elkaar zit, zodat je makkelijk de code kunt uitschrijven.
Ten tweede wil je dat de regels voor efficiente code zo simpel mogelijk zijn.
x86 heeft heel veel uitzonderingen, waar een compiler weinig mee kan, zeker als deze in runtime loopt, zoals een JIT-compiler.
Moderne architecturen zitten veel 'systematischer' in elkaar, waardoor de code dus veel makkelijker algoritmisch te schrijven is, en code eigenlijk bijna als vanzelf efficient is.
Neem een P4 als voorbeeld... die heeft een shift-unit die early-out heeft... je hebt 2 tot 4 clks nodig om een bitshift uit te voeren...
In sommige gevallen zijn een paar adds dus sneller dan een shift-left... in andere gevallen weer niet. De compiler moet dus analyseren met welk geval hij te maken heeft, en dan de beste optie kiezen.
Als je gewoon een processor hebt die altijd snel shift, dan hoeft de compiler zich daar niet druk om te maken, en bespaar je dus op iedere instructie een hoop tijd, en je loopt niet het risico dat je de verkeerde keuze maakt, en inefficiente code schrijft. Je KUNT namelijk geen inefficiente keuze maken.

Overigens is dit natuurlijk niet specifiek voor JIT, ook statische compilers hebben hier voordelen van. Dat was al de insteek sinds de eerste RISC-processors.

Sorry hoor, als ik heden ten dagen na al die jaren sun's java ondanks de snellere hardware nog steeds als traag ervaar, en regelmatig software ziet gebaseerd op .NET met dezelfde problemen dan moet je niet op de proppen komen met het argument dat ik niet zie wat jij in je lab zie.

Voor een deel is dat te wijten aan wat ik het 'VB-syndroom' noem: veel van die code wordt geschreven door beginnende/onervaren programmeurs, omdat de taal een lage leercurve heeft.
Dit kun je ook maken met Java: http://www.pouet.net/prod.php?which=10808

Als je ziet hoe soepel dat loopt, hoe compact de code eigenlijk is, en dan bedenkt dat dit GEEN hardware-acceleratie is, maar allemaal puur software-rendering, inclusief texture filtering en post-processing etc... ja... vind je Java dan echt heel traag?

[Verwijderd]

Veel agressiever? Waarom vind je dat?
De eerste generaties van PPC hadden eigenlijk helemaal geen OOO, omdat ze dat simpelweg niet nodig hadden.
Verder is de P4 veruit de meest agressieve OOO processor die ik ken

De pentium 4 kan 6 micro-op starten en er 3 per clock afronden. En een micro-op is niet evenveel als een x86 instructie, maar eerder te vergelijken met een RISK instructie. De pentium 4 is wel sterk in het hebben van een groot out-of-order window (126 instructies geloof ik, iets meer in latere modellen). De pentium 4 heeft dit samen met hyperthreading nodig om bezig te blijven, aangezien de pipeline zo idioot lang was. Alle prestaties moeten uiteindelijk door ruwe Gigahertzen gehaald worden.

De eerste generatie PPC had inderdaad geen OoOE, maar dit in in latere implementaties wel degelijk gebruikt. De pentium uit die tijd had dat ook niet! De G5 verwerkt 8 instructies per clock en kan er 5 per clock afronden. De Power5+ doet geloof ik nog net iets meer (details hiervoor zijn lastig te vinden) en heeft bovendien een out-of-order front-end (instruction fetch/decode).

Mijn punt is dat OoOE voor RISK cores (dus na instructie decodering), voor iedere 'general pupose' ISA een flinke verbetering is omdat daarmee automatisch meer aanwezige ILP benut kan worden. Iets waar een JIT die nooit aan 'echt optimale' instructie scheduling kan doen veel profijt heeft. Dit hele gebeuren staat natuurlijk los van TLP (iets waar IBM veel mee doet), want dat is weer een laag daarboven.

En wat mij betreft zijn er nog zan andere truuken die gedaan kunnen worden om x86 JIT vrienelijker te maken. Meest eenvoudige is natuurlijk een echt simple load/store gebaseerde instructieset ondersteunen die 1 op 1 te mappen is naar de RISC pipelines. Hoef je alleen maar een decoder context switch te maken, en klaar ben je!

Niet dat Intel of AMD dat zomaar gaan doen hoor, het is niet zo in hun belang eigenlijk. Meerdere instructiesets ondersteunen is niet zo gek als het lijkt, de onbetwiste koning op dat gebied is ARM voor zover ik weet. Er zijn er ongetwijfeld meer!

Verder denk in niet dat je JIT in de praktijk geheel los kan beschouwen van GC en de bijbehorende memory overhead (in de implementaties die ik ken). Met geheugen toegang als echte bottleneck, is dat niet iets om te negeren lijkt me.

Anyway.....we dwalen af! Reverse hyperthreading moet op het nivo van loops goed te realiseren zijn, de bijkomende overhead kan ik moeilijk inschatten, maar als AMD zecht dat ze het hebben...dan geloof ik dat zeker. Intel heeft ons tenslotte ook verrast met de Read Around Write, op een punt dat iedereen riep dat we niet meer verder konden in de race om meer effectieve ILP. Dit gaat nog wel even door .

[needless to say]

lol, het is heus AMD niet die ervoor gezorgd heeft dat itanium niet doorkomt.

De redenen die er wél voor gezorgd hebben zijn:
(*)te trage emulatie van x86 op de itanium
(*)een te grote software-bibiliotheek die dag in dag uit gebruikt wordt en die enkel op x86-processoren draait .

Vele bedrijven werken met er oude programma's die al 10-20 jaar aan een stuk gedebugged en geoptimaliseerd zijn. Zij gaane cht niet gaan investeren in een nieuw programma dat een hoop meer bugs gaat bevatten en waar ze een hoop mensen moeten voor opleiden, gewoon omdat de industrie besloten heeft van van x86 af te stappen.

Itanium x86 laten vervangen is al een tijdje van de baan. En als dit écht gepushed werd, dan zou AMD heus wel met een Itanium-kloon op de proppen komen.

Wat heeft 64-bit trouwens met itanium te maken? 64 bit is heus niet de reden waarom men op itanium zou moeten overstappen. Het veel betere ontwerp + groter potentiëel van de architectuur spreekt in zijn voordeel.

Trouens, AMD is erg slim geweest bij hun 64-bits implementatie. Dankzij hun hebben we nu 2 keer zoveel registers als voorheen. Ik vraag me af of intel hetzelfde gedaan zou hebben.

[needless to say]

Aangezien de x86 dan 'vast zou staan' op de snelste x86 ooit gemaakt, en de Itanium iedere paar maanden snellere steppings en revisies zou krijgen, zou de Itanium de x86 binnen de kortste keren inhalen, met emulatie en al.

mja, zeg nu zelf....

Ten tijde dat AMD AMD64 uitbracht waren we reeds aan 3GHz. Welke systeembeheerder gaat dan nog investeren in hardware die zijn software aan halve snelheid draait?

Om het dan nog even te hebben over die 10-20 jaar oude geoptimaliseerde en gedebugged software. Sure, die waren eerst geoptimaliseerd voor tragere hardware. Ondertussen staat die software mooi op nieuwere en snellere servers en werkt die software met een pak grotere databases dan 10-20 jaar geleden + werken een hoop meer requests af per seconde dan 10-20 jaar geleden. Probeer jij dan even die systeembeheerder te overtuigen van te investeren in nieuwe hardware die zijn code trager uitvoert. Ofwek vraag je hem mooi om zijn software opnieuw te schrijven (verschirkkellijk duur) die dan én meer bugs gaat bevatten én waarvoor weer een heleboel mensen voor opgeleid gaan moeten worden om dat te gebruiken?

Beste voorbeeld zijn banken. Vraag maar eens wanneer de software die zij gebruiken voor het beheer van hun rekeningen geschreven is.

Je moet niet afkomen met een nieuw product dat binnen 10 jaar wel sneller zal zijn om dezelfde code uit te voeren. Dat boeit niemand. Het moet nú sneller gaan. In de itanium-sevrer die nu gekocht wordt zullen de processoren heus niet bij elke revisie vervangen worden.

Je zou nog kunnen zeggen: verkoop die mensen dan nog x86-processoren. Maar zou dit betekenen dat zij jaren zullen moeten wachten op snellere processoren omdat de ontwikkeling van x86 stopgezet wordt? Wat moet je dan doen om je servers/workstations mee te laten schalen?

Als gevolg van het bovengenoemde zou die software-bibliotheek dus redelijk snel vervangen zijn, in alle gevallen waar de 'trage' x86-emulatie een probleem is.

Een software-bibilotheek kun je niet snel vervangen. Zeker niet bij kritieke applicaties die reeds 10-20 jaar gedebugged en geoptimaliseerd zijn. Dat is veel te kostelijk om dat te doen wanneer je even je serverpark moet uitbreiden om mee te schalen bij een verhoogd gebruik.

Dat zou toch geen probleem zijn? Dan heb je nog steeds die nieuwe, betere architectuur. Of AMD of Intel die dan maakt, is niet zo heel interessant.

Uiteraard. Dat bedoelde ik dan ook niet. Ik bedoel: had Itanium echt een kans gehad om x86 te vervangen, dan had AMD AMD64 nooit ontwikkeld en direct begonnen met de ontwikkeling van een itanium-kloon. Uiteraard boeit het niet wie de itanium bouwt. De discussie gaat over de invoering van AMD64.

Zonder AMD64 zou Itanium dus de enige 64-bit oplossing zijn voor de Windows-markt.

Uiteraard. En tegelijkertijd 32-bits-code te traag uitvoeren, wat geen issue is bij AMD64.

Vind je dat slim? Meer registers had ik ook nog wel kunnen bedenken. Verder vind ik het nog steeds bijzonder weinig. M'n 68000 had ook al 16 registers, en dat was in 1979 (ja, het is een generatiegenoot van de 8086).
Zou Intel hetzelfde gedaan hebben? Nee, Intel heeft de Itanium ontwikkeld. Die heeft VEEL meer registers, en daarnaast ook een compleet andere architectuur met VEEL meer slimmigheden dan alleen 16 registertjes in een architectuur uit 1978 proppen.

mja, Itanium is uiteraard een geheel andere architectuur als x86. AMD heeft zowat al de registers vergroot en verdubbeld: de gewone registers, de FP-registers, de SSE-registers... Als we kijken naar het verleden, dan heeft intel nog nooit zoveel registers toebevoegd aan het x86-ontwerp bij het uitbreiden van de instructieset. Bij de overstap van 16-bits naar 32-bits zijnd e registers gewoon vergroot. Bij MMX werden de FP-registers voor MMX-operaties gebruikt. Bij SSE zijn er gewoon 8 registers bijgekomen.

Daarom noem ik het slim. Juist 1 van de bottlenecks van x86 is het kleine aantal registers.

[Verwijderd]

Ten tijde dat AMD AMD64 uitbracht waren we reeds aan 3GHz. Welke systeembeheerder gaat dan nog investeren in hardware die zijn software aan halve snelheid draait?

Daar gaat het niet om. Je HOEFT de Itanium niet te kopen, als je al een x86 hebt.
Verder had je inderdaad een 3 GHz processor... maar die was net nieuw. Je gaat toch niet een 3 GHz processor kopen, en de volgende dag upgraden naar een Itanium?
De mensen die voor de keuze x86-Itanium komen te staan, zijn mensen die hun oude hardware upgraden, en dat is vaak geen 3 GHz spul, maar eerder Xeon 1.5 GHz of trager. Het probleem is in de praktijk dus niet zo groot als jij doet voorkomen.

In het begin heb je vooral mensen die naar 64-bit MOETEN overstappen. Die gaan dus Itanium gebruiken. De rest kan gewoon x86 uitmelken totdat Itanium en het software-aanbod op een punt zijn dat de investering WEL loont. Dat moment zal vroeger of later toch wel komen, omdat x86 niet meer sneller wordt... en de machines ook niet het eeuwige leven hebben.
Het is niet voor iedereen op ieder moment ideaal, maar daar gaat het niet om. De technologie moet voort. Je moet het grotere geheel bekijken. Verder vind ik systeembeheerders die zich zo slecht op vernieuwingen voorbereiden eigenlijk gewoon incompetent, en hebben het aan zichzelf te wijten dat ze de overstap niet kunnen maken.
Dat zie je in de software-wereld ook... sommigen hebben de grootst mogelijke moeite om bv van DOS naar Windows of UNIX over te stappen. Zijn veel te lang met oude software doorgegaan, terwijl er al mogelijkheden genoeg waren om over te stappen... Zo verf je jezelf in een hoekje.

Uiteraard. Dat bedoelde ik dan ook niet. Ik bedoel: had Itanium echt een kans gehad om x86 te vervangen, dan had AMD AMD64 nooit ontwikkeld en direct begonnen met de ontwikkeling van een itanium-kloon.

Dat lijkt me niet. De AMD64 is slechts een kleine aanpassing aan de Athlon-architectuur. Een Itanium-kloon ontwerpen zou veel meer tijd kosten en veel duurder zijn dan AMD64. AMD heeft wel x86-expertise en x86-ontwerpen om op voort te bouwen, maar van Itanium weten ze nog niks.
Ze konden dus eigenlijk niets anders dan AMD64.

Uiteraard. En tegelijkertijd 32-bits-code te traag uitvoeren, wat geen issue is bij AMD64.

Het is maar hoe je het bekijkt. Blijkbaar kijk jij alleen achterom, en zit je alleen in over je 32-bit code.
Mij kan die 32-bit code niets schelen, want daar wil ik toch zo snel mogelijk vanaf. Ik wil vooruit, en ik maak me vooral druk over de snelheid van de 64-bit code. Voor mij is het nooit snel genoeg, dus hoe eerder de prestaties omhoog gaan, hoe beter. En met de AMD64 kun je weliswaar je oude code redelijk snel draaien, maar ik zie weinig verbetering voor nieuwe code, en dat moet ik dus niet hebben.

Als we kijken naar het verleden, dan heeft intel nog nooit zoveel registers toebevoegd aan het x86-ontwerp bij het uitbreiden van de instructieset. Bij de overstap van 16-bits naar 32-bits zijnd e registers gewoon vergroot. Bij MMX werden de FP-registers voor MMX-operaties gebruikt. Bij SSE zijn er gewoon 8 registers bijgekomen.

Dat is nogal een kromme vergelijking.
Intel heeft maar 1 keer de instructieset opgewaardeerd voor een grotere woordbreedte, namelijk met de 386.
Toen hebben ze weliswaar maar weinig registers toegevoegd, maar dat speelde niet zozeer. Wat ze wel hadden gedaan, was de registers generiek bruikbaar maken, waardoor je in de praktijk dus wel veel meer registers tot je beschikking had, omdat je nu met alle registers zowel kon adresseren als arithmetische operaties kon uitvoeren. Dat vind ik een minstens zo belangrijke vooruitgang als de extra registers van de AMD64.
Ze hebben trouwens onder de motorkap wel steeds registers toegevoegd, die je weliswaar niet ziet in de architectuur, maar die wel met register renaming gebruikt worden.

De andere dingen die je noemt, zijn uitbreidingen op de instructieset, waarbij de rest backwards-compatible moest zijn. AMD64 is dat dus niet, de processor draait in een andere modus, net als bij de 386. Niet te vergelijken.

[Verwijderd]

Het is maar hoe je het bekijkt. Vooral ivm kritische applicaties: Ofwel blijf je software gebruiken die jaren aan een stuk gedebugged en geoptimaliseerd is, en die nog maar weinig geheimen kent voor de systeembeheerder, ofwel kom je af met een totaal nieuw product dat heel dat debug- en optimalisaite-proces nog moet doorlopen. Een proces dat gemakkelijk 10 jaar kan innemen om weer op hetzelfde niveau te komen

Veel te naief allemaal. Als je 10 jaar met die software draait, ga je er blijkbaar vanuit dat je in de tussentijd wel de hardware vervangt (zo niet, dan ga je dus ook geen Itanium nemen). Dat gaat ook in het geval van x86 niet altijd zonder problemen.
Verder is het ontwikkelen, debuggen en optimaliseren van software maar in beperkte mate afhankelijk van de hardware waarop deze draait. Als je overstapt op een andere architectuur, zijn er genoeg dingen die niet direct van x86 afhankelijk zijn, en die je dus gewoon klakkeloos kunt overnemen. Je hoeft niet het wiel opnieuw uit te vinden.

Als er geen noodzaak is om over te stappen, waarom dan overstappen op een product waarvan je weet dat het nog lang gaat duren eer het hetzelfde niveau haalt?

Dat is nou precies mijn punt. Als x86 stil blijft staan, gaat die noodzaak er vroeger of later komen, dus krijg je een heel ander verhaal. Zolang die noodzaak er niet is, kun je met je oude setup blijven draaien, natuurlijk. Als die noodzaak er niet is, zou het ook niet slim zijn om in nieuwe x86-hardware te investeren.

Programmeurs zijn gewoon om x86-code te schrijven en optimaliseren. Een x86 32-bit programma porten naar een programma die de AMD64-instructies gebruikt is een pak gemakkelijker en minder kostelijk dan te porten naar een volledig verschillende architectuur. En daar zit het grote probleem.

Je bent zeker geen developer?
Er wordt in de meeste gevallen weinig of geen architectuur-specifieke code geschreven, maar gewoon C/C++, Delphi, VB, of wat dan ook. DE meeste programmeurs KUNNEN niet eens asm schrijven, en kunnen dus geen x86-specifieke instructies gebruiken.
In de meeste gevallen is het gewoon een kwestie van opnieuw compilen met een 64-bit compiler (ervanuitgaande dat je geen 64-bit problemen in je code hebt, maar die heb je met AMD64 evengoed, dus kunnen we die buiten beschouwing laten).
Zeker in het geval van Windows/Visual Studio is het maken van x86, AMD64 en Itanium-code gewoon precies hetzelfde. Je kiest alleen je target platform, en compilen maar.
Ik heb mijn code al met de eerste Visual Studio.NET (was dat in 2002?) geprepareerd voor 64-bit (er zat namelijk detectie in voor 64-bit problemen), en toen ik een tijdje geleden voor het eerst een Windows XP64-machine tot m'n beschikking had, had ik dan ook m'n code binnen 5 minuten aan de praat. Op Itanium zal het ook meteen werken.
Grappig genoeg kun je in 64-bit met Visual Studio geen inline-asm gebruiken, dus bestaat het probleem van architectuur-specifieke code daar niet.

En we spreken dan nog niet eens over servers die gecombineerd 32-bit en 64-bit services moeten draaien, wat een sterk argument is tijdens een overgangsperiode tussen 32- en 64-bit.

Wat voor argument is dat dan? Windows op Itanium werkt ongeveer hetzelfde als op AMD64, met Windows-on-Windows, zodat je gewoon x86 en native code naast elkaar kunt gebruiken.

Tja, dat is inderdaad waar, AMD64 is veel makkelijker te ontwikkelen dan een itanium-kloon. Als je dan nog even al mijn argumenten samenneemt, dan snap je hun keus toch wel hé?

Natuurlijk snap ik hun keus, dat moge duidelijk zijn. Maar het gaat mij om de gevolgen.

Kijk, in een ideale wereld zou ik je gelijk willen geven. De techniek moet vooruit en we moeten af van de oude x86 CISC architectuur. Het is echter gewoon geen realistische visie.

We waren er anders heel dichtbij. Zonder de AMD64 had het 100% zeker gebeurd.

Je kunt niet van je klanten eisen dat ze al hun softwarepakketten opnieuw moeten kopen/ontwikkelen met het risico dat het slechter werkt + dat hun softwarepakketten mogelijks duurder worden + de opleiding van een heleboel programmeurs en gebruikers.

Vind ik allemaal zwaar overtrokken onzin. Apple is al voor de tweede maal overgestapt op een andere architectuur, en dat ging allemaal redelijk soepeltjes, en Apple is nu populairder dan ooit, mede doordat die nieuwe architectuur een aantal voordelen biedt voor de gebruiker. Ik zou dus eerder het omgekeerde beweren: de overgang naar een andere architectuur is de moeite meer dan waard.

We zullen nog even opgescheept blijven met x86 totdat er een nieuwe processor à la itanium uitkomt die x86-code sneller kan emuleren dan x86-processoren native kunnen uitvoeren.

Die gaat er dus nooit komen, want die is er al.
De x86 is al sinds de Pentium Pro geen native processor meer, maar een 'emulator'. Probleem is dat dit zo complex is, dat je geen ruimte meer hebt om er ook nog een nieuwe architectuur bij te bouwen.
Het zal in software moeten gebeuren, maar die stap is op het moment te groot. Software zal uiteindelijk sneller zijn dan hardware-emulatie, daar ben ik van overtuigd... Maar daarvoor moeten zowel de software als de hardware gewoon aardig doorontwikkeld zijn... de eerste generatie kan niet meteen die stap maken.
Zolang x86 niet stopt met ontwikkelen, kun je niet genoeg R&D bij elkaar krijgen om iets nieuws te proberen...

[Verwijderd]

Vandaar dat ik het AMD ten zeerste kwalijk neem dat zij de AMD64 hebben gebracht.

De Pentium 4 zou de laatste x86 zijn, en dan over naar de Itanium. Microsoft was ook al helemaal voorbereid, met Windows XP en Server voor Itanium, en het .NET-framework om ervoor te zorgen dat nieuw ontwikkelde software zonder problemen op zowel x86 als Itanium te gebruiken was (waarbij Itanium waarschijnlijk een voordeel zou hebben van JIT-compilatie, vanwege de simpele architectuur, zoals we dat ook zien bij bv PowerPC en Alpha).

Wanneer we eenmaal losgeweekt zijn van de x86-architectuur, en liefst op een platform-onafhankelijk systeem werken als .NET, dan zal het ook veel makkelijker worden om nieuwe architecturen in de praktijk te brengen. Backward-compatibility wordt dan impliciet verzorgd door de JIT-compiler.
Dat zou wel eens een revolutie kunnen zijn in computerland.

Als je iets meer af had geweten van de Itanium architecuur het je nooit deze uitspraken gedaan. Deze architectuur moet het juist hebben van slimme compilers die daar de nodige tijd voor nemen. Niet iets dat je met JIT technieken wilt doen. Verder is de Itanium een totaal ander beest dan Power of Alpha.

Power en Alpha zijn wbt concept en architectuur veel meer gelijk aan x86. Het grote verschil zit hem in de load/store achitectuur in combinatie met veel registers en gemakkelijk te decoderen instructies van echte RISK (power/alpha) tegenover de complexere instructies met aanverwante overhead van x86. Als de instructies eenmaal gedecodeerd zijn, maakt het eigenlijk geen bal meer uit, x86 implementaties werken intern ook met een RISK core. Het is dus meer een vaste executie overhead, en deze zal procentueel met de tijd minder worden (geld niet voor de gebruikte die space).

OOOE (out of order executie) ondersteunen ze ook allemaal, de Itanium NIET! De Itanium daartegen werk op een geheel andere manier en is zeker niet 'simpel' te noemen. Het hele idee bij itanium is de parallelisatie te doen in de compilatie fase (JIT doet het per definitie in runtime), die vervolgens vooraf netjes geparaliseerde instructie 'pakketen' genereerd zonder interne afhankelijkheiden. Doormiddel van 'predication' worden vervolgens niet bruikbare resultaten weggooid.

De Itanium heeft hiervoor wel extra 'execution resources' nodig, maar die nemen gelukkig niet veel die space in beslag (minder als complexe decoders e.d.). Dus vanuit hardware oogpunt is Itanium zeker een stap voorwaarts, maar vanuit software oogpunt voor de meeste toepassingen niet. Itanium is 'te star', en de code is 'te complex' om goede compilers voor te ontwikkelen. Het gedrag van doorsnede code is overigens niet statisch genoeg, waardoor OOOE (vergevings gezinder), vaak beter presteerd.

Ik geloof niet dat .NET of andere JIT compilatie dit euvel voor EPIC op kan lossen. De gegenereerde code zou te traag zijn en bovendien heel geheugen intensief zijn (een euvel van JIT op zich). Als je dan ook nog eens bedenkt dat de Itanium implementaties ver achterlopen w.b.t. bandbreedte, dan kun je wel stellen dat EPIC + JIT de ultieme slechte mix is.

Ik denk dan ook dat je heel erg gemakkelijk de hype van onderzoekers overgenomen hebt. Er wordt all ruim 10 jaar van de daken geschreeuw dat JIT beter en niet langzamer is, en nog steeds zie ik dagelijks het tegendeel. Van mij hoeft het allemaal niet, en ik ben dan ook blij dat AMD de verbeteringen die gemakkelijk bij x86 gedaan konden worden, ook heeft gerealiseerd.

Wat betreft Reverse Hyperthreading, ik kan me er wel wat bij voorstellen, al verwacht ik voor de mogelijke implementatie die ik me kan voorstellen eigenlijk niet zo schokkend veel prestatie winst.

Wat ik zou verwachten is dat net als bij het cachen van pre-decode informatie, extra 'speculatieve' parallelisatie gevonden wordt bij een eerste run, en deze vervolgens wordt opgeslagen en toegepast bij latere runs. Op deze manier is de hoge latency tussen de twee cores niet zo relevant, en kan er een netto winst geboekt worden.

Neem bijvoorbeeld een 'if then else' situatie. De branch die normaal niet genomen wordt vanwege 'branch prediction', kan geheel gedelegeerd worden naar de 2e core, om zo het effect van 100% branch prediction te verkrijgen. Dit is een erg statisch voorbeeld, en er zijn andere/betere manieren om het zelfde effect be verkrijgen...maar als je toch de extra core hebt liggen die onderbenut is, dan is dit wel de meest eenvoudige en goedkope manier om het te verwezelijken.

Een meer dynamische variant zal code snipets zien te vinden die met redelijke waarschijnlijkheid uitgevoerd gaan worden, om basis can gecache informatie (uitbreiding op de brach predictor). Het kan zo eenvoudig zijn als het begin adres onthouden en het aantal instructies dat alvast 'speculatief' uitgevoerd kan worden doorgeven aan de 2e core.

Een ander en mogelijk beter idee is om iig van loops (die gemakkelijk herkenbaar zijn), de iteraties over de twee cores te verdelen. Iedere iteratie kan geheel los van de ander uitgevoerd worden, en zijn natuurlijk speculatief. Aangezien de meeste tijd toch in loops besteed wordt, kan dit in gevallen waarbij geen afhankelijk is tussen de iteraties (initialisatie code van procedures, etc), of waarbij deze via een predictor speculatief vastgesteld kan worden tijd besparen. Met name memcopy en memmove, memset, sse e.d. zijn op deze manier aan te pakken.

Het is natuurlijk speculatie van mij, maar als reverse hyperthreading realiteit is, dan denk ik dat het een mix van deze zaken betreft. Ik verwacht niet dat AMD er massa's cache geheugen aan heeft besteed, temeer omdat ze er de productie capaciteit niet voor hebben. Hardwarematige loop paralisatie met hergebruik van executie resources is wel het meest economishe wat ze kunnen doen.

[Verwijderd]

zonder amd waren we niet zo ver gekomen en had intel weinig of geen noodzaak gehad om te innoveren..

Zonder amd had intel geen reden gehad te innoveren en was er ws niet eens een itanium geweest..

Wat een pseudo-economische onzin van de koude grond.
AMD speelde geen rol van betekenis in de x86-wereld voor de Athlon. De Itanium was toen al lang in ontwikkeling. Ook was de Itanium gericht op de high-end/servermarkt, waar AMD helemaal nog geen speler was. Dat is pas de laatste jaren een beetje, met de Opteron. Maar de Itanium schaalt veel verder, en zit dus in een markt die tot nog toe onbereikbaar is voor AMD.
Als Itanium al een gevolg is van concurrentie, dan eerder van IBM met de POWER-architectuur, en HP met de PA-RISC en Alpha. Met AMD heeft het in ieder geval niks te maken.
Ik geloof sowieso niet zo heel erg in dat concurrentie-verhaal, niet op het gebied van hardware in ieder geval.
Je concurreert vooral ook met jezelf. Je moet ervoor zorgen dat mensen iedere paar jaar iets hebben om naar te upgraden, anders verkoop je niks, ook al is er geen concurrentie. De hardware slijt namelijk niet of nauwelijks, dus mensen zullen niet iedere paar jaar een nieuwe PC gaan kopen als ie niet sneller/beter is.

De markt kiest niet voor vooruitgang, de beste systemen worden vaak genegeerd ten voordele van datgene wat al bekend is (x86/win32 etc).

Daar heb je helemaal gelijk in, en daarom vond ik het idee van het MOETEN overstappen naar Itanium ook zo fijn. De markt is dom, en die moet je soms gewoon wat opdringen, anders kom je nooit verder.

[Verwijderd]

Als je iets meer van JIT-technieken af wist, had je nooit deze uitspraken gedaan.
Natuurlijk ben ik op de hoogte van de Itanium-architectuur en het feit dat veel door de compiler gedaan moet worden (ik neem jouw onderschatting in deze dan ook ten zeerste kwalijk).

Maar ik ben ook op de hoogte van JIT-technieken, en in tegenstelling tot jou besef ik heel goed dat een groot deel van de compilatie nog steeds statisch is, en dat alleen de bytecode at runtime naar native code omgezet moet worden. De meeste optimalisaties voor Itanium hebben te maken met scheduling en branches, en kunnen tijdens de statische compilatie opgelost worden. At runtime hoef je alleen de codebundles nog te vormen, en dat is eigenlijk redelijk triviaal.

Je maakt het jezelf hier te gemakkelijk, ten eerste ga je er vanuit (of is dat ook zo?), dat bytecode zo is opgezet dat het alle benodigde informatie voor het efficient omzetten naar native Itanium code bevat (zeg maar de interne state van een compiler). Je zegt dat de meeste optimalisaties met scheduling en branches te maken hebben....correct. Maar wel op het nivo van de instructies, de bundeling ervan en de afhankelijkheden tussen bundels. Allen niet op het nivo van de bytecode dus, waardoor de optimalisaties op runtime zullen moeten gebeuren. Tenzij je in iedere instructie bundel maar 1 of 2 effectieve instructies plaatst en de itanium core degradeerd to een implentatie ala pentium 60 met meer MHz en cache.

Het goed bundelen van de instructies en bepalen of 'likely taken' en 'likely not taken' branches beide uitgevoerd moeten worden en het toepassen van predication, software register renaming en dat soort zaken zijn verre van eenvoudig. Als je daarbij in ogenschouw neemt dat een JIT niet meteen in de eerste run zo ver optimaliseerd als een reguliere compiler zou doen, dan zie je dat het probleem alleen maar groter wordt i.p.v. kleiner dus....niet vrij triviaal dus om het goed te doen.

x86 is veel complexer, omdat de instructieset niet orthogonaal is, de instucties geen vaste lengte hebben, en vanwege de legacy er allerlei rare regeltjes en uitzonderingen zijn.

Voor x86 is het een stuk eenvoudiger wat betreft instructie selectie, register gebruik en optimalisaties (minder noodzakelijk door aggressive OOOE). Het enige waar ik je gelijk in geef is dat de x86 instructies complexer gecodeerd zijn. Niet iets waar volgens mij de echte bottleneck zit bij JIT code generatie (tenzij je verre van optimale code genereerd).

En ja, er zijn rare regeltjes, maar voor zover ik ze nog ken uit mijn 286 assembler tijdperk bestaan deze voornamelijk op het nivo van de instructies zelf en zijn daardoor minder van belang. Tegenwoordig ondersteunen alle x86 processoren conditionele moves en volgens mij zijn er met de overstap naar 64 bit nog enkele andere rariteiten verdwenen.

Maar als x86 er niet was, zou Intel al z'n energie op de Itanium storten, en had je deze problemen niet. Je moet het natuurlijk wel in de juiste context plaatsen.
Verder had je, als je mijn verhaal goed gevolgd had, gezien dat het mij vooral gaat om los te komen van x86 (en daarmee ISAs in het algemeen)... niet zozeer dat Itanium nou de ultieme processor is voor de toekomst. Het zou een mooi begin kunnen zijn, en daarna zouden JIT-compilers en hardware hand-in-hand doorontwikkeld kunnen worden.

Abstractie is vaak handig...maar abstractie om de abstractie is dat niet. Wat maakt de bytecode van (.NET / java, etc) zoveel beter dan welke native ISA dan ook, en is dat dan voor alle type software zo? En als er morgen een radicaale betere architectuur gevonden wordt, is de vertaalslag van bytecode naar die nu nog onbekende architectuur dan niet juist de killer?

Kijk, alles wat in software gedaan kan worden kan in princiepe ook in hardware en dan sneller. Er zijn meer van die 'leuke' theoretische op papier perfecte 'uitvindingen' zoals JIT geweest....die het naar jaren ploeteren toch nooit zijn geworden. En ja....zelfs met de resources die Intel heeft (denk eens aan die volledig OO Intel processor, transputers, transmeta, etc). Hele boekwerken zijn er over geschreven door 'experts' en onderzoekers.....waar zijn ze?

Nee, ik *ben* zo'n onderzoeker.
Dat jij dat niet dagelijks ziet, kan kloppen. Ten eerste zie jij niet wat wij zien, maar alleen de commerciele oplossingen, en ten tweede heb je waarschijnlijk alleen de x86-hardware gezien, die juist niet interessant is voor JIT-compilatie.

Wat bepaald of een architectuur interesant is voor JIT? Is dat iets persoonlijks? Is het niet jou werk als onderzoeker met iets op de proppen te komen dat anderen ook daadwerkelijk kunnen gebruiken, ipv te roepen dat we van x86 af moeten, zodat de bouw van je JIT compiler beter presteerd?

Sorry hoor, als ik heden ten dagen na al die jaren sun's java ondanks de snellere hardware nog steeds als traag ervaar, en regelmatig software ziet gebaseerd op .NET met dezelfde problemen dan moet je niet op de proppen komen met het argument dat ik niet zie wat jij in je lab zie. JIT is verdorrie geen hobbie van je waar de hele industrie zich maar op aan moet passen, omdat onderzoekers het een leuk tijdverdrijf vinden.

Er zijn heus goede toepassingen voor, maar native code de rug willen toekeren alleen om de theoretische heilige graal van JIT te kunnen halen is gewoon fout.

[Verwijderd]

Maar is jou ervaring dan dat JIT op powerPC zich heel anders gedraagd wat betreft performance? Dit is namelijk een nog veel agressieve OoOE implementatie en is toch een vrij recent opgeschoonde instructieset als ik IBM en Motorola tijdens de introductie van de PPC601 het mogen geloven.

Veel agressiever? Waarom vind je dat?
De eerste generaties van PPC hadden eigenlijk helemaal geen OOO, omdat ze dat simpelweg niet nodig hadden.
Verder is de P4 veruit de meest agressieve OOO-processor die ik ken.

Bij IBM lijkt men erg in OoOE te geloven, zetten er ook heel zwaar op in.

Vind je? Ze hebben juist de OOO uit de Cell gehaald, omdat ze er juist niet in geloven.

Terwijl er bij de PowerPC toch niet die nadelen zitten die jij voor de x86 als doorslaggevend ziet.

Volgens mij haal je twee dingen door elkaar.
De nadelen die ik van x86 noem, gaan puur over de ISA.
De PowerPC ISA heeft die nadelen niet.
Maar OOO heeft te maken met de *implementatie* van een ISA. Bij moderne CPUs die met een 'oude' ISA werken, ontkom je bijna niet aan OOO. Ook de PowerPC wordt intussen een dagje ouder.
OOO is ook vooral nodig voor backward compatibility. De verhouding tussen CPU, cache en geheugen verandert constant, dus is het bijna onmogelijk om software te optimaliseren voor meer dan 1 generatie tegelijk. OOO is hier een oplossing voor.
Bij Cell heb je nog geen 'verleden', en mede daardoor zal men nog geen interesse in OOO hebben.

Het is ook niet zo dat IBM er geen rescources achter zet....en toch doen ze het heel goed op het gebied van de high-end performance. In ieder geval bij de grote broer...de POWER5+.

POWER5+ is een prima processor, en een uitstekend voorbeeld van het feit dat er meer wegen naar Rome leiden. Het is een compleet andere aanpak dan Itanium, en ongeveer even succesvol.
Het maakt me ook niet zo veel uit of een processor OOO heeft of niet... Ik zeg alleen dat het mooier is als je het niet nodig hebt, omdat je dan die transistors voor andere doeleinden kunt gebruiken. Intel heeft dat dus geprobeerd met de Itanium, en voorlopig halen ze er toch aardige resultaten mee op bepaalde gebieden. Dus zo kan het ook.

Ik denk overigens dat we er vanuit kunnen gaan dat x86 de eerst komende 10 jaar nog wel flink vertegenwoordigd zal zijn. En om JIT goed geaccepteerd te krijgen moeten JIT de prestaties op dit platform dan echt als eerste verbeteren. Wat zou jij toegevoegd willen zien aan x86 om dit mogelijk te maken?

Het kan gewoon niet. De x86 is gewoon een compleet verouderde ISA, gemaakt op aannamen die al lang niet meer relevant zijn (zoals "zo klein mogelijke codering van instructies").
De huidige x86 processors zijn prima x86 processors, en als ik wist wat je er aan kon verbeteren, had ik nu een goedbetaalde baan bij Intel of AMD. Het gaat mij erom dat de x86 gewoon weg moet, en we opnieuw moeten beginnen met de kennis en aannamen van nu, en niet die van 1978.

[Verwijderd]

De pentium 4 is wel sterk in het hebben van een groot out-of-order window (126 instructies geloof ik, iets meer in latere modellen).

Precies, het aantal instructies 'in-flight' is bij de P4 dus heel hoog. En dat zie ik juist als 'agressief', omdat het window dus bepaalt hoeveel instructies je kunt reorderen, en over welk 'bereik' je dat kunt doen.
Daarom zou ik dus eerder de P4 agressief noemen.

De pentium uit die tijd had dat ook niet!

De Pentium Pro wel (en de AMD K5 ook), en die zijn zo'n 2 jaar na de eerste PPC op de markt gebracht. De PPC kreeg pas later OOO.

De G5 verwerkt 8 instructies per clock en kan er 5 per clock afronden.

Maar dat komt niet door de OOO, maar door het feit dat de instructieset veel efficienter is, en er daarom veel minder overhead nodig is voor het decoderen, issuen en retiren van instructies. Ook hoeft het window dus niet zo groot te zijn als bij een P4, je kunt immers meer instructies verwerken, dus zul je minder vaak instructies hoeven reorderen.

Mijn punt is dat OoOE voor RISK cores (dus na instructie decodering), voor iedere 'general pupose' ISA een flinke verbetering is omdat daarmee automatisch meer aanwezige ILP benut kan worden.

Een 'flinke' verbetering? Dat valt nog tegen.
Als je een Pentium (geen OOO) tegen een PPro (wel OOO) afzet, zul je in aardig wat gevallen een hogere IPC halen met de Pentium. Neem je processors van dezelfde kloksnelheid, dan is de Pentium dus de snellere processor. De Pentium heeft namelijk een kortere pipeline en minder latency, mede doordat er geen OOO-stages in de pipeline zitten (afgezien daarvan verschillen de execution units niet zo heel veel).
OOO kan dus voordelen hebben, maar het is zeker niet altijd een voordeel, laat staan dat het een 'flinke verbetering' is.

Iets waar een JIT die nooit aan 'echt optimale' instructie scheduling kan doen veel profijt heeft.

Wederom een x86-redenatie.
Op een x86 heb je veel profijt van OOO, met 'slechte' code. Op andere processors valt dat nogal tegen, omdat daar het verschil tussen 'slechte' code en 'goede' code veel kleiner is.
Je moet dan de afweging moet maken of je de extra overhead van OOO voor lief neemt, of dat je juist de latency omlaag brengt en de performance omhoog, en eventuele performance hits voor lief neemt, die niet met statische scheduling op te vangen zijn. Cell en Itanium kiezen dus voor geen OOO, en doen qua prestaties zeker niet onder voor OOO-processors. Je moet dus niet generaliseren wat je van de x86 ziet.

En wat mij betreft zijn er nog zan andere truuken die gedaan kunnen worden om x86 JIT vrienelijker te maken. Meest eenvoudige is natuurlijk een echt simple load/store gebaseerde instructieset ondersteunen die 1 op 1 te mappen is naar de RISC pipelines. Hoef je alleen maar een decoder context switch te maken, en klaar ben je!

Hier hebben we blijkbaar een verschil in impliciete aannamen. Wat jij hier voorstelt, vat ik op als een nieuwe instructieset, en dat is dus GEEN x86 in mijn ogen, laat staan een uitbreiding erop.

Ik denk trouwens niet dat dit gaat werken... Je kunt je execution units altijd maar voor 1 architectuur optimaliseren. Dat zie je zowel bij AMD64 als bij Itanium, die beiden zowel een 64-bit als een 32-bit instructieset ondersteunen.
Bij de AMD64 zijn de 64-bit prestaties niet optimaal, en bij de Itanium zijn de 32-bit prestaties niet optimaal.

Verder denk in niet dat je JIT in de praktijk geheel los kan beschouwen van GC en de bijbehorende memory overhead (in de implementaties die ik ken). Met geheugen toegang als echte bottleneck, is dat niet iets om te negeren lijkt me.

Met .NET kun je anders prima de GC omzeilen, daar zijn standaard keywords voor ingebouwd. Met Java kan het officieel niet, maar je kunt wel je objecten 'pinnen' door refererenties te bewaren in een klasse die gedurende de leeftijd van de applicatie blijft draaien.
Dan heb je ook geen GC. Dat is 1 van de redenen waarom Croissant 9 zo soepel draait. Als je realtime animatie doet met GC aan, dan zul je om de zoveel seconden een 'tik' zien, wanneer de GC aan het werk is. Die zie je hier niet, dus in feite draai je zonder GC.

[Verwijderd]

@ ddbruijn

Maar dat komt niet door de OOO, maar door het feit dat de instructieset veel efficienter is, en er daarom veel minder overhead nodig is voor het decoderen, issuen en retiren van instructies. Ook hoeft het window dus niet zo groot te zijn als bij een P4, je kunt immers meer instructies verwerken, dus zul je minder vaak instructies hoeven reorderen

Hier gaan we dus nooit uitkomen, da's mij wel duidelijk. Jou opvatting over wat OOO doet verschilt fundamenteel anders dan dat van mij. Voor mij is het de executie units bezig houden wanneer er een 'stall' optreed door bijvoorbeeld een geheugen leesactie die niet in de cache staat. Wat natuulijk impliceerd dat hoe meer instructies je per cycle kan verwerken, des te meer kans aanwezig is dat er stalls optreden vanwege niet aanwezige, maar wel benodigde resources. En des te groter de behoefte om ver vooruit te kijken en instructies te vinden, die wel alvast verwerkt kunnen worden.

Jou opvatting staat hier haaks tegenover, en wat decoderen nu weer te maken heeft met OoOE is mij volkomen onduidelijk. Decoding is afgerond voordat er ook maar enige OoOE wordt gedaan, geheel ontkoppeld dus.

Als je een Pentium (geen OOO) tegen een PPro (wel OOO) afzet, zul je in aardig wat gevallen een hogere IPC halen met de Pentium. Neem je processors van dezelfde kloksnelheid, dan is de Pentium dus de snellere processor

De PPro en opvolgers hadden diepere pipelines en konden daardoor dus ook op hogere frequenties werken. Je vergeet dat hoe meer nuttig werk een processor kan verzetten per tijdseenheid, hoe meer resources (memory toegang) er nodig is in dezelfde tijd...dus hoe meer stalls er zullen optreden in een architectuur als die van de originele pentium. Het is alsof de core tegen een muur aanloopt en ondanks vrije resources, geen stap verder komt. Welnu, dit is het eigenlijke probleem wat OoOE oplost....en dit is dus ook waarom iedere moderne snelle RISK/CISK architectuur het aanboord beeft! Een langzame processor heeft gewoon niet zo'n last van langzaam geheugen, en bij Itanium lossen ze het enigsinds op met behulp van ongelovelijk veel lage latency cache. Op zich bewonderingswaardig, maar nou niet bepaald DE oplossing.

Wederom een x86-redenatie.
Op een x86 heb je veel profijt van OOO, met 'slechte' code. Op andere processors valt dat nogal tegen, omdat daar het verschil tussen 'slechte' code en 'goede' code veel kleiner is

Met goede en slechte code bedoel je goed/slecht geschedulde code. En inderdaad, een schone ISA heeft kleindere verschillen. Maar dat heeft absoluut niets met OoOE te maken! Ook in een mooite strakke ISA, heb he geheugen toegang en latencies die niet te verbergen zijn zonder OoOE of onmenselijk veel snel cache geheugen.

x86 is net zoals PPC, net zoals Mips....allemaal RISK van binnen, maar x86 heeft een legacy decoder ervoor geplakt zitten en heeft nog enkele complexe instructies die met een micro-code programma ge-emuleerd worden. De core, het memory sub-systeem, de OoOE, de branch-prediction, het is allemaal gelijk aan die van de RISK concurenten.

Met .NET kun je anders prima de GC omzeilen, daar zijn standaard keywords voor ingebouwd. Met Java kan het officieel niet, maar je kunt wel je objecten 'pinnen' door refererenties te bewaren in een klasse die gedurende de leeftijd van de applicatie blijft draaien

Wat je in het geval van .NET opzeilen noemt weet ik niet zeker, ik neem maar even aan dat je unmanaged C++ bedoeld, welke naar bytecode is gecompileerd. Zelfs dan heb je te maken (als je een doorsnee appicatie maakt), met enig GC, omdat doorgaans niet alle code van je eigen applicatie afkomstig is. Er is ook nog het framework, etc.

Je java voorbeeld shiet natuurlijk zijn doel voorbij. Je gebruikt dan juist nog meer geheugen dan wanneer je de GC de boel zo af en toe laat opruimen. Doe me denken aan somige libraries die beweerden dat ze je windows programma's sneller zouden maken. Wat ze dan deden is tegen windows zeggen, dat het geheugen niet ge-paged mocht worden, lol. Resultaat was natuurlijk dat bij een beetje programma, je systeem resource strarvation kreeg en totaal in elkaar storte. Was uit de mooie demo's natuurlijk niet op te maken .

Ik blijf er echt bij, dat je op processor architectuur wel wat details weet, maar de concepten erachter niet werkelijk begrijpt. Op JIT gebied denk ik dat je bepaalden dingen gewoon mooi/clean vindt werken, maar niet kan accepteren dat je niet altijd zo'n ideaal situatie kan hebben in de praktijk. Die is vaak toch wat complexer en minder 'perfect'.

Als je over de functie van OoOE hezelfde zou verstaan als ik dat doe, dan zou je je niet zo vastbijten op de ISA en bovendien met me eens zijn dat JIT juist gebaat is bij OoOE. JIT gebruikt impliciet meer resources, en dankzij OoOE wordt de processor daar niet meteen onmenselijk traag door.

Jij mag het laaste woord hebben, ik heb er eigenlijk nu wel genoeg van!

[Verwijderd]

lol, het is heus AMD niet die ervoor gezorgd heeft dat itanium niet doorkomt.

Jawel hoor, kijk verder dan je neus lang is:

(*)te trage emulatie van x86 op de itanium

Zou geen probleem zijn als er geen snellere x86s meer te koop waren (Intel zou ze niet meer maken in ieder geval). Dan heb je gewoon die keus niet, en moet je deze x86-emulatie accepteren.
Wat ook weer een extra impuls zou zijn om software zo snel mogelijk naar Itanium/64-bit te porten. De overstap zou dan waarschijnlijk veel sneller gemaakt zijn dan nu.
Aangezien de x86 dan 'vast zou staan' op de snelste x86 ooit gemaakt, en de Itanium iedere paar maanden snellere steppings en revisies zou krijgen, zou de Itanium de x86 binnen de kortste keren inhalen, met emulatie en al.

(*)een te grote software-bibiliotheek die dag in dag uit gebruikt wordt en die enkel op x86-processoren draait .

Als gevolg van het bovengenoemde zou die software-bibliotheek dus redelijk snel vervangen zijn, in alle gevallen waar de 'trage' x86-emulatie een probleem is.
Maar van wat ik gelezen heb, was de x86-emulatie van Itanium met Windows XP SP2 ongeveer vergelijkbaar met een Xeon 1.5 GHz.
Dat moet meer dan genoeg zijn voor echte oude software, die niet meer voor porting in aanmerking komt om wat voor reden dan ook. Software van 10-20 jaar geleden was ook gemaakt voor computers van 10-20 jaar geleden, en die waren bij lange na niet zo snel als een Xeon 1.5 GHz, dus 'traag' is maar heel relatief.

Itanium x86 laten vervangen is al een tijdje van de baan. En als dit écht gepushed werd, dan zou AMD heus wel met een Itanium-kloon op de proppen komen.

Dat zou toch geen probleem zijn? Dan heb je nog steeds die nieuwe, betere architectuur. Of AMD of Intel die dan maakt, is niet zo heel interessant.

Wat heeft 64-bit trouwens met itanium te maken? 64 bit is heus niet de reden waarom men op itanium zou moeten overstappen. Het veel betere ontwerp + groter potentiëel van de architectuur spreekt in zijn voordeel.

Het is een extra push. 32-bit begint krap te worden... databases gaan niet meer passen etc... dus de vraag naar 64-bit processors begint langzaam op te komen. Over een aantal jaren zul je bijna niet meer om 64-bit heen kunnen, net zoals we vandaag de dag met een 16-bit processor geen 'dagelijkse' software meer kunnen draaien.
Zonder AMD64 zou Itanium dus de enige 64-bit oplossing zijn voor de Windows-markt. Dat maakt de keus voor Itanium heel gemakkelijk. Sowieso zit je dan niet meer met het x86-legacy probleem.
Als je 64-bit software nodig hebt, moet die toch herschreven worden (in het minste geval toch opnieuw gecompileerd). Of dat nu voor AMD64 of voor Itanium moet gebeuren, maakt niet uit, het moet gebeuren.
Als je dus de keus niet hebt, wordt het automatisch de Itanium, en is succes verzekerd.

Trouens, AMD is erg slim geweest bij hun 64-bits implementatie. Dankzij hun hebben we nu 2 keer zoveel registers als voorheen. Ik vraag me af of intel hetzelfde gedaan zou hebben

Vind je dat slim? Meer registers had ik ook nog wel kunnen bedenken. Verder vind ik het nog steeds bijzonder weinig. M'n 68000 had ook al 16 registers, en dat was in 1979 (ja, het is een generatiegenoot van de 8086).
Zou Intel hetzelfde gedaan hebben? Nee, Intel heeft de Itanium ontwikkeld. Die heeft VEEL meer registers, en daarnaast ook een compleet andere architectuur met VEEL meer slimmigheden dan alleen 16 registertjes in een architectuur uit 1978 proppen.

[Chatslet]

Ik denk dat je toch het een en ander aan inzicht mist. Als de Itaniumk echt mainstream was geworden dan zaten we tenminste nog 10 jaar vast aan emulatie en na die 10 jaar zou de Itanium dus ook weer verouderd zijn. Grote onzin dus. Kijken we naar AMD64 dan is het eigenlijk best of both worlds x86 werkt er gewoon native op maar je kunt er ook gewoon 64 bit op draaien en dan bedoel ik niet zoals Microsoft doet: Windows XP opnieuw compilen op 64 bit (wat ze trouwens met veel linux meuk ook doen maar de software gewoon echt schrijven voor 64 bit. Zet voor de grap maar eens Solaris 10 op een Athlon 64 dan ga je echt het verschil merken.

[Verwijderd]

Ik denk dat je toch het een en ander aan inzicht mist. Als de Itaniumk echt mainstream was geworden dan zaten we tenminste nog 10 jaar vast aan emulatie en na die 10 jaar zou de Itanium dus ook weer verouderd zijn.

Met welk 'inzicht' bepaal je die 10 jaar?
Ik noemde 10 jaar vanwege de 'gemakzucht' van het bij x86 blijven, zoals we die door de jaren kennen.
Als we de overstap zouden maken, zouden er hele andere impulsen zijn, en zou de overstap veel sneller verlopen dan nu.
Je ziet het nu ook bij AMD64... Omdat 32-bit software bijna net zo goed werkt, blijven vraag en aanbod naar 64-bit software achter.
Bij Itanium zou 32-bit software minder goed werken, dus zou je automatisch meer vraag naar 64-bit software krijgen, en dus ook meer aanbod. Nu is het voor veel ontwikkelaars ook niet interessant om 64-bit versies te maken, omdat ze nauwelijks beter/sneller zijn dan 32-bit versies, en er dus weinig vraag naar zou zijn.
Sowieso draaien de meeste bezitters van AMD64-compatible machines nog niet eens een 64-bit OS, dus kunnen ze niet eens 64-bit software draaien. Dat is allemaal die gemakzucht. Met Itanium heb je geen keus... Alle OSen zijn per definitie 64-bit.

Kijken we naar AMD64 dan is het eigenlijk best of both worlds x86 werkt er gewoon native op maar je kunt er ook gewoon 64 bit op draaien

Over gebrek aan inzicht gesproken.... AMD64 is een 32-bit processor met de mogelijkheid om 64-bit software te draaien. Meer is het niet.
x86 was al geen bijzonder goede/efficiente 32-bit architectuur, en de 64-bit variant is nauwelijks een verbetering.
Met een moderne architectuur heb je weliswaar mindere 32-bit x86-prestaties, maar je hebt WEL superieure 64-bit prestaties, die heb je bij een AMD64 nauwelijks.
Zeker niet het beste van de 64-bit wereld.

[elteck]

Ben het wel me je eens dat het jammer is dat de Itanium nog steeds geen succes is. Maar daar is Intel toch zelf ook wel schuldig aan. Het is nieuwe techniek en de eerste versies presteerden niet echt geweldig, maar de architectuur heeft wel de potentie erg goed te worden.

Volgens mij had Intel met AMD om de tafel moeten gaan zitten. AMD had wel hun 64bit open gemaakt, zodat Intel kon meedoen. Andersom mag AMD geen Itanium equivalent maken.

Daarnaast had er naast de server variant ook een desktop variant van de Itanium moeten komen, zodat de processor betere bekentheid krijgt en er veel meer software voor ontwikkeld wordt.Zeker als het goed presteerd op games, is veel sneller geaccepteerd. Systeem beheerders kijken ook over de schouders van hun kinderen. Dankzij Linux en server2003 zijn alle moderne servers zo'n beetje pc's met extra redundancy.

[vcore791]

Dd..

als onderzoeker laat je je wel erg hard meeslepen in deze Betamax/VHS discussie

Je weet toch hoe het werkt..

Die met de meeste pr0n wint

[Verwijderd]

@ddbruijn:

Nette reply...ik liep mischien een beetje te hard van stapel in die van mij .

Maar is jou ervaring dan dat JIT op powerPC zich heel anders gedraagd wat betreft performance? Dit is namelijk een nog veel agressieve OoOE implementatie en is toch een vrij recent opgeschoonde instructieset als ik IBM en Motorola tijdens de introductie van de PPC601 het mogen geloven.

Bij IBM lijkt men erg in OoOE te geloven, zetten er ook heel zwaar op in. Terwijl er bij de PowerPC toch niet die nadelen zitten die jij voor de x86 als doorslaggevend ziet. Het is ook niet zo dat IBM er geen rescources achter zet....en toch doen ze het heel goed op het gebied van de high-end performance. In ieder geval bij de grote broer...de POWER5+.

Ik denk overigens dat we er vanuit kunnen gaan dat x86 de eerst komende 10 jaar nog wel flink vertegenwoordigd zal zijn. En om JIT goed geaccepteerd te krijgen moeten JIT de prestaties op dit platform dan echt als eerste verbeteren. Wat zou jij toegevoegd willen zien aan x86 om dit mogelijk te maken?

[blouweKip]

We waren er anders heel dichtbij. Zonder de AMD64 had het 100% zeker gebeurd.

Zonder amd waren we niet zo ver gekomen en had intel weinig of geen noodzaak gehad om te innoveren..

De markt kiest niet voor vooruitgang, de beste systemen worden vaak genegeerd ten voordele van datgene wat al bekend is (x86/win32 etc).
Zonder amd had intel geen reden gehad te innoveren en was er ws niet eens een itanium geweest..

[Chatslet]

Als je denkt dat AMD64 geen winst in prestatie geeft dan moet je toch eens Solaris proberen. Het is niet voor niets dat Sun met AMD in zee is gegaan. De nieuwe Itaniums bieden overigens geen x86 emulatie meer, dit moet dus uit het besturingssysteem komen wat het geheel nog trager maakt. Een migratie naar de Itaniumk is gewoon simpelweg niet haalbaar omdat dan alle software herschreven zou moeten worden vergelijk het bijvoorbeeld eens met engeland daar rijd men aan de linker kant van de weg. Stel dat de EU nu eens zegt dat ze allemaal rechts moeten gaan rijden dat zou betekenen dan hele kruispunten, rotondes en stoplichten allemaal op de schop moeten. Dan hou je ook nog zeker 10 jaar auto's waarbij het stuur aan de rechterkant zit (emulatie) voordat er een keer nieuwe auto's zijn waarbij het stuur aan de linkerkant zit. Zo een migratie is gewoon niet haalbaar. De Itanium is overigens ook nooit ontwikkeld voor normaal desktop gebruik maar voor gebruik in high end servers om te concureren met bijvoorbeeld IBM's AS/400 servers waar veel parrelelle threads worden uitgevoerd (denk aan zware database servers) en daar komt ook nog bij dat de Itanium in vergelijking met concurenten vrij matig presteerd. Een ander leuk feitje: Voor het geld van een Itaniumk server heb je vaak een Opteron server met meer cores die erg veel sneller is.

[Verwijderd]

Als je iets meer af had geweten van de Itanium architecuur het je nooit deze uitspraken gedaan. Deze architectuur moet het juist hebben van slimme compilers die daar de nodige tijd voor nemen. Niet iets dat je met JIT technieken wilt doen. Verder is de Itanium een totaal ander beest dan Power of Alpha.

Als je iets meer van JIT-technieken af wist, had je nooit deze uitspraken gedaan.
Natuurlijk ben ik op de hoogte van de Itanium-architectuur en het feit dat veel door de compiler gedaan moet worden (ik neem jouw onderschatting in deze dan ook ten zeerste kwalijk).
Maar ik ben ook op de hoogte van JIT-technieken, en in tegenstelling tot jou besef ik heel goed dat een groot deel van de compilatie nog steeds statisch is, en dat alleen de bytecode at runtime naar native code omgezet moet worden. De meeste optimalisaties voor Itanium hebben te maken met scheduling en branches, en kunnen tijdens de statische compilatie opgelost worden. At runtime hoef je alleen de codebundles nog te vormen, en dat is eigenlijk redelijk triviaal. x86 is veel complexer, omdat de instructieset niet orthogonaal is, de instucties geen vaste lengte hebben, en vanwege de legacy er allerlei rare regeltjes en uitzonderingen zijn.

Als je dan ook nog eens bedenkt dat de Itanium implementaties ver achterlopen w.b.t. bandbreedte, dan kun je wel stellen dat EPIC + JIT de ultieme slechte mix is.

Maar als x86 er niet was, zou Intel al z'n energie op de Itanium storten, en had je deze problemen niet. Je moet het natuurlijk wel in de juiste context plaatsen.
Verder had je, als je mijn verhaal goed gevolgd had, gezien dat het mij vooral gaat om los te komen van x86 (en daarmee ISAs in het algemeen)... niet zozeer dat Itanium nou de ultieme processor is voor de toekomst. Het zou een mooi begin kunnen zijn, en daarna zouden JIT-compilers en hardware hand-in-hand doorontwikkeld kunnen worden.

Ik denk dan ook dat je heel erg gemakkelijk de hype van onderzoekers overgenomen hebt. Er wordt all ruim 10 jaar van de daken geschreeuw dat JIT beter en niet langzamer is, en nog steeds zie ik dagelijks het tegendeel.

Nee, ik *ben* zo'n onderzoeker.
Dat jij dat niet dagelijks ziet, kan kloppen. Ten eerste zie jij niet wat wij zien, maar alleen de commerciele oplossingen, en ten tweede heb je waarschijnlijk alleen de x86-hardware gezien, die juist niet interessant is voor JIT-compilatie.

[Verwijderd]

Als je denkt dat AMD64 geen winst in prestatie geeft dan moet je toch eens Solaris proberen.

Ten eerste zeg ik niet dat AMD64 *geen* winst in prestatie geeft. Ik heb zelf ook meegemaakt dat een recursief algoritme 20% sneller liep vanwege de fastcall die nu mogelijk (en standaard) is vanwege de extra registers.
Ik weet alleen dat er *meer* winst te behalen zou zijn met een 64-bit architectuur die 'from scratch' ontworpen is.

Ten tweede vind ik dat geleuter over OSen onzin. Prestaties komen van de hardware en niet van het OS. Als ik software schrijf, dan is de bijdrage van het OS daarin nihil, als ik verder geen zware processen op de achtergrond draai, wat ik natuurlijk ook niet doe als ik de snelheid van een systeem wil onderzoeken.
De prestaties komen voor 99% van de kwaliteit van de code, de compiler en de hardware-architectuur.
De verschillen in prestaties van OSen zijn ook van die factoren afhankelijk. 2 OSen die op dezelfde hardware-architectuur draaien, zijn dus alleen nog maar afhankelijk van code en compiler.
Aangezien ik m'n eigen code schrijf, en niet die van het OS gebruik, heb ik weinig met het OS te maken. Hooguit voor disk I/O en dat soort randzaken, maar die probeer ik uiteraard altijd te mijden als ik de snelheid van de CPU/architectuur wil meten.

De nieuwe Itaniums bieden overigens geen x86 emulatie meer, dit moet dus uit het besturingssysteem komen wat het geheel nog trager maakt.

Dat is juist niet waar.
In Windows XP SP2 voor Itanium zat een vernieuwde JIT-compiler, die juist vele malen sneller was dan de eerdere x86-emulatie die veel meer op de hardware steunde.

[Verwijderd]

Volgens mij had Intel met AMD om de tafel moeten gaan zitten. AMD had wel hun 64bit open gemaakt, zodat Intel kon meedoen.

Dat is niet vanwege de onmetelijke goedheid van AMD hoor. AMD *moest* dit doen, omdat ze nou eenmaal op de x86-architectuur van Intel verder bouwen, en dat is gewoon onderdeel van de licentie-overeenkomst.

Andersom mag AMD geen Itanium equivalent maken.

Omdat ze geen Itanium-licentie hebben. Als ze om de tafel hadden gaan zitten, had die er vast wel gekomen... Maar zou AMD dan niet degene moeten zijn die de eerste stap zet, en niet Intel?
AMD heeft dat niet gedaan, en Intel kon niet voorzien dat AMD64 dermate succesvol zou worden dat het een bedreiging voor de P4 en de Itanium zou worden. Destijds was er zelfs sprake van dat er geen 64-bit Windows voor AMD64 zou komen.
Die is er pas sinds kort, nadat Intel zelf ook AMD64-compatible CPUs op de markt heeft.

Daarnaast had er naast de server variant ook een desktop variant van de Itanium moeten komen, zodat de processor betere bekentheid krijgt en er veel meer software voor ontwikkeld wordt.

Die zou er uiteraard ook gekomen zijn. Intel had al wel workstation-processors. HP had een tijdje Itanium workstations in de aanbieding, met Windows XP. Dat werkte allemaal best goed, en was maar marginaal duurder dan een x86 desktop/workstation.
Maar helaas is het geen succes geworden, dus blijft alleen de server-afdeling nu over.

[Chatslet]

Ten tweede vind ik dat geleuter over OSen onzin.

De prestaties van een systeem hangen wel degelijk af van het OS. Software draait de laatste tijd niet meer rechtstreeks op de hardware zoals dit met MS-DOS het geval was. Tegenwoordig gaat dit allemaal in een soort van virtuele machines. Natuurlijk heb je ook wel trage en snelle software maar er hangt gewoon erg veel van het OS af. Installeer voor de grap maar eens Linux op een Athlon/Pentium 4 dan zal die standaard de i686 kernel installeren in plaats van de i386 kernel en dat heeft dus een rede. Zet er voor de grap maar een i386 kernel op en zie de prestaties achter uit gaan. Het zelfde geld dus voor ieder ander besturings systeem en ook software code moet gewoon geoptimliseerd zijn wil het lekker draaien. Om maar even terug te komen op Wiondows op de Itanium, die emulatie is gewoon niet snel, buiten dat is er geen weldenkend mens dat windows op een Itanium zou gaan draaien en nogmaals: Een migratie naar een volledig andere architectuur is simpelweg niet haalbaar voor het bedrijfsleven omdat met nog te veel met legacy software werkt en emuleren nou eenmaal niet altijd perfekt gaat. Veel banken en overheidsinstellingen werken zelfs nog met Windows NT 4.0 omdat ze bijvoorbeeld erg veel maatwerk pakketten gebruiken en het gewoon te duur is deze om te zetten naar een nieuw systeem laat staan een hele nieuwe architectuur binnen halen en je volledige informatie systeem migreren alleen omdat iemand bij intel vind dat we allemaal aan een andere architectuur moeten. Herinner je je nog de ophef over het stop zetten van de Windows NT 4.0 support?

[Verwijderd]

De prestaties van een systeem hangen wel degelijk af van het OS

Ja, maar ik heb het over de processor, niet over het systeem.
Er is geen enkel OS dat magisch je processor ineens sneller laat rekenen.
Als ik software schrijf, dan draaien mijn routines altijd even snel op dezelfde processor, ongeacht het OS.
Er zit alleen verschil in de interactie met het OS, zoals multithreading, event handling, en OS-functies... Maar ik probeer er natuurlijk altijd voor te zorgen dat dat niet de bottleneck is. In welk geval de bottleneck dus in mijn code zit, en niet beinvloed wordt door het OS, maar alleen door de CPU. QED.

Software draait de laatste tijd niet meer rechtstreeks op de hardware zoals dit met MS-DOS het geval was. Tegenwoordig gaat dit allemaal in een soort van virtuele machines.

Je hoeft mij niet uit te leggen hoe een modern OS en een moderne processor werken. Ik heb ervoor doorgeleerd. Maar bij jou krijg ik sterk de indruk van een klok-en-klepel-verhaal.
Denk je dat iedere instructie gevirtualiseerd wordt? De gangbare instructies voor usermode-programma's draaien wel degelijk gewoon direct op de hardware. Voor sommige instructies zal er een speciale handler geinstalleerd worden, maar die zijn op de meeste software niet of nauwelijks van toepassing, en zullen de prestaties ook niet beinvloeden.

Installeer voor de grap maar eens Linux op een Athlon/Pentium 4 dan zal die standaard de i686 kernel installeren in plaats van de i386 kernel en dat heeft dus een rede. Zet er voor de grap maar een i386 kernel op en zie de prestaties achter uit gaan.

De prestaties van de kernel? Ja logisch... Maar ik heb het niet over de kernel, ik heb het over de processor. Dat de kernel trager wordt, heeft ermee te maken dat hij geen gebruik meer maakt van speciale instructies en features van de nieuwere processor. Maar daar heb ik het niet over. Dezelfde instructies zullen nog steeds even snel of even langzaam uitgevoerd worden. De processor is immers niet ineens vertraagd om een of andere vage reden.

buiten dat is er geen weldenkend mens dat windows op een Itanium zou gaan draaien

Zou je dat even willen toelichten, want ik word niet graag voor 'niet weldenkend' uitgemaakt zonder enige aanleiding.

en nogmaals: Een migratie naar een volledig andere architectuur is simpelweg niet haalbaar voor het bedrijfsleven omdat met nog te veel met legacy software werkt en emuleren nou eenmaal niet altijd perfekt gaat.

Zoals ik al zei, laat die mensen dan lekker hun oude spul blijven gebruiken. Ik word hier een beetje moe van, ik herhaal mezelf niet graag.
Ik word ook een beetje moe van al die mensen die de vooruitgang tegenwerken omdat ze hun zaakjes niet goed voor elkaar hebben.

Herinner je je nog de ophef over het stop zetten van de Windows NT 4.0 support?

Ja, die mensen vind ik ook allemaal incompetent, en zou ik liever nooit meer achter een computer willen zien.
Dat zijn mensen die niet leren van de fouten van het verleden. Ondertussen weten we allang dat systemen niet het eeuwige leven hebben, dus als je een systeem opzet, zorg je dat het goed gedocumenteerd is, zo veel mogelijk gebruik maakt van duidelijke standaarden, en zo veel mogelijk modulair en portable van opzet is. Dan is het ineens helemaal niet zo'n probleem meer om naar een ander systeem over te stappen. Maar ja, sommige mensen leren het nooit, en blijven prutsen. Ik heb daar geen medelijden mee, eerlijk gezegd.

[Verwijderd]

Dat is niet vanwege de onmetelijke goedheid van AMD hoor. AMD *moest* dit doen, omdat ze nou eenmaal op de x86-architectuur van Intel verder bouwen, en dat is gewoon onderdeel van de licentie-overeenkomst.

Weet jij (of iemand anders) of er zaken uit deze overeenkomst openbaar gemaakt zijn? Of is anderszins bekend wat deze licentie inhoudt?

(bekend is o.a. dat AMD maximaal 20% van zijn x86 produktie mag uitbesteden)

[GoBieN-Be]

""Vind ik allemaal zwaar overtrokken onzin. Apple is al voor de tweede maal overgestapt op een andere architectuur, en dat ging allemaal redelijk soepeltjes, en Apple is nu populairder dan ooit, mede doordat die nieuwe architectuur een aantal voordelen biedt voor de gebruiker. Ik zou dus eerder het omgekeerde beweren: de overgang naar een andere architectuur is de moeite meer dan waard.""

Inderdaad overgestapt naar x86 !!!

[Verwijderd]

En dat is met alles zo, stop je de ontwikkeling van een goed en snel product en ontwikkel je een bagger product door, dan zal dat bagger product op een geven punt natuurlijk moderner en sneller worden

Je geeft dus toe dat ik gelijk heb. Waarom noem je het dan kortzichtig?

maar liever geen zo'n dure proc in men desktopje hoor al zou de prijs wel dalen het zou toch nog een hele tijd geduurd hebben voor ze aan dezelfde prijs als een x86 zouden gekomen zijn.

De workstation processors waren destijds ongeveer $900.
Die prijs is dus vergelijkbaar met de Pentium EE/XE en Athlon FX processors, en die zijn niet te duur voor de desktop?
Ze hadden binnen no time rond de $200-$300 gezeten als het een beetje aansloeg. De processor op zich was namelijk niet duur, maar de uitvoeringen die ze ervan maakten wel... veel cache etc. Dat zie je ook bij Xeons bv. Bijna hetzelfde als een Pentium, maar wel veel duurder vanwege extra cache etc, die alleen interessant is voor de workstation/serverwereld.
Wie is er kortzichtig?

Trouwens Intel was niet van plan om alles op IA64 te zetten, droom verder, de roadmaps toonden duidelijk hun bedoeling om met netburst zeer ver te gaan. Tot nu dus, maar dat is een ander verhaal.

Ik zei toch ook dat Netburst de laatste was? Natuurlijk ging die nog wel even verder. Maar Core stond er tot voor kort niet op... en ook de Prescott was niet gepland natuurlijk.
Intel was echt wel van plan om op IA64 over te gaan. Ze hadden zelfs aangekondigd dat de Pentium 4 de laatste x86 zou zijn. Zoek maar terug in de tweakers-nieuwsberichten. Of droom lekker verder.

Als de Core2 (in fabeltjesland mss) AMD failliet zou maken dan zou Intel gewoon door doen met hun Core2 (een zuinige, goed presterende AMD killer) en de prijzen wat verhogen. Immers waaorm dan overstappen naar iets anders gekoppeld aan hoge investeringen ? Er is toch geen concurrentie meer !

gezonde concurrentie = innovatie !!

Deze flauwekul had ik al in een eerdere post ontkracht, ik ga me niet herhalen.
Ik word eerlijk gezegd een beetje moe van dit soort kortzichtige reacties, van mensen die overduidelijk nog nooit een computer hebben gehad voor het AMD-tijdperk, laat staan dat ze iets anders dan x86 van dichtbij hebben gezien.
Ik gebruikte al computers in de tijd dat AMD gewoon 1 van de fabrikanten van Intel-chips was, en destijds gebruikte ik ook niet eens Intel-chips. Je hoeft mij niet te vertellen wat er gebeurt als Intel geen concurrentie heeft op de x86-markt, of hoe x86 zich verhoudt tot andere architecturen. Ik heb het allemaal meegemaakt.

[Verwijderd]

Voor mij is het de executie units bezig houden wanneer er een 'stall' optreed door bijvoorbeeld een geheugen leesactie die niet in de cache staat. Wat natuulijk impliceerd dat hoe meer instructies je per cycle kan verwerken, des te meer kans dat er stalls optreden vanwege benodigde resources die nog niet beschikbaar zijn.

Hier kan ik het inderdaad niet mee eens zijn, omdat het de omgekeerde wereld is. Hoe meer instructies je per cycle kunt verwerken, hoe minder instructies er 'ophopen' omdat ze nog niet verwerkt kunnen worden. Code is altijd hetzelfde, en in de praktijk heb je niet zo enorm veel geheugentoegang (zeker niet buiten cache), en ook niet zo heel veel instructies die niet afhankelijk van elkaar zijn.
De PPC heeft eigenlijk 'te veel' resources, en heeft daarom dus minder belang bij OOO. Er zijn meer 'gaatjes' om instructies in te proppen, dus hoef je minder hard te zoeken naar een leeg gaatje, en raken de gaatjes minder gauw verstopt.
Mede daarom heb je dus ook een minder agressieve OOO (minder instructies in-flight). Een P4 raakt juist heel snel verstopt omdat ie relatief weinig werk gedaan krijgt per cycle.
Jij noemt dus het aantal instructies dat de processor per cycle kan verwerken als kenmerk van OOO, maar dat is een kenmerk van de achterliggende execution-units. OOO zit daar precies voor, en als je die OOO weg zou laten, kan de processor nog steeds evenveel instructies per cycle verwerken. Je zult de execution units dan alleen wat minder effcient kunnen vullen. Maar dat is een ander verhaal dan het maximum aantal instructies dat ie aankan.

en wat decoderen nu weer te maken heeft met OoOE is mij volkomen onduidelijk. Decoding is afgerond voordat er ook maar enige OoOE wordt gedaan, geheel ontkoppeld dus

Het punt is dat bij een x86 de instructies na decoderen heel anders zijn dan voor decoderen. Het kunnen er ineens veel meer worden, met allerlei dependencies, dus neemt de noodzaak van OOO toe.
Bij een instructieset die zo goed als 1:1 vertaalt naar de backend, heb je dat dus niet, en kun je de OOO wat simpeler en compacter uitvoeren.

De PPro en opvolgers waren hadden diepere pipelines en konden daardoor dus ook op hogere frequenties werken. Je vergeet dat hoe meer nuttig werk een processor kan verzetten per tijdseenheid, hoe meer resources (memory toegang) er nodig is in dezelfde tijd...dus hoe meer stalls er zullen optreden in een architectuur als die van de originele pentium.

Dat vergeet ik helemaal niet. Ik geef alleen aan dat er een moment was waar OOO niet voor een 'flinke verbetering' zorgde, zoals jij beweerde.
Bij de introductie van de PPro had je dat voordeel van de kloksnelheid nog niet. Zowel de Pentium als de PPro waren in 200 MHz te krijgen, rond die tijd. En de Pentium kon je vaak sneller laten rekenen, met goed uitgekiende code.
Natuurlijk werd de PPro uiteindelijk sneller, maar dat kwam niet doordat OOO hem efficienter maakte, maar doordat de kloksnelheid omhoog kon. Dan kom je in een gebied waar je enerzijds de OOO harder nodig hebt, omdat de geheugentechnologie achterblijft, en anderzijds de Pentium niet meer mee kan schalen (en sowieso een verouderde architectuur was geworden). Maar voor die tijd was OOO dus alleen maar extra overhead, en geen prestatiewinst. Dat was het punt dat ik wilde maken.

Een langzame processor heeft gewoon niet zo'n last van langzaam geheugen, en bij Itanium lossen ze het enigsinds op met behulp van ongelovelijk veel lage latency cache. Op zich bewonderingswaardig, maar nou niet bepaald DE oplossing.

IBM smijt er juist weer heel veel cores tegenaan... Je kunt niet spreken van DE oplossing, er is voor beide methoden wat te zeggen.
Voor x86 is echter wat minder te zeggen, naar mijn mening. Die wordt kunstmatig in leven gehouden, niet omdat het de beste oplossing is.

Maar dat heeft absoluut niets met OoOE te maken! Ook in een mooite strakke ISA, heb he geheugen toegang en latencies die niet te verbergen zijn zonder OoOE of onmenselijk veel snel cache geheugen.

Het lijkt erop dat jij totaal gefixeerd bent op geheugentoegang... Er spelen nog veel meer dingen... Zoals dus dependency chains en branches.
PowerPC heeft wat handigheidjes waardoor je met 1 instructie dingen kunt doen waar je bij x86 3 of 4 afhankelijke instructies zou moeten gebruiken.
Dat zijn dus 3 a 4 instructies minder waarbij je extra instructies moet zien te OOO'en om de rest van de CPU bezig te houden.
PowerPC heeft ook wat handigheidjes om branches beter te kunnen voorspellen (bv een link-register en een count-register). Minder foute branches betekent minder vaak de verkeerde code in de cache proppen en decoderen, en dus minder vaak dit op hoeven vangen met instructies die nog in de buffer zaten dmv OOO.
De PowerPC heeft aligned code waardoor decoding simpeler wordt, en je dus minder gauw 'vast' komt te zitten met je decoder... Dat betekent dus dat je een minder grote buffer nodig hebt die je vol moet proppen met instructies om de OOO maar bezig te houden.
Het werkt allemaal strakker, minder latency, minder ver vooruit kijken.

De core, het memory sub-systeem, de OoOE, de branch-prediction, het is allemaal gelijk aan die van de RISK concurenten.

Niet dus, zie oa bovengenoemde punten.

ik neem maar even aan dat je unmanaged C++ bedoeld

Nee, kan ook met C#... waarschijnlijk ook met VB.NET en andere talen, maar daarmee ben ik niet bekend.

Je java voorbeeld shiet natuurlijk zijn doel voorbij. Je gebruikt dan juist nog meer geheugen dan wanneer je de GC de boel zo af en toe laat opruimen.

Gaat het om geheugengebruik dan? Ik dacht dat het om performance ging. Ten eerste heb je zat geheugen... Ten tweede gebruik je dat geheugen niet *echt*, omdat het OS er wel voor zorgt dat dat soort dingen uitgepaged worden, omdat je het toch niet aanspreekt. Zo gaat het ook met Windows services bv. Die gebruiken meestal maar een paar kb, omdat ze constant hetzelfde kleine stukje code runnen, en de rest van het proces er maar een beetje voor niks bij hangt, daar kom je nooit.
Dus NIET wat jij zegt met die libraries, omdat je het geheugen niet fysiek vastzet. Je zet alleen de references vast, zodat ze nooit in de lijst van de gc komen, en als de gc dan gedraaid wordt, meteen weer klaar is, omdat de lijst gewoon leeg is. Overhead is dus verwaarloosbaar.

Ik blijf er echt bij, dat je op processor architectuur wel wat details weet, maar de concepten erachter niet werkelijk begrijpt.

Nou, na deze post heb ik sterk de indruk dat jij degene bent die nogal wat kennis ontbeert. Je lijkt te denken dat x86 hetzelfde is als bv PowerPC. Dan heb je het blijkbaar niet goed bestudeerd. Er zitten een hoop cruciale verschillen in, waarvan ik er hierboven een aantal genoemd heb.

Als je over de functie van OoOE hezelfde zou verstaan als ik dat doe, dan zou je je niet zo vastbijten op de ISA en bovendien met me eens zijn dat JIT juist gebaat is bij OoOE. JIT gebruikt impliciet meer resources, en dankzij OoOE wordt de processor daar niet meteen onmenselijk traag door.

Ik ben niet tegen OOO, omdat het in de praktijk een goede oplossing is. Je snapt kennelijk alleen niet dat het in feite maar een lapmiddel is, waar je het liefst zo min mogelijk gebruik van wilt maken. Je wilt immers je execution backend zo efficient mogelijk maken. Die wordt minder efficient als er allerlei extra stages voor moeten om de code te gaan reorderen etc. Dat is allemaal extra latency, die je weer extra gaat kosten bij branches en dergelijke.

Jij mag het laaste woord hebben, ik heb er eigenlijk nu wel genoeg van!

Jammer, ik denk dat deze post toch nog een hoop vragen opwerpt.
Verder ben jij de enige die hier nog enigszins inhoudelijk wilt discussieren ipv alleen maar wat anti-Intel dingen roepen.

[Verwijderd]

Wellicht is x86 inderdaad steeds meer loze bagage aan het verzamelen, maar het is wel een zeer succesvolle architectuur qua performance. Als al die andere architecturen echt zoveel beter waren geweest in de praktijk dan hadden ze zichzelf allang bewezen. Verder ben ik erg blij dat we in ieder geval niet de Titanium zonder T zullen krijgen als nieuwe dominante architectuur, zodat er tenminste mogelijkheden blijven om een architectuur te ontwerpen die echt goed in elkaar zit. En daarbij is Intel geen logische keuze om die taak op zich te nemen, aangezien ze al jaren achtereen aantonen dat hun ontwerpteams slechts beschikken over middelmatig talent.

We kunnen alleen hopen dat de Core 2 dermate goed is dat AMD failliet gaat, waardoor Intel alsnog de x86 vaarwel kan zeggen, en de Itanium kan brengen.

We kunnen beter hopen dat Intel failliet gaat zodat we van een bedrijf dat op schandalige wijze machtmisbruik pleegt af zijn en dat alle Intel-fanboys weer met beide benen op de grond komen, maar dat terzijde.

[Verwijderd]

Zou geen probleem zijn als er geen snellere x86s meer te koop waren (Intel zou ze niet meer maken in ieder geval). Dan heb je gewoon die keus niet, en moet je deze x86-emulatie accepteren.

Dan zouden ze alle processoren uit dit millenium en van ver daarvoor onmiddelijk van de markt moeten halen, want zo groot was het verschil in het begin. Beetje een domme redenatie dus.

Aangezien de x86 dan 'vast zou staan' op de snelste x86 ooit gemaakt, en de Itanium iedere paar maanden snellere steppings en revisies zou krijgen, zou de Itanium de x86 binnen de kortste keren inhalen, met emulatie en al.

Dit noemt men in vaktermen nou wishful thinking.

Als je dus de keus niet hebt, wordt het automatisch de Itanium, en is succes verzekerd.

Succes van de beurskoers van Intel wellicht, succes op computergebied in elk geval niet.

Zou Intel hetzelfde gedaan hebben? Nee, Intel heeft de Itanium ontwikkeld. Die heeft VEEL meer registers, en daarnaast ook een compleet andere architectuur met VEEL meer slimmigheden dan alleen 16 registertjes in een architectuur uit 1978 proppen.

Al deze zogenaamde "slimmigheden" (die vooral in jouw fantasie die kwalificatie verdienen) betalen zich anders niet uit in echte performance, hoe zou dat nou toch komen?

Jouw hele post (en trouwens ook andere posten daarvoor) getuigt van een enorme vooringenomenheid waardoor je niet meer naar de feiten kijkt. Verder vind ik jouw ideaalbeeld van het dwingen van mensen om over te stappen omdat je weigert de huidige technologie fatsoenlijk te blijven ondersteunen getuigen van een ongezond soort machtswellust. Beetje de communistische aanpak - als mensen toch alleen maar in een Trabant kunnen rijden gaan ze het ding vanzelf leren waarderen, en als ze vijf jaar op de wachtlijst moeten staan voordat ze hem aan kunnen schaffen zijn ze helemaal trots als dat ze dan uiteindelijk een keer gelukt is.

Je reacties op posten van anderen zijn net zo tendentieus en zitten vol met beweringen die nergens op slaan maar die misschien in jouw belevingswereld heel logisch lijken. Verder vind ik het erg grappig (maar ook wel weer triest) dat je anderen naïviteit verwijt, terwijl je eigen posts daar juist zo overduidelijk door gekenmerkt worden. Ook tekenend is dat jij het kunnen gebruiken van assembly als een probleem ziet, terwijl ieder weldenkend mens dit juist ziet als een nuttige (of misschien zelf essentiële) optie.

Ook zie ik dat jij heel erg duidelijk redeneert als een programmeur (die graag luistert naar marketingpraatjes) en niet als chip- of systeemontwerper. Opvallend is verder je blinde liefde voor machine-onafhankelijke code en JIT, terwijl iedereen weet dat je hiermee hooguit (bijna) dezelfde performance kunt halen als met native code, en dus per definitie nooit beter (uitgaande van perfecte optimalisatie). Natuurlijk wil iedereen graag zijn eigen expertisegebied promoten, maar hier vertroebelt het de discussie nogal.

Tot slot: De Titanium zonder T is helemaal niet zo vernieuwend als jij denkt, aangezien VLIW processoren allang in andere markten gebruikt worden, denk bijvoorbeeld aan de Philips TriMedia processor. Intel maakt vervolgens de fout om te denken dat VLIW ook voor general purpose processoren wel eens een goed idee zou kunnen zijn. Daarvoor zijn de compilers echter totaal ongeschikt, en dat hadden ze Intel allang kunnen vertellen bij Philips.

[Verwijderd]

Dan zouden ze alle processoren uit dit millenium en van ver daarvoor onmiddelijk van de markt moeten halen, want zo groot was het verschil in het begin. Beetje een domme redenatie dus.

Nee hoor, ik wist namelijk al lang dat die emulators met goede performance zouden komen (Intel wist dit natuurlijk ook). Beetje dom van mensen die dat niet inzagen.
Verder zijn die emulators er nu, dus wat is dom?

Succes van de beurskoers van Intel wellicht, succes op computergebied in elk geval niet.

Wat vind jij succes op computergebied dan?
x86 is dat sowieso niet, want die moet het toch al op veel gebieden afleggen tegen de Itanium en andere architecturen. Die heeft alleen commercieel succes.

Al deze zogenaamde "slimmigheden" (die vooral in jouw fantasie die kwalificatie verdienen) betalen zich anders niet uit in echte performance, hoe zou dat nou toch komen?

Niet? De Itanium heeft anders toch een redelijk aantal benchmark-records in handen.
Niet slecht voor een processor die maar een klein deel van de resources van Intel toegewezen krijgt, en in feite tegen de x86 moet vechten met z'n handen op de rug.

Jouw hele post (en trouwens ook andere posten daarvoor) getuigt van een enorme vooringenomenheid waardoor je niet meer naar de feiten kijkt.

Naar mijn mening is het eerder dat de x86-gebruikers zo vooringenomen zijn dat ze geen flauw benul hebben van wat er verder in de wereld te koop is, en eigenlijk niets van de Itanium afweten.
Dat maakt mij dus een van de weinigen die juist WEL naar de feiten kijkt. En die spreken op veel gevallen in het voordeel van de Itanium, zoals ik in mijn posts duidelijk probeerde te maken.
Als je het daar niet mee eens bent, hoor ik graag technische argumenten, in plaats van dit soort kinderachtige op-de-man spelen.

Verder vind ik jouw ideaalbeeld van het dwingen van mensen om over te stappen omdat je weigert de huidige technologie fatsoenlijk te blijven ondersteunen getuigen van een ongezond soort machtswellust. Beetje de communistische aanpak - als mensen toch alleen maar in een Trabant kunnen rijden gaan ze het ding vanzelf leren waarderen, en als ze vijf jaar op de wachtlijst moeten staan voordat ze hem aan kunnen schaffen zijn ze helemaal trots als dat ze dan uiteindelijk een keer gelukt is.

Scheve vergelijking, het punt is hier dat de meeste mensen niet weten wat de Itanium hen kan brengen. Het is absoluut geen 'Trabant'.
Een betere vergelijking zou een auto op waterstof zijn. Die is energiezuniger en milieuvriendelijker dan normale auto's, maar die wordt dus tegengehouden doordat mensen niet weten dat ze hem willen, en door de lobby van de olie-industrie.
In het openbaar vervoer wordt deze wel doorgedrukt, en zie je dus ook de voordelen ervan. Is dat slecht? Vind ik niet.

Opvallend is verder je blinde liefde voor machine-onafhankelijke code en JIT, terwijl iedereen weet dat je hiermee hooguit (bijna) dezelfde performance kunt halen als met native code, en dus per definitie nooit beter (uitgaande van perfecte optimalisatie).

Hierbij verwijs ik dan nogmaals naar het HP Dynamo-project, en verwacht ik bovendien een verontschuldiging van jouw kant...
Je zit enorm op de man te spelen... waarom, omdat je het niet met me eens bent? Geef dan technische argumenten... Je zit me alleen maar te beledigen.

Ook tekenend is dat jij het kunnen gebruiken van assembly als een probleem ziet, terwijl ieder weldenkend mens dit juist ziet als een nuttige (of misschien zelf essentiële) optie.

Je geeft zelf aan dat ik graag machine-onafhankelijke code zie. Ieder 'weldenkend mens' zal dan toch zien dat assembly hierin een probleem is? Dus wat wil je nou eigenlijk zeggen?

Tot slot: De Titanium zonder T is helemaal niet zo vernieuwend als jij denkt, aangezien VLIW processoren allang in andere markten gebruikt worden, denk bijvoorbeeld aan de Philips TriMedia processor.

Ik heb nergens beweerd dat de Itanium vernieuwend is, laat staan dat dat zou komen doordat het een VLIW-processor is. Ik heb grote moeite met de manier waarop je me loopt te beledigen en me woorden in de mond probeert te leggen.

Intel maakt vervolgens de fout om te denken dat VLIW ook voor general purpose processoren wel eens een goed idee zou kunnen zijn. Daarvoor zijn de compilers echter totaal ongeschikt, en dat hadden ze Intel allang kunnen vertellen bij Philips.

Dit is wederom onzin, want ook de Transmeta Crusoe is een VLIW-processor, en deze is wel redelijk succesvol, zelfs wanneer deze x86-emulatie draait.
Dat de processors van Philips niet geschikt zijn voor general purpose, zou best kunnen, maar dat zal dan meer liggen aan het ontwerp (en mogelijke toepassingsgebieden), en niet zozeer aan het feit dat ze VLIW zijn.

Je hebt eigenlijk weinig tot geen argumenten gegeven. Zou je niet liever mij willen overtuigen van mijn ongelijk (en van jouw gelijk), dan deze lange, maar nietszeggende post?
Ik hoor graag van jou hoe het zit met x86 vs Itanium en JIT etc, maar dan inhoudelijk, zoals ik in mijn posts ook getracht heb. Dus niet alleen vertellen wat je denkt, maar ook waarom je dat denkt.

[Verwijderd]

Stukje hierover gelezen in een duits blad, en dat klopt idd.

[Terracotta]

De reden waarom niemand overstapt is gewoon software. Het is dezelfde reden als waarom niemand overstapt op Linux, de commerciele en gekende software draait er niet op dus gaan de mensen niet proberen iets anders te gebruiken. (Probeer al maar eens in 64-bit Linux te werken, je komt gegarandeerd van alles tegen dat er niet voor bestaat omdat de (proprietary-)software provider geen versie voor jouw architectuur heeft). Kijk al maar eens hoe lang het heeft geduurd voor windows op 64-bit werkte dat maar een uitbreiding was op de gekende x86-instrcutieset. Dit is trouwens nog een nadeel van closed source maar dat is off-topic.

Nu ja je hebt wel gelijk dat de miljarden dollars die in de x86 structuur zijn gekropen er ook voor zorgen dat hij uiteindelijk de meest effectieve structuur is op dit moment (minst last van warmte), voor de mainstream chip dan (ppc werd te warm, hoe het met de ultrasparc zit weet ik niet). Je kan het vergelijken met waarom de wankelmotor het nooit gehaald heeft: de 'gewone' motor was al zoveel verder ontwikkeld dat die veel zuiniger was, ook al heeft de wankelmotor theoretisch een beter rendement en nog tal van technische voordelen.

[mashell]

eens in 64-bit Linux te werken, je komt gegarandeerd van alles tegen dat er niet voor bestaat omdat de (proprietary-)software provider geen versie voor jouw architectuur heeft).

Als je alles bij open source houdt en lekker ouderwets zelf gaat zitten compileren is dat probleem er natuurlijk niet.

[arjankoole]

(Probeer al maar eens in 64-bit Linux te werken, je komt gegarandeerd van alles tegen dat er niet voor bestaat omdat de (proprietary-)software provider geen versie voor jouw architectuur heeft).

of juist wel, IBM brengt bijvoorbeeld DB2 netjes in 64-bit versie uit. toch ook niet de eerste de beste.

[Wouter Tinus]

De reden waarom niemand overstapt is gewoon software.

Met een fatsoenlijke emulator en een groot genoeg prestatieverschil hoeft dat helemaal geen punt te zijn. Er is bijvoorbeeld een periode geweest waarin het emuleren van x86 op een Alpha sneller was dan x86 zelf. Zoiets extreems is echter niet eens nodig: als IA64 of welk ander 'nieuw' iets genoeg (prestatie)voordeel biedt is een redelijke backwards compatibiliteit al goed genoeg om de klant tevreden te houden. Zie bijvoorbeeld hoe Apple nu van PowerPC naar x86 gaat, daar klaagt niemand over.

[Verwijderd]

De software wordt juist steeds minder een probleem. Neem bijvoorbeeld alle moderne MS software wordt in .Net ontwikkeld. Dit werkt met een Intermediate Laguage die in een runtime-compiler wordt uitgevoerd. (In feite hoe Perl vroeger al werkte).

Dus je hebt dan alleen nog een aparte versie van het .net framework nodig. De software zelf hoeft niet speciaal gecompileerd te worden

[OpenMinded]

@Terracotta
...reden waarom niemand overstapt op Linux...
Wat lul je nou, de afgelopen jaren is het marktaandeel voor Linux sterk gestegen, dus wie is niemand?
@all
Het mooie aan Linux en Open source in het algemeen is, is dat de code openbaar is.
Die kan dus gemakkelijk geport worden naar andere architecturen.
Voor de meeste software is het het aanpassen van library aanroepen.
Daarnaast is er in Linux ook een compatibility 32-bit library pacjk, waardoor veel 32 bit apps op een amd64 werken.
Overigens komt dat ook doordat de AMD64 in x86 compatibility mode kan draaien, dus hoeft er minder gesleuteld te worden.

[i-chat]

noem dan ook 's een x64 office suite
want OpenOffice bijv. komt (volgens de geruchten) niet eerder met een x64 compatible code dan v.2.5 of 3.0

[Verwijderd]

De software wordt juist steeds minder een probleem. Neem bijvoorbeeld alle moderne MS software wordt in .Net ontwikkeld. Dit werkt met een Intermediate Laguage die in een runtime-compiler wordt uitgevoerd. (In feite hoe Perl vroeger al werkte).

De software blijft een probleem, want .Net is zeker nog niet voor alle platformen geschikt gemaakt en het is (zeker bij Microsoft zelf) niet echt populair. Java bestaat ook al een hele tijd en je ziet dat java de markt ook niet heeft veroverd.

De meeste code zal gewoon dicht bij de processor worden geschreven vanwege de betere prestaties en vast nog tal van andere redenen.

Maar persoonlijk juich ik .Net wel toe (programmeer C#), tis alleen jammer dat het zo weinig wordt gebruikt bij echt grote programma's.

[Verwijderd]

De software blijft een probleem, want .Net is zeker nog niet voor alle platformen geschikt gemaakt

Dat is niet zo relevant, aangezien het geschikt is voor het platform dat op meer dan 95% van alle computers draait.

[Verwijderd]

Hoor ik daar iemand Betamax roepen?

Gebeurt vaker dat een technisch beter platform het aflegt tegen een op andere vlakken superieur ontwerp.

[YoMarK]

DB2 is ook een slecht voorbeeld. die draait al minimaal 5 jaar op 64bits hardware op b.v. de As/400 systemen.

[Stevendefeij]

@Guru Evi

QUOTE: maar eenmaal je de consument kunt laten overschakelen is het toch een goede stap (zie Apple).
/QUOTE.

Ja alleen Apple is juist van Risc naar Cisc overgestapt.
Met het invoeren van de Intel processor i.p.v. de IBM Powers.
Precies het tegenovergestelde van wat jij zegt en om de pure reden van marketing (Wij kunnnen Windows draaien)

Helaas is Windows belangrijker dan overstappen op een andere architectuur, voor mij niet, voor jou misschien niet
Maar voor de meeste mensen wel.

De Xbox is overigens wel een voorbeeld van het overstappen van Cisc naar RISC.
Celeron > PowerPC

Dus ik ben bang dat we nog wel een tijdje met de CISC > RISC vertaling zitten.

De dag dat we van x86, Windows en Spyware af zijn is de dag dat ik gelukkig ben!

[0rbit]

Voor het uitvoeren van multipliers in logica is er een techniek die alvast de mogelijkheden voor het volgende groepje bits uitrekent. Dat heette geloof ik "carry look ahead".

Kan het niet zijn dat AMD iets soortgelijks probeert te doen? Dat je bij iedere branch de ene core de instructies voor waarde 1 en de andere voor waarde 0 laat uitvoeren, zodat je later, als je weet welke kant je op had gemoeten de resultaten van die instructies al klaar hebt? Vervolgens breek je de ene thread af en laat je die core alvast de code van de volgende mogelijk branch uitvoeren. Dit is eigenlijk een soort scout alleen gemakkelijker te implementeren dan een scout die de code "begrijpt".

Ik vind het maar een vreemd verschijnsel en kan er eigenlijk niet echt veel kaas van maken. Misschien is het wel een hoop gebakken lucht

[Wouter Tinus]

Een complete branch uitbesteden aan een andere core is alleen maar moeilijker dan losse instructies. Ga maar na: je moet alles kunnen doen wat je voor losse micro-ops moet kunnen, maar daar bovenop ook nog eens op hoger niveau dingen gaan bijhouden en coordineren.

Dat wil overigens niet zeggen dat het uitrekenen van twee branches tegelijk geen goed idee kan zijn: de Itanium doet het (binnen een core) en dat levert in sommige gevallen aardige winsten op.

[H!GHGuY]

ik dacht toch ooit gelezen te hebben dat ook de P4 meerdere branches in de pipeline stak. Dan wel zo dat de even instructies de ene branch waren en de oneven instructies de andere branch. Wanneer de uitkomst van de branch dan uiteindelijk gekend was, konden de even of oneven instructies uit de pipeline geflusht worden en verloor je slechts 50% terwijl je bij een branch misprediction de volle 100% zou verliezen.
Waarschijnlijk zou dit echter niet de enige toegepaste techniek zijn

[needless to say]

Mja, er zijn maar weinig hedendaagse processoren die bij een verkeerde branch prediction de hele pijplijn doorlopen. Je verliest dus geen 100% Branch prediction wordt ook vaak toegepast in cycles waar anders een unit in de pipeline idle zou draaien.

[Verwijderd]

Dan wel zo dat de even instructies de ene branch waren en de oneven instructies de andere branch.

Dat zou ik wel erg vreemd vinden... Bij een lus die bv 10 keer doorlopen wordt, zal een simpele branchpredictor met geschiedenisvoorspelling en 2-bits saturerende voorspeller al 9 van de 10 keer de sprong juist voorspellen en dus 90% efficiëntie scoren, terwijl de implementatie van Intel dan slechts 50% scoort.

Heb je daar bronnen van?

[jp]

Als je bij het compileren al weet dat hij 10x uitgevoerd gaat worden, sloopt de compiler de lus er gewoo uit.

[Verwijderd]

Mja, er zijn maar weinig hedendaagse processoren die bij een verkeerde branch prediction de hele pijplijn doorlopen.

Zeker de P4 niet, die gedecodeerde instructies in z'n tracecache opslaat.
Decoderen wordt dus maar eenmalig gedaan, zolang het in de cache past.

[Ralph Smeets]

Die slide van AMD geeft volgens mij toch aan waar AMD naartoe wilt in de toekomst. Neem bijvoorbeeld de titel:
"Multi-threading done right". Met andere woorden, AMD wil met deze slide laten zien wat de beste manier van multi-threading is. Dan zie je daarna vier gebieden, waarbij je de beste prestaties met de hoogste dichtheid van transistors kunt bereiken met Cluster-based Multi-threading. Daar zet AMD dan ook nog even bij dat er met ongeveer 50% meer oppervlakte er tot maar liefst 80% betere prestaties geboekt kunnen worden. Iets dat normaal alleen min of meer mogelijk is met een verdubbeling van het aantal cores, wat neerkomt op 100% meer oppervlakte.

Ik denk dat we CMT in de toekomst gaan zien. Ik denk namelijk niet dat het een technologie is die te moeilijk is te implementeren. Veel dingen die voor CMT nodig zijn, zitten immers al verwerkt in processors. Neem bijvoorbeeld zoiets als out-of-order execution. Dat werkt door bij te houden waar een instructie vandaan komt. Normaal gesproken gebeurt dit door de instructie een tag mee te geven voordat hij richting een van de execution units gaat, om als deze uitgevoerd is, de tag weer te lezen. Voeg voor een dualcore-processor een bit toe aan dit veld en je kunt nagaan welke core deze instructie liet uitvoeren. Het enige wat er dan nog moet gebeuren is op het gebied van de instructionshedulars die van elkaar moeten welke instructieunit waar vrij is. Die functionaliteit zit al in elke oooe-processor ingebouwd. Het enige dat er gedaan moet worden is deze tabel delen. Dan is er de re-order buffer, waar de instructie in terrecht komt als deze is uitgevoerd. Tja, daar geld hetzelfde verhaal voor. Blijft er over de overige controlle logica, wat te doen als een instructie iets dat wat niet de bedoeling is. Wat als er een interrupt is, enzovoort, enzovoort. Tja, ik zie niet in waarom dat zo veel complexer zou moeten zijn. Je kunt immers gewoon gebruik maken van de twee aanwezige controllers en gezien elke instructie van een logische vlag is voorzien om bij te houden bij welke core deze hoort, kunnen alle instructies van een core zonder veel problemen worden gewist.

Bovenstaande wil echter niet zeggen dat ik denk dat CMT in de K8L of in de K10 zit. Als ik alleen al naar de plaatjes kijk van beide processors, zie ik nog steeds een ontwerp waarbij er gewoon twee cores zitten. Terwijl er bij CMT er eigenlijk geen sprake meer is van twee apparte cores (indien goed uitgevoerd). Zoals de naam al aangeeft kan een processor met CMT execution units clusteren om zo een soort van virtuele processor te creëren.

[elteck]

Hyperthreading (uitvinding van AMD) was in feite twee instructie pipe lines, die beide van dezelfde core gebruik maakte. Voordeel was er dan te behalen, wanneer de ene een andere executie eenheid nodig had dan de andere, zodat ze gelijkteidig uitgevoerd konden worden.

Stel nu dat je dual core, als single core implementeerd, met een dubbel aantal executie eenheden. In hyperthreading mode heb je dan een echte dual, terwijl in single je heel veel executie eenheden to je beschikking hebt en kunt gaan clusteren. In feite is het verschil tussen Intel's Conroe en AMD K8 ook het aantal executie eenheden.

[Carbon]

Hyperthreading (uitvinding van AMD)

Hyperthreading ofwel SMT (Simultaneous Multi Threading) is uitgevonden door IBM (1968) De eerste CPU met SMT is ontwikkeld door DEC maar deze heeft nooit het commerciële stadium bereikt.

[Vorlon]

Hmm, dat is op zich niet eens zo'n slecht idee. In een single core alles dubbel uitvoeren. Dat zou wel veel glue-logic vereisen om alle units met elkaar te verknopen, maar het is dan wel flexibeler dan twee gescheiden cores met één memorycontroller.

Als ze straks met een quad core komen is dit misschien wel efficienter dan nu van single core naar dual core. Ik heb nu liever twee aparte cores dan één enkele om het simpele feit dat je dan de os eigen threads kan scheiden van de applicatie threads. Als er nu een applicatie 100% cpu trekt loopt je halve windows/linux vast.

Vb: Als ik op mijn werk een vastlopende simulatie heb en ik draai het lokaal (P4 3.2GHz met Redhat linux) dan loopt half X ook vast totdat ik de bokkende applicatie afschiet. Als ik dit zelfde krijg op een van de compute servers (4x Opteron 850 met Redhat linux) dan gebeurt er niets behalve dat 1 process 25% cpu power trekt en verder weinig doet. De collega's die ook op die server werken merken er ook niet of nauwelijks iets van.

Dus ik wil eigenlijk wel dual core houden. Als we quad cores krijgen is reverse multitreading misschien wel handig.

[elteck]

Ik geloof dat je op het zelfde systeem werkt als ik. Ik gebruik Cadance op inderdaad Redhat Linux. Mijn PC is een dual processor gelukkig.

[Verwijderd]

Het lijkt mij ook mogelijk om de twee instructiestromen aan de twee cores aan te bieden, op 'synchrone' wijze. Wanneer een thread een tijd moet wachten (kan honderden cycli zijn voor RAM-toegang), kunnen instructies uit de tweede thread starten en men bijhouden welke reeds op de tweede core gestart zijn. Uiteindelijk is er toch een 'retirement buffer' die garandeert dat de uitvoer correct is. Wanneer instructie selectie, register sets en retirement buffer van de twee cores dicht naast elkaar (centraal) liggen is intercommunicatie niet zo'n probleem en kunnen de execution units zelfs een eind van elkaar liggen.

Da's inderdaad wel iets dat pas bij K10 ten vroegste verwacht kan worden.

[Wouter Tinus]

Het lijkt mij ook mogelijk om de twee instructiestromen aan de twee cores aan te bieden, op 'synchrone' wijze. Wanneer een thread een tijd moet wachten (kan honderden cycli zijn voor RAM-toegang), kunnen instructies uit de tweede thread starten

Ik zie niet in waarom je hier twee cores (of synchrone threads) voor nodig zou hebben. Wat je beschrijft - andere instructies uitvoeren terwijl er gewacht wordt op iets - is het basisprincipe van OoOE (out of order execution) en dat wordt al sinds de Pentium Pro gebruikt.

[Verwijderd]

Out-of-order execution kan enkel een paar tientallen instructies voorop lopen. Vaak zijn er al eerder afhankelijkheden waardoor het beperkt is tot een klein aantal instructies. Voor een RAM-toegang gaan er dus nog zeer veel klokcycli verloren.

Niet zo bij (Reverse) Hyper-Threading. Tijdens het lange wachten kan de core gebruikt worden om instructies van een andere thread uit te voeren.

[Wouter Tinus]

Wat je nu beschrijft is normaal HyperThreading (SMT) of SoEMT (switch-on-event multithreading), geen CMT. Als de OoO-engine van één core keer geen onhankelijke instructies meer kan vinden in een bepaalde thread, zal een tweede core niet op magische wijze ineens wel verder kunnen in dezelfde thread c.q. een kopie daarvan. Hoe verder je vooruit loopt, hoe lager de kans is dat je iets vindt waarvan je zeker kunt zijn dat het onafhankelijk is. Speculatief multithreaden is nog wel een interessant onderzoeksgebied, maar ik zou wel m'n petje afdoen voor AMD als ze dat al werkend hebben gekregen .

[Verwijderd]

Misschien mis ik iets, maar zou het software-matig uberhaupt niet mogelijk kunnen zijn om gegeven x86 code dat zich op 1 core richt, een geoptimalizeerde versie te genereren dat zich wel op meerdere core's richt ?

Er bestaan genoeg assembly-code-provers die tijdelijke referentiele transpariteit kunnen aantonen van stukjes code. Heel vaak worden er bepaalde commando's serieel gegeven die onafhankelijk zijn van elkaar.

Ik moet toegeven dat ik niet bekend met het bestaan van een tool die je gegeven machiene code een geoptimalizeerdere variant oplevert, maar onmogelijk is het niet.

Alleen zal de winst niet zo groot zijn als je mag hopen omdat de volgorde van berekening alleen irrelevent is tussen momenten van input/output. (stack en geheugen dus niet meegerekent). Dus de aanroep van een functie uit een .dll of ander soortig shared-object zal toch serieel moeten gebeuren (helaas).

Het probleem is dan ook niet zo zeer de machiene code, maar de achterliggende OS-specifieke infrastructuur die slimmer moeten worden.

Een intressant paradigma zijn bijvoorbeeld de functioneel-reactieve programmeertalen. Dat zijn object-georienteerde talen, waar elk object _per definitie_ in z'n eigen thread draait. Er wordt hier onderscheid gemaakt tussen de void-achtige methode-aanroepen en de methode-aanroepen waarvan je een resultaat wilt hebben. De void-achtige methode-aanroepen gaan meteen verder met de executie van hun eigen thread, terwijl de methode-aanroepen die geen void terug-geven, de threads verplicht synchronizeren. Het is een hele natuurlijke manier om concurrency en OOP te integregen, maar wordt van nature niet door de c/c++ calling conventie ondersteund.

Aan de andere kant, met genoeg core's zou het wel eens handig kunnen zijn om maar gewoon te gaan zitten emuleren en op die manier concurrency af te dwingen. Je zou dan kunnen denken aan een stack waarvan het opvragen van bepaalde positie op de stack ervoor zorgt dat je wacht tot ze ingevult zijn door de andere thread. Stel je voor: er is een berekening die zijn resultaat op de stack zet. Deze berekening laat je door een andere core uitvoeren en zelf ga je verder met de code na deze berekening. Kom je nu een pop-instructie tegen, dan kijk je of de andere thread klaar is; zoniet: dan wacht je tot het wel zo is. Er is wel een behoorlijke overhead qua administratie op deze manier, maar like I said: met genoeg core's en domme sequentiele code, kan dit toch nog een snelheids-winst opleveren.

[Verwijderd]

Wat mij opviel aan de review is dat ik de tekst bij de AMD slide en de slide zelf niet kan rijmen.

Als ik naar de slide kijk lijkt deze te zeggen dat cluster-based multi-threading de grootste efficiency en performance geeft. Verder wordt er in een aparte box ook nog eens aangegeven dat er 80% meer doorzet is bij een 50% groter chip-oppervlak. Dit lijkt mij erop te duiden dat AMD de toehoorder wil overtuigen dat dit de beste weg is.

In de T.net tekst wordt echter gesuggereerd dat AMD deze weg waarschijnlijk niet gaat bewandelen.

(ik zeg dus niet dat de argumenten van T.net (om niet voor cl.based MT te gaan) niet kloppen maar wel dat mijns insziens de 2 genoemde zaken enigszins in tegenspraak lijken)

[Verwijderd]

Omgekeerde logica,

Beschouw even de eerste verklaring, core's die elkaars execution units delen. Laten we deze verklaring is anders uitleggen, stel, de pipeline voor de execution units (fetch en decode stages), wordt verdubbeld, de execution units hebben vanzichzelf al een soort queue in de vorm van schedulers, en zouden dus instructies van meerdere Front-End pipelines aan kunnen.

In dit geval heeft een single threaded applicatie het volle scala aan execution units te benutten, en multithreaded applicaties (die daar theorethisch toch minder mee zouden kunnen) hebben het voordeel van de extra frontend om instructies te fetchen en decoden.

Het zou dus een vele kleinere en efficientere manier van multi core processing zijn.

[TD-er]

Het lijkt er dus op dat je die techniek kunt aan en uitzetten in de BIOS.
Zou je dan, met die techniek aan, bij SMT-geoptimaliseerde programma's, of software die met een geoptimaliseerde compiler gemaakt is een vermindering in de performance kunnen verwachten?
Zeker als ze de 2e core inderdaad gaan gebruiken om een veel betere branchprediction te doen, is die core in feite niet te gebruiken voor andere threads.

Dus het lijkt erop dat dat soort dingen dus op een enkele thread best wel veel voordeel kunnen bieden, maar in een druk systeem pas na gebruik van >2 cores voordeel geven. (meestal zijn er 2 keuzes in de branchprediction, dus met meer dan 2 cores mee laten lopen krijg je waarschijnlijk niet echt veel winst)

[needless to say]

tjah, ten opzichte van je besturingssysteem is het precies maar 1 core. Je zit dus direct opgescheept met al de nadelen van een single core, namelijk een "serieuze" vermindering van de performance bij meerdere simultaan lopende threads. De processor zal uiteraard wel sneller lopen dan een gewone single core, maar trager dan wanneer de technologie uit zou staan.

Net zoals met Hyperthreading zal het weer een verhaal worden van: voor het ene programma brengt het een snelheirdwinst, voor het ander programma snelheidsverlies.

Een soort hybride versie van de techniek, waarbij je zowel meerdere threads tegelijk op de verschillende cores kunt laten toepassen, maar toch die omgekeerde hyperthreading wanneer je 1 thread hebt die veel CPU-power vraagt, zou in dit geval ideaal zijn.

Bvb: Toch multicore blijven voor het besturingssysteem, maar wanneer de tweede core veel idlet en de eerste constant werkt, de eerste core cycle-stealing laten doen bij de tweede core. Via een systeem zoals interrupts.

Dit zal uiteraard niet makkelijk te implementeren zijn, aangezien de tweede core op voorhand moet weten wanneer hij gaat idlen om een instructie over te nemen van de eerste core (de instructie ophalen neemt ook minstns 1 cycle in beslag), terwijl die instructie ook nog geen afhankelijkheden mag hebben met de instructies die op dat moment bij de eerste core in de pipe zitten.

Ik veronderstel dat de L2 data cache van elke core ook door de andere core aangesproken kan worden?

[TweakerNummer]

Een of andere website (welke kan ik je niet zeggen op het moment) claimde dat AMD de techniek zo ontworpen heeft dat deze automatisch in of uit geschakeld zal worden.

Edit: dit was helaas de inquirer; http://www.theinquirer.net/?article=32589

AMDs Reverse-HT is a dynamic technology, and with Microsoft's Windows update and a new processor driver, the driver will copy the graphics drivers of today's 3D accelerators. The driver will detect the app, see if it is multithreaded or not and turn the ReverseHT on, or leave it off.

[TD-er]

Hmm dat zou inhouden dat die driver dus vrij groot zal zijn.
Niet echt een ideale oplossing.
Het zou makkelijker zijn als de processor zou kunnen detecteren of er een proces draait wat nogal veel branch-mispredicties heeft en dan alsnog iets in de driver kan triggeren om die 2e core erbij te betrekken.
Op die manier lijkt me dat je een goede balans krijgt tussen multi-core gebruik en toch die single-thread kunnen versnellen.

[Verwijderd]

Wat the Inquirer beweert kan geloof ik niet.
Want als er op de andere core een ander programma loopt (wat iig bij Windows altijd zo is (niet-actieve systeemprocessen)) dan wordt dat programma gewoon afgebroken. Wat bijna onherroepelijk tot een crash zal leiden, aangezien geen enkele kernel er op berekend zal zijn dat de processor bedenkt dat ie zn ene core maar even voor iets anders gaat gebruiken.

[TD-er]

Het is in dit geval toch een driver die dit op processor-niveau regelt, dus dan zou die 2e core toch gewoon iets langer erover kunnen doen, over het proces wat je OS naar die core stuurt?
Lijkt me niet echt een probleem.

[Verwijderd]

Toch multicore blijven voor het besturingssysteem, maar wanneer de tweede core veel idlet en de eerste constant werkt, de eerste core cycle-stealing laten doen bij de tweede core. Via een systeem zoals interrupts.

Dat zou dan willen zeggen dat je telkens als je een interrupt doet, je alle registers voor algemeen gebruik op de stapel zou moeten zetten, om het andere proces niet te verstoren.
Dat is onaanvaardbaar: de cycli die je eventueel zou winnen verlies je weer doordat je die registers moet opslaan.

edit:
Geen idee, maar mss heeft het te maken met het feit dat de Itanium enorm veel registers heeft. Mss worden die registers dan verdeeld onder de verschillende branches.

[needless to say]

true, ik was die registers even vergeten . Hoe wordt dat dan bij de Itanium opgelost waarbij zogezegd verschillende cores verschillende branches zouden uitvoeren?(zie reacties hierboven) Daar zit je dan toch met hetzelfde probleem?

[Verwijderd]

Hoe wordt dat dan bij de Itanium opgelost waarbij zogezegd verschillende cores verschillende branches zouden uitvoeren?(zie reacties hierboven) Daar zit je dan toch met hetzelfde probleem?

Voor zover ik weet, worden die branches niet over verschillende *cores* verdeeld, maar over verschillende *pipelines*.
Het blijft dus binnen dezelfde core, en de execution units worden gewoon gedeeld tussen de twee takken van de conditionele jump. Eigenlijk is het ongeveer hetzelfde idee als hyperthreading, maar dan zijn de 'threads' dus de twee takken. Deze worden naast/door elkaar verwerkt door een enkele core.

[Tenaya]

De broncode