Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 63 reacties

AMD heeft een sse5-instructieset gepubliceerd die vanaf 2009 in de Bulldozer-core te vinden moet zijn. De uitbreidingen moeten voor betere prestaties zorgen en het schrijven van code vereenvoudigen.

Zowel Intel als AMD voorzien hun processors van steeds meer cores, maar het duurt lang voor de softwareindustrie hier optimaal van gebruikmaakt. De verwerking van single-threaded-code kan ondertussen wel een duw in de rug gebruiken, en onder ander sse5 moet hier voor zorgen. Vooral veeleisende applicaties zullen baat hebben bij sse5 en volgens AMD maken de extensies het schrijven van code een stuk makkelijker. De sse-extensies zorgen volgens AMD voor vijf keer zo hoge prestaties bij aes-encryptie en een verbetering van dertig procent bij dct, een wiskundige bewerking die gebruikt wordt bij audio- en videocodecs.

Met de sse5-instructieset gaat AMD de concurrentie aan met Intel die de sse4-instructieset heeft ontworpen. De functionaliteit van sse4 en sse5 overlapt elkaar deels, maar verschillende instructies die wel aanwezig zijn in sse4 zijn niet aanwezig in sse5, en omgekeerd. Verwacht wordt dat Intel niet voor sse5 zal kiezen.

Vergelijking sse4 en sse5

Een van de verbeteringen die AMD noemt in de specificaties van zijn 'AMD64 Technology 128-Bit SSE5 Instruction Set', is de ondersteuning voor 3- en 4-operand-instructies. Hiermee kan een programmeur een extra register benaderen waarmee de bewerking op twee andere registers kan worden be´nvloed. Zonder deze functionaliteit zouden hiervoor meerdere operaties nodig zijn. Dankzij deze uitbreiding komt de sse5-instructieset op bijna gelijke voet te staan met de AltiVec-instructieset die deze functionaliteit al langer biedt. Verschil is wel dat bij sse5 ÚÚn van de inputregisters gebruikt moet worden om het resultaat op te slaan terwijl AltiVec hier een apart register voor biedt. In totaal biedt sse5 ruim honderd nieuwe instructies waarmee bewerkingen op vectoren versneld kunnen worden.

Moderatie-faq Wijzig weergave

Reacties (63)

Het is allemaal fantastisch wat SSE5 allemaal kan maar als dit het geval is.
Met de sse5-instructieset gaat AMD de concurrentie aan met Intel die de sse4-instructieset heeft ontworpen. De functionaliteit van sse4 en sse5 overlapt elkaar deels, maar verschillende instructies die wel aanwezig zijn in sse4 zijn niet aanwezig in sse5, en omgekeerd. Verwacht wordt dat Intel niet voor sse5 zal kiezen.
Dan zul je er weinig aan hebben en zal het ook een zeer lage adoptie hebben door programmeurs die toch iets generiek schrijven voor alle CPU's. Krijg je dadelijk ook al met deze instructie sets iets vergelijk baars als DVD +/- en blueray en HD DVD etc etc.
Valt wel mee. 3DNow! was ook AMD-specifiek en werd best wel gebruikt. Snelheid is belangrijk genoeg om stukken te optimaliseren voor specifieke instructiesets. Daarbij worden compilers ook steeds slimmer; als je je source zo opstelt dat het duidelijk is wat de vectoroperaties zijn kan je compiler de juiste extensies gebruiken. Kwestie van hercompileren.

Je moet het zo zien: als de baas zegt "kun je die outputroutine 10% sneller maken op de nieuwste processor" dan zegt de programmeur niet "ja maar da's zo'n moeite, ik kan die verbetering niet echt generiek schrijven". Dan neemt de concurrent het voortouw. Het is niet echt vergelijkbaar met de verschillende hardwarestandaarden, die het moeten hebben van wie er materiaal voor uitbrengt -- het zit al in je processor en je hoeft het niet te gebruiken, maar je wordt er alleen maar beter van als je het wel doet.

Edit: zie ook de compilerondersteuning zoals vermeld door .oisyn hierboven. Afhankelijk van wat je wil is het soms heel goed mogelijk om de code generiek te schrijven.

[Reactie gewijzigd door MneoreJ op 30 augustus 2007 23:31]

Heb zelf niet al teveel verstand van programmeren maar denk dat je ook wel in code grofweg zoiets tegen kan komen
If sse=5 use code="xxx"
If sse=4 use code="yyy"

