AMD voegt sse4a toe aan Barcelona-core

In een technische handleiding voor programmeurs heeft AMD onthuld dat de Barcelona-core sse4a ondersteunt, vier nieuwe instructies voor multimedia die zoals het er nu naar uit ziet exclusief door Phenom ondersteund zullen worden.

Omdat er nu al vier verschillende instructiesets zijn die - al dan niet terecht - sse4 genoemd worden, wordt het hoogste tijd voor een overzicht. Het begon ruim een jaar geleden, toen het verhaal rondging dat Intels nieuwe architectuur ondersteuning voor sse4 zou krijgen. Omdat dit niet alleen in het nieuws kwam maar later ook door (online) winkels en zelfs systeeminfo-software werd overgenomen is dit een vrij hardnekkige mythe geworden, maar er is niets van waar: er zijn wel nieuwe instructies aanwezig in de Core 2 Duo, maar die heten ssse3, of 'supplemental sse3'.

De tweede bron van verwarring is Intel: in september 2006 presenteerde het sse4 alsof het één instructieset was, maar vorig maand tijdens het Developer Forum in Beijing bleek dat die uitgesmeerd zal worden over twee chipgeneraties, waar ongeveer een jaar tussen zit: Penryn krijgt sse4.1 (maar dat wordt ook wel kaal 'sse4' genoemd) en zijn opvolger Nehalem sse4.2. En nu komt AMD dus ook nog eens aanzetten met sse4a, dat niets gemeen heeft met Intels versie.

Naam	Jaar	Instructies	Intel	AMD	Doel
SSE	1999	70	Pentium III	Athlon XP	Floatingpoint-aanvulling op MMX
SSE2	2001	144	Pentium 4	Athlon 64	Volledige vervanging MMX
SSE3	2004	13	Prescott	Venice	Kleine toevoeging voor 3d/dsp
SSSE3	2006	32	Conroe		Complexe getallen, signaalverwerking
SSE4a	2007	4		Barcelona	Datatypeconversie
SSE4(.1)	2007	47	Penryn		Dot product, datatypeconversie
SSE4.2	2008	7	Nehalem		Strings, bitcount, crc32

Om het nog leuker te maken ondersteunt Barcelona wel alvast één van de zeven instructies uit sse4.2, maar die geeft AMD weer een hele andere naam: ABM. Het is goed mogelijk dat de concurrenten in de toekomst meer van elkaars instructies gaan ondersteunen, maar de situatie zal de komende jaren ingewikkeld blijven. Gelukkig is het niet allemaal voor niets: puur dankzij de experimentele ondersteuning voor sse4(.1) blijkt DivX 44% sneller te draaien op een 3,2GHz Penryn.

Reacties (57)

[ErnstH]

Volgens mij staat er toch echt in de tekst onder het grafiekje dat slechts een klein onderdeel van het hercodeerproces 44% sneller gaat. De tekst in het artikel is dus een beetje misleidend...

[Wouter Tinus]

Nee, er staat juist dat het deel waarvoor sse4 gebruikt wordt drie keer zo snel is, waardoor het uiteindelijke resultaat 44% hoger komt te liggen. Op IDF heeft Intel ook een demonstratie gegeven van een 2,93GHz Kentsfield tegenover een 3,33GHz Yorkfield (beide quadcore), waarbij de laatste meer dan twee keer zo snel was dankzij een combinatie van kloksnelheid, sse4-optimalisaties, groter cache en andere verbeteringen in de architectuur. De nieuwe Bearlake-chipset is daar nog niet eens bij ingenomen, dus Penryn wordt echt een videocodeermonstertje .

[OddesE]

Wat nog veel misleidender is: Eén en ander werkt alleen als de programmatuur geoptimaliseerd is voor de instructieset. Aangezien er vier verschillende varianten BIJkomen (er zijn er al flink wat) wordt de kans dat dat in de praktijk ook echt het geval zal zijn behoorlijk klein...

In de praktijk kan het er zo zelfs toe leiden dat de algehele snelheid omlaag gaat, omdat allerlei transistors op de cpu ongebruikt blijven...

[Cristan]

Ik denk dat voor de software waarbij je het ECHT goed kan gebruiken (zoals video coderen) dit wel gaat implementeren. DivX heeft dit bijvoorbeeld nu al gedaan zonder dat de nieuwe lading processoren ook maar te koop is.

[Verwijderd]

dat word een rechtzaak Intel VS AMD

Intel begon met MMX en dat mocht AMD later ook gebruiken. toen is Intel begonnen aan de ontwikkeling van SSE maar voordat het klaar was kwam AMD met On now 3D wat uiteindelijk de strijd verloor van SSE.

daarna kwamen de andere SSE varianten van Intel, SSE2, SSE3 en meerdere SSE4 varianten. Los van het feit dat AMD het nu verwarrend maakt voor consumenten gebruiken ze Intels naams bekendheid van SSE om te scoren.

[_JGC_]

Na MMX heb ik nooit meer een marketingcampagne gezien over een of andere wazige extentie. Destijds kwamen ze met de Pentium MMX: een CPU met lager voltage, verdubbelde L1 cache en een MMX instructieset. De CPUs werden aan tijdschriften geleverd, er kwam een reclamecampagne en iedereen moest en zou een Pentium MMX hebben, want die was veel sneller dan de niet-MMX pentium. De marketing zorgde er wel voor dat het leek alsof MMX de sleutel tot het success was, het was echter de verdubbelde L1 cache die de Pentium MMX versnelde.
Er waren in het begin een handjevol met spellen die een speciale MMX geoptimaliseerde versie kregen: de MMX versie van het spel draaide trager dan het niet-MMX versie op de Pentium MMX. Het enige voordeel van MMX op dat moment was dat concurrenten het niet hadden, en dat de consument toch geen drol snapt van wat MMX is, ze moeten het gewoon hebben.
Er zijn idd rechtzaken geweest tussen intel en AMD of Cyrix over het mogen gebruiken van de MMX merknaam voor CPUs die het ondersteunen. Hierna hebben we met SSE nooit hetzelfde gezien. Intel kwam met de Pentium III, die ze gewoon op de markt zetten als opvolger van de Pentium II, en die dan nog beter was. Aangezien de concurrenten toch al niets tegen de Pentium II in te brengen hadden, was de Pentium III een eitje, heb je geen marketinghype rond SSE voor nodig. Ik zie dan ook geen enkele fabrikant schermen met "heeft SSE, heeft SSE2 en heeft SSE3". Het Centrino of Duo beeldmerk van Intel doet veel meer dan een instructieset in een naam plakken, centrino staat immers voor een laptop met lange batterijduur, dat heeft de concurrent niet, want die hebben geen Centrino sticker.

[YaPP]

De marketing zorgde er wel voor dat het leek alsof MMX de sleutel tot het success was, het was echter de verdubbelde L1 cache die de Pentium MMX versnelde.

Grappig detail: als je de MMX instructieset doorkijkt blijkt dat het niets meer is dan standaard opdrachen (vermenigvuldigen e.d.) die i.p.v. 2 getallen 4 getallen verwerken. Daardoor gebruik je de registers efficienter, en bespaar je dus een extra opdracht voor de 2e vermeningvuldiging.

Leuk dat zo'n marketing hype uiteindelijk om zoiets - voor de leek - triviaals kan gaan.

Zie ook: http://nl.wikipedia.org/wiki/MMX

[roy-t]

Ik denk niet dat de naam echt patenteerbaar is:
SSE staat voor

Streaming
SIMD(Single Instruction, Multiple Data)
Extensions

Wat een heel 'algemene' term is.

Wel lastig dat AMD dit sse4a noemt een andere naam was veel begrijpelijker geweest om de verwarring te voorkomen, als je voor een programma sse4 nodig hebt en je controleert je proc en ziet sse4a dan zou ik denken ok! heb ik.

(gelukkig controleren de meeste programmas of ze sse instructies kunnen gebruiken, en zal er dus net als nu geen incompetibaliteit ontstaan, ik met mijn sse1 AMD 2400+ kan nog steeds divXjes maken enzo.)

[Verwijderd]

SSE5: scatter/gather. Wishful thinking...

Op dit moment worden elementen van vectoren uit opeenvolgende geheugenlocaties gehaald. Met gather zou echter elk element afzonderlijk van een totaal willekeurige geheugenlocatie opgehaald kunnen worden. Dit is in principe mogelijk door een andere vector te vullen met de adressen (of offsets tegenover een 64-bit register dat het basisadres bijhoudt) waar de elementen gelezen moeten worden. En voor scatter hetzelfde maar dan voor het schrijven.

