[cdimauro]

Originariamente inviato da dontbeevil

Titolo onesto:

"Jeff Wilcox torna ad intel, l'ingegnere che Apple strappo' ad Intel"

Meglio ancora:
"Torna a casa veterano Intel, dopo esperienza alla Apple".

@Manolo, ma ti sta tanto sullo stomaco Intel?

Originariamente inviato da ImPeTo

Intel assunse Jim Keller per poi farlo scappare a gambe levate solo qualche anno dopo. Gli auguro di non ripetere lo stesso errore perché ce tanto bisogno di competizione.

E' evidente che non hai nemmeno letto l'articolo.

Keller ha cambiato casacca innumerevoli volte, rimanendo per poco tempo. E' l'equivalente calcistico di Bobo Vieri.

Wilcox ha passato la stragrande maggioranza della sua carriera professionale alla Intel. Quindi torna a casa. Vedilo come un Leonardo Bonucci.

Originariamente inviato da pabloski

Si ok, belle battutine, ma questo conferma quello che i fanboy Apple vanno dicendo, ovvero che i chip Mx sono eccellenti.

Per mesi ci è toccato leggere che quei bench erano tutta fuffa, che è impossibile che siano così potenti e blah blah...

Con quest'acquisizione si conferma che quei chip hanno trombato tutto l'establishment.

Non ne hai azzeccata una. E ce ne vuole...

Originariamente inviato da CrapaDiLegno

Dico questo sostenendo che i core M di Apple sono fantastici, magari un po' pompati rispetto alle loro vere capacità e con il vantaggio non secondario di un ecosistema ad-hoc cucitogli addosso per sfruttarne il massimo (e anche viceversa, l'architettura è stata creata per rispondere a determinati problemi al meglio), cosa che AMD e Intel ma anche ARM stessa non si possono permettere.

Infatti i SoC Apple sono l'emblema dell'estrema personalizzazione.

Intel e AMD potrebbero fare lo stesso, ma poi a chi li vendono i loro chip? Apple ha dalla sua dei solidissimi piani e sa cosa, come, quanto, e quando proporre una determinata tecnologia alla sua clientela.

Ma dimostrano che si possono avere prestazioni elevate senza dover usare l'energia di una centrale atomica se ci si libera di tutti i vincoli del passato (quindi altro che l'ISA x86 non sono il problema delle prestazioni perché i decoder sono piccoli... la dimensione del decoder non è quello che determina le limitazioni di una architettura che usa istruzioni a lunghezza variabile

Diciamo che i decoder (e il legacy x86) incidono di più quando parliamo di core piccoli.

Ma non è più il caso già da parecchio tempo: di core piccoli ormai è difficile vederne nei prodotti mainstream dell'elettronica di consumo.

Infatti i SoC Apple sono rinomati per le prestazioni, ma i suoi core sono molto grandi proprio perché servono vagonate di transistor per arrivare a quei risultati.

con una manciata di registri neanche tutti aggiornati a 64 bit,

Non so a cosa ti riferisca qui. x64 ha tutti i registri a 64 bit. A parte i 6 dei segmenti, che però sono rimasti a 16 bit (per ovvie ragioni).

roba da far accapponare la pelle a pensare cosa avrebbero potuto fare nella transizione 32-64 bit, e invece...).

Infatti. AMD ha preferito aggiungere un'orribile pezza a x86, che già non brillava di suo, per aggiungere i 64 bit, ma peggiorando la situazione.

Invece di fare come ARM, che per l'ISA a 64 bit ha colto l'occasione per riprogettare da zero tutto, sfornando un capolavoro di architettura a 64 bit.

Originariamente inviato da AlexSwitch

Normale amministrazione nella competizione tra aziende concorrenti ( anche se Apple non vende i suoi SoC per Mac a terzi e non ha intenzione di farlo in futuro ).

Esatto. E' una pratica molto comune.

Più che altro mi sembra esagerato il termine " voltafaccia " usato nel titolo e nel testo dell'articolo;

Clickbait o personale antipatia dell'articolista nei confronti di Intel.

erano anni ( da Skylake ) che Apple si lamentava con Intel per le sue CPU energivore, per la qualità produttiva e per i ritardi sullo sviluppo dei nuovi processi produttivi.
Intel ha preferito pensare alla finanza piuttosto che curare una partnership con Apple che comunque andava avanti da anni.
Alla fine a Cupertino hanno deciso di dare fondo alle loro tecnologie maturate in casa su base ARM e farsi la propria roadmap senza condizionamenti terzi.