Gewoon een grof idee hoor heb geen verstand van hoe het in echte code eruit zou zien...
Niet op het niveau zoals je het hier voorstelt. Al die conditional branching maakt het erg duur en neemt dus het hele nut van de nieuwe instructies weg. Je zult eerder zien dat hele lappen code meerdere keren worden geimplementeerd/gecompileerd, of zelfs hele verschillende binaries worden gemaakt (denk aan een DLL die voor SSE4 is geoptimaliseerd, en een DLL die voor SSE5 is geoptimaliseerd)
Ik vind het maar raar. Ze willen dat single-threaded applicaties sneller lopen, MAAR die moeten wel (deels) herschreven worden om van SSE5 gebruik te maken. Lijkt mij dat ale je toch al dingen moet herschrijven je beter je code multi-threaded kan maken zodat je in plaats van SSE5 gebruik kan maken van alle cores. Lijkt me een betere investering, vooral omdat je programma dan ook op de andere 80% van de computers met Intel processor retesnel wordt...
SSE[1-5] worden vaak niet door de programmeur van de individuele programma's gebruikt maar door de compilers. Als je programma goed is geschreven en de verschillende delen voor de compiler dus duidelijk te herkennen zijn is het hercompileren van de broncode al een mooie stap op weg naar versnellen. Je kan later nog de belangrijkste operaties wat herschrijven om de compiler nog optimaler te laten werken en nog meer gebruik te maken van de extra instructies, maar dat is een extra bonus.

Daarentegen is het compleet herwerken van je software om multicores uit te buiten heel wat meer werk.
Voorbeeldje: De laadste Visual Studio levert 20-40% snelheidswinst op omdat deze compiler veel meer gebruik maakt van MMX/SSE/3dNow. Ook recompilen met een nieuwere gcc met optimalisatieflags voor je arch kan een vergelijkbare snelheidswinst opleveren.
Met geringe extra investering je oude troep sneller maken is altijd interessant, ook als je met veel meer extra investering je oude troep heel veel sneller kan maken. Gaat er maar net om wat snel genoeg is. Vlak ontwikkelkosten niet uit, en multithreading is zo ongeveer het lastigste waar een programmeur mee te maken kan krijgen. Nuttig gebruik maken van nieuwe instructies is daarbij vergeleken een eitje.
Mag AMD de SSE5 naam eigenlijk wel gebruiken? Het klinkt als een opvolger van SSE4, 3, 2 en 1, en die zijn allemaal van Intel...
Hiermee kan een programmeur een extra register benaderen waarmee de bewerking op twee andere registers kan worden be´nvloed. Zonder deze functionaliteit zouden hiervoor meerdere operaties nodig zijn.
Ik denk dat er erg weinig programmeurs zijn die dat kunnen. Ik denk dat het meerendeel de compiler dit soort optimalisaties laat doen. En daarbij, een Office applicatie heeft het niet nodig.

Maar ik ben blij dat AMD nog met vernieuwingen komt. Ze hebben dus nog een R&D afdeling die leeft. Nieuwe processoren ontwerpen is al aardig moeilijk maar de antieke x68 nog weer een keer uitbreiden lijkt me helemaal een hel. Aan de andere kant, alles valt of staat met goede compilers, iets waar Intel een goede naam heeft en wat ik van AMD niet weet.
En daarbij, een Office applicatie heeft het niet nodig.
Een Office-applicatie heeft voldoende aan een processor van drie generaties terug, dus dat is sowieso een non-issue. SSE en vrienden zijn altijd bedoeld geweest voor het versnellen van specifieke operaties, vooral op het gebied van beeld en geluid. In die markt is snelheid zeker belangrijk genoeg om specifiek voor instructiesets te schrijven.
Natuurlijk laten programmeurs veelal dit soort dingen over aan de compiler, en dus zijn het juist de compilerbouwers die hier iets mee zullen moeten doen. Overigens gebruiken programma's als multimedia (de-)coders weldegelijk vaak zelf direct features op de core voor hun meest tijd-kritische stukken code.
Lijkt me idd wel leuk als ze de gpu gaan combineren met de cpu! Dan krijg je pas een performance boost. De cpu zou bijvoorbeeld een ge´ntegreerde videokaart kunnen bevatten die als er echte videokaart wordt toegevoegd als co cpu kan worden gebruikt. :P :9 beetje zoals de Cell van de PS3.
Als je niet voor performance gaat heb je dan gewoon een goedkope ge´ntegreerde videokaart :)
dat is wel wat AMD en Intel aan het bekokstoven zijn volgens enkele geruchten. (die zijn ook op deze site gepubliceerd).

