Link alla notizia: https://www.hwupgrade.it/news/cpu/intel-strappa-ad-apple-l-ingegnere-che-ha-realizzato-m1-il-chip-del-clamoroso-voltafaccia_103743.html

Jeff Wilcox, uomo che ha guidato la transizione di Apple dai chip Intel alle soluzioni M1 proprietarie, ha detto addio alla casa di Cupertino per passare proprio nelle file di Intel dove si occuperà di sviluppare i SoC per il settore client.

Click sul link per visualizzare la notizia.

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 mentre Apple si preoccupava di facebook... :asd:

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.

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.per mesi cosa avrebbero detto?

Credo che il suo ruolo sarà quello di trovare le migliori soluzioni per sfruttare le nuove interfacce di comunicazione (EMIB e Foveros) che Intel intende usare su tutte le CPU da MeteorLake in poi e che sta sperimentando adesso con Ponte Vecchio e con Sapphire Rapids (quindi sono incluse anche le CPU server).

Decisamente l'evoluzione futura sarà basato sulla capacità di sfruttare questi nuovi metodi di packaging piuttosto che vedere dei miracoli sui PP che oramai stanno arrivando al capolinea come capacità di miglioramenti (ci scordiamo i 2x che facevano in tutti i campi di qualche anno fa ad ogni nuovo step)e continueranno a crescere in costi di R&D a dismisura.

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.

Mi sembra una forzatura bella grande questa.
Quindi quando è passato da Intel a NVIDIA era perché Intel sfornava le migliori GPU del secolo e NVIDIA ha voluto prendere colui che stava lavorando sul meglio del meglio per migliorare le proprie architetture?

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.
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 con una manciata di registri neanche tutti aggiornati a 64 bit, roba da far accapponare la pelle a pensare cosa avrebbero potuto fare nella transizione 32-64 bit, e invece...).

EDIT.

è mi immagino una cappa di soldi anche se non può di certo cambiare la fisica un ingegnere però può avere un bagaglio di soluzioni custom e fix di problemi già riscontrati non indifferente.

io sto provando un m1 pro da una settimana e devo dire che non va per niente male anche se gli ecore sono scesi a 2 barattati dai p core rispetto alla versione liscia...
sinceramente già m1 andava molto bene facevo compressione di video 4k con la stessa velocità che ho a casa ma con un decimo del consumo...
inutile dire che per la prima volta nella storia abbiamo una piattaforma alternativa che parte dall home fino al mondo professionale concorrenziale all x86.
Mancano i server per adesso....ma la capitalizzazione di apple dimostra che i suoi prodotti stanno entrando sempre di più nel mondo come standard de facto specialmente in quello professionale.

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 ).
Più che altro mi sembra esagerato il termine " voltafaccia " usato nel titolo e nel testo dell'articolo; 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.

Mi sembra una forzatura bella grande questa.
Quindi quando è passato da Intel a NVIDIA era perché Intel sfornava le migliori GPU del secolo


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.

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.


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?page=article&item=intel-xeonclear-21&num=1

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

per mesi cosa avrebbero detto?

Fatti un giro su questo forum, nei commenti ai vecchi articoli sugli M1. Gli attacchi e li sbeffeggiamenti erano all'ordine del giorno. Con annessa negazione dei risultati dei benchmark.

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?page=article&item=intel-xeonclear-21&num=1

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

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.

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?
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.
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...
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.
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.
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?page=article&item=intel-xeonclear-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).
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.

Ritorno su questo, perché ci ho rimuginato parecchio ieri.
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.
Anche per AVX (quindi non AVX-512) ho trovato non una, ma ben 4 soluzioni (forse ne spunteranno fuori altre quando ci metterò mano concretamente :D) che permettono di realizzare codice simile a quello vector length-agnostic (dunque con un solo loop principale che fa tutto il lavoro, e niente versioni apposite per codice di testa/head e coda/tail).

Ci sono differenze sostanziali sulle soluzioni che ho pensato. Ognuna ha pro e contro, com'è ovvio che sia: più o meno compatte a livello di spazio occupato, con più o meno istruzioni da eseguire, con più o meno istruzioni "intere" (general-purpose) o vettoriali (AVX), con più o meno (anche nullo) uso della memoria.

Tutte, comunque, si differenziano sul codice di preambolo e di epilogo. Il corpo/body, ossia il loop vettoriale, rimane esattamente lo stesso.

Adesso devo "soltanto" trovare del tempo per implementarle, e poi fare dei test prestazionali, per vedere i loro punti di forza e debolezza, ed eventualmente quale sia il miglior compromesso.
C'è bisogno di mettere seriamente mano ai compilatori (sì: anche quello di Intel).
Ho rivisto un po' anche i risultati generati da alcuni compilatori, e quest'idea che ho scritto prima, qui sopra, non fa che rafforzarsi sempre di più.

Ma anche per questo mi serve lavorarci un bel po', dopo aver finito quanto sopra, prima di esprimere un giudizio definitivo.

Anche se mi continuo a chiedere perché non ci abbiano già pensato gli sviluppatori dei compilatori... :stordita: