Intel stopt vijftig nieuwe instructies in 45nm-chips

Intel heeft aangekondigd dat zijn 45nm-processors voorzien zullen worden van ongeveer vijftig nieuwe instructies, die samen SSE4 zullen worden genoemd. De functies kunnen grofweg verdeeld worden in drie groepen: het eerste en overgrote deel is bedoeld om multimedia te versnellen, waaronder spellen, video en 2d/3d-rendering. Om dit soort toepassingen te helpen geeft de instructieset ontwikkelaars en compilers meer gereedschap om met vectoren te werken. Ondanks het feit dat er op dit moment al 259 instructies bestaan in SSE1 tot en met SSE3, hoefde men zich verrassend genoeg toch niet in vreemde bochten te wringen om nog nieuwe features te verzinnen: vrij voor de hand liggende operaties als het opzoeken van het laagste of hoogste getal, afronden, vergelijken en het uitrekenen van een Dot Product (standaardgereedschap voor alles wat zich met 3d bezighoudt) zitten er kennelijk nog niet in. Andere nieuwe instructies verbeteren de prestaties door de samenwerking tussen normale code en vectorcode te versoepelen, bijvoorbeeld door snelle conversie tussen verschillende datatypes.

Het tweede belangrijke deel van SSE4 zijn instructies die het doorzoeken en vergelijken van tekst versnellen. Intel verwacht dat deze erg nuttig zullen zijn voor zaken als virusscanners, compressie, databases en compilers. Ten derde zullen er nog een paar applicatiespecifieke functies worden toegevoegd: een hardwarematige implementatie van het CRC-algoritme (dat bijvoorbeeld gebruikt wordt om te controleren of bestanden intact zijn) en een zogeheten 'pop counter' die telt hoe vaak de binaire 1 voorkomt in een getal. Laatstgenoemde is nuttig voor patroonherkenning en schijnt naast de officiële doelstellingen als handschriftsoftware en gen-analyse ook populair te zijn bij crypto-analisten.

Overigens is de naamgeving 'SSE4' voor sommige mensen wellicht verwarrend, want eerder werd her en der aangenomen dat de nieuwe instructies in de Core 2-processor zo (zouden gaan) heten. De 32 nieuwe instructies in Woodcrest, Conroe en Merom schijnt men echter niet spannend genoeg te vinden om een nieuw versienummer te rechtvaardigen, en deze zijn nu dan ook officieel omgedoopt tot 'Supplemental SSE3'.

Reacties (48)

[-GSF-JohnDoe]

Worden veel van dit soort instructies niet al door de video kaart gedaan? Het is wel fijn dat een cpu dit ook kan, maar je zou denken een video kaart kan het nog altijd sneller.

[Wouter Tinus]

Er is een beetje een strijd aan het ontstaan tussen videokaarten die meer algemene functies krijgen en processors die meer specifieke functies krijgen. Hoewel ze nooit alle taken van elkaar over kunnen nemen is er wel een grijs gebied dat Intel zoveel mogelijk aan zijn kant van het spectrum (de processor dus) wil houden. Intel is er namelijk geheel niet bij gebaat als de behoefte aan meer rekenkracht afneemt c.q. verschuift naar ander componenten die ze zelf niet maken .

[Verwijderd]

zou het?

http://www.intel.com/support/graphics/sb/cs-023086.htm

[Wouter Tinus]

Ik weet dat ze marktleider zijn op het gebied van graphics als het gaat om aantallen, maar hun prestaties zijn bijna lachwekkend te noemen vergeleken bij die van ATi en nVidia (hoewel er tekenen zijn dat ze willen gaan inhalen). Een geïntegreerde videochip vormt in ieder geval geen enkele bedreiging voor een processor, terwijl dikke GeForce of Radeon dat wel is voor bepaalde toepassingen.

[Verwijderd]

lachwekkend? daar zijn ze helemaal niet voor gemaakt, jij en ik spelen misschien graag een spelletje, zijn er genoeg die al dat 3d geweld helemaal niet nodig hebben