Ik zie er echter het nut niet zo van in. Wil je een videokaart met DirectX 11 ondersteuning, kun je weer je hele CPU vervangen (en eventueel ook je moederbord vanwege de socket, het geheugen omdat dat dan op DDR<n> zit, etc, etc).

Het grote voordeel van de PC is juist de verwisselbare componenten, zodat je een PC kunt aanpassen naar gelang de vraag veranderd. Zeker voor ons tweakers en IT profs geen nutteloze feature. Voor zakelijke computers ligt dat uiteraard wel weer anders.

Het leuke vind ik weer wel het ding wat AMD pas geshowcased heeft, een Terraflop in a box. Dat was een systeem met een dualcore opteron, en een tweetal ATi videokaarten. Dat geheel leverde een terraflop aan rekenkracht, en dat maakt het heel intressant voor de supercomputer markt. (alhoewel de stroomconsumptie en hitte uitstoot daar wel een zorgenkindje zal zijn)
Ja maar je hebt ook nog een uitbreidingsslot voor 'betere' videokaarten. Ik denk dat die gpu in de cpu voorlopig low end zal blijven en hoogstens handig voor een office pc'tje ofzo. Maar ook handig als eventuele physics berekenaar of gewoon om bepaalde instructies uit te voeren waarin die sneller is dan de cpu.

High end videokaarten zullen gewoon nog een aardige tijd los blijven denk ik.
Intel Larabee? Ik weet het niet, maar dat was toch ook zoiets?
De PS3 heeft een aangepaste 7800GTX gpu ;)
Ik zou liever zien dat men ook een instructieset voor A.I. besturing maakt. Zodat men bijvoorbeeld games makkelijker kan voorzien van waardige tegenstanders.

Ook wel handig dat ze RISC technieken gaan gebruiken in de vorm van 3 Operand instructies. Ook algoritme decompresies voor bijvoorbeeld DRM (ja die meuk weer) en hdtv codecs( mpg-4 en H.264) ,mp3 encoding met de Discrete Cosine Transformation is erg handig. Uit de whitepapers maak ik op dat de AES algoritme een factor 5 performance boost krijgt.

Meer is te vinden in het technishe document van AMD.

Er zitten interessante dingen in
A.I. is erg moeilijk te optimaliseren omdat je van te voren niet weet welke beslissingen er gemaakt gaan worden. De wat simpelere A.I. routines gebruiken gewoon welbekende algoritme's a;s minmax, graven etc... en die zijn al reeds geoptimaliseerd.
Gaat Windows weer kiezen welke te ondersteunen, en die zal ook de enige winnaar zijn!

Gelijk bij de 64bit exensies
Ik denk dat dat wel mee valt, je zou dan namelijk de volgende windows ook niet op je huidige CPU kunnen draaien. Aangezien de huidige CPU tot SSE3 hebben. Nu is het voor een OS ook niet super essentieel, het is meer dat zware apps er wat aan hebben.

Voor 64bit instructies was het een ander verhaal, daar bouw/compile je native het OS voor. Voor SSE4/5 valt dat wel mee, een OS kan makkelijk zonder, en verschil zou je toch bijna niet merken.
Nouja, wanneer je een OS maakt afhankelijk van SSE4/5 en je schrijft routines voor het geval SSE4/5 niet aanwezig is zul je wel een performanceverschil merken. (OSX op Intel is bijvoorbeeld afhankelijk van SSE2/3 en kan alleen maar gepatcht op SSE2 draaien, en word daar een stuk minder prettig van voor zover ik heb gehoord)
Ik meen mij te herinneren dat sse3 enkel belangrijk was om Rosetta te draaien (de PowerPC emulator voor de toen nog niet universal binaries)

Itunes was in de eerste maanden van MacIntel nog geen universal bin.

