Newsgroup: it.comp.hardware.cpu
Titolo: E' la fine delle CPU Intel

Possiamo gettare tutto, amici.
Il futuro e' finalmente arrivato.
 
https://mac.iphoneitalia.com/111623/mac-m1-piu-veloci-mac-intel
 
 
 


 
"Rosetta 2 è infatti in grado di emulare perfettamente le app Intel sui
Mac M1, con prestazioni che Apple definisce addirittura superiori rispetto
a quelle dei Mac Intel."
 
In altre parole, questo cagata e' in grado di emulare Intel meglio della
cagata di prima. Complimenti Apple, avete fatto una cagata leggermente
piu' tiepida della cagata di prima, che era proprio fredda fredda. :)
 
Per fare un confronto serio, invece, perche' non mettiamo a paragone le
prestazioni di questa nuova e fiammante cagata con quelle che un
processore Intel offre in nativo, su un PC, con le stesse applicazioni?
E dico con un processore Intel, perche' con un Ryzen sarebbe bastardo! :)
 
Cioe', se Apple si congratula da sola per aver messo a punto una cagata
migliore di quella che lei stessa aveva fatto prima, beh, auguri. :-)))
 
Ah, a proposito: fare Mac con la tecnologia SoC e', hem, come dire...
antidiluviano. Quello e' il modo in cui si costruiscono i TABLET.
Se poi gli utenti Apple saranno felici di pagare i soliti 3000 euro per un
tablet travestito da PC, allora si capisce anche come mai gente come Trump
possa andare alla Casa Bianca.
Con imbecilli a sufficienza, qualunque cosa trova spiegazione.
-- 
 
-----
  | NFINITY is so far as you want to see.
-----
Codice-Wii: 2163-8155-7668-5528
Se vuoi rispondermi in E-Mail, combatti la politica. ;-)

 cagata di prima.
 
Capisco che e' una marchetta per far abboccare i figli di papa', ma qui sta 
dicendo che M1 con Rosetta2 emula (sul maxc nuovo) le app Intel meglio di 
quello che nativamente Intel riesce a fare sui mac con Intel.
 
Ti sembra possibile?
 
Non e' che le app Intel su un mac Intel stanno emulando qualcosa con 
Rosetta2. Stanno andando nativamente.
E' con M1 che queste app vengono emulate, ma girano piu' velocemente.
 
 

 Ti sembra possibile?
 
No.
 
O stanno confrontando l'emulatore su un ARM 8 core con 32GiB di RAM e 
buoni SSD con un Pentium di 20 anni fa dotato di HD a pedali o c'e' 
qualcos'altro di simile sotto.
 
Lieto di essere smentito dai fatti, ma nel frattempo non trattengo il fiato.
 
P.S. A scanso di equivoci, non ho nulla contro ARM, che anzi sono CPU 
che mi attirano molto, ma con software nativo (e non con un OS Apple >:-)

 antidiluviano.
 
Al contrario, e' il futuro.
Non perche' sia meglio, ma perche' costa meno (e l'acquirente non 
capisce un ...)

 No.
 
Non e' una vera e propria emulazione, ma e' una "ricompilazione" del 
codice Intel con codice ARM, quindi l'esecuzione e' alla fine nativa.
E' un qualcosa di simile all'hot-spot di Java (compilazione run-time del 
codice Java in codice nativo macchina).
 
Infatti il primo avvio richiede un po' di tempo (qualche decina di 
secondi), mentre i successivi sono immediati (salvera' da qualche parte 
il binario "ricompilato").
 
Quindi si', se il processore ARM ha prestazioni migliori di quelli Intel 
montati sui "vecchi" Mac, e' possibile che abbia prestazioni migliori 
anche nell'eseguire il codice Intel.
 
Ciao!
  Luca

capisce un ...)
 
Il futuro della presa per culo e della mungitura dei clienti fessi,
allora.
Non certo quello della tecnologia. :-/


qualcos'altro di simile sotto.
 
Penso anche io qualcosa del genere.


 codice Intel
 
E dove lo prendono il codice Intel?
E come puo' un codice Intel essere ricompilato per ARM senza modifiche 
radicali?
 
 

 codice Java in codice nativo macchina).
 
Solo che quello e' fatto apposta in partenza.

 Ti sembra possibile?
 