en intel is bezig met een cpu met 32 cores waarbij wat nu de gpu is onderdeel wordt van de 86x pipeline, is 4 keer vlugger dan wat een losse 'dikke' gpu daar tegenover kan stellen, waarom denk je dat amd ati heeft overgenomen?

[Wouter Tinus]

lachwekkend? daar zijn ze helemaal niet voor gemaakt, jij en ik spelen misschien graag een spelletje, zijn er genoeg die al dat 3d geweld helemaal niet nodig hebben

Thank you Captain Obvious . Het gaat in deze subdiscussie over dingen die een GPU eventueel sneller kan doen dan een CPU. Als het 3d-geweld van Intels videochips al waardeloos is, wat zegt jou dat dan over de geschiktheid van die dingen voor andere soorten werk?

en intel is bezig met een cpu met 32 cores waarbij wat nu de gpu is onderdeel wordt van de 86x pipeline, is 4 keer vlugger dan wat een losse 'dikke' gpu daar tegenover kan stellen

Dit bevestigt precies mijn originele punt dat er een strijd gaande is tussen processors en videokaarten.

[Verwijderd]

en intel is bezig met een cpu met 32 cores

De marketing afdeling werkt schijnbaar nog echt heel goed bij Intel. AMD doet vast ook onderzoek (is bezig) naar een processor met 1024 cores. Van onderzoek naar eind-produkt is nog een heel lange weg.

edit:

Ik trek mijn keudel terug
http://www.computerbase.d...tel_prototypen_80_kernen/

@Countess
Een FPU zou dus alleen een floating point berekening kunnen uitvoeren maar geen commando's. En er staat in het stuk nergens dat het slechts om FPUs gaat. Er staat zelfs duidelijk dat de cores een zeer vereenvoudige commandoset bevatten die schijnbaar alleen met Floating Point waarden kan rekenen. Laten we wel wezen de x86 architectuur zeker met de uitgebreidere commandosets (zoals SSE3, SSE4, etc...) maken de structuur log. Om 80 van dergelijke CPUs naast elkaar te produceren op 1 chip zal een heidenskarwei worden. Ik vind het de juiste weg die Intel ingaat (ik had eigenlijk gehoopt dat AMD deze weg op zou gaan). Vooral ook omdat de software steeds meer platform onafhankelijk geschreven wordt en ook OSen kunnen ondertussen vrij eenvoudig worden geport.

[Countess]

die 80 cores zijn enkel hele simplele floating point units.
leuk, 80 bij elkaar maar vrij beperkt toepasbaar en vormen samen geen echt cpu.
enige nut dat ik kan bedenken is een co-processor bijvoorbeeld.

[hansg]

Vanaf 32 cores wordt het allemaal anders: dan hebben we helemaal geen GPU meer nodig. 32 CPU's is namelijk voldoende om in realtime te kunnen raytracen.

Linkje, voor de geinteresseerden: http://www.openrt.de/

[peke]

32 cores zijn dan misschien wel krachtig genoeg, de bandbreedte en latencies vd fsb of HT zijn lachwekkend ivm het huidige GDDR3/4.
Er zal dus altijd behoefte zijn aan gpu's.

[klaafstra99]

Zolang de software er niet voor geschreven is, heb je er (helemaal!) niks aan.

[Countess]

niet persee geschreven. het moet iniedergeval ondersteund worden door de compiler waarmee het gecompileerd is.
veel dingen kan de compiler namelijk automatische toepassen.

maar bepaalde stukken herschrijven kan echter zeker geen kwaad voor een aantal dingen als je ze echt optimaal wilt benutten.

[RobLemmens]

En daar komt spul als .net goed tot zen recht. Je compileerd naar de intermediate language en voila, ten tijde dat de applicatie gestart word op de gebruiker zijn computer wordt deze gecompileerd naar machine code en kan er automatisch gebruik van de nieuwe instructies gemaakt worden. Zelfs als deze er niet eens waren toen de software geschreven werd.