Een Hackintosh op sse2 was mogelijk maar kon slechts heel traag Rosetta apps draaien (Adobe, ms office, itunes, ..)
Hiermee kan een programmeur een extra register benaderen waarmee de bewerking op twee andere registers kan worden be´nvloed. Zonder deze functionaliteit zouden hiervoor meerdere operaties nodig zijn.
Als ik me niet vergis zat dit soort technologie al in de originele PowerPC instructieset 15 jaar geleden.
Daarom is x86 zo ruk.
De enige reden dat x86 als maar blijft staan is omdat Windows (helaas nogsteeds het grootste OS) alleen maar voor deze arch wordt uitgebracht.
x86 is de grootste bij elkaar gehackte bende die ik ooit gezien heb. De reden daarvoor is dat Intel marketing technisch gedwongen wordt de zaak tot in de oneindigheid backward compatible te houden, omdat er nogsteeds mensen zijn die Word '95 willen installeren op een Core2Duo. Lang leve closed source software.

Stel nou eens dat software in source verspreid wordt (voor zover mogelijk) dan maakt dat al een eind aan dat CPU's tot in de oneindigheid binary backward compatible moeten zijn. In dat geval kunnen ontwerpers CPU's veel sneller maken in ontwerp ipv maar weer een snellere transistor uit te vinden en weer een Ghz erbij.
Om dit even te illustreren: In de Pentium4 is 3/4 bezig met administratie of alles goed loopt en slechts 1/4 met het eigelijke rekenwerk. De Pentium D en Core2Duo reeks scoort beter, maar nogsteeds belabberd.

Hadden we die vrijheid gehad dan waren er veel meer archs dan alleen x86 in de desktop markt en had ik zeer waarschijnlijk een PowerPC of MIPS in me kast gehad, en zaten we ook niet met ze allen onder de plak van Intel.
Diversiteit is altijd beter.

[Reactie gewijzigd door merethan op 30 augustus 2007 23:41]

Pardon, je weet niet waarover je het hebt. Windows NT is uitgebracht op DEC Alpha, PowerPC en MIPS. Al deze versies zijn inmiddels ter ziele, maar beweren dat x86 alleen nog maar bestaat vanwege Windows is kul. Als jij denkt dat het zo makkelijk is om compleet opnieuw te beginnen, ga dan naar Intel en roep "Itanium". Kijken hoeveel handen je op elkaar krijgt.

Backwards compatibility? Natuurlijk! x86 mag een "bij elkaar gehackte bende" zijn, het is niet zo vreselijk dat het niet werkt. De manier waarop Intel nu nog compatible is met de 8086 mag zelfs elegant genoemd worden, al is het resultaat dat dan niet -- het had een nog veel grotere bende kunnen zijn.

De ontwikkelkosten voor een compleet nieuwe architectuur zijn aanzienlijk, en je gaat het echt niet verkopen met "nu is het geen bende meer, en de software kan nog sneller ook". Natuurlijk kun je radicaal breken met het verleden, maar wat kost het? Hoeveel mensen kopen het als alle oude software niet gaat draaien, en de fabrikanten met nieuwe versies moet aankomen? Zo eenvoudig als jij het doet voorkomen (gewoon ff opnieuw compilen die hap!) is het niet. Portability kost ook tijd en moeite, en niet iedereen heeft die er al in gestoken.
Power5 zijn echt super snel in vergelijking met de core-duo2/xeon, ik hoop dat IBM nog meer tech uitleend aan AMD.
Fourier Transforms :9

Elke (ex)TU student weet wat voor ellendige vraagstukken je er meekan verzinnen :*)
Jammer dat ik geen SSE5 heb zitten in mn hoofd :/
Ik denk dat de GPU voorlopig de beste kandidaat is om dat soort algoritme's op te draaien, wat performance betreft.
Klopt inderdaad. Een direct voorbeeld is fft3dGPU, een beeldruisfilter wat werkt met behulp van FFT (fast fourier transformations) in 32bit floating point (en ook nog eens in "3D", dwz FFT vergelijkingen met 2 frames voor de huidige en 2 erna).

Dit filter werkt met een snelle GPU vrijwel real-time in standaard PAL resolutie. Bij de modernste kaarten gaat zelfs 1280x720 bijna in real time.

Ter vergelijking: Er bestaat ook een NON GPU versie van (hier) en die gaat zelfs met de modernste CPU's vaak nog niet eens met 10% van de snelheid van de GPU-versie.

[Reactie gewijzigd door G_M_C op 30 augustus 2007 23:07]

