Apple M2, arrivano i SoC di nuova generazione con un nuovo MacBook Air 13

[MaxVIXI]

bah... non vedo sto gran passo aventi... mi sembrano macchine che lavoreranno nello stesso identico modo dei vecchi air con un design (imo) peggiore...
io ho un air m1 8/8 16 1tb... probabilmente avrei fatto meglio a comprare il 7/8 8 256, perchè alla fine il collo di bottiglie è il fatto che è uno scatolino trasportabilissimo comdo con tanta batteria, ma per lavorare proprio no...

[Nui_Mg]

Originariamente inviato da RaZoR93

Ma supporta 8k HEVC e ProRes. Non si capisce se Apple faccia sul serio con AV1 onestamente.

Se è basato su A15 allora non ce l'ha in hardware, oltre al fatto che apple cerca di spingere le sue licenze hevc, cioè cerca di contrastare av1/avif.

[ThE cX MaN]

Originariamente inviato da AlexSwitch

Già... I nuovi Air si fanno pagare cari principalmente per il nuovo design del case ed in parte per il SoP M2.
Inoltre qui in Europa si sconta anche la politica aggressiva di Apple con il cambio USD vs Euro ( oggi un Euro vale 1,07 USD ) che ha una sua incidenza sul prezzo finale...

Ecco qualche confronto per il MBA 2022 M2 8 Core CPU/GPU 8GB Ram 256GB storage:

Prezzo USA IVA ( VAT ) esclusa: 1199 USD
Prezzo USA IVA ( VAT ) inclusa ( 22% ): 1462 USD
Prezzo ITA - IVA 22% ed altri oneri: 1529 Euro
Prezzo GER - IVA 19% ed altri oneri: 1499 Euro
Prezzo FRA - IVA 20% ed altri oneri: 1499 Euro
Prezzo ESP - IVA 21% ed altri oneri: 1519 Euro

Rimangano sempre da vera e propria rapina gli upgrade di ram e SSD con opzioni da 230 Euro per raddoppio di capacità per lo storage e di ben 230 Euro ( moccolo potente censurato ) per ogni 8GB di ram aggiuntivi visto che l'opzione da 24GB, non 32, Apple ha la faccia tosta di farseli pagare ben 460 EURO ( altro moccolo potente )!!

Sono già a 1400 su Amazzone… e spendeteli sti soldi!

[RaZoR93]

Originariamente inviato da Nui_Mg

Se è basato su A15 allora non ce l'ha in hardware, oltre al fatto che apple cerca di spingere le sue licenze hevc, cioè cerca di contrastare av1/avif.

Tecnicamente Apple è "Governing member" dell'Alliance for Open Media, il cui scopo è appunto sviluppare AV1. Mi pare piuttosto illogico quindi che cerchi di "contrastare AV1", al contrario dovrebbe supportarlo appena possibile; ma chiaramente tutto è possibile con Apple.

[Piedone1113]

Originariamente inviato da RaZoR93

AMD annuncerà Phoenix con tutta probabilità al CES 2023 (fra 7 mesi), con reale disponibilità solo mesi dopo.
Vedere Zen3+ mobile: https://www.tomshardware.com/news/ze...option-is-slow

ARM vs X86 non è importante, ciò che conta è l'implementazione e l'architettura proprietaria usata da Apple/AMD/Intel.
Il processo produttivo è solo parte dell'equazione, ma certo M3 sul nodo N3 avrà cambiamenti più significativi rispetto ad M2 che usa fondamentalmente lo stesso nodo.

No, quello che è importante è il pp adottato.
Il numero di transistor.
Una volta che sono vincolate queste variabili ( e quindi divengono delle costanti) si vede chi dei due ha maggior capacità di calcolo e miglior efficienza.
come se volessimo paragonare l'efficienza di un P4 a 90nm con alder a 7n Intel. Avrebbe senso per definirne prestazioni e efficienza?
Se poi intel o amd ti inserisce una parte hardware interna a soc per un determinato compito questa va conteggiata come se fosse la cpu propria.
Non tralasciamo nemmeno il fatto che x86 sta diventando sempre più efficiente mentre ARM sempre più complessa e se da un lato x86 potrebbe sembrare ad oggi che paga la necessità della retrocompatibilità tra 5 generazioni si troverà nella stessa identica situazione ARM poichè volendo entrare nel settore hpc ( ed attualmente mostra moltissimi limiti architetturali nello scalare di prestazioni) sarà costretta per forza di cose mantenere una retrocompatibilità hardware ( e non software) sui path ed istruzioni oggi utilizzati ( non è che sia un settore dove si riscrive da zero ogni volta un software complesso)
La retrocompatibilità di x86 è un peso per l'architettura, ma un pregio per l'utente.
Pregio che dovrà per forza di cose offrire anche arm, altrimenti verra ributtata nel mondo home e iniziata a essere trascurata anche dai software pro ( pochi in vero) oggi disponibili per osx.

[CrapaDiLegno]

Originariamente inviato da Piedone1113

No, quello che è importante è il pp adottato.
Il numero di transistor.
Una volta che sono vincolate queste variabili ( e quindi divengono delle costanti) si vede chi dei due ha maggior capacità di calcolo e miglior efficienza.
come se volessimo paragonare l'efficienza di un P4 a 90nm con alder a 7n Intel. Avrebbe senso per definirne prestazioni e efficienza?
Se poi intel o amd ti inserisce una parte hardware interna a soc per un determinato compito questa va conteggiata come se fosse la cpu propria.
Non tralasciamo nemmeno il fatto che x86 sta diventando sempre più efficiente mentre ARM sempre più complessa e se da un lato x86 potrebbe sembrare ad oggi che paga la necessità della retrocompatibilità tra 5 generazioni si troverà nella stessa identica situazione ARM poichè volendo entrare nel settore hpc ( ed attualmente mostra moltissimi limiti architetturali nello scalare di prestazioni) sarà costretta per forza di cose mantenere una retrocompatibilità hardware ( e non software) sui path ed istruzioni oggi utilizzati ( non è che sia un settore dove si riscrive da zero ogni volta un software complesso)
La retrocompatibilità di x86 è un peso per l'architettura, ma un pregio per l'utente.
Pregio che dovrà per forza di cose offrire anche arm, altrimenti verra ributtata nel mondo home e iniziata a essere trascurata anche dai software pro ( pochi in vero) oggi disponibili per osx.

Ma cosa dici?
Compatibilità hardware a livello di data path?
Ma cosa credi faccia un compilatore?
La compatibilità hw è proprio l'ultima cosa che importa. Nemmeno x86 ce l'ha (AMD e Intel usano 2 microarchitecture diverse). Nel mondo HPC ancora meno, visto che si ricicla il codice, ma non in formato binario già compilato. Si ricompila per ogni nuova architettura e se ne sfruttando le caratteristiche.
Ecco perché si hanno super computer che sono x86, Power o ARM, con uno che sostituisce il precedente senza particolari problemi.
Ecco perché Nvidia ha il 99% del mercato delle schede acceleratrici, perché con CUDA permette proprio di riciclare il SW infischiandosene dell'HW sottostante. Ci penserà il compilatore a usare al meglio l'HW a disposizione, fino a livello di creazione del giusto numero di thread per ciascuna architettura.

Il problema è solo nel mercato consumer dove non di può ricompilare il SW a piacere (a meno che non sia open source, ma anche lì poi dubito che dietro vi sia un codice capace di adattarsi visto che nessuno pensa che x86 cambierà radicalmente in futuro).
Lì si usano binari precompilati e se Adobe (per dirne una) ha compilato in un certo modo, puoi apportare tutte le migliore che vuoi ai tuoi core, ma non saranno mai sfruttati se non si portano dietro il legacy.
Apple da questo punto di vista è avvantaggiata perché impone sistemi di sviluppo e librerie e permette così di portare facilmente il codice da una architettura ad un'altra.
Sotto Windows con .Net che doveva essere "il Java" moderno e poi si è rivelato nel tempo la solita chiavica incompatibile con se stessa, non c'è nulla che si possa fare.
Se cambi l'architettura (anche semplicemente togliendo tutte le istruzioni obsolete e ridondanti che si sono moltiplicate nel tempo) o ti munisci di emulatore oppure rischi il crash.
E più vuoi ottimizzare per andare meglio nel futuro, peggio andranno le applicazioni vecchie. E con 30 e più anni di programmi sviluppati e compilati in tutte le maniere, hai voglia a sperare di non avere problemi.

[Piedone1113]

Originariamente inviato da CrapaDiLegno

Ma cosa dici?
Compatibilità hardware a livello di data path?
Ma cosa credi faccia un compilatore?
La compatibilità hw è proprio l'ultima cosa che importa. Nemmeno x86 ce l'ha (AMD e Intel usano 2 microarchitecture diverse). Nel mondo HPC ancora meno, visto che si ricicla il codice, ma non in formato binario già compilato. Si ricompila per ogni nuova architettura e se ne sfruttando le caratteristiche.
Ecco perché si hanno super computer che sono x86, Power o ARM, con uno che sostituisce il precedente senza particolari problemi.
Ecco perché Nvidia ha il 99% del mercato delle schede acceleratrici, perché con CUDA permette proprio di riciclare il SW infischiandosene dell'HW sottostante. Ci penserà il compilatore a usare al meglio l'HW a disposizione, fino a livello di creazione del giusto numero di thread per ciascuna architettura.

Il problema è solo nel mercato consumer dove non di può ricompilare il SW a piacere (a meno che non sia open source, ma anche lì poi dubito che dietro vi sia un codice capace di adattarsi visto che nessuno pensa che x86 cambierà radicalmente in futuro).
Lì si usano binari precompilati e se Adobe (per dirne una) ha compilato in un certo modo, puoi apportare tutte le migliore che vuoi ai tuoi core, ma non saranno mai sfruttati se non si portano dietro il legacy.
Apple da questo punto di vista è avvantaggiata perché impone sistemi di sviluppo e librerie e permette così di portare facilmente il codice da una architettura ad un'altra.
Sotto Windows con .Net che doveva essere "il Java" moderno e poi si è rivelato nel tempo la solita chiavica incompatibile con se stessa, non c'è nulla che si possa fare.
Se cambi l'architettura (anche semplicemente togliendo tutte le istruzioni obsolete e ridondanti che si sono moltiplicate nel tempo) o ti munisci di emulatore oppure rischi il crash.
E più vuoi ottimizzare per andare meglio nel futuro, peggio andranno le applicazioni vecchie. E con 30 e più anni di programmi sviluppati e compilati in tutte le maniere, hai voglia a sperare di non avere problemi.

o si certo, in hpc si ricompila tutto per il nuovo hardware.
E poi sia intel che AMD hanno creato istruzioni ridondanti per fare le stesse cose.
Perchè poi nel mondo hpc prima ricompilano tutto e poi testano i sistemi con software gia compilato.
Dunque vediamo quindi mettono insieme il sistema, ci installano il software compilato per la nuova architettura e sono gia online.
Peccato però che lo stesso sorgente quasi sempre va modificato prima di passare a compilarlo ( proprio per sfruttare la nuova architettura) e che migliaia di programmi/comandi/daemon ( o quello che vuoi) sono immutatio da decenni perchè la fase di testing è molto complessa gia con software classico su nuove architetture, figuriamoci due salti nel buoi in contemporanea ( non mi parlare di simulatori hardware però che è un tasto molto più dolente).
Ti sei chiesto perchè windows server 2022 nonostante le limitazioni hardware imposte con opportune modifiche si installa anche su macchine obsolete?
Ma come non basta ricompilarlo per le ultime 5/6 generazioni di sistemi e renderlo defacto incompatile con tutte le istruzioni obsolete?
Perchè windows for Arm è così diverso ( e poco performante) in confronto a windows x64 se bastasse solo precompilare il codice per arm?
Ricompilare ex novo milgliaia di routine e subroutine richiederebbe anni solo per il testing. tanto varrebbe buttare tutto e riscrivere tutto d'accapo ( come pure i molti software che su M1 viaggiano in emulazione se davvero sarebbe bastato ricompilare).
Si ricompila solo le parti che ti daranno vantaggio dalle nuove architetture, ricompilare tutto per le nuove architetture costerebbe uno sproposito di tempo tale che finita la fase di testing ti toccherebbe ricompilare ( e ripetersi) perchè nel frattempo la fantastica nuova architettura è diventata obsoleta

[CrapaDiLegno]

Originariamente inviato da Piedone1113

