Link alla notizia: http://www.hwupgrade.it/news/cpu/22355.html

Attese per il 2009, le prime cpu dotate di core Bulldozer implementeranno tra le altre il nuovo set di istruzioni SSE5

Click sul link per visualizzare la notizia.

Ho un dubbio ancestrale sulle istruzioni SSE.

Chi determina quali istruzioni devono esserci all'interno?

Nel senso che fino ad ora ero convinto che Intel le proponesse e che AMD le corresse dietro...

Invece a quanto sembra ognuno fa quel che vuole e chi le presenta prima deve sperare che l'altro lo segua per evitare incompatibilità.

Se è così siamo all'assurdo!!

Notizia interessante, se AMD intende lanciare quasta nuova architettura nel 2009 significa che K10 avrà un ciclo di vita relativamente breve.

ma ogni quanto li cambmbiano sti socket?

comunque succederà:
a.FLOP
b.Piattaforma innovativa ma con enormi colli di bottiglia..

Non ti sembra un pò presto per azzardare questi pronostici?

Hitman prevede il futuro.
Magari c'e' la possibilità
c. Processore degno concorrente di intel e si arrabattano con gli sconti per venderne il più possibile entrambi con grande gioia nostra.

E quali sarebbero i colli di bottiglia?

Invece a quanto sembra ognuno fa quel che vuole e chi le presenta prima deve sperare che l'altro lo segua per evitare incompatibilità.

Se è così siamo all'assurdo!!Ci hai preso. AMD vuole ri-fare quello che è successo con gli A64 e le sue istruzioni a 64-bit. Si vede che è l'unico modo per scalfire il gigante Intel, a meno che questo non implementi le SSE5 già nel 2008 ;)
Assurdo comunque dare notizie su una CPU prevista nel 2009, due architetture avanti a quelle odierne :mbe:

ero pessimista riguardo ad ogni fronte di AMD, fino a poco fa.
ora invece credo di più che si stiano muovendo bene: prodotti "intelligenti" in quanto a features, consumi ridotti, prezzi bassi, "facilità" e lineups veloci... fidatevi amd in toto stupirà tipo il Wii anche senza prestazioni mostruose : )

strano a dirsi ma vi assicuro che non sono un fanboy... solo ottimista!

Chi determina quali istruzioni devono esserci all'interno?

Chi inventa un set di istruzioni definisce l'interfaccia esterna per utilizzare queste istruzioni, poi come lavorano all'interno del processore lo sa solo chi produce il processore stesso. Esempio:
Intel inventa l'SSE, definisce le istruzioni e implementa nel processore i meccanismi per eseguirle. AMD se vuole (e in genere vuole) si adegua, implementa A MODO SUO le SSE nei propri processori in modo che possano essere usate dagli stessi software. Il vantaggio prestazionale non è detto che sia lo stesso tra i due processori, perché ognuno le ha implementate a modo suo. Generalmente Intel è quella che propone, AMD quella che segue, e il vantaggio prestazionale (inteso come guadagno prestazionale nell'utilizzo di queste istruzioni rispetto al non utilizzo delle stesse) è per la prima (Intel).
AMD a volte ha anche proposto dei set di istruzioni propri, tipo 3DNow!, ma Intel non l'ha seguita.

Assurdo comunque dare notizie su una CPU prevista nel 2009, due architetture avanti a quelle odierne :mbe:

Si sa niente sulle CPU previste per il 2256?

@burlone Solo che avraqnno 1024 processori e che avranno un tera di memoria cash :)

Ma io mi chiedo... un programma per supportare i set di istruzioni deve essere progettato apposta?
Tipo, se io progetto un programma che supporta le SSE5, e ho un Core 2 non posso eseguirlo?

AMD a volte ha anche proposto dei set di istruzioni propri, tipo 3DNow!, ma Intel non l'ha seguita.

Anche x86-64 è un progetto di amd, e intel l'ha seguita in questo caso. ;)

Ma io mi chiedo... un programma per supportare i set di istruzioni deve essere progettato apposta?
Tipo, se io progetto un programma che supporta le SSE5, e ho un Core 2 non posso eseguirlo?Tu programmi con a mente alcune "scorciatoie" nel caso la CPU supporti tali set di istruzioni. Nel caso non lo faccia, semplicemente andrà un po' più lenta (o, se vuoi il bicchiere mezzo pieno, andrà più veloce nel caso le supporti).