Moderne CPU's zijn reeds uitgerust met meerdere eenheden voor geheugentoegang (per core). Dus scatter/gather kan sneller zijn dan elementen afzonderlijk te moeten lezen en schrijven.

[Wouter Tinus]

Wat je beschrijft lijkt me wel te kunnen met SSE4. Kijk maar eens naar de Extract en Insert instructies:

http://softwarecommunity....ogramming%20Reference.pdf

[Verwijderd]

Die zijn al een stap in de goede richting, maar nog geen echte scatter/gather. Je zou vier extract/insert instructies nodig hebben om alle elementen naar/van willekeurige geheugenlocaties te schrijven/lezen. Met een echte scatter/gather gebeurt dit in één instructie, waarbij de adressen (of offsets) in een vectorregister zitten in plaats van een generiek register.

[Wouter Tinus]

Ok, ik zie het verschil . De vraag is dan natuurlijk of je met één instructie veel sneller uitbent, want volgens mij ben je eerder afhankelijk van je load/store units voor de snelheid waarmee je vier waarden bij elkaar kunt verzamelen, dan van de snelheid waarmee je insert/extract instructies kunt issuen.

[Verwijderd]

De vraag is dan natuurlijk of je met één instructie veel sneller uitbent...

Met SSE4 kost zo'n bewerking acht instructies. Dus ja er is nog wel heel wat te winnen. Wel moet je best vier load/store units hebben. De latentie is wel gelijk aan die van andere geheugenbewerkingen, maar je doet gewoon vier keer meer werk en iedere klokperiode kan de volgende gestart worden.

[Wouter Tinus]

Je hebt in de praktijk echter maar 1 load unit en 1 store unit, dus een instructie om 4 of meer van zulke operaties tegelijk in de wachtrij te zetten heeft maar beperkt nut. Als je niet direct het L1-cache raakt zet je makkelijk de overige drie opdrachten in de wachtrij voor het resultaat van de eerste terugkomt.

[Verwijderd]

Je hebt in de praktijk echter maar 1 load unit en 1 store unit...

Voor zover ik weet zijn huidige CPU's typisch uitgerust met twee load units en één store unit. Dat is ook nodig: Core 2 kan vier instructies in parallel uitvoeren, en die moeten vaak het geheugen aanspreken.

RISC architecturen met vier load units en twee store units zijn geen uitzondering. Dus het zou mogelijk moeten zijn om op efficiënte wijze scatter/gather te implementeren op toekomstige x86 CPU's.

Als je niet direct het L1-cache raakt zet je makkelijk de overige drie opdrachten in de wachtrij voor het resultaat van de eerste terugkomt.

Klopt, maar dat heb je ook met insert. Je kan niet verder met de vectorberekening voor je alle elementen hebt. Huidige architecturen kunnen trouwens loads out-of-order uitvoeren, dus je houdt er geen andere bewerkingen mee tegen.

[Wouter Tinus]

Voor zover ik weet zijn huidige CPU's typisch uitgerust met twee load units en één store unit. Dat is ook nodig: Core 2 kan vier instructies in parallel uitvoeren, en die moeten vaak het geheugen aanspreken.

Nee, Core 2 heeft echt maar één load en één store unit, zie bijvoorbeeld hier (even naar pagina 4 scrollen). De K8 heeft twee load/store units en is dus wat flexibeler.

RISC architecturen met vier load units en twee store units zijn geen uitzondering.

De meest bekende: Power5+ heeft twee load/store-units, HP PA-8900 heeft twee load/store units, Alpha EV7 heeft twee load/store units, Sun UltraSparc IV heeft één load/store-unit. Alleen de Itanium 2 komt met twee keer load en twee keer store in de buurt van wat volgens jou geen uitzondering is, maar dat is dan weer geen RISC . Zit je niet aan vectorprocessors te denken?

Klopt, maar dat heb je ook met insert.

Ik had het juist over Insert. In een situatie waarin je load/store de bottleneck is heeft het imo weinig zin om instructies toe te voegen die er vier tegelijk uitvoeren. Door parallelle verwerking zal je wel iets sneller klaar zijn, en je legt ook minder druk op de decoders, buffers en instructiecaches, maar echt heel veel schiet je er volgens mij niet mee op.

[Verwijderd]