o si certo, in hpc si ricompila tutto per il nuovo hardware.
E poi sia intel che AMD hanno creato istruzioni ridondanti per fare le stesse cose.
Perchè poi nel mondo hpc prima ricompilano tutto e poi testano i sistemi con software gia compilato.
Dunque vediamo quindi mettono insieme il sistema, ci installano il software compilato per la nuova architettura e sono gia online.
Peccato però che lo stesso sorgente quasi sempre va modificato prima di passare a compilarlo ( proprio per sfruttare la nuova architettura) e che migliaia di programmi/comandi/daemon ( o quello che vuoi) sono immutatio da decenni perchè la fase di testing è molto complessa gia con software classico su nuove architetture, figuriamoci due salti nel buoi in contemporanea ( non mi parlare di simulatori hardware però che è un tasto molto più dolente).
Ti sei chiesto perchè windows server 2022 nonostante le limitazioni hardware imposte con opportune modifiche si installa anche su macchine obsolete?
Ma come non basta ricompilarlo per le ultime 5/6 generazioni di sistemi e renderlo defacto incompatile con tutte le istruzioni obsolete?
Perchè windows for Arm è così diverso ( e poco performante) in confronto a windows x64 se bastasse solo precompilare il codice per arm?
Ricompilare ex novo milgliaia di routine e subroutine richiederebbe anni solo per il testing. tanto varrebbe buttare tutto e riscrivere tutto d'accapo ( come pure i molti software che su M1 viaggiano in emulazione se davvero sarebbe bastato ricompilare).
Si ricompila solo le parti che ti daranno vantaggio dalle nuove architetture, ricompilare tutto per le nuove architetture costerebbe uno sproposito di tempo tale che finita la fase di testing ti toccherebbe ricompilare ( e ripetersi) perchè nel frattempo la fantastica nuova architettura è diventata obsoleta

Ma cosa dici ancora?
Il sw per hoc si ricompila! O cosa credi abbiano fatto con il sistema Power+Nvidia? Hanno riscritto tutto, testato tutto e dopo poco hanno buttato tutto per passare a x86? E con il Fugaku? Rifatto tutto da zero compreso le parti che normalmente sono accelerate dalle schede dedicate?
Con il Cell che hanno fatto? E il Cell era incompatibile con qualsiasi cosa precedente!
Su HPC si usa Linux, che infatti si ricompila. O credi che ogni volta che ricompili run codice già verificato va testato ancora per mesi?
O prendi il kernel Linux già compilato per un altra architettura ma stessa ISA e lo metti su così, al volo, sapendo che funzionerà senza problemi?
Stai scherzando, vero?

Quando si progetta un HPC il tempo di messa in opera non sta solo nel.comprare e installare le CPU+GPU ma anche appunto ricompilare OS e librerie e testarle.
I bench non li fai con eseguibili già pronti, ma compili i singoli test e lo provi. E i parametri di compilazione dipendono dal test, infatti.

Quando cambi le schede Nvidia non metti gli stessi eseguibili ma ricompili con la nuova versione di CUDA fatta per la nuova architettura e lo stesso identico codice funzionerà al meglio sulle nuove ove schede. Poi puoi sempre apportate modifiche ulteriori per ottimizzare ancora di più, ma già usare le librerie fatte per la nuova architettura aumenta l'efficienza di esecuzione.

Tutto questo per dire che ARM non deve tenere nessuna compatibilità HW sulle architetture HPC. E nemmeno a livello di ISA dove infatti a ogni architettura viene sempre aggiunto qualcosa di nuovo.

Il problema è il mercato consumer. Magari ti sarai chiesto perché le architetture ARM non ci sono in questo mercato e l'unica che propone qualcosa di decente è Apple.
Windows è il classico esempio di quanto dicevo prima: anche se hai il sorgente è stato costruito per anni per una sola architettura che non è mai cambiata. E non basta ricompilarlo per ottimizzare per una architettura completamente diversa mai presa in considerazione. Neanche .Net è portabile. E doveva essere il Java di Microsoft.

Infine sì, nei decenni di sviluppo esistono istruzioni X86 ridondanti che fanno le stesse cose in maniera diversa. Si chiama perdita di ortogonalità e x86 ne e un illustre vittima vista l'età e le innumerevoli estensioni subìte (16, 32 e poi 64bit, ognuno con il suo set di istruzioni separate ma mai abbandonate).

[megamitch]

Originariamente inviato da AlexSwitch

Il notch e ben 64 pixel in più per la risoluzione verticale…

non lo capisco il marketing Apple.

Il mio MB Air M1 ha lo schermo "retina"
Il nuovo MB Air M2 ha lo schermo "liquid retina"
Il nuovo MB Pro M2 ha lo schermo "retina"

Chi ci capisce è bravo

[Piedone1113]

Originariamente inviato da CrapaDiLegno