Ma io mi chiedo... un programma per supportare i set di istruzioni deve essere progettato apposta?
Tipo, se io progetto un programma che supporta le SSE5, e ho un Core 2 non posso eseguirlo?

Il programma capisce da solo se ci sono le SSE5, se ci sono esegue il pezzo di codice che funziona solo su SSE5 (e che andra' presumibilmente piu' veloce) altrimenti usa le SSE4 o quello che vuole, generalmente le si usa soltanto per algoritmi specifici nei quali il vantaggio prestazionale è tangibile, il resto del codice è scritto in linguaggio di medio livello, non in assembler. Anche il codice C/C++ comunque puo' essere ottimizzato per i vari set di istruzioni in fase di compilazione, se ad esempio si sa che il programma girera' soltanto dai Pentium 3/Athlon XP in su, lo si compila direttamente per SSE1.


Anche x86-64 è un progetto di amd, e intel l'ha seguita in questo caso.

Vero, non ci pensavo.

Non se fai la bastardata che ha fatto Adobe con Premiere 2, obbligando ad usare una cpu con supporto alle SSE2 e tagliando fuori così, con nonchalance, gli Athlon XP...

Anche Apple ad esempio, ha compilato interamente il sistema operativo per SSE3, tanto i primi mac intel erano dei Core Duo.

Se usano la sigla SSE5 per me c'entra di sicuro la Intel.

OK, grazie a tutti.

Non se fai la bastardata che ha fatto Adobe con Premiere 2, obbligando ad usare una cpu con supporto alle SSE2 e tagliando fuori così, con nonchalance, gli Athlon XP...

non vorrei dire cavolate ma solo i primi athlon xp non avevano le ss2 (core paolimino per capirsi), il barton mi pare di si!