Nee, Core 2 heeft echt maar één load en één store unit...

Dat zijn enkel de load/store units van de integer pijplijn. De FPU/SSE pijplijn heeft er ook. Maar de details doen er weinig toe, het voornaamste is dat meerdere load en store units mogelijk zijn. Merk ook op dat terwijl het er voor scatter/gather meer zouden moeten zijn, ze wel minder breed hoeven te zijn.

In een situatie waarin je load/store de bottleneck is heeft het imo weinig zin om instructies toe te voegen die er vier tegelijk uitvoeren.

L1 toegang kost slechts enkele klokcycli. Da's even veel latency als een add of mul. En statistisch gezien zijn de meeste toegangen naar L1. Dus hoewel er zeker "situaties" zijn waar het weinig helpt, kan het in de praktijk een grote prestatiesprong zijn.

Vier insert instructies hebben afhankelijkheden waardoor hun totale latency zeer hoog ligt, ook als alles in L1 zit. Een echte scatter/gather werkt op de hele vector in parallel zodat er geen valse afhankelijkheden zijn.

Men zou het ook hiërarchisch kunnen implementeren. Wanneer alle elementen zich in L1 bevinden worden ze in parallel uitgelezen en is de instructie zeer snel. Wanneer echter een element zich verder bevindt kan men op microcode overgaan die de elementen sequenteel laadt. Zo kost het een minimum aan extra transistors en versnelt men toch het typische geval.

Het is maar een voorstel he. Ik zie er wel nut in voor SSE5. Ook (benaderende) instructies voor log en exp zouden handig zijn...

[rschwartnld]

Mja amd kan en mag niet zomaar de instructie sets overnemen als intel deze heeft gepatenteerd.
Andersom idem dito.
Maar tot nu toe merk de gewone man niet of nauwelijks iets van deze toegevoegde sets, op sse2 na maakt het vrijwel niets uit.
En ja amd maakt ook eigen instructie sets : 3dnow bijv.
Het punt is dat al die eigen stukjes code wel moeten worden gebruikt/geprogrammeerd in nieuwe software om er gebruik van te maken als dit niet gebeurt heb je helemaal niets aan deze extra processor balast

[Verwijderd]

Mja amd kan en mag niet zomaar de instructie sets overnemen als intel deze heeft gepatenteerd.

Ze patenteren het wel maar hebben ook afspraken om licenties uit te wisselen. AMD maakt gebruik van SSE* en Intel van x86-64. Ze beseffen beide dat het geen zin heeft om incompatibiliteit te creëren.

Maar tot nu toe merk de gewone man niet of nauwelijks iets van deze toegevoegde sets, op sse2 na maakt het vrijwel niets uit.

Dik fout. Zowat elke muziek- en videocodec maakt er intensief gebruik van, inclusief MMX. Ook spelletjes maken er gebruik van, en drivers hebben er ook veel voordeel bij. Dus je ziet het misschien niet altijd, maar het wordt meer gebruikt dan je denkt.

Het punt is dat al die eigen stukjes code wel moeten worden gebruikt/geprogrammeerd in nieuwe software om er gebruik van te maken als dit niet gebeurt heb je helemaal niets aan deze extra processor balast

Intel en AMD hebben enkele kant-en-klare bibliotheken voor rekenintensieve doeleinden. Dus veel van het werk komt op hun schouders terecht en de programmeur wordt grotendeels afgeschermd van de details. Ook is het aan de compilers om deze instructiesets automatisch te gaan gebruiken. Dit is nog een onderzoeksgebied maar maakt vorderingen. Het is dus goed om op voorhand al deze instructies beschikbaar te hebben.

[Zwartoog]

Intel en AMD hebben enkele kant-en-klare bibliotheken voor rekenintensieve doeleinden. Dus veel van het werk komt op hun schouders terecht en de programmeur wordt grotendeels afgeschermd van de details.

Helaas zijn ook deze bibliotheken (ik neem aan dat je MKL en ACML bedoelt) niet direct uitwisselbaar. Hoewel ze hetzelfde kunnen is de syntax iets anders, dus je moet nog immer een check uitvoeren of je op een Intel of AMD CPU draait.

[Verwijderd]