[Verwijderd]

En daar komt spul als .net goed tot zen recht.

In theorie ja. In de praktijk is het vaak wel degelijk nodig om in de broncode zelf efficienter om te gaan omdat je weet hoe het later in machinetaal en op de processor afgehandeld kan worden. Sommige processen kun je bundelen of juist splitsen om een sneller resultaat te krijgen. Compilers en .NET zijn geen programmeurs die jouw code wel even perfect herschrijven, het is een vertaling zodat het WERKT op de target machine.

Dat kan ook betekenen dat er soms juist grootste gemene delers gekozen worden die juist minder snellere code opleveren. Compatibiliteit is het hoofddoel, niet prestatie.

Beetje offtopic, maar het is toch ook niet zo dat .NET bij elke willkeurige software ervoor zorgt dat de applicatie opeens efficient multithreaded is? Dat is nog altijd de taak van de broncode zelf.

[SKiLLa]

Ik denk dat RobLemmens bedoelt dat nieuwe versies van VMs & JIT (zoals oa. Java & .Net gebruiken) bestaande code efficienter/sneller kunnen uitvoeren (op die hardware) zonder dat de broncode hoeft te worden aangepast ...

Multi-threading is niet relevant in deze context, het gaat erom dat een JIT compiler efficientere/snellere native-code kan genereren zonder een source-recompile (naar VM opcodes).

Trouwens, met "het is een vertaling zodat het WERKT op de target machine" doe je moderne JIT compilers wel tekort hoor; zo kan de .Net JIT b.v. SSE2 instructies genereren indien je machine dat ondersteunt ... De evaluatie van ondersteunde instructies vindt plaats @runtime en zal dus altijd optimaal gebruik maken van de aanwezige hardware.

[Verwijderd]

dan zou het ook geen bal uitmaken wat je voor procesor er in je kast zit als een videokaart het sneller kan

[Verwijderd]

Het renderen van graphics in Maya of 3D Studio Max, wordt niet over de GPU gedaan. Dit soort software kan wel profiteren van dit soort instructies.

[MneoreJ]

Eerst hadden we CISC processoren. Daarna kwam RISC, met veel eenvoudigere instructiesets. RISC werd toen gebruikt als basis om een CISC processor op te implementeren... en het word nu alleen maar CISCeriger, alleen zijn de instructies nu zodanig dat ze van je CPU een halve dedicated vectoreenheid maken. Dat is met name interessant omdat we nu ook de drive naar multicore hebben: je kunt vectorberekeningen parallel uitvoeren met "gewone" instructies. Je vraagt je dan toch af of CPU en GPU uiteindelijk niet weer dichter naar elkaar toe gaan groeien, na heel lang gescheiden te zijn geweest.

[botervlieg]

Ja, dat is het probleem nu net, alles blijft constant evolueren van centralisatie naar decentralisatie over periodes van 10-20 jaar. Maar nu we eindelijk evolueren naar multicore en parallel processing vind ik het een nogal rare keuze om 'grafische' instructies, of zoveel instructies in een cpu te stoppen.
Ik zou liever een nog meer gedecentraliseerde, modulaire structuur zien, een nieuw soort mobo waar je naar gelang het soort gebruik, cpu's, gpu's, physics units, dsp ... etc instopt.Zou toch handig zijn, je bouwt je computer naar eigen wens. Ben je eerder een gamer of 3d designer dan stop je er een paar grafische cores in, ben je bezig met audio processing, dsp cores ...

en die processing units zouden er dan kunnen uitzien als die van HAL 9000, ipv die onhandige sockets en wanorde in je computer kast

[hardwareaddict]

50 vingers bij intel is toch minder als 50 vingers bij mij.

Tja wel aardige instructies toch.

inproduct is natuurlijk een leuke instructie.

leuker om te zien is de unsigned vermenigvuldiging van:

(int1,int2,int3,int4) * (int5,int6,int7,int8)
en dan de uitslag opslaan in 4 registers van 64 bits;
maar naar ik vrees willen ze alles weer opslaan in 2 registers van 64 bits en niet in 4 registers.

De gierigaards.

Ook uitermate aardig is een hardware matige popcount. in itanium2 (montecito) is die nu 1 cycle en op K8 is dat een paar cycles met een De Bruijn calculatie veel meer cycles als 1, dus daarmee kunnen ze AMD aftroeven, dus hup de instructieset in met dat ding. Voor de big brother types natuurlijk een leuke instructie.

Deze instructies zijn aardig natuurlijk, maar wat je in werkelijkheid wilt hebben op zo'n chip is 2 vermenigvuldingen van

64 bits * 64 bits == 128 bits en dat in parallel.

Daarvoor zijn nodig 2 multiplicatie units op de chip die dat kunnen en momenteel zit er maar 1 op die chip die dat kan.

Zowel intel als AMD doen veel moeite om hun execution units enorm te ontlasten als het gaat om vermenigvuldigen. Vermenigvuldigen zit dicht aan tegen het worst case path, vooral SSE2/SSE3 vermenigvuldigingen en dan kom je dus aan de prijs per product omdat het de yields (aantal geslaagde cores per drukgang) raakt.

Veel number crunching software wordt natuurlijk pas echt significant sneller als je 2 vermenigvuldigingen (int64 * int64) tegelijk kunt doen en alleen maar meer 32 bits instructies lig ik eerlijk gezegd niet op te wachten.

int64 * int64 is 4 cycles op K8 en 3 cycles op core2 en die hebben elk maar 1 execution unit die dat kan uitvoeren.

3 en 4 cycles is enorm traag, bovendien blokkeren die instructies alle andere execution units, dus gedurende een cycle of 4 ben je al je resources kwijt.

Dat zuigt.

Die software wordt letterlijk 2x sneller met NTT (numeric theoretic transforms) als dat momenteel met FFT/DWT (Fast Fourier Transform) het geval is, op het moment dat er 2 multiplication units unsigned 64 bits zijn.

Voor 3d was er natuurlijk al veel. 3d werkt met name met single precision floating point (32 bits grofweg) en voor 3d is de zwakste schakel altijd de graphics card, niet zozeer de cpu zelf.

Die graphics card overbodig maken met nog meer instructies lijkt me een ambitieus plan.

De instructies staan allemaal in het teken van het overnemen van highend calculaties die momenteel op supercomputers lopen en echt totaal niet in het teken van 3d.

Inproduct is belangrijk in veel software die op honderden cpu's tegelijk per run loopt momenteel.

Big-brother-watching-every-email-yours wil graag snel het aantal bitjes kunnen tellen en in alle highend processoren zat die instructie. Overigens dienen ze dan ook BSF en BSR wat sneller te bakken als dat die instructie momenteel is (11 cycles grofweg op de k8).
Door PopCount nu al in SSE4 te stoppen en ervan uit te gaan dat ze die ook naar een beperkt aantal cycles weten te krijgen in toekomstige Core2 chips, maakt intel natuurlijk direct de itanium cpu overbodig en kan die naadloos vervangen door Core2's met SSE4.