...da quando fu introdotta l'istruzione con mnemonico assembler CPUID, è la sua esecuzione che permette di stabilire le caratteristiche hardware del processore.
In virtù di ciò, poi, è possibile utilizzare diramazioni (previste in fase di stesura del programma) facenti uso di particolari tipi di set di istruzioni s.i.m.d (nella fattispecie).
Quanto agli adeguamenti ai set di istruzioni, ciò è molto "semplice" e la metodologia è in auge come minimo (parlando di processori a circuito integrato) dall'epoca in cui esitevano dei veri e propri cloni del processore per anonomasia a 32 bit di Intel: l'80386.
Con analizzatori di stati logici e ssitemi di in-circuit-emulation era (e figuratevi oggi in epoca di GHz e TiB) possibile inserire un processore "originale" 80386 su apposito socket e averlo descritto (con vari livelli di astrazione) in termini comportamentali (naturalmente esplorando tutto l'Universo del set di istruzioni x86 a 16 e 32 bit).
Come inciso il Verilog naque proprio negli anni '83-'85 del secolo scorso...
Le prime implementazioni di set di istruzioni "multimediali" partendo dalle M.M.X e proseguendo con le S.S.E, quasi sicuramente per l'insufficiente "numero di transistor" integrabili era imlementato ricorrendo a del microcodice con relative P.L.A.
Grazie.

Marco71.

no, nemmeno il barton le ha, amd ha inserito una estensione delle SSE2 solo con i primi A64 e Opteron.
Comunque il modo con cui vengono chiamate questi set di istruzioni e a dir poco fuorviante, perchè ogni volta che vengono implementate in una famiglia di processori, oltre ad essere implementate in modo più o meno diverso a seconda dei casi, spesso vengono "estese" , ma poi di fatto si chiamano SSE2 sia la versione di intel che quella di AMD, senza tenere conto ne che sono implementate diversamente ne che uno dei due Set ha più istruzioni dell'altro.
Alla fine vanno avanti così sia Intel che Amd...volendo fare un breve sunto la storia è andata così (stando a quello che dice wikepedia)
-Intel pensa di implementare infelicemente le MMX
-Amd rivisita la MMX in modo più felice e sforna 3Dnow!, nei K6 mi pare, poi le estende in Enhanced 3Dnow! e Enhanced 3dNow Pro negli anni a seguire.
-Intel di risposta sforna le SSE nel PIII
-Amd già che c'è aggiunge il supporto alle SSE insieme a estensione del 3dNow negli XP.
-Intel sforna le SSE2 con i primi P4
-Amd sforna le AMD64 e già che c'è implementa una rivisitazione estesa delle SSE2
-Intel è costretta a conformarsi all'AMD64 e sforna EM64T aggiornando a sua volte le SSE2 come amd
-Intel sforna le SSE3 con il Prescott
-Amd implementa le SSE3 in una rev degli A64
e stando a quello dichiarato..
-Intel implementa le SSE4 in Penryn
-AMD implementa una rivisitazione castrata delle SSE4 chiamata SSE4a

Tutto questo alla fine, in termini pratici significa poco, perchè come detto precedentemente, ogni singola implementazione porta vantaggi prestazionali differenti...quindi tutta sta confusione è solo una ulteriore complicazione nel confronto di CPU con architettura differente. Ecco perchè non ha senso parlare di "vantaggio prestazionale" in generale parlando di CPU.. l'unica cosa che si può fare è paragonare diversi tipi specifici di benchmark..e vedere come e dove va meglio una di un altra...ovviamente se si scegli di fare il paragone per Clock, per fascia di mercato o per PRating. Che casino :p

Si, ok, ma basta con i cambi di socket ogni anno, mi sono rotto le balle, se mi passate il francesismo..
Ma certo, se mantenessero i socket e le compatibilità con le memorie, come farebbero a spennarci come i polli?
Minchia che odio..

dalla news:
"Sul sito AMD dedicato agli sviluppatori sono disponibili, a questo indirizzo, ulteriori dettagli su questo nuovo set di istruzioni. Non è chiaro al momento attuale se Intel deciderà di seguire questa strada per le proprie future architetture di processore, o se deciderà di sviluppare differenti estensioni del set di istruzioni SSE attualmente disponibili."

quindi le ss5 non sono, come si potrebbe pensare e come è stato finora la nuova specs delle sse definita da intel che verrà poi adottata anche da amd, ma un nuovo set di istruzioni simd che amd si è inventata di suo ?
(in tal caso potrà essere "sse5" il nome uffciale ? non è un marchio registrato di intel ?)

se effettivamente stavolta è amd ad essersi portata avanti col lavoro per l'ormai abituale nuovo set simd, spero che questa volta sia intel ad accodarsi, la prospettiva di avere due set simd diversi anche se magari totalmente incompatibili da una parte rende ancor più accesa ed interessante la competizione tecnologica, ma dall'altra scradinerebbe quello che +/- ora è uno standard di fatto

e forse per la diffusione e fruibilità per l'utenza di apps che beneficino a fondo di queste istruzioni, in mancanza di uno standard concordato a tavolino, meglio averne uno "di fatto" con un competitor che definisce le specifiche e l'altro che segue piuttosto di due set simd incompatibili, come è stato fin'ora prima con le mmx e poi con le sse dal p3 ion poi (con la parentesi delle 3dnow! che alla fine sono morte nell'oblio)

In molti ambiti scientifici, dalla fisica , all'ingegneria, all'agraria ecc si usano programmi di ricerca, fatti dagli stessi ricercatori(che non hanno studiato ingengeria del software). In genere questi programmi non sono complessi, ma hanno un numero di variabili elevatissime. Spesso viene usato il fortan e poi il compilatore ottimizza in base al processore.

Inutile dirlo, GNU/Linux si compila come tutto il software open source, ci sono molte distro compilate per ogni architettura(tipo ark-linux), gentoo ottimizza al massimo, debian e derivati anno apt-build (che uso con soddidfazione).
Per esempio io uso anche swiftfox, una versione di firefox identica, ma compilata per varie architetture(e la differenza si sente).

I Programmi professionali, come Autocad, Maya, Matlab (insomma quelli che costano) ecc anno all'interno i binari per i vari tipi di istruzioni. Un po' come i fat-binary della Apple che contengono codiìce per i vecchi G4-G5 e i nuovi intel (anche se il discorso è diverso)

dire già che fra 18mesi punteranno su nuova cpu con nuovo socket non invoglierà di certo le persone a comprare i Barcelona su socket am2 :rolleyes:

suppongo che questo "bulldozer", visto che si parla di arch totalmente nuova, sdia quello che ormai anni fa veniva chiamato k9 e di cui non si sentiva nulla da tempo ... ora magari a suo tempo sarà "etichettato" come minimo k12