Ma cosa dici ancora?
Il sw per hoc si ricompila! O cosa credi abbiano fatto con il sistema Power+Nvidia? Hanno riscritto tutto, testato tutto e dopo poco hanno buttato tutto per passare a x86? E con il Fugaku? Rifatto tutto da zero compreso le parti che normalmente sono accelerate dalle schede dedicate?
Con il Cell che hanno fatto? E il Cell era incompatibile con qualsiasi cosa precedente!
Su HPC si usa Linux, che infatti si ricompila. O credi che ogni volta che ricompili run codice già verificato va testato ancora per mesi?
O prendi il kernel Linux già compilato per un altra architettura ma stessa ISA e lo metti su così, al volo, sapendo che funzionerà senza problemi?
Stai scherzando, vero?

Quando si progetta un HPC il tempo di messa in opera non sta solo nel.comprare e installare le CPU+GPU ma anche appunto ricompilare OS e librerie e testarle.
I bench non li fai con eseguibili già pronti, ma compili i singoli test e lo provi. E i parametri di compilazione dipendono dal test, infatti.

Quando cambi le schede Nvidia non metti gli stessi eseguibili ma ricompili con la nuova versione di CUDA fatta per la nuova architettura e lo stesso identico codice funzionerà al meglio sulle nuove ove schede. Poi puoi sempre apportate modifiche ulteriori per ottimizzare ancora di più, ma già usare le librerie fatte per la nuova architettura aumenta l'efficienza di esecuzione.

Tutto questo per dire che ARM non deve tenere nessuna compatibilità HW sulle architetture HPC. E nemmeno a livello di ISA dove infatti a ogni architettura viene sempre aggiunto qualcosa di nuovo.

Il problema è il mercato consumer. Magari ti sarai chiesto perché le architetture ARM non ci sono in questo mercato e l'unica che propone qualcosa di decente è Apple.
Windows è il classico esempio di quanto dicevo prima: anche se hai il sorgente è stato costruito per anni per una sola architettura che non è mai cambiata. E non basta ricompilarlo per ottimizzare per una architettura completamente diversa mai presa in considerazione. Neanche .Net è portabile. E doveva essere il Java di Microsoft.

Infine sì, nei decenni di sviluppo esistono istruzioni X86 ridondanti che fanno le stesse cose in maniera diversa. Si chiama perdita di ortogonalità e x86 ne e un illustre vittima vista l'età e le innumerevoli estensioni subìte (16, 32 e poi 64bit, ognuno con il suo set di istruzioni separate ma mai abbandonate).

Non hai minimamente cognizione di quello che parli.
Difatti secondo la tua personalissima opinione basta creare un nuovo set di istruzioni, eliminare le vecchie ( ma anche addirittura una nuova architettura) dare in pasto i sorgenti al compilatare ( con i flag attivi per ottimizzare le nuove istruizioni e eliminare quelle non più supportate, non quelle deprecate) ed il gioco è fatto.
Talmente logico e semplice da rendere inutili i driver e dichiarare incapaci tutti i programmatori che fanno porting da un'architettura ad un'altra ( ma anche a quelli che fanno porting sulla stessa architettura, ma con os differenti).
Per fare quello che dici devi avere tutti i sorgenti che puntano ad API e Librerie intermedie e scrivere da zero tutte le librerie per la macchina target.
Cosa non proprio immediata.
Questo potrebbe essere un approccio base che non punta alle prestazioni pure, ma alla sola interoperabilità tra os-architetture diverse.
Questo tipo di soluzione è poco adatta al mondo hpc perchè l'universalità del sorgente limita le prestazioni e le ottimizzazioni specifiche, mentre un sorgente universale ( quindi che usa api e librerie standard) se portato su architetture hardware/software moderne, ma retrocompatili, può essere ottimizzato solo in alcune parti tralasciando il resto.
Hai fatto l'esempio di cell?
Proprio il cell che ha fatto impazzire migliaia di programmatori dovendone modificare i soprgenti per avere prestazioni decenti su software scritto 3/4 anni prima?
Scrivi una volta e ricompili sempre è valido soltando se la macchina target è retrocompatibile ( proprio come fugaku) altrimenti buona fortuna a trovare prestazioni.

[AlexSwitch]

Originariamente inviato da megamitch

non lo capisco il marketing Apple.

Il mio MB Air M1 ha lo schermo "retina"
Il nuovo MB Air M2 ha lo schermo "liquid retina"
Il nuovo MB Pro M2 ha lo schermo "retina"

Chi ci capisce è bravo