Possibile e` possibile, dato che il
codice x86 (codice macchina) viene
compilato per l'altra CPU.
 
Che sia reale, e` un altro discorso.
 
A mio avviso, hanno scelto qualche SW
peculiare che ha vantaggi sulla loro
piattaforma e possono dire che va piu`
veloce, ma che sia vero in generale e`
tutta un'altra storia...
 
bye,
 
-- 
 
piergiorgio

 compilato per l'altra CPU.
 
Ma quando mai?
Dov'e' il codice dell'APP?
 
Se apri la calcolatrice di Windows hai il codice o il compilato X86? 
 
 

 Se apri la calcolatrice di Windows hai il codice o il compilato X86? 
 
Che differenza c'e`?
Sempre un linguaggio di programmazione e`.
 
Se il codice assembly della CPU X e`:
 
ldx R0,10
ldx R1,20
mul R0,R1,R2
stx R2,$ff00
 
Questo puo` essere compilato, o trasformato,
come vuoi, nel codice della CPU Y, dove
magari viene riscritto come:
 
mulx #10,#20,R0
store R0,$ff00
 
Questa "tecnologia" risale almeno ai tempi
della CPU Alpha di Digital.
All'epoca avevano lo stesso problema, una
CPU senza programmi, perche` il SW era quasi
esclusivamente per x86.
Quindi, gia` allora, hanno iniziato ad usare
questo metodo di tradurre un assembly (x86)
in un altro (Alpha).
Nota che non e` emulato, cioe` non viene
interpretata istruzione per istruzione,
ma viene proprio tradotto, cioe` compilato,
nell'altro assembly, un intero pezzo di codice.
 
Il punto, ora come allora, e` che certi
blocchi di codice possono essere ottimizzati
per la CPU target molto bene, altri no.
 
Per cui i benchmark, dipende da come sono
fatti, possono dare ottimi risultati.
Oppure no... :-)
 
All'epoca di Alpha, mi pare che Digital
sostenesse un incremento delle prestazioni.
La gente che usava il compilatore, invece,
diceva che il codice era generalmente poco
piu` lento (non troppo, pare).
 
bye,
 
-- 
 
piergiorgio

 sostenesse un incremento delle prestazioni.
 
Considerando quanto erano superiori gli Alpha rispetto ai coetanei x86...
Non credo che il rapporto ARM/x86_64 oggi sia proprio lo stesso.

 Non credo che il rapporto ARM/x86_64 oggi sia proprio lo stesso.
 
Mah, questo e` da vedersi.
 
I nuovi ARM64 hanno diverse soluzioni simili
od equivalenti agli x86, anche riguardo i
consumi elevati, se e` per questo.
 
Inoltre scalano meglio come numero di core.
 
D'altro canto, come gia` scritto, c'e`
differenza tra quello che e` possibile e
tra quello che e` reale.
 
Immagino che vi siano benchmark e benchmark
e si scelgano quelli piu` convenienti.
 
bye,
 
-- 
 
piergiorgio

 radicali?
 
Se parli di codice sorgente, normalmente questo e' in C/C++/C# e - a meno 
di sezioni molto specializzate scritte in assembly - e' normalmente 
ricompilabile senza nessuna modifica (questo vale per la quasi totalita' 
del Software Libero, ad esempio).
Se parliamo invece di codice macchina, e' quello che fa gia' QEMU: 
traduce funzioni/sezioni di codice binario di una architettura in 
un'altra, tenendosele in cache. Non e' cosi' tanto ottimizzato come 
Rosetta, ma con il "compilatore" QEMU si e' in grado, ad esempio, di far 
girare nativamente un eseguibile ARM/MIPS/PPC su macchina Intel e 
viceversa. Lo uso per velocizzare la compilazione dei vari programmi 
delle distribuzioni GNU/Linux: in chroot posso lavorare su un sistema ARM 
da macchina Intel, senza le penalizzazioni dell'intera emulazione di 
tutto il sistema.
 
Ciao!
  Luca
 

 Solo che quello e' fatto apposta in partenza.
 
Si', e' vero che Java e' fatto apposta per essere in qualche modo 
tradotto in altro codice macchina, pero' Java e' nato per essere 
interpretato, e JIT (o il vecchio Jazelle di ARM, ormai deprecato in 
favore di JIT) e' venuto solo dopo aver constatato le pessime prestazioni 
in interpretazione/emulazione.
 
Ciao!
  Luca