Een prima marketing grafiekje. Het klopt maar is niet zinnig/correct.
Waarom een vergelijking met SSE2 als de SSE2 CPU uit productie zijn?
SSSE3 of SSE3 zou meer inzicht geven voor de consument.
Het feit dat voor SSE2 gekozen is is voor mij het bewijs dat het grafiekje er dan slecht uit zal zien.
Ook draait men vanaf RAMdrive. Ok natuurlijk als je meer pure CPU specs wilt.
Maar minder realistisch voor de gebruiker.
Real life winst max. 20 fps schat ik.

[Wouter Tinus]

SSE2 is helemaal niet uit productie, het zit in iedere processor die je vandaag de dag kunt kopen. Misschien heeft (S)SSE3 wel gewoon geen nuttige instructies voor DivX? Of misschien gebruikt men het niet omdat SSE2 veel breder ondersteund wordt door oudere machines? Misschien had het gewoon geen prioriteit bij de ontwikkelaars? Het is in ieder geval niet zo dat er een SSE3-versie van DivX bestaat die men sneaky heeft weggelaten.

In ieder geval, ik heb gesproken met degene die samen met DivX deze optimalisaties heeft gedaan, en ik heb een test live zien draaien zonder ram-drive. Het is echt geen oplichterij: er zijn gewoon hele reeksen van 12-16 instructies in kritieke delen van DivX, die miljarden keren uitgevoerd worden tijdens het coderen van een video, die met SSE4 teruggebracht kunnen worden tot één instructie. En daar wordt het bloedsnel van.

[TeXiCiTy]

Als ze alles anders doen kunnen ze het beter 3dNow.2 en MMX.2 gaan noemen. Intel en AMD waren net zo "goed" op weg met de instructie-uniformiteit.

[groene henk]

Dit is goed waardeloos. Weer instructies, die niet door Intel en AMD tegelijk worden ondersteund. Dus we gaan weer naar meer incompatibiliteit.

Op deze manier hopen AMD en Intel dat hun huidige klanten hun incompatible chip kopen en deze nieuwe instructies gaan gebruiken, waardoor ze tot in de lengte van dagen aan de chips van Intel en AMD vastzitten.

Daarna kunnen ze weer de prijzen omhoog schroeven. Want je zit er eenmaal aan vast.

En dan zal het nog wel even duren, totdat de EU (Nelie Smit-Kroes) hier dan tegen gaat optreden.

[Verwijderd]

Ja, dit begint echt te irriteren. Vooral omdat ik nu extra checks moet uitvoeren op sse versies in mijn (nog incomplete)game engine. En dan moet ik ook voor sommige sse versies een aparte routine coden in assembly om de processor optimaal te benutten. Als ze nou 1 standaard hadden dan zou dat een hoop werk schelen.

[Verwijderd]

Dit is goed waardeloos. Weer instructies, die niet door Intel en AMD tegelijk worden ondersteund. Dus we gaan weer naar meer incompatibiliteit.

Het duurt gewoon een generatie tot de instructies ook door de concurrentie ondersteund worden. Je moet ergens beginnen he, anders zaten we nu nog met 16-bit code.

Op deze manier hopen AMD en Intel dat hun huidige klanten hun incompatible chip kopen en deze nieuwe instructies gaan gebruiken, waardoor ze tot in de lengte van dagen aan de chips van Intel en AMD vastzitten.

Neen, onderlinge afspraken tussen Intel en AMD verzekeren dat ze elkaars uitbreidingen mogen gebruiken. Daarom ook dat hun 64-bit uitbreidingen compatibel zijn. Niemand wordt dus ingesloten.

[Brent]

Doet AMD's nieuwste nu ook aan SSSE3?

[Wouter Tinus]

<img src="http://tweakers.net/g/check0.gif">

(had je uit de tabel kunnen halen dus )

[Brent]

De tabel is helaas onduidelijk, want er staat immers niet welke cpu de instructie niet ondersteund. Het jaartal 2006 doet vermoeden dat het over de huidige Athlons gaat, en daar weet ik het toevallig zelf van.

Jammer dat de nieuwe generatie van AMD dus naast een verbeterde SSE3 implementatie niet zo gek veel extra's bied (het aantal instructies van SSE4a is erg beperkt in vergelijking met SSSE3 en SSE4.x), terwijl Intel met hit na hit uitkomt, en waarschijnlijk betere ondersteuning zal krijgen wbt deze instructies.

[Madrox]