Caro mio non c'è da capire nulla... E' il marketing da supercazzola in cui Apple è abilissima per " incartare " meglio i suoi prodotti.
E' come l'uso della parolina " Pro " che appiccicano a tutto ciò che ha qualche feature in più per spiccare un prezzo più alto... Che differenze " Pro " ci sono tra i nuovi MBA M2 e i MBP M2? Sostanzialmente nessuna: stesso SoP, stessa dotazione di memoria di default, stessa dotazione di base per lo storage, stessa dotazione di porte I/O... Paradossalmente il novissimo MBP M2 da 13" ha ancora la vecchia videocamera FaceTime da 720p senza Center Stage!!

[Phoenix Fire]

Originariamente inviato da elica2099

Originariamente inviato da: carloUba:

Sono comunque prodotti rivolti ad influencer e persone non troppo informatizzate.
Non ci vedo nulla di male per un brand che basa tutto sull'immagine.
Nell'ambito della moda ce ne sono a centinaia così.


Oddio, e io che uso il Mac per scrivere app che usano gli utenti sugli smartphone (ios e android) sono un influescer? Sono poco informatizzato? E quelli che usano il Mac per comporre musica o fare grafica professionale sono anche loro "poco informatizzati"?
Per cortesia smettiamola con i luoghi comuni. Chi sceglie un Mac non lo fa solo per "moda" (anche se ci saranno sicuramente), ma lo fa anche per lavorare e vivere.
La scelta individuale è libera in ogni campo e mezzo. Senza dare giudizi affrettati.

Dov'è l'icona del facepalm?

immagino che l'air non abbia come target principale sviluppatori, compositori o grafici professionisti

[Phoenix Fire]

Originariamente inviato da AlexSwitch

Caro mio non c'è da capire nulla... E' il marketing da supercazzola in cui Apple è abilissima per " incartare " meglio i suoi prodotti.
E' come l'uso della parolina " Pro " che appiccicano a tutto ciò che ha qualche feature in più per spiccare un prezzo più alto... Che differenze " Pro " ci sono tra i nuovi MBA M2 e i MBP M2? Sostanzialmente nessuna: stesso SoP, stessa dotazione di memoria di default, stessa dotazione di base per lo storage, stessa dotazione di porte I/O... Paradossalmente il novissimo MBP M2 da 13" ha ancora la vecchia videocamera FaceTime da 720p senza Center Stage!!

il pro non ha la ventola?

[CrapaDiLegno]

Originariamente inviato da Piedone1113

Non hai minimamente cognizione di quello che parli.
Difatti secondo la tua personalissima opinione basta creare un nuovo set di istruzioni, eliminare le vecchie ( ma anche addirittura una nuova architettura) dare in pasto i sorgenti al compilatare ( con i flag attivi per ottimizzare le nuove istruizioni e eliminare quelle non più supportate, non quelle deprecate) ed il gioco è fatto.
Talmente logico e semplice da rendere inutili i driver e dichiarare incapaci tutti i programmatori che fanno porting da un'architettura ad un'altra ( ma anche a quelli che fanno porting sulla stessa architettura, ma con os differenti).
Per fare quello che dici devi avere tutti i sorgenti che puntano ad API e Librerie intermedie e scrivere da zero tutte le librerie per la macchina target.
Cosa non proprio immediata.
Questo potrebbe essere un approccio base che non punta alle prestazioni pure, ma alla sola interoperabilità tra os-architetture diverse.
Questo tipo di soluzione è poco adatta al mondo hpc perchè l'universalità del sorgente limita le prestazioni e le ottimizzazioni specifiche, mentre un sorgente universale ( quindi che usa api e librerie standard) se portato su architetture hardware/software moderne, ma retrocompatili, può essere ottimizzato solo in alcune parti tralasciando il resto.
Hai fatto l'esempio di cell?
Proprio il cell che ha fatto impazzire migliaia di programmatori dovendone modificare i soprgenti per avere prestazioni decenti su software scritto 3/4 anni prima?
Scrivi una volta e ricompili sempre è valido soltando se la macchina target è retrocompatibile ( proprio come fugaku) altrimenti buona fortuna a trovare prestazioni.