certo suona "strano" per amd, la quale dopo ben 4 anni e qualche mese di k8 (primi opteron a primavera 2003) programmerebbe un "k12" per il 2009 quando l'amcora non commercializzato k10 dovrebbe diffondersi veramente solo nel 2008 (anche perché in relazione al futuro socket am3/ddr3 si era sempre parlato di k10 e di 2008 o 2009)

... magari, se verranno grosso modo confermati i tempi della news, "bulldozer" uscirà solo a fine 2009 ed all'inizion con "tutta calma" solo con qualche versione server, tipo gli immineneti k10 e penryn di adesso... anche se solo 2 anni di tempo di vita al top tot. per una nuova arch (con fase "a regime" quindi ancora più ridotta) sembrerebbero cmq tempi relativamente serrati non consueti per amd... anche se può pure essere benissimo che abbiano deciso di uniformarsi al ritmo biennale che intel dice di voler tenere
:boh:

no, nemmeno il barton le ha, amd ha inserito una estensione delle SSE2 solo con i primi A64 e Opteron.

hai ragione ;)


GNU/Linux si compila come tutto il software open source, ci sono molte distro compilate per ogni architettura(tipo ark-linux), gentoo ottimizza al massimo, debian e derivati anno apt-build (che uso con soddidfazione).
Per esempio io uso anche swiftfox, una versione di firefox identica, ma compilata per varie architetture(e la differenza si sente).

vero, ti correggo qualche cosina :) Arch linux e non ark linux, sono 2 distro diverse. Arch linux è ottimizzata per i686, con gentoo compilando tutto da zero è possibile utilizzare tutte le istruzioni della propria cpu, gcc permettendo.

Cmq vorrei dire che anche il compilatore fa la sua parte, con il gcc 4.3 per esempio sarà possibile compilare con le cxflags -core2 utilizzando quindi anche le ss3 per eseguire i programmi. E' un bel vantaggio rispetto alla compilazione i386 di windows xp tanto per fare un paragone. Ritengo che la compilazione sia importante, basta pensare che con un core duo e super pi compilato, faccio quello da 1mb in 5.2 secondi, roba che su windows manco con un core2duo a 4ghz ci si arriva (penso faccia sui 17 secondi). Insomma viva le sse :asd:

Ecco il casino che sta facendo AMD:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3073
C'è l'immagine che chiarisce tutto

...per architetture Core Intel (ma anche di norma per molte altre famiglie di processori Intel come Pentium 4, Pentium III, Pentium II, Pentium PRO ma senza possibilità di utilizzare set di istruzioni s.i.m.d) i migliori compilatori c/c++ e fortran sono quelli, neanche a dirlo, Intel.
Sono disponibili anche per Linux (oltre che naturalmente per s.o Windows) e, tra l'altro, hanno sistemi di "parallelizzazione automatica" ed un vectorizer "superiori" a quelli disponibili con compilatori G.N.U.
Non è un caso che i più veloci codici eseguibili per S.e.t.i/B.O.I.N.C siano compilati proprio con compilatore Intel c/c++, I.P.P e librerire math kernel sempre Intel.
Grazie.

Marco71.

...per architetture Core Intel (ma anche di norma per molte altre famiglie di processori Intel come Pentium 4, Pentium III, Pentium II, Pentium PRO ma senza possibilità di utilizzare set di istruzioni s.i.m.d) i migliori compilatori c/c++ e fortran sono quelli, neanche a dirlo, Intel.
Sono disponibili anche per Linux (oltre che naturalmente per s.o Windows) e, tra l'altro, hanno sistemi di "parallelizzazione automatica" ed un vectorizer "superiori" a quelli disponibili con compilatori G.N.U.
Non è un caso che i più veloci codici eseguibili per S.e.t.i/B.O.I.N.C siano compilati proprio con compilatore Intel c/c++, I.P.P e librerire math kernel sempre Intel.
Grazie.

Marco71.

;) grazie per l'intervento molto interessante :)

Ecco il casino che sta facendo AMD:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3073
C'è l'immagine che chiarisce tutto