Il problema di Intel lo sappiamo tutti: è stato l'enorme ritardo col nuovo processo produttivo a 10nm.

Non è stato un problema di finanza o mancanza di volontà nel volersi tenere stretta Apple.

Originariamente inviato da pabloski

Ma Nvidia non si trovava in estrema difficoltà, con un competitor dato per fallito che è risorto dalle sue ceneri e l'avanzata di ARM su tutti i fronti.

E siccome questo signore è un esperto di CPU, probabilmente NVidia lo assunse per lavorare sui suoi SoC ARM e non sulle GPU.

Ma tutti i recenti segnali in casa Intel indicano che quest'acquisizione riguarda proprio le CPU.

Riguarda i SoC. Le CPU (o forse volevi riferirti ai core) sono UNA componente di un SoC.

Questa panzana gira da anni e francamente fa ridere. Le CPU ARM, Intel e AMD non sono componenti segreti che solo gli ingegneri Intel/AMD/ARM conoscono a fondo. E' hardware capillarmente documentato e per il quale è possibilissimo scrivere software ottimizzato, a patto di volerlo e saperlo fare.

Intel stessa c'insegna che si può fare https://www.phoronix.com/scan.php?pa...clear-21&num=1

E non perchè si chiama Intel. Del resto il team dietro a Clear Linux non lavora nella divisione processori.

Non è affatto una panzana. Evidentemente non ti sei mai preso la briga di vedere com'è fatto l'M1 di Apple, e confrontarlo con un qualunque altro processore (non solo di AMD).

Per il resto il fatto che i componenti di Intel o AMD siano standard e pubblici NON vuol dire che si riescano a ottimizzare il codice per sfruttarlo al meglio.

Di recente sono tornato a mettere mano alla mia architettura per completare la parte SIMD. E ho visto il codice che viene generato per AVX-512 (e non solo. Penso che lo stesso si applichi anche alle AVX, ma mi serve ancora un po' di tempo per verificarlo) in un esempio classico. Ci credo che venga preso come esempio di wall-of-code inefficiente, se viene confrontato con quello per ARM, RISC-V, o persino MIPS.

C'è bisogno di mettere seriamente mano ai compilatori (sì: anche quello di Intel).

Originariamente inviato da CrapaDiLegno

Credo che tu non sappia quello che dici.
L'HW Apple è da sempre profondamente customizzato e ottimizzato. Vatti a vedere come avevano supportato i famosi 64 bit per primi che in verità 64 non erano.
HW e compilatore, interfacce e librerie sono sotto il suo diretto controllo e può permettersi di fare cose che chi lavora con terze parti non può.
AMD e Intel non possono permettersi di dire "eliminiamo il supporto a queste 100 istruzioni x86" per usane di migliori, non possono dire "mettiamo questa istruzione in più perché ci facilita il lavoro e chi non ce l'ha si inc*la", non possono mettere side channel per il passaggio di informazioni che necessitano di istruzioni proprietarie.
Apple sì. E non è che se la sua documentazione per creare un compilatore non ti dice che una istruzione non esiste questo significa che loro non l'abbiano usata per creare il LORO OS con le LORO LIBRERIE che sei costretto ad usare per creare gli applicativi sul LORO HW.
E viceversa, non è che se sono compatibili con l'ISA standard ARM (di cui in verità potrebbero benissimo non esserlo) non possono mettere tutte le estensioni che vogliono (è una prerogativa dell'ISA ARM quella di poter essere estesa).

Quindi Apple ha un vantaggio di ottimizzazione che gli altri non possono permettersi (nemmeno Qualcomm che non può costringere a ricompilare Android e tutte le applicazioni perché usa istruzioni nuove).
Apple può e infatti lo fa. Non ha vincoli con nessuno, tanto che è l'unica che si è potuta permettere di passare per 3 ISA completamente diverse in 20 anni.

Esatto. Apple usa ARMv8 e solo quella: niente ARMv7 et similia. E l'ha personalizzata per le sue esigenze.

Intel e AMD non possono fare lo stesso.

A meno di non rimettere mano al progetto e cambiare completamente architettura / ISA.