No, non ci siamo capiti.
Io non ho detto che basa fare la ricompilazione e i giochi sono fatti.
Ho detto che se anche cambi il set di istruzioni ma ricompili, IL TUO PROGRAMMA HPC CONTINUERA' A FUNZIONARE e non serve che l'HW sottostante mantenga alcuna compatibilità HW.
L'OS lo si ricompila, per forza, non si usa "Windows compilato per un altra CPU"! Non c'è windows infatti. Alcuni driver per forza si riscrivono, anche perché tra una generazione e l'altra non si usa la stessa cosa (nuove interfacce, diversi bus a seconda del fornitore).
Non ho fatto solo l'esempio del Cell, per il quale sono stati fatti tutti i driver nonostante l'architettura completamente diversa e con il quale e' stato fatto IL supercomputer più veloce in quel momento che non aveva alcuna compatibilità con nessun codice già scritto.
I programmatori sono impazziti per via dell'architettura "strana", non semplicemente diversa. Che è ben altra cosa.
Ti ho fatto anche gli esempio di super computer fatti con x86, x86+N tipi di schede Nvidia, Power+Nvidia, x86 in layered e mesh architecture (Xeon Phy) e ARM con custom core.
In nessun caso si è parlato di "ommioddio dobbiamo riscrivere tutto da zero perché l'ISA Power non è compatibile con niente! Dobbiamo riscrivere tutti i driver da zero perché non si può usare il 90% del codice C già scritto per un'altra architettura. Dobbiamo trovare l'eseguibile dell'OS che è compatibile con i "path" di quest microarchitettura".
E in nessun caso, quindi, E' NECESSARIO CHE ARM MANTENGA ALCUNA COMPATIBILITA' HW CON IL PASSATO perché in nessuno dei precedenti casi è stato impossibile costruire super computer. Nemmeno con il Cell, "quello che ha fatto impazzire i programmatori" ma per altri motivi, non perché mancassero OS, driver o non si potesse usare lo stesso identico codice di computazione precedente (con evidenti problemi di efficienza, vista l'architettura che richiedeva di ripensare il problema da zero) ma con il sorgente in mano sempre possibile ricompilarlo per "un data path diverso".

[megamitch]

Originariamente inviato da AlexSwitch

Caro mio non c'è da capire nulla... E' il marketing da supercazzola in cui Apple è abilissima per " incartare " meglio i suoi prodotti.
E' come l'uso della parolina " Pro " che appiccicano a tutto ciò che ha qualche feature in più per spiccare un prezzo più alto... Che differenze " Pro " ci sono tra i nuovi MBA M2 e i MBP M2? Sostanzialmente nessuna: stesso SoP, stessa dotazione di memoria di default, stessa dotazione di base per lo storage, stessa dotazione di porte I/O... Paradossalmente il novissimo MBP M2 da 13" ha ancora la vecchia videocamera FaceTime da 720p senza Center Stage!!

infatti mi chiedo: perchè uno dovrebbe comprare Macbook Air M2 pagandolo di più di un M1 ?

Per le "prestazioni in single core" ? Da quanto leggevo anche qui sul forum il target di clienti del MB Air non sono persone con elevati bisogni computazionali, per cui che se ne fanno di un processore un pò più veloce se devono spendere di più?

Per dire: io ho comprato un Air M1, lo uso come computer di casa ma se ci fosse stato un modello con un processore un pò meno potente e me lo avessero scontato di 300 euro avrei preso quello con meno potenza.

[CrapaDiLegno]

Il problema ce l'hai nel mondo consumer dove usi Windows già precompilato, e i programmi sono scritti per usare i core nel modo in cui Windows li vede e li mette a disposizione.
Già solo l'introduzione dei core P ed E è stato traumatico, perché nessun programma scritto finora ha il concetto di "lavoro in background" o in "foreground" che è diverso tra lavoro ad alte prestazioni o meno, che è quello che lo scheduler di Intel usa per capire se mettere un thread in esecuzione su un P core o su un E core.
Lì devi rispettare la compatibilità HW per non avere problemi perché il binario è immutabile e di SH che vogliono portare il loro SW su architetture diverse le conti sulle dita di una mano (e non sono mai le più grandi che fanno i programmi più diffusi). Lo fanno su Apple perché Apple li obbliga a farlo se vogliono continuare a vendere.
E sarebbero costrette anche su Windows se cambiasse l'HW sottostante, ma siccome il 90% del SW è ormai non più mantenuto, Intel e AMD non ci pensano nemmeno un secondo (e spendono un dollaro) a fare modifiche radicali alle architetture. Perderesti una fetta enorme di mercato.
L'ultima chance è stata con l'introduzione dei 64 bit. Avrebbero potuto cambiare completamente tutto, perché un eseguibile a 64 bit non deve necessariamente compatibile con una macchina a 32 bit e viceversa.
Invece hanno solo esteso l'ISA per renderla ancora più complicata senza approfittare dell'occasione per riordinarla: oggi avremmo applicazioni a 64bit basate su un set di istruzioni diverso (potevano pure essere RISC) e invece abbiamo un Frankenstein di istruzioni vecchia, nuove, a 32 e 64 bit, i soliti 4 registri ora ad uso ancora più misto e istruzioni a lunghezza variabile fino a un chilometro.
Praticamente siamo rimasti al 1970 con solo più bit da gestire.

E le altre architetture sono andate avanti, e non di poco.
Che ti piaccia o no, l'implementazione ARM di Apple è dalle 2 alle 4 spanne sopra quello che hanno fatto finora AMD e Intel, senza 5.5GHz e 230W di consumo, segno che l'unica cosa che finora ha frenato ARM è, come ho sempre sostenuto, il fatto che non ci fosse un mercato che giustificasse di fare core più complessi di quelli necessari per uno smartphone e che le uniche possibilità di vedere degli ARM seri erano o per il mercato HPC o per mano di Apple e il suo mercato chiuso.
Con diversi anni di ritardo, ora stiamo vedendo proprio questo. E x86 è là dove era prima, quando Intel tentava di usarlo per il mercato mobile, ovvero indietro di un paio di generazioni.

[recoil]

Originariamente inviato da megamitch

infatti mi chiedo: perchè uno dovrebbe comprare Macbook Air M2 pagandolo di più di un M1 ?

è un altro design, hai un po' più di display e c'è il MagSafe oltre a prestazioni di poco superiori, non è molto ma una piccola differenza di prezzo ci sta
il punto è che su M1 sicuramente si troveranno offerte a prezzo più basso di quello ufficiale Apple e allora conviene stare su quel modello lì

[Marko#88]

Originariamente inviato da megamitch

infatti mi chiedo: perchè uno dovrebbe comprare Macbook Air M2 pagandolo di più di un M1 ?

Per le "prestazioni in single core" ? Da quanto leggevo anche qui sul forum il target di clienti del MB Air non sono persone con elevati bisogni computazionali, per cui che se ne fanno di un processore un pò più veloce se devono spendere di più?

Per dire: io ho comprato un Air M1, lo uso come computer di casa ma se ci fosse stato un modello con un processore un pò meno potente e me lo avessero scontato di 300 euro avrei preso quello con meno potenza.

Perché uno dovrebbe comprare una Polo quando può comprare la Fabia?
Perché uno dovrebbe comprare uno Swatch da 100 euro quando ci sono i Casio da 20?
Perché ci sono scarpe e vestiti da xxx euro quando puoi comprare quelli da xx (anche senza marchi di lusso)?
Semplice, ci sono un casino di persone, qualcuno ha più capacità/volontà di spesa di altri e magari trova valido comprare un nuovo portatile che è "meglio" del vecchio anche se la differenza nella pratica non è tanta.
Non parlo solo di marchio/lusso/status, è proprio un discorso di: "300 euro non mi cambiano la vita, li spendo"
Allo stesso modo c'è chi va al ristornate due volte a settimana e in estate va al mare in riviera e chi va poco al ristorante e poi in estate si fa due settimane costose.
Non è che ci sia chissà cosa da capire eh, il mondo è abbastanza vario.

[oatmeal]

Non mi serve un laptop ma lo comprerei solo per il ritorno del MagSafe, una follia toglierlo

[megamitch]

Originariamente inviato da Marko#88

Perché uno dovrebbe comprare una Polo quando può comprare la Fabia?
Perché uno dovrebbe comprare uno Swatch da 100 euro quando ci sono i Casio da 20?
Perché ci sono scarpe e vestiti da xxx euro quando puoi comprare quelli da xx (anche senza marchi di lusso)?
Semplice, ci sono un casino di persone, qualcuno ha più capacità/volontà di spesa di altri e magari trova valido comprare un nuovo portatile che è "meglio" del vecchio anche se la differenza nella pratica non è tanta.
Non parlo solo di marchio/lusso/status, è proprio un discorso di: "300 euro non mi cambiano la vita, li spendo"
Allo stesso modo c'è chi va al ristornate due volte a settimana e in estate va al mare in riviera e chi va poco al ristorante e poi in estate si fa due settimane costose.
Non è che ci sia chissà cosa da capire eh, il mondo è abbastanza vario.

quindi convieni con me che non c'è un solo motivo per comprare MB Air M2, a parte aver soldi da spendere.