Je verhaalte rammelt aan alle kanten. AMD bedenkt wel degelijk zelf technieken, komt zelf met innovatieve architectuur oplossingen. Waarom ze dan met SSE "achterlopen" is makkelijk te verklaren, maar dan moet je wel het juiste verhaal vertellen.

AMD heeft wel degelijk zelf een intructieset gehad, 3Dnow heette dat. 3Dnow is geen succes geworden omdat, net als met de SSE intructieset (made bij intel), er een brede ondersteuning voor nodig is van de programmeurs/software-ontwikkelaars. De meesten daarvan ondersteunden alleen MMX/SSE en lieten 3Dnow in de kou staan. Niet omdat 3Dnow inferieur was, maar omdat het meer tijd en geld kost om ook die nog eens te programmeren in de software.

AMD is zo verstandig geweest 3DNow te laten voor wat het was en ovegestapt naar SSE ondersteuning; om toch die prestatiewinst te pakken die ze anders zouden laten liggen als ze met alleen 3Dnow waren doorgegaan.

Het probleem voor AMD is altijd hetzelfde geweest; ten opzichte van Intel zijn ze een kleintje, Intel heeft veel meer fabrieken en meer cash achter de hand. Desondanks heeft Intel een paar jaar achter de feiten aangelopen, dankzij de uitmuntende K7-architectuur van AMD. Medunkt een hele prestatie.

Intel heeft na de eerste schik, een paar tandjes opgeschakelt, R&D wakkergeschud en nu zijn ze weer de beste. Wat je ook mag verwachten van een chip-reus als Intel.

AMD speelt nu weer de tweede viool en ze kunnen niet anders dan de schade in te dammen, om vervolgens later weer eens met wat moois te komen. Dat dit geen makkelijke opgaaf is moge duidelijk zijn, maar dat was voor de K7 kwam ook al niet. M.a.w.; niets is veranderd, hoewel, nu draaien er meer mensen met een AMD-cpu dan toen. AMD systemen zijn ook stabieler als toen.

Qua aandeel en prestige zijn ze vooruit gegaan, nu alleen nog de cash ;-)

[Wouter Tinus]

Het jaar in de tabel is het jaar waarin de instructies werden/worden geïntroduceerd. De genoemde processors zijn de eerste die hem ondersteunden. AMD is daarbij altijd (veel) later geweest dan Intel. De Athlon 64 kwam bijvoorbeeld in 2003 uit, maar staat toch genoemd bij de SSE2-instructieset uit 2001. Logischerwijs had Barcelona dus ook wel bij SSSE3 gestaan, als hij het had ondersteund .

[Brent]

Voor de schrijver zelf is zijn tekst altijd logisch Ik vind het wat cpu-ondersteuning betreft een vaag tabelletje, welke open staat voor uiteenlopende interpretatie.

Kunnen we SSSE3 ooit nog verwachten bij AMD?

[Wouter Tinus]

Ik denk dat AMD uiteindelijk wel SSSE3 en SSE4.1/2 gaat ondersteunen, maar het zou me niets verbazen als dat nog een jaar of twee duurt.

[bozotheclown]

pardon? mijn opteron185 heeft gewoon sse3, en mijn x2 4400 had ook gewoon sse3.
edit: ssse3? uh? wat? help eens even.

[Brent]

@bozotheclown:
De implementatie SSE3 op huidige processors van AMD zijn echter trager dan de Core2duo (die heeft grotere registers dacht ik). De nieuwe CPU's van AMD zullen dit ook hebben (en dus niet meer achterlopen kwa prestaties tov de C2D), maar tegen die tijd heeft Intel alweer ruim een jaar SSSE3 in de markt staan en SSE4.1, waar voor mijn lekenoog SSE4a maar karig tegen afsteekt.

[Verwijderd]

maar het zou me niets verbazen als dat nog een jaar of twee duurt.

Wat de oorzaak?
1) Intel staat hun (nog) niet toe on sse* te gebruiken?
2) AMD heeft het nog niet (laat) in de core?

(IMO is er versnelling in de SSE versies gekomen toen AMD de x86-64 in licentie aan Intel heeft gegeven, toen heeft Intel ook iets terug gegeven).

Edit typo: x86 moest x86-64 zijn.

[humbug]