Più che altro direi che "stavolta il casino lo sta facendo AMD prima di Intel": è normale che un produttore cerchi di implementare quello che pensa sia meglio anzichè implementare (in ritardo) ciò che il competitor produce per i suoi scopi.
E tra l'altro anche anandtech conclude che sebbene sia una mossa rischiosa, le potenzialità di queste estensioni sono decisamente notevoli (senza contare che saranno il primo passo verso Fusion).

...figurati...di niente...

Marco71.

Più che altro direi che "stavolta il casino lo sta facendo AMD prima di Intel": è normale che un produttore cerchi di implementare quello che pensa sia meglio anzichè implementare (in ritardo) ciò che il competitor produce per i suoi scopi.
E tra l'altro anche anandtech conclude che sebbene sia una mossa rischiosa, le potenzialità di queste estensioni sono decisamente notevoli (senza contare che saranno il primo passo verso Fusion).L'implementare solo un sotto insieme delle SSE4 a me sembra un suicidio commerciale, volendo Intel può porre pressione proprio sulle funzionalità mancanti. Inoltre non vedo di buon occhio il voler imporre uno standard sfruttando l'infrastuttura di altri (che sarebbero le SSE). Sarebbe stato più corretto chiamarle 3DNow!2, o ASSE (AMD SSE).

Le conclusioni di AnandTech (che poi sono le prime impressioni) danno una visione negativa del tutto, ma per mantenere una certa imparzialità citano come buona innovazione la funzionalità MADD, non disapprovando quindi in partenza l'iniziativa.

Frasi come:
"Simply put, we believe AMD will be unsuccessful with SSE5 if Intel is unwilling to add it to their own processors"
"Without Intel's support developers will code for the least-common-denominator among the extensions, or worse will focus on any Intel-only extensions should the two CPU families further diverge, something that is more likely to result now due to AMD's failure to include full SSE4 support on Bulldozer."
"Intel failing to support SSE5 at the hardware level will mean that they will also not include it with their compiler. Intel's compilers are near-legendary in their ability to optimize code in the right situations"
"we are always more concerned about them than Intel due to AMD's operating position"

Sono impietose.

Per me, come già detto, AMD sta raschiando il barile tentando di ripetere il colpaccio delle istruzioni a 64-bit (che gli han pur sempre garantito il 5% di supremazia in tali ambienti rispetto a quelle Intel, senza contare una certa supremazia tecnologica).

Sarà curioso ora vedere Intel.

L'implementare solo un sotto insieme delle SSE4 a me sembra un suicidio commerciale, volendo Intel può porre pressione proprio sulle funzionalità mancanti. Inoltre non vedo di buon occhio il voler imporre uno standard sfruttando l'infrastuttura di altri (che sarebbero le SSE). Sarebbe stato più corretto chiamarle 3DNow!2, o ASSE (AMD SSE).

Le conclusioni di AnandTech (che poi sono le prime impressioni) danno una visione negativa del tutto, ma per mantenere una certa imparzialità citano come buona innovazione la funzionalità MADD, non disapprovando quindi in partenza l'iniziativa.

Frasi come:
"Simply put, we believe AMD will be unsuccessful with SSE5 if Intel is unwilling to add it to their own processors"
"Without Intel's support developers will code for the least-common-denominator among the extensions, or worse will focus on any Intel-only extensions should the two CPU families further diverge, something that is more likely to result now due to AMD's failure to include full SSE4 support on Bulldozer."
"Intel failing to support SSE5 at the hardware level will mean that they will also not include it with their compiler. Intel's compilers are near-legendary in their ability to optimize code in the right situations"
"we are always more concerned about them than Intel due to AMD's operating position"

Sono impietose.

Per me, come già detto, AMD sta raschiando il barile tentando di ripetere il colpaccio delle istruzioni a 64-bit (che gli han pur sempre garantito il 5% di supremazia in tali ambienti rispetto a quelle Intel, senza contare una certa supremazia tecnologica).

Sarà curioso ora vedere Intel.

"But with those warnings out of the way, don't take this as a disapproval of SSE5. We believe that this will be the most important extension to the x86 instruction set since SSE2, and the new instructions like MADD in particular can offer the kind of performance improvements AMD wants to hit while avoiding the need to increase clock speeds significantly and the problems that result from such. What such a performance increase will be on actual applications however is something we're going to have to wait on the delivery of Bulldozer silicon to find out."

