Dit is zeker niet waar.
Wel waar, aangezien praktisch gezien beide is.
Athlon XP is FSB zwaar afgeknepen en de klok is laag dus kan ook minder per seconde verwerken bij gelijke core, maar ja dat zijn ze niet dus dat architektuur verschil speeld ook mee wat je hier onder dus verteld.
Wanneer je dieper in de ontwerpen van beide processoren gaat kijken zul je zien dat de Athlon gewoon veel minder behoefte heeft aan grote geheugenbandbreedte:
Dan kan zijn maar dan is ie nog altijd FSB afgeknepen FSB is een factor 2 minder de Klok 1,5 de IPC 1,5 dus zeker sterk fsb afgeknepen.
Dan hangt het ook af welke app je gebruikt want de membandbreete is daar ook erg variable van niks tot veel.
Alleen voor de P4 wordt er meer geoptimaliseerd en in stream proscessing is ie een kei vooral als de code licht is Q3A is bijvoorbeeld erg memory optimised.
De Pentium 4 heeft een hele lange pipeline. Hier is voor gekozen om de kloksnelheid makkelijk ophoog te kunnen gooien (de instructies worden in simpelweg kleinere 'brokjes' (uOps) gesplitst dan bij de Athlon, maar hierdoor heb je wel meer brokjes voor één instructie. Omdat één brokje dus minder 'werk' voorstelt neemt de tijd per brokje dus af: de kloksnelheid is dus makkelijker omhoog te gooien).
Ik dacht dat het eerder was dat de instrukties in kleine stappen wordt verwerkt dus in 20 snelle evenredige kleine stappen voor de goede Clock schaling daar aan kleven zoals gezegt nadelen aan.
Deze lange pipeline heeft echter een heel groot nadeel: mocht er sprake zijn van een zogenaamde 'Branch mispredict' (wanneer de CPU een vergelijking doet en elk van beide antwoorden een andere volgende instructie geeft, zal de Branch Predictor gaan 'gokken' welk antwoord het meest waarschijnlijk zal zijn. Heeft hij fout gegokt dan heet dat een Branch mispredict) dan zal de hele pipeline leeg gegooid moeten worden en moet deze opnieuw gevuld worden (want de pipeline was gevuld met instructies voor het 'verkeerde antwoord'). Dit kost dus relatief veel tijd. Het ontwerp van de Pentium 4 is er dan ook helemaal op gericht om ervoor te zorgen dat het percentage mispredicts zo klein mogelijk blijft (willen ze bij AMD ook hoor ).
De Branch Predictor van Intel's Pentium 4 is echter een stuk beter en geavanceerder dan die van de Athlon.
Dat kan zijn maar het is meer iNtels P4 performance is te zwaar afhankelijk van zijn branche predictions door de keuze van die 20stages en hog clock en lage werkelijk klok dus multyplier verhouding..
En zo goed is ie niet want oude code doet ie slecht want predictie is ook beperkt aangezien bepaalde code onmogelijk te predicten valt en andere weer rete goed. iNTel compilers helpen hier een handje dus geoptimaliseerde code helpt een handje.
Heb 'n keer 'n oude bench gezien van erg moeilijk te predicte code en toen versloeg 'n Duron de toen snelste P4 gelukkig voor iNtel wordt deze extreme code zelden gebruikt. Maar de Applicaties schommelen tussen die twee uitersten.
Om een Branch Predictor zo goed mogelijk z'n werk te laten doen moet ie "ver vooruit kunnen kijken". Hij moet dus snel grote delen van het geheugen kunnen 'bekijken'.
Heb je het hier over de dataprefets want branch prediction slaat op sprong gokken.dus het gaat hie rom de goede code pad goed te raden.
Die branch predictor werkt samen met de data prefetch en de cache. Goed voorspelbare code is bij voorhanden al in de cache
Dat is de belangrijkste reden voor het feit dat de Pentium 4 zoveel meer voordeel heeft bij een hoge geheugenbandbreedte: z'n Branch Predictor werkt dan beter en hij hoeft dus minder vaak kostbare tijd te verspillen aan het vullen van die lange pipeline.
Branch predictie heeft niks direct met membandbreedte te maken.
maar met if then else constructische in de code gokt het voorwerken dus de then {}of the else{} verkeerd gegok 'n hoop werk voor niets wat dus opnieuw moet en das dde performance hit.
Membandbreedte is 'n data blok laden en daar routines op laten die weinig clock cyclie eisen dus snel afwerkbare sSE2 instruksies dan kan je veel data aanslepen en als dat stream is zoals video proscesing met sSE2 dan benut je de de membandbreedte goed. dus veel data met lichte bewerkingen genereerd bandbreedte gebruik zware code vereist geen bandbreedte maar juist FPU of SSE2 kracht.
ja AMD heeft er ook last van daarom heeft AMD ook die technieken en dus ook branch prediktion maar de performance hit is daar geringer en vanaf palomino ook data prefetch
DAt de iNtel meer memmory bandbreedte hongerig is komt doordat hun ALU op dubbele Clock loopt en de FPU en SSE2 unit lopen ook op een veel hogere clock dus kunnen dan ook per seconde meer streamed code/data verwerken
Dus zodra er een memory hongige app gebruikt wordt is de P4 in zijn nopjes.
Vooral als je kijkt dat iNtel de Bandbreedte als grote plus heeft met een hoog geclockte core en nog kan AMD hun bij blijven dat houd in dat er ook evenredige zwakke isues zijn en dan kan je branch prediction ophemelen maar het kan niet toveren alleen de schade beperken door het goed gohk ratie optimaal te maken..
Het huidige ontwerp van de Athlon (ook van de Athlon 64) heeft hier veel minder baat bij. Ook al zou een Athlon procentueel gezien evenveel mispredicts hebben als een Pentium 4, dan nog maakt het voor een Athlon minder uit aangezien zijn pipeline slechts uit de helft van het aantal stages bestaat. Het opnieuw vullen kost een Athlon dus maar de helft van het aantal klokslagen dan wat een P4 nodig heeft. Maak je een Branch Predictor beter (door oa grotere geheugenbandbreedte),
Branche predictor maak je beter door het algoritme te verbeteren of hulp vanuit de compiler band breedte doet hier niks aan ook kunnen de coders er branch intensieve kode vermijden door een meer streamed methode te gebruiken dus het probleem oplossen met in gedachte de P4 streamed eigenschap
De branch hit verbeter je door de latenchy te verkleinen zoals die ondie mem controler of een evenredige hoge echte mem clock nu is dat 200Mhz QDR daar is de latency op gebaseerd maar kwa bandbreedte pompt ie viermaal
dan zie je dat een P4 daar veel meer voordeel uit zal halen. Dit bewijst ook maar weer eens dat de Netburst-architectuur van de Pentium 4 nog helemaal niet aan z'n max zit.
Je zit die netburst wel erg op te hemelen maar uh als dat zo'n wonder techniek is dan moet ie elke athlon dus TB tot hammer wegblazen dat doet ie niet dus er is iets erg mis met iNtels keuze en ik zie het zo iNtel heeft voor hoge Clock schaling gekozen vanwege de Klok minden desktop markt. intel speeld daar op in en das een goede zet alleen de techniek die daarvoor gebruikt wordt kleven ook grote nadelen aan die neit in spects te zien is want het is de bedoeling om de clock te verhogen en eventueel ook de IPC
Dus die 20 stages hebben maar een doel Klok en de nadelen voor lief genomen. Marketing kompenseerd dat wat dus ook gebeurt.
De IPC van deze architectuur gaat dan ook nog steeds met kleine beetjes omhoog...
Tja dat klopt iNTel staat niet stil en bied hun CPU ook de hoge FSB die het nodig heeft en introduceerd technieken die alleen hun CPU hebben zoals HT het iNTel platform ondersteund de CPU zeer goed en gaat snel vooruit.
AMD blijft hier op achter doordat hun Fabs en R&D centers kleiner zijn zijn hebben ook veel langere vertragingen en hierdoor loopt intel makkelijker vooruit niet door netburst maar doordat AMD problemen heeft hun roadmap waar te maken.
Als hun netburst architektuur zo supper is dan had AMD nooit die in het verleden kunnen overtreffen maar zoals je weet is dat niet zo dus heb ik dus sterk mijn bedenkingen aan die netburst techniek.
enige voordeel wat ze hebben is dat ze als markt leider makkelijk eenzijdige feature de markt in pushen wat hun concurentie postistie versterkt zoals HT en SSE2 SSE3 waarmee AMD minstens 'n core cylus achter op mee loopt of neit mag implementeren.
Sorry dat t zo'n lang verhaal is geworden, maar ik wilde het nu eens helemaal uitleggen...