De SSE4 dus als instrument om de number crunching volledig over te nemen van IBM en AMD en als onontbeerlijke additie voor alle supercomputer software die met name matrixvermenigvuldigingen uitvoert; mogelijk ook in de hoop natuurlijk de K8L te bevechten die op double precision gebied intel van tafel zou moeten blazen (al stelt AMD die chip wel steeds uit, is 't niet eind 2008 nu dat hij zou moeten uitkomen ipv 2007?).

[Wouter Tinus]

Wat is de code naam van deze processor "Trashcan" "recyclebin"?

Penryn.

[rant over legacy troep]

Backwards compatibiliteit is de drijfveer van de pc-industrie. Nieuwe x86-processors die oude software niet of traag draaien zouden simpelweg floppen. Bovendien is het echt niet zo dat men vandaag de dag nog veel tijd besteed om exotische instructies uit het DOS-tijdperk te implementeren. Lelijke dingen uit het verleden worden alleen nog maar functioneel gemaakt, de optimalisatie van het ontwerp (het echte moeilijke werk) gebeurt alleen voor moderne code. De echte gedrochten zitten zelfs alleen nog maar in software (micro-code) op de chip.

Volgens mij is dit niet in het belang van het vermogens gebruik en produktie kosten?

Dat valt nog maar te bezien. Deze instructies kunnen ervoor zorgen dat er meer werk in hetzelfde aantal kloktikken gedaan wordt (betere prestaties per watt) of dat dezelfde hoeveelheid werk eerder af is en de chip dus eerder terugkan naar slaapstand (zuiniger). Qua productiekosten zou het me verbazen als een 45nm Core2 duurder is dan een 65nm Core2.

[Verwijderd]

Backwards compatibiliteit is de drijfveer van de pc-industrie.

Ik denk dat Apple anders bewezen heeft. Ze gebruiken al de derde processor in hun Mac type. Eerst 68000 familie daarna PowerPC en nu x86.

Over vemogens verbruik.
In gemiddeld gebruik is de processor de meeste tijd in idle status (Desktop en veel (web)servers). Dan geldt toegevoegde functionaliteit is extra transistors is extra lekstroom. Is extra vermogen.

Persoonlijk vind ik het jammer dat de beste processors nu weg of bijna weg zijn. Zijnde Alpha G5 etc. Ik hoop dat de opkommende landen (India en China) een keer een betere processor zullen uitbrengen. Sneller, zuiniger etc. Want dat is met de huidige technologie mogelijk. Zie bv de MIPS en ARM chips tav vermogensverbruik. En de power 5 voor snelheid.

[Wouter Tinus]

Ik denk dat Apple anders bewezen heeft. Ze gebruiken al de derde processor in hun Mac type. Eerst 68000 familie daarna PowerPC en nu x86.

De overstap van 68000 naar PowerPC verliep rampzalig en de stap naar x86 is alleen maar soepel verlopen omdat het systeem via emulatie volledig backwards compatible bleef. Bovendien was het voordeel van x86 boven PowerPC zo groot dat het niet eens grappig meer was. Er is echter helemaal geen indicatie dat een x86-ontwerp zonder 16-bit mode of x87-eenheid ook maar 1% sneller zou zijn dan degene die we nu hebben, dus er is niet echt een motivatie om de compatibiliteit te breken.

Dan geldt toegevoegde functionaliteit is extra transistors is extra lekstroom. Is extra vermogen.

Het blijft een afweging, maar als een ongewijzigde 45nm-versie bijvoorbeeld 20% zuiniger is dan de 65nm-versie en men vervolgens 10% meer gaat gebruiken door nieuwe functionaliteit (een grove overschatting voor een paar nieuwe instructies trouwens) dan heb je netto nog steeds een zuinigere chip. Het zou me trouwens niets verbazen als SSE4 ook al in het huidige ontwerp zit, maar dan alleen voor testdoeleinden.

Persoonlijk vind ik het jammer dat de beste processors nu weg of bijna weg zijn. Zijnde Alpha G5 etc. Ik hoop dat de opkommende landen (India en China) een keer een betere processor zullen uitbrengen. Sneller, zuiniger etc. Want dat is met de huidige technologie mogelijk. Zie bv de MIPS en ARM chips tav vermogensverbruik. En de power 5 voor snelheid.

De 'beste processors' zijn mijns inziens degenen met een goede verhouding tussen prijs, prestaties en verbruik. Voor consumenten zijn dat op dit moment gewoon x86-chips. Andere instructiesets hebben geen magische voordelen die ze 'beter' zouden maken. Denk je bijvoorbeeld dat een ARM nog zo zuinig is als je hem even snel maakt als een Core 2? Of dat een Power nog zo goed presteert als hij voor 200 euro (of nog goedkoper) verkocht moet kunnen worden en maar 65W mag verbruiken? Ik weet wel zeker van niet: het zijn chips gemaakt voor andere markten met andere doelstellingen, en dat zijn veel belangrijkere verschillen dan de instructieset.

[Wouter Tinus]

Als je een nieuwe procesor zou ontwerpen met de R&D-mogelijkheden van de x86, dan zou je waarschijnlijk een aardige sprong voorwaarts kunnen maken.

Misschien, maar dit is een volstrekt onrealistisch scenario. Je hebt niet het R&D-budget van x86 als je niet zo groot bent als x86, en geen enkel theoretisch voordeel in je architectuur gaat je helpen om marktaandeel te winnen. Intel zelf maakt nog de beste kans met Itanium, maar zelfs daar is pijnlijk duidelijk hoe de verhoudingen liggen qua mankracht en budget: Conroe is een handgemaakt meesterwerkje qua layout en circuits, terwijl grote delen van Montecito door software in elkaar zijn gezet. En dat is goed te merken aan de maximale kloksnelheid en fysieke afmetingen van beide cores.

[Verwijderd]

Er is echter helemaal geen indicatie is dat een x86-ontwerp zonder 16-bit mode of x87-eenheid ook maar 1% sneller zou zijn dan degene die we nu hebben, dus er is niet echt een motivatie om de compatibiliteit te breken.

Dat komt omdat de 32-bit en 64-bit modes gebaseerd zijn op die 16-bit modus.
x87 wordt trouwens ook al geemuleerd op een P4, en waarschijnlijk ook in de Core2, is al niet echt meer geimplementeerd dus, behalve in microcode in de decoder. SSE2 is de 'native' FPU nu (mede daarom de slechte x87-prestaties van de P4, maar SSE2 is juist supersnel, zelfs sneller dan Core2 soms).

Maargoed, het punt is dus dat die 32-bit en 64-bit modus zo ontworpen zijn dat er weinig verschil is. Daarom is het niet zo erg dat er ook 16-bit op zit.
Maar dan bekijk je het probleem dus van de verkeerde kant. De 32-bit en 64-bit modes van de x86 zijn namelijk behoorlijk zwak en onelegant ('Een space-shuttle besturen met een pincet'). Als je kijkt naar PowerPC of andere 32/64-bit processors, zie je dat die door de jaren eigenlijk altijd betere IPC, performance-per-watt en meer van dat soort fratsen hadden, mede doordat de instructieset veel efficienter was ontworpen, en daarom de processor kleiner kon zijn. Minder grote decoders, kortere pipelines etc.
Helaas zagen Motorola en IBM het niet meer zitten om de PowerPC nog verder door te ontwikkelen als een desktop-processor, omdat de markt daar te klein voor was.
Zelfs de Itanium van Intel zelf is al efficienter... alleen merk je dat niet zo, omdat ze daar van die hele grote serverchips van bouwen met veel cache en 256-bit bussen etc. Maar puur de core van een Itanium is wel een stuk kleiner dan van een moderne x86, en dat is ook bij multicore straks veel interessanter. Je kunt er namelijk veel meer van op 1 die krijgen.

Vanuit dat oogpunt lijkt het me dus wel een goede zet om gewoon de legacy vaarwel te zeggen en opnieuw te beginnen. x86 heeft al die jaren nooit echt aan de top gestaan, ze hadden vooral een schaalvoordeel, waardoor Intel meer R&D erin kon stoppen en de processors dus beter leken dan dat ze eigenlijk waren.
Als je een nieuwe procesor zou ontwerpen met de R&D-mogelijkheden van de x86, dan zou je waarschijnlijk een aardige sprong voorwaarts kunnen maken.

[Tomatoman]

Al die nieuwe instructiesets zijn prachtig, maar ze zadelen programmeurs wel met een probleem op. In speciale CPU-registers valt bij iedere moderne x86-processor op te zoeken welke instructies ondersteund worden, maar een programmeur kan moeilijk rekening houden met alle mogelijke situaties.

Om bijvoorbeeld gebruik te kunnen maken van SSE4-instructies kunnen delen van de code, moet de software daarvoor speciaal worden gecompileerd. Dan is er een executable die wel heel snel kan rekenen, maar aangezien verreweg de meeste CPU's nog niet met SSE4 overweg kunnen moet er ook een stuk code worden opgenomen voor al die computers zonder SSE4. Er komen dan stukken code die in verschillende varianten zijn geschreven en die precies hetzelfde doen, namelijk voor SSE4, SSE3, SSE2, SSE, MMX en/of zonder 'speciale' instructies.

Om hieraan te ontkomen zullen de meeste programmeurs ervoor kiezen om de nieuwere SSE-instructies zoveel mogelijk te vermijden. Daardoor zul je SSE3 en SSE4 nauwelijks tegenkomen op andere plaatsen dan game engines en een paar specialistische, rekenintensieve programma's. Mooi bedacht die nieuwe instructies, maar in de praktijk zal bijna niemand ze gebruiken.

[humbug]

Een programmeur hoeft ook geen rekening te houden met die verschillende problemen. Daar heb je een compiler voor.
Bij het compileren van de hogere programmeertaal (o.a. c++) naar de machinecode bepaald de compiler in welke gevallen zaken als SSE1,2,3 en 4 interessant zijn en worden die geimplementeerd. Maar bij zo'n implementatie wordt er ook een alternatief voorzien voor CPUs die de functionaliteit niet hebben.

Als programmeur gebruik je dus een functie als dotproduct(M1, M2) en de compiler doet de rest.

[MneoreJ]

maar een programmeur kan moeilijk rekening houden met alle mogelijke situaties.

Dat wordt dan ook niet verwacht. De programmeur moet rekening houden met alle interessante situaties.

Als jij of je compiler geen SSE4 support diggen, stop je het er gewoon niet in. De reden dat je het er nou net wel in zou stoppen is omdat je weet dat je dingen aan het doen bent die goed kunnen profiteren van de nieuwe instructies.

Om hieraan te ontkomen zullen de meeste programmeurs ervoor kiezen om de nieuwere SSE-instructies zoveel mogelijk te vermijden.

Onzin. Inspelen op de processorcapaciteit is gewoon wat extra werk (een sprongtabel opzetten voor de verschillende versies van functies). De performancewinst die SSE oplevert maakt dat ruimschoots goed. Programmeurs gaan er niet voor "kiezen" ze "zoveel mogelijk te vermijden", ze gaan het gewoon niet gebruiken als niet duidelijk is dat het winst oplevert. Dat is een heel andere insteek. Vergeet niet dat als een programma "snel genoeg" is dat het niemand een drol kan schelen of je SSE gebruikt, en als een programma "niet snel genoeg" is zullen programmeurs hemel en aarde bewegen met de gekste trucs om het maar sneller te krijgen -- en SSE is dan nog niet eens een gekke truc.

Daardoor zul je SSE3 en SSE4 nauwelijks tegenkomen op andere plaatsen dan game engines en een paar specialistische, rekenintensieve programma's.

Ja, én? Dat is nou ook precies waar je die instructiesets nodig hebt! Dacht je soms dat Office of WinRAR een stuk sneller zouden gaan als ze SSE gebruikten? Als je echt algemene ondersteuning wil moet je een runtime ertussen zetten met een vectorizing API -- dat wordt een ingewikkeld verhaal, en je hebt de overhead van de runtime erbij. Hier zouden de meeste applicaties gewoon niet van profiteren. Als je in Java of .NET bezig bent is het een ander verhaal, want dan betaal je die prijs toch al.

Een interessantere aanpak is compilermagie te gebruiken. Je gebruikt dan een algemene aanpak die de compiler als vectoroperaties herkent, en de compiler genereert dan functies die afhankelijk van de herkende processor andere instructies gebruiken. Dat heeft enorme voordelen voor de onderhoudbaarheid en schaalbaarheid van de code, want je krijgt een hoop portability "gratis".

Iets soortgelijks bestaat al in de huidige compilers met vectorizing optimalisaties, maar het staat nog in de kinderschoenen (vaak kun je maar voor één bepaald platform compileren, bijvoorbeeld, niet automatisch runtime code laten genereren voor meerdere platforms, en vectorizing operaties herkennen gaat vaak ook nogal slap). Dat extra werk voor de programmeur gaat alleen maar afnemen in de toekomst.

[hardwareaddict]

Je hebt helemaal gelijk.

Met SSE4 willen ze ook niet op jouw pc gaan rekenen.

Ze willen enkel en alleen AMD de loef afsteken op benchmarks waar ze WEL SSE4 kunnen gebruiken en hun cpu's meer potentie geven in de highend waarin wel speciale executables met SSE4 gebakken kunnen worden voor allerlei number crunching software.

Eigenlijk zouden ze objectief gesproken natuurlijk al die SSE1-4 standaarden in prullenbak moeten doen en gewoon die instructies aan x86-64 moeten toevoegen, want die waardes zitten toch al in dezelfde registers.

3 execution SSE/SSE2 execution units van Core2 zijn letterlijk gecast op 3 normale general processor execution units. Dus in principe is die overgang al naadloos.

Het probleem is dan dat AMD ze finaal wegblaast met K8L, terwijl microsoft ook niet blij gaat zijn; anderzijds kunnen ze met SSE4 wel een en ander voordeel behalen en ook nog de highend 't leven gemakkelijker maken bij al die number crunching berekeningen.

Die lui compileren wel degelijk hun programma speciaal voor alleen die paar duizend chips in zo'n supercomputer met SSE4 extensies.

Dan is SSE4 wel degelijk een enorm groot voordeel om mee te rekenen.

[iceblink]

dotproduct heet in het Nederlands inwendig product of kortweg inproduct

http://nl.wikipedia.org/wiki/Inproduct

[ernstblaauw]

Kan AMD nu ook gebruik maken van deze 'SSE4'? Of is dit nog niet geregeld in bestaande overeenkomsten tussen de bedrijven?

[Countess]

volgens mij mogen ze er idd al gebruik van maken.
maar ik zou het nog niet en AMD's aankomende CPUs verwachten. dit soort dingen in je ontwerp opnemen kost tijd, tijd die AMD niet kwijt wil raken.

[SuperDre]

Is leuk en aardig, maar hoe goed worden nu de huidige SSE1-3 al gebruikt?

[Countess]

2 word zeker een hoop gebruikt. (en waarom ook niet, elke beetje modern CPU heeft het)
3 nog een flink stuk minder maar ook daar zie je verbetering.
maar over het algemeen duur het jaren voor het wijd verbreid is.
van de andere kant de applicaties die er echt veel baad bij hebben zijn er meestal een stuk sneller mee (denk aan photo shop en 3d max bv)

[Verwijderd]

Elk software pakket waarop staat dat het minstens een pentium 3 800mhz of compatible processor nodig heeft, heeft geen SSE2.

SSE werd in de pentium 3 geintroduceerd. De programma's die SSE2 gebruiken zullen dus of alles dubble moeten schrijven of de minimum eisen moeten verhogen naar pentium 4 of compatible.

Mac OSX gebruikt SSE3.

[Verwijderd]

Even een reactie op het plaatje... mis ik niet het 130nm procedé?

[Wouter Tinus]

In de Northwood zijn geen nieuwe instructies toegevoegd.

[da_flipped_man]

dat zouden AMD en ATI misschien ook willen doen...
nieuws: Gerucht: AMD-ATi gaat gpu op cpu bakken