heb ff snel liggen zoeken wat het is.. maar knapt het gewoon je beeld een beetje op dat het er strakker uit ziet.. of kun je er daarna met een 3d bril naar kijken?
Volgens mij is de derde dimensie in dit geval tijd (als in meerdere frames).
en dan vooral op een 8 bitter :)
Wel slim om alvast de naam SSE5 te claimen. Zo'n eigen 3DNow! in de markt zetten, dat was nog geen sinecure. Maar op deze manier krijg je argeloze consumenten beter mee. Ik zie de verkopers al uitleg geven in de winkel.. ja, deze Intel heeft slechts SSE4, die AMD heeft al 5! Veel mensen zullen wel denken dat alles wat in 4 zit ook wel in 5 moet zitten.
zeer slimme verkooptruc van AMD, dat wel, maar de tweaker weet beter
De tweaker heeft geen flauw benul van deze extenties nu echt concreet inhouden, daar hebben slechts de hoogst opgeleiden in de informatica echt iets mee te maken.
Hoogst opgeleiden ?

Alsof het over zoiets speciaal gaat...

SSE of 3DNow is niets anders dan een extensie van de instructieset met een hoop extra, dedicated instructies.
Ja maar wat houd het nou precies in dan? En kom dan niet zeggen ja het versneld bepaalde processen maar zeg dan eens wat voor processen en hoe of waarom.

Edit:
Het was een reactie op Green.Velvet maar .oisyn heeft het wel even mooi uitgelegt mijn complimenten

[Reactie gewijzigd door SRI op 31 augustus 2007 08:46]

Het zijn speciale hardware-instructies die bepaalde berekeningen doen die je eerst ook wel kon doen, maar dan in meerdere stappen. Je kunt je wel voorstellen dat een CPU z'n werk efficienter kan doen als hij van tevoren in een keer de hele berekening weet en wat precies het doel is.

Stel er bestaat een spartaanse CPU, met een instructie om twee registers bij elkaar op te tellen, maar niet eentje om af te trekken. Er is wel een instructie die het teken van een register verandert, oftewel als de input x is, dan is de output -x. In principe heb je aan deze instructie, inclusief de instructie voor optellen, genoeg om een register van een andere af te trekken. In plaats van x - y schrijf je x + -y. Alleen kost dat dus twee stappen - je moet eerst -y berekenen, en dan kun je het pas bij x optellen.

Nou blijkt later dat dat aftrekken toch wel heel erg vaak voorkomt, en het handig zou zijn als er gewoon een aparte instructie voor was. Er komt een nieuwe CPU uit met die extra instructie, zodat nieuwe applicaties gewoon direct kunnen aftrekken, waardoor hun performance stijgt (mits ze er gebruik van maken dus, het werkt niet automatisch voor oudere applicaties die die instructie nog niet kenden).

Natuurlijk is SSE5 wat complexer dan alleen een aftrekken-instructie, maar in feite komt het op hetzelfde neer. Neem een audio-applicatie. Om het volume van een geluid aan te passen, zal hij elke sample met een bepaalde waarde moeten vermenigvuldigen. Met een samplerate van 44.1kHz, betekent dat 44100 samples per seconde, per kanaal (dus links en rechts). Voor een geluid van een seconde zijn dus 88200 vermenigvuldigingen nodig. Toen kwam MMX, waarmee het mogelijk was om 8 8-bit samples of 4 16-bit samples in een register te laden, en al die samples in een keer met dezelfde waarde te vermenigvuldigen. Je kunt je wel voorstellen dat dat een enorme performance-boost geeft. SSE is weer een uitbreiding op MMX, met nog bredere registers (128 bits ipv 64 bits), en support voor floating-point berekeningen (in een register passen 4 32-bits floats, of 2 64-bits floats vanaf SSE2), ideaal voor onder andere 3D applicaties.

Een beschrijving van welke instructies de verschillende SSE versies allemaal implementeren is wel op internet te vinden, bijv. op wikipedia.

[Reactie gewijzigd door .oisyn op 31 augustus 2007 00:12]

En ondertussen heeft MMX geen nut meer, omdat al de MMX-instructies in SSE (ik dacht SSE2?) opgenomen zijn.

En jouw verhaal valt best nog te nuanceren.

Huidige processoren zijn niet meer puur CISC. 1 assembler-instructie wordt vaak door de processor in meerdere stappen berekend. Een instructie die meerdere atomaire instructies bundelt is niet noodzakelijk sneller dan de opeenvolging van de atomaire instructies. Dit is zeker het geval als de atomaire instructies niet steeds 100% afhankelijk zijn van een vorig resultaat, zodat de atomaire instructies gepipelined kunnen worden.