Il succo del discorso è che questa è comunque una mossa rischiosa (e l'avevo già detto) tuttavia per AMD potrebbe essere più fruttuosa che non il continuare a (in)seguire Intel sul fronte SSE, soprattutto datosi che AMD ha un progetto, Fusion, che dividerà ancora di più le strade intraprese sull'estensione dell'ISA x86 dai due produttori, e di cui queste "SSE5" paiono soltanto essere le prime avvisaglie. Una mossa d'altra parte comprensibile, visto che alcune inclusioni (tipo il ricorso ad operazioni di tipo MADD, a più operandi) sono derivate dal lavoro svolto nel campo GPU da ATI, e che Intel difficilmente cercherà di includere in estensioni successive alle SSE4.

guardando al futuro meno lontano, mi pare cmq una cosa non simpaticissima per gli utenti il fatto che amd implmenti sse4 "castrate"(si sà in che rapporto è il sottoinsieme sse4a con la totalità ? differenza grande o poco significativa ?) nel k10 e che probabilmente non le metta affatto nel "k12", in quanto, visto che intel le introduce con gli imminenti penryn e con ogni probabilità le manterrà anch sulle future arch con "sse5 made in santa clara" (come ha sempre fatto), nei prossi anni si presume che ci sarà qualcosa in circolazione che le sfrutti e chi avrà le prossime cpu amd non potrà usufruire al meglio di tali sw

altra cosa: sembrava dalla news (o anche da un'altra di questi giorni) che bulldozer sarebbe stato il primo core ad integrare una gpu, ma da quel che leggo delle madd nelle sse5 come "primo passo" verso questo tipo di implementazione, pare che "fusion" sia ancora più in là nel futuro... :wtf:

altra cosa 2: leoneazzurro, dalle tue considerazioni sulla futura accentuata divergenza delle estensioni al set x86, sembra di intuire che intel abbia in qualche modo fatto sapere di non avre affatto in programma, al contrario di amd, di integrare core grafici nella cpu... è effettivamente questa la direzione o "intuisco" male io ? :stordita:

... cmq apparte i "dettagli", ma se in futuro i due non si sfideranno più con "marcatura stretta", imho, non so quale, ma uno di due rischierà di prendre una brutta botta... :sofico:

guardando al futuro meno lontano, mi pare cmq una cosa non simpaticissima per gli utenti il fatto che amd implmenti sse4 "castrate"(si sà in che rapporto è il sottoinsieme sse4a con la totalità ? differenza grande o poco significativa ?) nel k10 e che probabilmente non le metta affatto nel "k12", in quanto, visto che intel le introduce con gli imminenti penryn e con ogni probabilità le manterrà anch sulle future arch con "sse5 made in santa clara" (come ha sempre fatto), nei prossi anni si presume che ci sarà qualcosa in circolazione che le sfrutti e chi avrà le prossime cpu amd non potrà usufruire al meglio di tali sw

altra cosa: sembrava dalla news (o anche da un'altra di questi giorni) che bulldozer sarebbe stato il primo core ad integrare una gpu, ma da quel che leggo delle madd nelle sse5 come "primo passo" verso questo tipo di implementazione, pare che "fusion" sia ancora più in là nel futuro... :wtf:

altra cosa 2: leoneazzurro, dalle tue considerazioni sulla futura accentuata divergenza delle estensioni al set x86, sembra di intuire che intel abbia in qualche modo fatto sapere di non avre affatto in programma, al contrario di amd, di integrare core grafici nella cpu... è effettivamente questa la direzione o "intuisco" male io ? :stordita:

... cmq apparte i "dettagli", ma se in futuro i due non si sfideranno più con "marcatura stretta", imho, non so quale, ma uno di due rischierà di prendre una brutta botta... :sofico:

Il discorso è che AMD intende integrare non solo i core grafici nella CPU, ma di renderli accessibili da parte dell'ISA. Questa strada al momento non è del tutto chiaro se verrà intrapresa anche da Intel (nonostante gli annunci su "Larrabee", e se lo sarà, comunque non credo che le due soluzioni saranno compatibili. Quello che dici è vero, è più probabile che i programmatori sfruttino le estensioni più diffuse, evidentemente quello su cui punta AMD è che vi siano comunque sviluppatori che useranno queste estensioni e che queste siano effetttivamente molto più performanti di quelle di Intel, spingendo altri sviluppatori ad avere path specifici AMD e nelle loro applicazioni.