In principe mag AMD de SSE instructiesets gebruiken. Echter als Intel de instructieset nog niet af heeft terwijl AMD met een core bezig is, is het lastig om die instructieset in te bouwen. Het lijkt dus dat de "barcelona" core te vroeg ontworpen is om de nieuwe SSE instructie van de Penryn te kunnen bevatten.

Bij een nieuwe core zal AMD wel de missende instructies toevoegen. Maar voordat die core uitkomt zijn we wel weer wat maanden verder.

Het probleem is dus simpelweg dat Intel degene is die de technieken bedenkt en AMD slechts kan volgen en de instructies pas kan implementeren als Intel deze gepubliseerd heeft. Hierdoor zal AMD altijd achterlopen.

[Brent]

Waarom heft AMD er dan geen SSSE3 in gebakken? Die al een jaar in de Core 2 te vinden.

[Wouter Tinus]

Omdat je een jaar voor de release écht geen grote wijzigingen in je ontwerp meer kunt maken. Voor een ontwerp als Barcelona moet je minstens vier jaar rekenen, en wat hij wel en niet kan ligt al vrij vroeg in het traject vast.

[TheCapK]

@humbug:

Als Intel alles bedenkt en AMD alleen maar volgt:
waarom komt er dan uiteindelijk toch een memcontroller in toekomstige Intel CPU's? Of heb ik gemist dat Intel die in het verleden heeft ontworpen en aan AMD heeft doorgeschoven omdat ze het niet interessant vonden?
x86-64 instructies was dan zeker ook een Intel uitvinding net zoals de Echte Dual core (dus niet die aan elkaar geplakte dingen die als haastklus voor de concurrentie moesten worden uitgebracht)?

Sommige instructiesets zijn van Intel afkomstig en andere weer van AMD. Hiervan profiteren ze beide door de cross-license die ze hebben. Soms denkt de een echter: dat is nu voor ons overbodig dus voeren we dit niet in cq we maken er nu geen gebruik van. Zoals AMD dus doet met het DDR-DDRII-DDRIII verhaal en Intel met het onboard-memcontroller verhaal.

[Verwijderd]

en AMD maar pronken met de sterk (42%) verbeterde floating point prestaties van hun toekomstige barcelona core tov de huidig verkrijgbare intel xeon processoren.

dit zullen wel de 'legacy' standaard x87 floating point berekeningen zijn dan?

tegenwoordig wordt zowat alles qua floating point op de SSE units gedaan; loopt AMD hier dan niet feitelijk een aantal generaties mee achter?

[Nox]

De vraag is waarom AMD die instructie's niet toevoegt. Het is niet iets waardoor de yields slechter worden ofzo. Is er daar niet genoeg mankracht voor? Licentie's? Het zou zoveel kunnen schelen in performance. Of is het toch hardwarematig?

[Wouter Tinus]

Dit soort instructies moet hardwarematig ondersteund worden om er voordeel van te hebben. Er zijn wel mogelijkheden om het in microcode (zeg maar de 'software' op de processor) af te handelen, maar dan schiet je er qua prestaties niets mee op; waarschijnlijk wordt het er alleen maar slechter van. Het zal dus voornamelijk te maken hebben met tijd. AMD zou jaren van te voren uitgebreide documentatie van Intel moeten krijgen om tegelijk of eerder met dezelfde instructies te komen, en die krijgen ze gewoon niet.

[Nox]

Maar als er dus hardwarematige ondersteuning nodig is, waarom krijgt AMD dan die informatie te laat? Of is alleen intel de ontwikkelaar van die instructiesets? Mag AMD wel eens zijn eigen instructiesets gaan ontwikkelen. Denk dat die misschien wel efficienter kunnen zijn dan die van intel.

Ook agaia/physics ondersteuning zou dan kunnen? Zou een hoop gamers aantrekken.

[Wouter Tinus]

Intel ontwikkelt ze inderdaad, in overleg met een hoop softwarebedrijven, maar zonder AMD. Ze kunnen wel hun eigen instructies gaan verzinnen maar als één fabrikant 80% en de ander 20% van de markt heeft dan lijkt het me wel duidelijk welke instructies een betere kans maken om opgepikt te worden. Met AMD64 hadden ze het geluk dat Intel geen enkel bruikbaar alternatief bood, maar 4 SSE4a-instructies tegen 86 nieuwe SSSE3/SSE4-instructies van Intel... tja, dat gaat gewoon de kant van 3dNow op als je het mij vraagt .