SSE is dus niet per definitie sneller. Het hangt sterk af van de processorbouwer, hoeveel hij de speciefieke instructies in zijn design heeft versneld.
Klopt, de MMX instructies zitten ook in SSE2, maar tevens kun je SSE instructies ook op MMX registers loslaten (tot versie 4 iig, 4 was de eerste versie die daarmee brak en instructies introduceerde waarbij geen MMX registers te gebruiken waren).

En natuurlijk beweer ik niet dat SSE per definitie sneller is. Het geeft echter wel meer mogelijkheden tot optimalisaties.
Een fiets is een stuk staal met wielen 8-)
En je hoeft niet hoog opgeleid te zijn om erop te kunnen rijden en een band te kunnen plakken :Y)
Spreek voor jezelf. Zo hoog opgeleid ben ik nou ook weer niet, maar ik weet best wat MMX, 3DNow! en SSE inhouden. Met een beetje tijd en moeite zou jij dat ook kunnen weten; daar heb je echt geen opleiding informatica voor nodig. Alleen de tweaker-eigen nieuwsgierigheid. :P
De vraag is of je het echt gebruikt ;)

Je moet wel de juiste compiler vlagjes aangooien en een compiler hebben die er iets mee doet, anders blijft het mooie verkoop praat
Compilers zijn nog niet zo ver met het effectief gebruiken van die instructiesets. Ze kunnen al heel aardig met vectoren omgaan, maar je kunt nog niet gewoon vertrouwen op je compiler om alles snel te maken. Wie echt voor de performance gaat (en natuurlijk doe je dat als je dit gebruikt) zal toch echt wel stukjes zelf gaan schrijven.
Niet helemaal juist, de gangbare C/C++ compilers (gcc, VC++) bieden gewoon ondersteuning voor zogenaamde intrinsics en speciale datatypes. Dat compileert gewoon rechtstreekts naar de relevante assembly instructies midden in de code waarin je het gebruikt.

Voor onze games gebruiken wij gewoon vector en matrix classes die layeren bovenop die speciale datatypes, zodat je gewoon duidelijk een stukje code als 3 * (a + b) kunt schrijven waarbij a en b vectoren zijn, wat helemaal compileert naar inline assembly. Dit werkt gewoon op de PC(SSE), Xbox(SSE), Xbox360(Altivec) en PS3(Altivec en SPU).

Wel vind ik het jammer dat AMD ervoor heeft gekozen niet de dotproduct-instructie van SSE4 over te nemen. Dat is een "ramp" om te implementeren in standaard SSE of Altivec code omdat de berekening afhankelijk is van alle componenten van de vectoren (je moet doen: mul, rotate, add, rotate, add, waarbij elke instructie afhankelijk is van de uitkomst van de vorige). Het is niet voor niets dat ook de Xbox360 hier een speciale instructie voor heeft, het is een van de meest gebruikte operaties in 3d applicaties.

[Reactie gewijzigd door .oisyn op 30 augustus 2007 22:59]

@ .oisyn
Zou AMD SSE4 dan overslaan ? denk zelf dat tegen die tijd AMD 4 ook al wel ondersteunt.
@Fiander
Waarom zou SSE5 dan functies van SSE4 bevatten als ze toch beiden worden gebruikt?
Lijkt me dat het of SSE4 is of SSE5.
Misschien ook om licentiekosten aan Intel (voor het gebruiken van SSE4) te vermijden.
Intel en AMD hebben een cross license agreement.....
@JW1:
je bedoelt het plaatje ? in dat plaatje staan SSE3 en SSSE3 als onderdeel van SSE4 aangegeven, en als je verder zoekt, zul je vergelijkbare plaatjes vinden, met daarin SSE2 als onderdeel van SSE3, en SSE1 als onderdeel van SSE2.
Ik denk eigenlijk dat dit de consument geen ene zier boeit.

In geen enkel foldertje van media markt (oid) heb ik al eens zien staan wat er aan instructiesets ondersteund wordt, SSE, SSE2, etc.. Het is al een wonder dat ze het hebben over 64-bit en cache geheugen, want zelfs daar snap een gewone consument niks aan. Die denken puur in Gigabytes en Gigahertzen, en hoe meer hoe beter :)

En Tweakers, tja, die houdt je niet zo makkelijk voor de gek :)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True