Link alla notizia: http://www.hwupgrade.it/news/apple/apple-ritornano-le-voci-sul-passaggio-ad-arm-per-desktop-e-portatili_44505.html

Un passaggio che, seppur destinato ad avvenire non immediatamente, pare essere inevitabile: l'abbandono di Intel a favore di ARM consentirebbe alla compagnia di avere una piattaforma tecnologica comune per tutte le sue soluzioni

Click sul link per visualizzare la notizia.

Fanno bene a studiare tecnologie alternative, Apple ha le risorse interne per fare bene e sicuramente disegnare in casa la cpu ti offre tutta una serie di vantaggi per il design del prodotto e per l'integrazione/ottimizzazione di software e servizi.

Beh apple è riuscita a fare un passaggio indolore tra PPC e x86, vedremo nel futuro.

Da un certo punto di vista questa soluzione è condivisibile, interfaccia utente, bla bla bla...

Ma da un altro, chi con il mac ci lavora pesante (photoshop, premiere), potrebbe accettare una diminuzione delle performance?

Non credo, e se lo mettessero solo sull'air non sarebbe ancora una line up omogenea. Boh.

è un addio quindi a windows su mac?

Le fondamenta e konw how, lato OS e applicazioni, ci sono tutte per un cambio di piattaforma... OS X è nato su PPC, ma già programmato per x86 grazie al progetto Rhapsody... iOS, nelle sue fondamenta, è OS X, e le app sono progettate e sviluppate nella stessa maniera di quelle per Macintosh.
Già con Tiger ( OS X 10.4 ), primo OS ufficialmente sviluppato per x86, Apple fece vedere quanto fosse semplice compilare codice per entrambe le piattaforme.
Quindi nessun problema lato sviluppo software... piuttosto sull'hardware, a mio parere, passare ad ARM, significherà inchiodare la bara del settore " Pro ", ovvero portare a termine un percorso iniziato 5 anni fa con il primo iPhone ( ed Apple eliminò la parola computer dalla sua ragione sociale ) che ha visto la scomparsa degli XServe, la prossima dipartita dei Mac Pro, la creazione di Macintosh sempre più " sottili " ( iMac compresi.... che fesseria!!! ).

Ovviamente ARM significherebbe anche perdere il supporto integrale a Windows in dual boot e concordo con chi ha affermato che potrebbe rivelarsi come un clamoroso autogol.

a me sembra credibile ma non è una cosa che si fa dall'oggi al domani
sicuramente ci stanno pensando e avranno già dei prototipi...

per gli Air avrebbe perfettamente senso, magari meno sui fissi, ma non si può tenere un Mac con un'architettura e uno con altra
è successo, ma solo nel periodo di transizione da PPC a Intel, poi tutti i Mac sono passati alla nuova architettura quindi se ci sarà questa transizione inizierà con gli Air ma dovrà riguardare tutti nel giro di uno o due anni

edit: per quanto riguarda Windows esiste sempre la virtualizzazione
mi sembra che la strada tracciata con iOS (e gli altri brand non sono da meno) sia proprio quella del sistema chiuso, puntando molto su App store e cercando di fidelizzare l'utente con le app
perderanno qualche cliente forse, ma stiamo parlando di percentuali non elevate in un mercato che rispetto al totale Apple non è nemmeno così alto, non credo che il supporto al dual boot sia in cima alle priorità di Cupertino...

Azz, praticamente sono cambiate più architetture alla Apple che per le Play Station :D

Scherzi a parte, possono permetterselo (e secondo me devono farlo) per vari motivi:
-Il parco di applicazioni x86 di Apple non è così esteso
-Microsoft ha licenze per produrre cpu Arm, anche Microsoft ha già fatto questa scelta (sta solo aspettando che il parco di applicazioni Arm aumenti e rimpiazzi quello x86), lo sta facendo gradualmente ma lo stanno già facendo, se Apple non vuole ritrovarsi indietro deve adeguarsi
-Arm è di base un architettura migliore di x86 (ed è anche più efficiente e parca nei consumi, migliore per un futuro sempre più "mobile")
-I seguaci della setta Apple comprerebbero qualsiasi cosa, un passaggio più indolore con questi consumatori non potrebbe esistere :D

Su questo non ci piove recoil.... Apple può benissimo ricalcare gli stessi passi quando passò ad Intel.
Mi chiedo però che razza di Mac ci troveremo per le mani... Come hai giustamente fatto notare, che senso ha adottare una piattaforma specificamente nata per i mobile device su un desktop???
A meno che non si dovrà dire goodbye ai desktop..... :eek: :(

Per il dual boot c'è sempre Windows RT! Comunque non credo sia una cosa che verrà fuori a breve, ci vorrà tempo prima che i processori ARM raggiungano le prestazioni degli Intel di fascia alta. Che Apple stia studiando la possibilità per il futuro è possibile, ma penso che per 2 o 3 anni possiamo stare tranquilli.

è un addio quindi a windows su mac?

Bisogna vedere gli sviluppi di windows RT, ad ora sembra un'esperimento in futuro chissà

Azz, praticamente sono cambiate più architetture alla Apple che per le Play Station :D

Scherzi a parte, possono permetterselo (e secondo me devono farlo) per vari motivi:
-Il parco di applicazioni x86 di Apple non è così esteso
-Microsoft ha licenze per produrre cpu Arm, anche Microsoft ha già fatto questa scelta (sta solo aspettando che il parco di applicazioni Arm aumenti e rimpiazzi quello x86), lo sta facendo gradualmente ma lo stanno già facendo, se Apple non vuole ritrovarsi indietro deve adeguarsi
-Arm è di base un architettura migliore di x86 (ed è anche più efficiente e parca nei consumi, migliore per un futuro sempre più "mobile")
-I seguaci della setta Apple comprerebbero qualsiasi cosa, un passaggio più indolore con questi consumatori non potrebbe esistere :D

Grazie per avermi dato di settario!!! :rolleyes:
Una CPU Arm non vede nemmeno con il cannocchiale le controparti x86 nelle applicazioni intensive, dove i consumi hanno una importanza relativa...
Se poi, diciamo tra 5 anni, Apple cesserà lo sviluppo di computer veri per buttarsi definitivamente in tablet e derivati, allora il passaggio avrà senso...
Inoltre non si stanno facendo i conti con l'oste Intel....

ma gli arm, nel giro di un paio d'anni, avranno prestazioni pari agli intel?
al momento il divario di prestazioni mi pare elevato, soprattutto considerando le cpu montate sul 15'' retina, sugli imac e ancora di più sui macpro.

Su questo non ci piove recoil.... Apple può benissimo ricalcare gli stessi passi quando passò ad Intel.
Mi chiedo però che razza di Mac ci troveremo per le mani... Come hai giustamente fatto notare, che senso ha adottare una piattaforma specificamente nata per i mobile device su un desktop???
A meno che non si dovrà dire goodbye ai desktop..... :eek: :(

addio ai desktop non credo, gli iMac piacciono ancora anche se il grosso delle vendite lo fanno con i laptop
resta da capire come saranno le prestazioni, la sensazione è che Apple stia diventando sempre più orientata al consumer e non al PRO "duro e puro", vedi caso MacPro

vediamo gli ultimi iMac, linea più sottile e compromessi (come il disco a 5400) per il design compatto
li faranno sempre più sottili e anche la dissipazione di calore diventerà un problema, a quel punto ARM sarà la soluzione ovvia
stesso discorso negli Air e nei Pro retina che a loro volta sono diventati molto sottili, altri problemi per dissipare energia

io penso da anni che, almeno nel mondo mobile (parlo dei portatili) l'autonomia è tutto
avere un Air che ti dura 10 ore come iPad vuol dire poter fare davvero l'intera giornata lavorativa senza attaccarsi alla corrente e per fortuna pian piano ci stiamo arrivando
il discorso è diverso se parliamo del fisso, ma penso che gran parte dei Mac che vendono li piazzerebbero lo stesso pure con prestazioni di CPU inferiori, per il design e per l'ecosistema Mac
e qui si torna al discorso che ho fatto prima sul fidelizzare il cliente tenendolo legato alla propria piattaforma

per questi motivi ritengo credibile il passaggio ad ARM, non immediatamente ma nel prossimo futuro
qualche utente Mac storico probabilmente rimarrà deluso, ma ho idea che incrementeranno il market share e a loro interessa quello

è un addio quindi a windows su mac?

E perchè mai? Mi risulta che Windows 8 supporta anche ARM e credo che se Microsoft e Apple spingessero nello sviluppo le architetture ARM potrebbero fare passi da gigante anche sui futuri ultrabook e portatili.

Grazie per avermi dato di settario!!! :rolleyes:
Una CPU Arm non vede nemmeno con il cannocchiale le controparti x86 nelle applicazioni intensive, dove i consumi hanno una importanza relativa...
Se poi, diciamo tra 5 anni, Apple cesserà lo sviluppo di computer veri per buttarsi definitivamente in tablet e derivati, allora il passaggio avrà senso...
Inoltre non si stanno facendo i conti con l'oste Intel....

Pensi che il target medio di chi acquista una MB Air o anche un MB Pro da 13" sia quello di chi fà uso di "applicazioni intensive"? Se si facesse una statistica su come l'utente medio utilizza il proprio computer scopriremmo che un core i3 mobile sarebbe già una soluzione sovradimensionata per il carico della macchina. Per come la vedo io un piattaforma ARM tra un paio d'anni accoppiata con 2-4 GB di Ram e disco SSD soddisferebbe una grandissima fetta di utenti che oggi sbandierano le specifiche dei loro portatili Intel e magari avrebbero pure una batteria che dura 14 ore.
Tutto sta nel fare il porting delle applicazioni X86 su ARM.

addio ai desktop non credo, gli iMac piacciono ancora anche se il grosso delle vendite lo fanno con i laptop
resta da capire come saranno le prestazioni, la sensazione è che Apple stia diventando sempre più orientata al consumer e non al PRO "duro e puro", vedi caso MacPro

vediamo gli ultimi iMac, linea più sottile e compromessi (come il disco a 5400) per il design compatto
li faranno sempre più sottili e anche la dissipazione di calore diventerà un problema, a quel punto ARM sarà la soluzione ovvia
stesso discorso negli Air e nei Pro retina che a loro volta sono diventati molto sottili, altri problemi per dissipare energia

io penso da anni che, almeno nel mondo mobile (parlo dei portatili) l'autonomia è tutto
avere un Air che ti dura 10 ore come iPad vuol dire poter fare davvero l'intera giornata lavorativa senza attaccarsi alla corrente e per fortuna pian piano ci stiamo arrivando
il discorso è diverso se parliamo del fisso, ma penso che gran parte dei Mac che vendono li piazzerebbero lo stesso pure con prestazioni di CPU inferiori, per il design e per l'ecosistema Mac
e qui si torna al discorso che ho fatto prima sul fidelizzare il cliente tenendolo legato alla propria piattaforma

per questi motivi ritengo credibile il passaggio ad ARM, non immediatamente ma nel prossimo futuro
qualche utente Mac storico probabilmente rimarrà deluso, ma ho idea che incrementeranno il market share e a loro interessa quello

Bhè il settore Pro in Apple è già andato.... Server cancellati e rimpiazzati dal Mac Mini o Pro, Mac Pro venduti con hardware di quasi due generazioni fa, programmi come Aperture ( chi si ricorda la prima o la seconda versione?? ) tramutati in iPhoto con gli steroidi... idem per FinalCut X....
Ripeto: il passaggio ad Arm è fattibilissimo, ma dubito che potrà garantire certi prodotti... D'altronde lo stesso Jobs, negli ultimi tempi, parlava sempre più spesso di " post PC era ".....

Pensi che il target medio di chi acquista una MB Air o anche un MB Pro da 13" sia quello di chi fà uso di "applicazioni intensive"? Se si facesse una statistica su come l'utente medio utilizza il proprio computer scopriremmo che un core i3 mobile sarebbe già una soluzione sovradimensionata per il carico della macchina. Per come la vedo io un piattaforma ARM tra un paio d'anni accoppiata con 2-4 GB di Ram e disco SSD soddisferebbe una grandissima fetta di utenti che oggi sbandierano le specifiche dei loro portatili Intel e magari avrebbero pure una batteria che dura 14 ore.
Tutto sta nel fare il porting delle applicazioni X86 su ARM.

Dici? Vorrei vedere, se fosse possibile, come le nuove architetture Cortex A50 se la cavano con immagini da 24Mpx, o a renderizzare e comprimere un filmato a 1080p di qualche GB... Chissà magari, tra qualche tempo, ci lavoreranno agevolmente, ma sono scettico.
A parte ciò, io mi sto riferendo in particolar modo a chi usa desktop e non certo sub notebook o notebook, visto che in listino ci sono ancora tre prodotti di questo segmento. Magari verranno sviluppate versioni desktop per ARM...
Il vero scoglio è proprio il porting di determinate applicazioni senza che se ne pregiudichino le prestazioni....

Ma cosa intendete per "pro"? E, soprattutto, quanti di questi "pro" necessitano, ancora oggi, di una potenza di calcolo maggiore di quella offerta da una cpu di livello medio-basso? Stiamo parlando di un settore di mercato in rapidissima contrazione, mi pare ovvio che diventi sempre meno interessante dal punto di vista strategico.

Dici? Vorrei vedere, se fosse possibile, come le nuove architetture Cortex A50 se la cavano con immagini da 24Mpx, o a renderizzare e comprimere un filmato a 1080p di qualche GB... Chissà magari, tra qualche tempo, ci lavoreranno agevolmente, ma sono scettico.
A parte ciò, io mi sto riferendo in particolar modo a chi usa desktop e non certo sub notebook o notebook, visto che in listino ci sono ancora tre prodotti di questo segmento. Magari verranno sviluppate versioni desktop per ARM...
Il vero scoglio è proprio il porting di determinate applicazioni senza che se ne pregiudichino le prestazioni....

Io non so se tra uno o due anni con una soluzione ARM riuscirai ad aprire 10 RAW da 24 Mpx con lightroom o se potrai editare un video 1080p di 40 minuti con premiere, so che se chiedi a 100 persone che possiedono un MB air o un MBP da 13" 90 ti rispondono che quelle cose non sanno mennemo cosa siano. Probabilmente gli altri 10 ti risponderebbero che hanno anche il desktop e magari un ultrabook solo per internet-word-excel-facebook-youtube-itunes-skype-iphoto-ivideo con un processore ARM, una batteria performante ed un costo contenuto se lo prenderebbero volentieri. Io sono uno di quelli ad esempio ...

Grazie per avermi dato di settario!!! :rolleyes:
Una CPU Arm non vede nemmeno con il cannocchiale le controparti x86 nelle applicazioni intensive, dove i consumi hanno una importanza relativa...
Se poi, diciamo tra 5 anni, Apple cesserà lo sviluppo di computer veri per buttarsi definitivamente in tablet e derivati, allora il passaggio avrà senso...
Inoltre non si stanno facendo i conti con l'oste Intel....

Ad Apple frega poco Intel o non Intel, loro guardano ai profitti.
Hanno già abbandonato la divisione server e stanno abbandonando quella dei desktop.
La "massa" (quelli che non sanno la differenza tra un i7 e un arm da 3 watt, e ne sono tanti) vuole solo cose fighe...e pagano bene...

a mio parere, verrà integrato un chip ARM all'interno della scheda madre dei futuri Mac, così da poter far girare sia Applicazioni OSX che iOS senza emulazioni.... IMHO... dopotutto i SOC sono decisamente piccoli...
La sostituzione totale sarebbe impossibile... vi immaginate lavorare in Photoshop su ARM... per adesso manca potenza e +potenza +consumo.. quindi tanto varrebbe tenere gli Intel

Ma cosa intendete per "pro"? E, soprattutto, quanti di questi "pro" necessitano, ancora oggi, di una potenza di calcolo maggiore di quella offerta da una cpu di livello medio-basso? Stiamo parlando di un settore di mercato in rapidissima contrazione, mi pare ovvio che diventi sempre meno interessante dal punto di vista strategico.

Boh! Non direi che dal punto di vista strategico quello dei PC ad alte prestazioni sia un settore poco interessante, può essere poco profittevole, ma se un utente che necessita di potenza si trova a dover usare un altro sistema, non pensi che poi alla lunga sia portato ad affezionarsi alla concorrenza?????

Vedremo cosa ci prospetta il futuro, ma il mercato fa presto a virare e tutte le aziende devono tenerne conto.....

è un addio quindi a windows su mac?

Niente è eterno, men che meno in un settore come quello tecnologico.
Chi è cresciuto nei 20 anni wintel forse fa fatica a rendersi conto che anche questa piattaforma è giunta al capolinea e che il futuro non sarà più dominato dai pc, noi "vecchi" che siamo nati con IBM e l' abbiamo vista disfarsi in pochi anni invece abbiamo già potuto vivere un momento simile.
Non sarà l' anno prossimo e forse neppure quello dopo, ma la frana si sta muovendo sempre più velocemente e le aziende come Intel, AMD e Microsoft si rendono conto che la posizione dominante che avevano sta diventando irrilevante mentre emergono nuovi colossi come Apple e Google.



Ma da un altro, chi con il mac ci lavora pesante (photoshop, premiere), potrebbe accettare una diminuzione delle performance?

Lo dicevano anche negli anni '80: "quelle scatolette non possono fare niente, non hanno la potenza di calcolo sufficente, non hanno abbastanza ram, sono solo dei giocattolini, il futuro è e resterà quello dei mainframe, chi ci deve lavorare non può usare certa roba" :fagiano:

audio, video, grafica, progettazione edile e meccanica, giusto per citarne qualcuno. non mi pare che tutti insieme si possano considerare un settore di nicchia.
Secondo me sì, hanno un ruolo importante ma numericamente poco consistente. Probabilmente è solo una mia impressione.
Inoltre più aumentano i dispositivi in grado di fruire di contenuti multimediali (vedi tablet e smartphone), più aumentano i fornitori di tali contenuti. E questi fornitori hanno bisogno di hardware con potenza di calcolo per creare contenuti di qualità sempre migliore.
Secondo me, per creare contenuti di qualità migliore serve maggiore potenza di calcolo nella scatola cranica, più che nella cpu dello strumento usato.
Dire che è un mercato in rapidissima contrazione mi pare proprio errato...se poi hai qualche fonte che testimonia questa tendenza sarò felice di leggerla.
No, nessuna. E' semplicemente la mia percezione della realtà che vedo intorno a me (e quindi assolutamente inaffidabile, per questo mi piace confrontarla con quelle altrui).
Aggiungiamo ai pro anche chi si diletta a livello amatoriale, con foto/video. Anche loro hanno bisogno di una certa potenza di calcolo.
Sempre imho, la peggiore delle cpu esistenti oggi sul mercato può ampiamente soddisfare le loro esigenze (tradotto: non sono più clienti il cui acquisto è basato sulla ricerca di potenza, come poteva essere qualche anno fa).
Certo il professionista inteso come scrittore/medico/avvocatocommercialista ecc... potrebbe già da oggi lavorare con un arm.
E, infatti, a mio parere quest'ultima categoria, a livello numerico, rappresenta la fetta più grossa del settore cosiddetto "pro" (sempre che vogliamo continuare a chiamarlo così).

Sono completamente fuori di senno! :eek: :eek: :eek:

ARM al momento è molto più lento! Ma anche fosse veloce uguale o più veloce, hanno idea che al passaggio perderanno tutti i software!?!?

Secondo me è una bufala, al momento non ci sono proprio i presupposti per fare una cosa del genere, nel senso che non esiste un processore ARM che possa lontanamente competere con un X86, anche se di fascia bassa.

Quindi unica piattaforma hardware (ARM) e unico OS (iOS), niente dual boot e quindi niente windows o altri OS installabili, in puro stile cupertino direi, spero avvenga al più presto.

Ma da un altro, chi con il mac ci lavora pesante (photoshop, premiere), potrebbe accettare una diminuzione delle performance?Se vuoi prestazioni non compri un mac.

è un addio quindi a windows su mac?Direi di sì, a meno che uno non voglia metterci Win 8 RT ma lì non ci girano le app classiche, quindi è pressoché inutile.

Scherzi a parte, possono permetterselo (e secondo me devono farlo) per vari motivi:
-Il parco di applicazioni x86 di Apple non è così esteso
-Arm è di base un architettura migliore di x86 (ed è anche più efficiente e parca nei consumi, migliore per un futuro sempre più "mobile")
-I seguaci della setta Apple comprerebbero qualsiasi cosa, un passaggio più indolore con questi consumatori non potrebbe esistere :D
- parco applicazioni esteso o meno tutti i soldi che c'ha speso la gente andranno buttati, dubito che tutte le app verranno rifatte per ARM e dubito che quelle che verranno convertite verranno anche "regalate" dalle case produttrici.
- ARM consuma di meno ma a livello di prestazioni pure è ancora sotto, inoltre Intel ultimamente ha migliorato parecchio i consumi dei suoi processori quindi non so quanto convenga.
- Riguardo ai seguaci hai ragionissima! :asd:

I cinesi lo avevano predetto un mese fa. Hanno informatori migliori. :sofico:
http://www.bitsandchips.it/9-hardware/1758-apple-pronta-ad-abbandonare-le-cpu-intel

Secondo me, per creare contenuti di qualità migliore serve maggiore potenza di calcolo nella scatola cranica, più che nella cpu dello strumento usato.

Quello sempre e in qualsiasi settore... Poi però arriva il momento in cui devi trasformare quello che hai nella scatola cranica in qualcosa di concreto e uno strumento con una CPU veloce, che ti riduce l'elaborazione a metà del tempo o meno, aiuta la produttività, inutile negarlo.

Secondo Geekbench, l'iPhone 5 se la vede alla pari con i G5 di 8 anni fa.
Diciamo che ho qualche dubbio.

Secondo Geekbench, l'iPhone 5 se la vede alla pari con i G5 di 8 anni fa.
Diciamo che ho qualche dubbio.

In calcoli interi, in virgola mobile penso che le prenda di brutto, a meno che il codice non sfrutti la GPU tramite OpenCL o roba simile.

Noi pensiamo ad ARM solo per le soluzioni mobile che abbiamo visto. È altresì vero che Apple può prendere in licenza da ARM solo il set di istruzioni e sviluppare una CPU che funzioni con "parametri desktop". Quindi molto più veloce e meno parca nei consumi di una mobile. Tutto ciò che la CPU non è in grado di fare con un set di istruzioni ridotto lo si potrebbe veicolare verso una GPU discreta. Un po' come già avviene oggi sugli smartphone. Sarebbe una bella rivoluzione.

--- edit - post doppio ---

Comunque è interessante vedere dove possono arrivare gli ARM con meno limiti di consumo, certo che perdere la virtualizzazione x86 è una palla, ma magari per il 2017 ci sarà tanto software compatibile con Windows RT e successivi... Vedremo.

Io non so se tra uno o due anni con una soluzione ARM riuscirai ad aprire 10 RAW da 24 Mpx con lightroom o se potrai editare un video 1080p di 40 minuti con premiere, so che se chiedi a 100 persone che possiedono un MB air o un MBP da 13" 90 ti rispondono che quelle cose non sanno mennemo cosa siano. Probabilmente gli altri 10 ti risponderebbero che hanno anche il desktop e magari un ultrabook solo per internet-word-excel-facebook-youtube-itunes-skype-iphoto-ivideo con un processore ARM, una batteria performante ed un costo contenuto se lo prenderebbero volentieri. Io sono uno di quelli ad esempio ...

Itunes è un tumore su x86 dual core con 4gb di ram, me lo immagino su arm mentre magari usi excel, piú che un ultrabook avresti un ultralag....
Arm non colmerà mai il gap con x86 sono una 10 di anni indietro per quanto riguarda le performance...

Itunes è un tumore su x86 dual core con 4gb di ram, me lo immagino su arm mentre magari usi excel, piú che un ultrabook avresti un ultralag....
Arm non colmerà mai il gap con x86 sono una 10 di anni indietro per quanto riguarda le performance...

Vedremo, sta di fatto che non sono nè scemi nè sprovveduti, se è vero che stanno valutando un portatile su architettura ARM penso che abbiamo fatto degli studi di fattibilità, non è che si improvvisano costruendo un pezzo d'alluminio e poi dicono vediamo adesso come ci girano i programmi.

Sono completamente fuori di senno! :eek: :eek: :eek:

ARM al momento è molto più lento! Ma anche fosse veloce uguale o più veloce, hanno idea che al passaggio perderanno tutti i software!?!?

Ai tempi che furono l'ARM2 realizzato con un quarto dei transitor dell'80286 gli spaccava il cuBo a colpi di pura potenza di calcolo. :read:

Solo che poi mentre Intel con gli x86 si è concentrata su cpu per desktop e server, ARM ha invece privilegiato le soluzioni embedded e mobile (dove una volta raggiunto un certo livello di potenza di calcolo, la cosa più importante è che un chip costi poco e consumi poco).

Ma se poniamo AMD decidesse di applicare tutto il know how che ha in termini di capacità di sviluppare roba ad alte prestazioni e tirata al limite dell'inviluppo di potenza, ci metterebbe poco a realizzare una cpu ARM capace di competere ad armi pari con gli x86.
Questo perchè il decoder istruzioni degli ARM è molto più semplice ed efficiente di quello degli x86 mentre tutta la roba "dopo il decoder" può essere adattata in tempi relativamente ridotti.

Con un calcolo spannomentrico, a parità di tecnologia di produzione si potrebbe realizzare un core ARM con minimo il doppio dei thread rispetto ad un x86.
Anche a parità di prestazioni per thread, il maggior numero di thread eseguibili in parallelo gli darebbe un bel vantaggio.

Rimane il problema delle vecchie applicazioni disponibili solo per x86, ma su questo lato Apple ha di gran lunga meno problemi rispetto a Microsoft (senza contare che pure Microsoft sta spingendo da anni gli sviluppatori a non dipendere dall'architettura x86 sebbene la cosa proceda per le lunghe).

Il problema di Apple sta nell'esser troppo avanti, e quindi nell'aver dismesso la linea pro troppo presto. Il futuro visto da Jobs sta nel cloud, e tutte le decisioni prese vanno in quella direzione. Tutte le applicazioni esose di risorse in meno di 10 anni verranno gestite da remoto. Chi pensa che non sarà mai possibile causa rete inappropriata, sbaglia.
Personalmente in azienda ho deciso di dotarmi solo di mac come client, ospitando tutti i software esosi e quelli windows e linux, su server remoti, utilizzando la tecnologia PCoIP di teradici per collegare client e server (più che server nel mio caso attuale trattasi di workstation remote). Su rete locale la latenza è inavvertibile (non passo attraverso switch ma il collegamento ethernet è diretto), ed in molti casi risulta buono anche il collegamento remoto via internet (bastano anche solo 3 mb in entrata e 1 in uscita).
Il vantaggio di questa architettura è l'aver le workstation collegate in fibra ottica e poterne sfruttare il calcolo parallelo delle GPU Tesla, con prestazioni superiori alle CPU intel, compresi gli xeon più prestazionali.
Con tale struttura potrei già oggi avere iMac e Macbook pro dotati di CPU ARM.

Il problema di Apple sta nell'esser troppo avanti, e quindi nell'aver dismesso la linea pro troppo presto. Il futuro visto da Jobs sta nel cloud, e tutte le decisioni prese vanno in quella direzione. Tutte le applicazioni esose di risorse in meno di 10 anni verranno gestite da remoto. Chi pensa che non sarà mai possibile causa rete inappropriata, sbaglia.
Personalmente in azienda ho deciso di dotarmi solo di mac come client, ospitando tutti i software esosi e quelli windows e linux, su server remoti, utilizzando la tecnologia PCoIP di teradici per collegare client e server (più che server nel mio caso attuale trattasi di workstation remote). Su rete locale la latenza è inavvertibile (non passo attraverso switch ma il collegamento ethernet è diretto), ed in molti casi risulta buono anche il collegamento remoto via internet (bastano anche solo 3 mb in entrata e 1 in uscita).
Il vantaggio di questa architettura è l'aver le workstation collegate in fibra ottica e poterne sfruttare il calcolo parallelo delle GPU Tesla, con prestazioni superiori alle CPU intel, compresi gli xeon più prestazionali.
Con tale struttura potrei già oggi avere iMac e Macbook pro dotati di CPU ARM.

Apple ha semplicemente tralasciato la linea pro perchè la consumer ha maggiori margini, il problema fondamentale per professionisti come me è che allo stato attuale non c'è nulla di pro, windows 8 punta tutto sul consumer OSX rimane un os solido per i professionisti ma con ciò che apple sta assemblando dentro quei mac è praticamente l'anti-pro.
Forse dovremo buttarci tutti su windows 7, che tuttavia ha ancora al max 5-8 anni di supporto garantiti da casa microsoft e che non è comunque al livello di osx.
Quindi cammafà? Linux? Sarebbe bello ma non ci sono gli applicativi necessari.
Si prevede un brutto futuro per i professionisti con macchine ad hoc e costosissime e dall'altro lato macchine consumer dal prezzo intermedio e praticamente inutili per un utilizzo avanzato.

La vedo molto improbabile.... probabilmente qualcuno ha bisogno che i titoli apple/intel subiscano una variazione.... così come ogni tot di tempo si legge che samsung comprerà amd a breve....;)

Per me Apple si sta cavando la fossa con le sue mani. Chissà perchè era ritornata a Intel (e i miglioramenti si sono visti subito).....boh...andranno e poi ritorneranno...andranno e poi ritorneranno...andranno e poi ritorneranno....

Ha un certo senso, ma ci vogliono almeno altre 3 generazioni di SoC Arm prima di parlarne.

Diciamo, effettivo dall'anno 2020. :cool:

Hanno ancora tutto il tempo di aggiornare la linea Mac Pro ;)

Con un calcolo spannomentrico, a parità di tecnologia di produzione si potrebbe realizzare un core ARM con minimo il doppio dei thread rispetto ad un x86.
Anche a parità di prestazioni per thread, il maggior numero di thread eseguibili in parallelo gli darebbe un bel vantaggio.


Non diciamo sciocchezze
La parte decoder è minima e il vantaggio di arm su Intel non esiste, anzi probabilmente è la seconda in posizione di vantaggio grazie all' immenso know-how e ai fondi smisurati.
Arm ha già provato in passato a contrastare Intel e ne è uscita a pezzi, è relativamente facile produrre una cpu nuova e ottenere grandi prestazioni, ci sono riusciti in tanti ( anche Motorola, Sun, AMD e IBM lo hanno fatto ), il problema è restare in vetta senza perdere il ritmo.

windows 8 punta tutto sul consumer.
Forse dovremo buttarci tutti su windows 7, che tuttavia ha ancora al max 5-8 anni di supporto garantiti da casa microsoft

1)Io non capisco perchè reputi Win7 buono e Win8 spazzatura. Win8 è più veloce, reattivo, leggero, occupa meno ram, si accende e si spegne in un quarto del tempo di Win7, sicurezza migliore, migliorie ovunque...
2)Le licenze costano anche meno.
3)L'interfaccia metro non influenza NIENTE per quanto riguarda la produttività (anzi hanno aggiunto molte scorciatoie con le hotkey da tastiera comodissime).
Win+Q, scrivi "photos" e photoshop è già li, premi Invio e si apre
Win+Q, scrivi "blend" e blender è già li, premi Invio, fine.
Oppure te li metti nella barra delle applicazioni sotto
Ad aprire i programmi ci vuole pochissimo, una volta aperti che ti cambia?
Io non capisco...io che uso il computer per lavorare, lo accendo e l'unico pulsante "Metro" che premo è "Desktop". Fine.

e che non è comunque al livello di osx.
un dual boot Win8 + CentOS e ho tutto
OSX non fa nè le cose di Win8 nè le cose di Linux, è una via di mezzo inutile (per il mio utilizzo, non metto assolutamente in dubbio che sia un ottimo OS)
Poi magari chi usa programmi particolari si trova meglio con OSX, ma non è sempre vero in generale, a ognuno il suo ;)

Non diciamo sciocchezze
La parte decoder è minima e il vantaggio di arm su Intel non esiste, anzi probabilmente è la seconda in posizione di vantaggio grazie all' immenso know-how e ai fondi smisurati.

Stai facendo troppa confusione tra architetture di cpu ed aziende. :read:

Non a caso ho scritto "se AMD decidesse di applicare tutto il know how che ha in termini di capacità di sviluppare roba ad alte prestazioni e tirata al limite dell'inviluppo di potenza ...".
AMD non ARM ltd. ;)
AMD ha il know-how necessario e le risorse per tirar fuori degli ARM ad alte prestazioni, non ARM ltd (che continua ad avere il suo core business come fornitore di IP, non come produttore/venditore di hardware).

Poi è vero che la parte decoder sulle cpu per desktop/server è "minima" rispetto al resto, ma non è così ininfluente come potrebbe sembrare a prima vista.

Pensa ad esempio al flop clamoroso di IA64 dovuto in primo luogo al suo set d'istruzioni ed a quello che implicava a cascata riguardo banda di I/O, decoder ed unità di esecuzione.
Nonostante Intel ci si sia svenata dietro in tutti i modi ormai sopravvive solo grazie al contratto capestro di HP che impone ad Intel di continuare a supportare tale cpu.
Ed infatti dopo quella batosta Intel se ne è uscita con la sua attuale strategia "x86 ovunque".

Arm ha già provato in passato a contrastare Intel e ne è uscita a pezzi, è relativamente facile produrre una cpu nuova e ottenere grandi prestazioni, ci sono riusciti in tanti ( anche Motorola, Sun, AMD e IBM lo hanno fatto ), il problema è restare in vetta senza perdere il ritmo.

No, ARM Ltd. a suo tempo si è concentrata sulla progettazione e la vendita di licenze ed Proprietà Intellettuali per il settore embedded e mobile, non ha mai provato a contrastare Intel sui desktop e sui server.
Al massimo i primi ARM sono stati usati su home computer (e come potenza di calcolo erano più potenti dei corrispettivi x86 del periodo, usando pure meno gate sul chip) ma poi praticamente più niente in tal senso, al massimo PDA e smartphone, solo ora con tablet e smarphone sempre più potenti (e con la nuova architettura a 64bit) potrebbe iniziare l'attacco verso i desktop.

Proprio ora che i Mac hanno buone prestazioni vogliono utilizzare processori meno potenti?

1)Io non capisco perchè reputi Win7 buono e Win8 spazzatura. Win8 è più veloce, reattivo, leggero, occupa meno ram, si accende e si spegne in un quarto del tempo di Win7, sicurezza migliore, migliorie ovunque...
2)Le licenze costano anche meno.
3)L'interfaccia metro non influenza NIENTE per quanto riguarda la produttività (anzi hanno aggiunto molte scorciatoie con le hotkey da tastiera comodissime).
Win+Q, scrivi "photos" e photoshop è già li, premi Invio e si apre
Win+Q, scrivi "blend" e blender è già li, premi Invio, fine.
Oppure te li metti nella barra delle applicazioni sotto
Ad aprire i programmi ci vuole pochissimo, una volta aperti che ti cambia?
Io non capisco...io che uso il computer per lavorare, lo accendo e l'unico pulsante "Metro" che premo è "Desktop". Fine.


un dual boot Win8 + CentOS e ho tutto
OSX non fa nè le cose di Win8 nè le cose di Linux, è una via di mezzo inutile (per il mio utilizzo, non metto assolutamente in dubbio che sia un ottimo OS)
Poi magari chi usa programmi particolari si trova meglio con OSX, ma non è sempre vero in generale, a ognuno il suo ;)Quoto tutto.

Proprio ora che i Mac hanno buone prestazioni vogliono utilizzare processori meno potenti?A loro non gli interessa come vano le macchine, gli basta che siano una cosa tutta loro che venda.

Sinceramente non la vedo male questa transizione.

Sono piattaforme diverse, e' vero, ma io guarderei un po' la differenza prestazionale... Su un dispositivo che consuma pochi milliwatt (per quanto sia un quad core tegra 3 sticazzi e mazzi) ci girano giochi che tra poco arrivano al livello delle console.

Un x86 e' un'architettura diversa, ma se penso che con un ARM ci faccio le stesse cose (e anche di piu') con un consumo irrisorio e un calore generato quasi nullo... Le dimensioni di un netbook... E lo dimostrera' bene Windows 8 su ARM.


Cosi' comunque Apple avrebbe anche il vantaggio di fare un OS unico ma con una GUI diversa a seconda se e' un iP-qualcosa o un MacBook-qualsiasi. Oppure fara' come Microsoft e fara' una GUI unica per tutti i dispositivi.


Per quanto Apple non mi possa piacere, i suoi prodotti non sono schifezze (anche se il prezzo e' alto e io al massimo li prendo usati a poco) e le scelte che fa di abbandonare certi standard (attenzione, abbandonare, non cambiare) non e' per nulla un male.
Che io sappia e' stata la prima a dire "basta ai floppy", "basta alle unita' ottiche" e ora "basta a x86".

La vera capacita' di Apple non e' quella di inventare cose, ma far cambiare tendenza alle persone e alle aziende. Nessuno si cag*va di striscio i palmari/cellulari, arriva iPhone e tutti a comprare e produrre cellulari touch. Nessuno pensava ai tablet come dispositivi da utilizzare, arriva lei a farne uno e tutti a fare tablet. Idem per l'Air, sottile, leggero e giu' a fare gli ultrabook.
L'iPod touch, che io sappia, e' l'unico lettore mp3/mp4 multimediale dove ci puoi installare anche delle app. Se esistono anche quelli Android (tipo forse gli Archos) quasi nessuno li sente mai nominare.
Forse forse (parlo sempre per "quello che ne so io") anche gli all-in-one sono stati commercializzati pesantemente (quindi non inventati, ma commercializzati) la prima volta da Apple.
E del mac-mini? Per quanto si voglia e possa dire, e' l'unico nel suo genere cosi' potente e a quel prezzo.
E come estetica (che puo' non piacere) sinceramente e' una bella linea. Io ho sempre sbavato sull'Air e sull'iMac della Apple (l'Air, usato, ora ce l'ho e pagato poco :D con su Windows 7 in dual boot).


Questa e' una cosa che apprezzo di Apple, sinceramente. Poi che costringa i clienti ad utilizzare il dispositivo come vogliono loro (con restrizioni all'OS, blindature varie, ecc) e' gia' una cosa che fa girare i maroni, cosi' come i prezzi assurdi.
Ma non e' colpa loro se la gente fa la fila dormendo davanti agli Apple Store e pestandosi per gli ultimi iPhone del day-one (quando basterebbe starsene tranquilli e comprarlo i giorni successivi)...


EDIT: ah, prima che partano commenti vari... Io odio Apple ma non i suoi prodotti (i prezzi si'), ho un Android (HTC Desire HD con MIUI Jelly Bean) come smartphone dopo aver passato anni con Nokia e Symbian, un iPod 2G preso usato quando il vecchio Creative Zen (si', quello con schermo in bianco e nero) e' saltato, un Asus G51JX preso personalmente a New York come notebook gaming (firma), un Air 2010 (con la GT 320M) preso usato dall'america per spendere poco con Windows 7 in dual boot... Quindi non sto tanto a guardare chi o cosa crea un prodotto, ma sto a guardare cosa conviene comprare sia per il prezzo (usato o nuovo), sia per la dotazione e le capacita' di un dispositivo (potevo prendere un lettore MP3 qualsiasi, ma ho preferito un piu' evoluto iPod e sono contento cosi', l'Air mi piaceva ed e' comodo da trasportare (forse pero' se aspettavo il modello successivo che hanno fatto anche l'11"...), un iPhone costa troppo e non si puo' cambiare la batteria, inoltre ero abituato agli smanettamenti su Symbian quindi ho preferito Android).

Ai tempi che furono l'ARM2 realizzato con un quarto dei transitor dell'80286 gli spaccava il cuBo a colpi di pura potenza di calcolo. :read:

Solo che poi mentre Intel con gli x86 si è concentrata su cpu per desktop e server, ARM ha invece privilegiato le soluzioni embedded e mobile (dove una volta raggiunto un certo livello di potenza di calcolo, la cosa più importante è che un chip costi poco e consumi poco).

Ma se poniamo AMD decidesse di applicare tutto il know how che ha in termini di capacità di sviluppare roba ad alte prestazioni e tirata al limite dell'inviluppo di potenza, ci metterebbe poco a realizzare una cpu ARM capace di competere ad armi pari con gli x86.
Questo perchè il decoder istruzioni degli ARM è molto più semplice ed efficiente di quello degli x86 mentre tutta la roba "dopo il decoder" può essere adattata in tempi relativamente ridotti.

Con un calcolo spannomentrico, a parità di tecnologia di produzione si potrebbe realizzare un core ARM con minimo il doppio dei thread rispetto ad un x86.
Anche a parità di prestazioni per thread, il maggior numero di thread eseguibili in parallelo gli darebbe un bel vantaggio.

Rimane il problema delle vecchie applicazioni disponibili solo per x86, ma su questo lato Apple ha di gran lunga meno problemi rispetto a Microsoft (senza contare che pure Microsoft sta spingendo da anni gli sviluppatori a non dipendere dall'architettura x86 sebbene la cosa proceda per le lunghe).

Ieri avevo scritto un bel post, ma HWU se l'è mangiato :(

E riscriviamo! :D

Secondo me quello che dici è giusto ma non considera una cosa fondamentale: la ricchezza di Intel. Intel è un'azienda che ha dalla sua fondi, fabbriche e know-how necessari per sviluppare al massimo x86. Sarà anche un'architettura inefficiente e obesa (Atom ne è uno degli ultimi esempi) ma riesce a garantire un buon livello di potenza, e con quei tre elementi di poco fa Intel ci metterebbe poco a farla spingere al massimo. A suon di riduzioni di PP la fanno sembrare sempre più efficiente, e di fatto quello che conta è il consumo effettivo.

ARM può sperare con AMD ma non sarebbe in grado di competere per un ingresso di punta nel mercato, non ha le risorse necessarie. In più dovrebbero appoggiarsi a TMSC (che ultimamente non brilla) e Globalfoundries, ma le rese produttive potrebbero non essere sufficienti.

Quindi si potrebbe fare si un ARM bello carrozzato ma di fatto avrebbe lo stesso consumo di Intel, dato che Intel potrebbe sempre scendere di PP. Ma si porterebbe dietro gli svantaggi di non avere software. La storia ci insegna che niente software = FALLIMENTO. Vedi Symbian che è fallito alla velocità della luce, di recente. Apple come spera di garantire questo cambio radicale mantenendo tutti i software? I big potrebbero reagire male e rilasciare con lentezza o cmq sfornare sw non troppo ottimizzato. Se fino al giorno prima, Adobe per esempio, deve fare Photoshop per il Mac con Intel, non può passare di colpo a Photoshop per ARM. Ci vuole tempo. E nel frattempo che si fa? QUando esce quello nuovo, le patch per il vecchio? Anche il vecchio andrebbe mantenuto in sviluppo. Costi, costi e costi. Col passaggio PowerPC->Intel era diverso perchè Win aveva già x86 e quindi si poteva riciclare parecchio da lì. Ma ora ci sarebbe da fare un grosso lavoro, come testimonia Windows 8 RT. Apple potrebbe perdere di colpo tutta la fascia professionisti che già sono inca**ati perchè di fatto li stanno già abbandonando. Ma se fanno brutti scherzi anche a quei professionisti meno esigenti che gli bastano quei due SW per essere contenti, potrebbero perdere tutto il mercato PC, o cmq una buona fetta.

Visto che il mercato mobile tira parecchio Apple sta facendo i soldi con quelli ma non può sperare di rimanere SOLO con quelli. I dati parlano chiaro. Samsung sta acquisendo quote di mercato e sono pronto a scommettere che anche Nokia-MS con Win Phone 8 farà un ingresso molto più aggressivo di Win Phone 7. Non che Cook debba rinunciare ai suoi sogni tranquilli, ma fai iniziare l'erosione di quote di mercato in un settore dove fino al giorno prima eri in espansione... Non è così rosea la situazione. GLi investitori potrebbero perdere fiducia, e visto che Apple vale quel che vale anche e soprattutto per il mercato virtuale speculativo potrebbe scendere in picco.

IMHO, ad entrare così nel mercato ARM, Apple si butta nel vuoto senza paracadute. Soprattutto per il modo in cui vuole farlo, dato che sicuramente vorrà anche la SUA CPU e non si accontenterà di stringere accordi con AMD, nVidia o altro...

Ma si porterebbe dietro gli svantaggi di non avere software. La storia ci insegna che niente software = FALLIMENTO. Vedi Symbian che è fallito alla velocità della luce, di recente. Apple come spera di garantire questo cambio radicale mantenendo tutti i software? I big potrebbero reagire male e rilasciare con lentezza o cmq sfornare sw non troppo ottimizzato. Se fino al giorno prima, Adobe per esempio, deve fare Photoshop per il Mac con Intel, non può passare di colpo a Photoshop per ARM. Ci vuole tempo. E nel frattempo che si fa? QUando esce quello nuovo, le patch per il vecchio? Anche il vecchio andrebbe mantenuto in sviluppo.

https://itunes.apple.com/it/app/adobe-photoshop-express/id331975235?mt=8

Se gia' esiste questo, ci vuole poco a fare quello completo.

Forse tu, come altri, non vi rendete conto di una cosa: se Apple cambia, anche gli altri cambiano (come ho appena scritto sopra).
Windows 8 e' gia' su piattaforma ARM, ora anche Apple. Credi che Adobe e le altre aziende non si mettano a produrre software per ARM? Ma dai...

Gia' la mela di suo e' un bel trattore (ripeto: mio post sopra), se poi c'e' anche Windows... E contiamo che molte distro Linux gia' vanno su ARM, senza menzionare Android.

Non mi sembra che ci sia tutto sto casino che dici tu. Anzi, al contrario di quello che hai detto tu (che non ho quotato) e' Intel che si deve spaventare di ARM e non ARM che fara' fatica a spuntare fuori anche nei pc...

E pure AMD si deve spaventare, il doppio, non solo sul fronte CPU ma anche GPU visto che Nvidia e' gia' fuori con Tegra da mesi e mesi.

Apple potrebbe perdere di colpo tutta la fascia professionisti che già sono inca**ati perchè di fatto li stanno già abbandonando. Ma se fanno brutti scherzi anche a quei professionisti meno esigenti che gli bastano quei due SW per essere contenti, potrebbero perdere tutto il mercato PC, o cmq una buona fetta.

Se il mercato cambia, anche i professionisti si adeguano, altrimenti non "professano" piu' nulla, fidati.

Visto che il mercato mobile tira parecchio Apple sta facendo i soldi con quelli ma non può sperare di rimanere SOLO con quelli. I dati parlano chiaro. Samsung sta acquisendo quote di mercato e sono pronto a scommettere che anche Nokia-MS con Win Phone 8 farà un ingresso molto più aggressivo di Win Phone 7. Non che Cook debba rinunciare ai suoi sogni tranquilli, ma fai iniziare l'erosione di quote di mercato in un settore dove fino al giorno prima eri in espansione... Non è così rosea la situazione. GLi investitori potrebbero perdere fiducia, e visto che Apple vale quel che vale anche e soprattutto per il mercato virtuale speculativo potrebbe scendere in picco.

Quello potrebbe anche succedere rimanendo su x86...

IMHO, ad entrare così nel mercato ARM, Apple si butta nel vuoto senza paracadute. Soprattutto per il modo in cui vuole farlo, dato che sicuramente vorrà anche la SUA CPU e non si accontenterà di stringere accordi con AMD, nVidia o altro...

Quale sua CPU... Fino a poco fa i chip ARM degli iphone erano della Samsung... Apple non produce nulla di suo, se non il software. I componenti hardware sono fatti da altri (CPU intel e samsung, ssd intel o salcavolo, schede video nvidia, ecc). Lei ci mette software e design.

Semplicemente potrebbe passare a Tegra o Qualcomm, dov'e' il problema... Anzi, cerchera' di mantenere compatibilita' con quelli di iPhone e iPad in modo che una stessa app possa essere sviluppata per tutti i dispositivi con poche modifiche da fare (ovviamente senza dare la possibilita' che un'app per un iMac funzioni per iPhone, anche perche' su iMac hai tastiera e mouse...).

https://itunes.apple.com/it/app/adobe-photoshop-express/id331975235?mt=8

Se gia' esiste questo, ci vuole poco a fare quello completo.

Forse tu, come altri, non vi rendete conto di una cosa: se Apple cambia, anche gli altri cambiano (come ho appena scritto sopra).
Windows 8 e' gia' su piattaforma ARM, ora anche Apple. Credi che Adobe e le altre aziende non si mettano a produrre software per ARM? Ma dai...

Gia' la mela di suo e' un bel trattore (ripeto: mio post sopra), se poi c'e' anche Windows... E contiamo che molte distro Linux gia' vanno su ARM, senza menzionare Android.

Non mi sembra che ci sia tutto sto casino che dici tu. Anzi, al contrario di quello che hai detto tu (che non ho quotato) e' Intel che si deve spaventare di ARM e non ARM che fara' fatica a spuntare fuori anche nei pc...

E pure AMD si deve spaventare, il doppio, non solo sul fronte CPU ma anche GPU visto che Nvidia e' gia' fuori con Tegra da mesi e mesi.



Se il mercato cambia, anche i professionisti si adeguano, altrimenti non "professano" piu' nulla, fidati.



Quello potrebbe anche succedere rimanendo su x86...



Quale sua CPU... Fino a poco fa i chip ARM degli iphone erano della Samsung... Apple non produce nulla di suo, se non il software. I componenti hardware sono fatti da altri (CPU intel e samsung, ssd intel o salcavolo, schede video nvidia, ecc). Lei ci mette software e design.

Semplicemente potrebbe passare a Tegra o Qualcomm, dov'e' il problema... Anzi, cerchera' di mantenere compatibilita' con quelli di iPhone e iPad in modo che una stessa app possa essere sviluppata per tutti i dispositivi con poche modifiche da fare (ovviamente senza dare la possibilita' che un'app per un iMac funzioni per iPhone, anche perche' su iMac hai tastiera e mouse...).

Apple è potente solo nel mercato in cui già ora domina, quello dei tablet/smartphone e dei lettori multimediali. Nel resto non vale una buccia di pera, basta vedere i dati di mercato. Può far diventare "magic" quel che vuole ma nel mercato professionale nessuno gli darà corda. Può solo sperare nel mercato consumer/semiprofessionale ma la vedo grigia pure lì con una mossa del genere.

Il fatto è che non può svegliarsi la mattina e dire da oggi ARM e sparare fuori tutta una nuova linea con CPU ARM. Per avere ìl software ci vorrà tempo. I big sicuramente lo faranno ma i piccoli sviluppatori potrebbero anche decidere di mandare a quel paese la mela e non aggiornare i propri sw. A parte questo, appena lanciata la nuova linea non si avrà niente da installarci sopra. O quasi nulla insomma, a parte le 4 applicazioncine Apple. Il ragionamento della gente sarà:

- Sanno della cosa e dicono "aspetto cosa fanno gli altri"
- Non lo sanno, comprano il PC, lo prendono nel :ciapet: e potrebbero decidere di abbandonare Apple al prossimo giro.

Questo nel mercato consumer. Nel mercato professionale dove già conta poco potrebbe perdere tutta una nuova linea di clienti.

E questo lato software. Lato HW ci sono molte sfide da vincere. Devono produrre una CPU ARM abbastanza potente da reggere OSX almeno alla stessa velocità con cui gira oggi su Core. La sfida è difficile, perchè servono risorse e conoscenze. Apple, che vuole disegnarsi la CPU in casa come quella di iPhone, non sarebbe in grado. Dovrebbe appoggiarsi a qualcuno:

- TI
- nVidia
- Qualcomm?

Al momento non sono competitivi contro Intel e penso non abbiano neanche interessi per investire nel ridicolo market share di OSX. Si parla di investimenti importanti e grossi rischi.

Apple deve aspettare i tempi degli altri e del mercato, questa volta non potrà fare lei il mercato, perchè non può permetterselo. E penso saranno Microsoft e Google/Linux a tirare questa volta.

ARM sta avendo un grosso impulso tirato dal mobile e nei giorni futuri ne vedremo delle belle ma: tempo al tempo! Intel con ARM perderà quote di mercato, ma non oggi e non con Apple.

Anche se qualcosa si sta muovendo, è di oggi la notizia dell'acquisizione di MIPS Tec da parte di Imagination Tec, quella che produce i SOC per Apple. Che Apple scelga MIPS? Se non altro il MIPS si sta preparando per un ritorno in grande stile, visti i risultati prestazionali che ha ;)

Eh, ora parli di cose che non so :D

Architettura x86, Cell, ARM, CISC, RISC, MIPS... In questo campo mi limito a vedere i risultati finali (prestazioni, consumi, calore generato) :D


In ogni caso non vedo il cambiamento cosi' drammatico come dici tu. Contando che i nuovi pc Apple usciranno l'anno prossimo, in un anno di Windows 8 su ARM secondo me ne vedremo delle belle... E magari noi stiamo qui a dire di Apple, e tra 1 anno i pc saranno gia' ARM e non piu' x86 :D

Non a caso ho scritto "se AMD decidesse di applicare tutto il know how che ha in termini di capacità di sviluppare roba ad alte prestazioni e tirata al limite dell'inviluppo di potenza ...".
AMD non ARM ltd. ;) per sviluppare implementazioni non ARM della isa ARM mi risulta occorra una licenza architetturale
licenza che intel possedeva (ereditò da Digital e usò per sviluppare le cpu XScale - e poi vendette a Marvell se non erro - e probabilmente si sarà mangiata le mani...) ma che AMD non mi risulta possieda...
AMD ha il know-how necessario e le risorse per tirar fuori degli ARM ad alte prestazioni, non ARM ltd (che continua ad avere il suo core business come fornitore di IP, non come produttore/venditore di hardware)....quindi questo è un discorso destinato a restare nell' ipotetico
Poi è vero che la parte decoder sulle cpu per desktop/server è "minima" rispetto al resto, ma non è così ininfluente come potrebbe sembrare a prima vista.il decoder non è ininfluente, ma nemmeno così sostanziale...

a giudicare dal floorpan del K10 (http://www.chip-architect.com/news/K8L_floorplan_720.jpg) (in cui peraltro il - anzi i - decoder sono superscalari, quindi replicati a gruppi di 3, nonchè ulteriormente duplicati - per la decodifica nel caso normale e per quello in cui in cache non vi siano informazioni di tagging) molto più spazio del decoder prendono alu, strutture di esecuzione dinamica e riordino, eccetera
Pensa ad esempio al flop clamoroso di IA64 dovuto in primo luogo al suo set d'istruzioni ed a quello che implicava a cascata riguardo banda di I/O, decoder ed unità di esecuzione.quello può essere stato un fattore, ma molto di più ha influito il fatto che intel abbia cercato di sostituire x86 con qualcosa di radicalmente diverso in un momento in cui il mondo informatico era ancora meno maturo di adesso per l'abbandono di X86,
motivo per cui venne messa una pezza integrando in Merced un vero e proprio subcore P6 (un pentium 2) dedicato alla retrocompatibilità
ma un sistema del genere aveva poco senso in partenza, se non come soluzione temporanea - infatti l' intenzione era di avere Itanium su tutti i nuovi sistemi da lì a qualche anno ...
solo, non si erano fatti i conti con le difficoltà inerenti al dover gestire esplicitamente da parte del programmatore il parallelismo delle istruzioni e l' allocazione dei registri, che se da un lato è necessaria per impiegare efficacemente l' architettura, è qualcosa non proprio alla portata di tutti o di tutte le occasioni d' impiego (anche per motivi di tempi), oltre che si è visto non essere la scelta ottimale con codice general purpose (dove l' hw di esecuzione speculativa può ottenere risultati molto migliori)
ma quando si cominciava a sfruttarla efficamente almeno per i calcoli scientifici, le cpu x86 avevano colmato il divario prestazionale e stavano a loro volta passando in vantaggio ...
Al massimo i primi ARM sono stati usati su home computer (e come potenza di calcolo erano più potenti dei corrispettivi x86 del periodo, usando pure meno gate sul chip) ma poi praticamente più niente in tal senso, al massimo PDA e smartphone, solo ora con tablet e smarphone sempre più potenti (e con la nuova architettura a 64bit) potrebbe iniziare l'attacco verso i desktop.sì ma vedi in questo caso subentrano due tipi di problemi ... il primo prestazionale:
le istruzioni simd della isa ARMv8 prevedono calcoli su registri a 128 bit (peraltro condivisi con le istruzioni FP scalari), ma un Core che un' ipotetica cpu di classe ARM a 64 bit dovrebbe eguagliare (anzi superare, altrimenti non ci sarebbe alcun incentivo alla migrazione) possiede unità capaci di calcoli su 256 bit per volta (doppio di GFlOPS)
inoltre, trattandosi di una ISA RISC con istruzioni a lunghezza fissa di 32 bit, da una parte questo può implicare un decoder più semplice (se non altro perchè non è necessario fare un matching parallelo su tutti i 16 byte provenienti da una cache line - che potrebbero ognuno essere il primo di una differente istruzione a lunghezza variabile - nè decodificare tutti i prefissi prima dell' opcode vero e proprio)
ma comunque non è detto, dovendo il decoder fare comunque i conti con una varietà di modalità operative, come thumb/thumb2/thumbeee con i suoi opcode a 16 bit, e di indirizzamento - a meno che queste non vengano escluse...
e d' altra parte ha delle ricadute sulla code density e sul "lavoro utile" espresso in termini di quelle istruzioni
una cpu x86 moderna (k8 / K10 / core) integra 3 alu e 3 load/store più dei sommatori dedicati allo stack pointer e in certi casi altri sommatori a valle del decoder per pregenerare nel front end l' indirizzo dell' operando - quindi può eseguire fino a 6 operazioni (7 contando l' aggiornamento dell' SP in sideband), anche memoria - memoria, per ogni 3-4 istruzioni x86 (+1 condizionale che per un Core può essere fusa con un eventuale confronto, ottenendo un salto condizionato)
ma un' ipotetica CPU ARM di prestazioni paragonabili, quindi come minimo dotata di altrettante unità di calcolo (con annessa complessità), per tenerle alimentate costantemente avrebbe bisogno quantomeno di altrettante (6) istruzioni in ingresso, ma allora anche di cache line senz' altro più ampie e maggiore banda (anche come decode bandwidth) ma a quel punto il transistor count probabilmente non sarebbe più quello esiguo delle implementazioni arm in order non superscalari...
oltre al richiedere in certi casi più istruzioni a parità di lavoro (una load, un' operazione registro registro e una store piuttosto che una operazione memoria - memoria) come conseguenza intrinseca del tipo di architettura

in secundis, non sottovalutare l' importanza della retro- ed auto- compatibilità
tablet, smartphone ed altre appliance, nonchè in certo qual modo i centri di calcolo (accomunati dall' essere piattaforme principalmente "autocontenute" che si esauriscono in sè stesse, non influenzate dal sw che c'è stato prima e quel che verrà dopo) sono una cosa,
per una piattaforma usata nel "mondo reale" in cui la possibilità di usare sw attuale od anche di dieci- venti anni prima (basta vedere il PC, che solo adesso si sta "davvero" lasciando alle spalle il DOS, per supportare il quale il bios è stato mantenuto in vita finora) è un selling point, è assai diverso...

Eh, ora parli di cose che non so :D

Architettura x86, Cell, ARM, CISC, RISC, MIPS... In questo campo mi limito a vedere i risultati finali (prestazioni, consumi, calore generato) :D


In ogni caso non vedo il cambiamento cosi' drammatico come dici tu. Contando che i nuovi pc Apple usciranno l'anno prossimo, in un anno di Windows 8 su ARM secondo me ne vedremo delle belle... E magari noi stiamo qui a dire di Apple, e tra 1 anno i pc saranno gia' ARM e non piu' x86 :D

Tutto il mercato in massa non credo :D Cmq sono curioso di vedere queste nuove soluzioni :) Quando i tempi saranno maturi un bel portatile ARM me lo faccio :D

Eh, ora parli di cose che non so :D

Architettura x86, Cell, ARM, CISC, RISC, MIPS... In questo campo mi limito a vedere i risultati finali (prestazioni, consumi, calore generato) :Dil problema è che se da appassionati ci si può soffermare sulle squisite caratteristiche tecniche delgi oggetti tecnologici in circolazione, in un' ottica generale fermarsi alla superficie non è sufficiente
In ogni caso non vedo il cambiamento cosi' drammatico come dici tu. Contando che i nuovi pc Apple usciranno l'anno prossimo, in un anno di Windows 8 su ARM secondo me ne vedremo delle belle... E magari noi stiamo qui a dire di Apple, e tra 1 anno i pc saranno gia' ARM e non piu' x86 :Dsbagli prospettiva ...
una regola aurea da tenere sempre presente è che "una piattaforma è utile tanto quanto il sw che permette di far girare"
quindi se per delle piattaforme sostanzialmente autosufficienti e più o meno chiuse, è ancora ancora plausibile imporre che sia il sw a seguire l' hw (ma è necessario un notevole incentivo, reale oltre che percepito dagli utenti, perchè ciò avvenga - altrimenti si ottiene l' effetto opposto), per un PC o un Mac è l' opposto ...
prima viene il sw di cui ha bisogno l' utente (che sia un' applicazione di sviluppo, di progettazione, o un gioco), quindi dato il sw si cerca ciò su cui può girare finchè serve
già che la seconda regola aurea è che "uno strumento si cambia solo quando se ne pone la reale necessità" (quando non è più in grado di funzionare o quando un nuovo strumento apporta vantaggi quantificabilmente maggiori - come una produttività 10 volte maggiore a fronte di TOC non certo 10 volte maggiore)
e d' altra parte la base installata inficia le scelte di supporto (se il mercato mainstream è dominato da una certa architettura di cpu, è logico per quale mi convenga sviluppare)
quindi nel caso di una piattaforma retrocompatibile si innesca un circolo virtuoso e un andamento a "pipeline" (supporto per il sw legacy da parte di cpu correnti, per le quali nel frattempo si sviluppa e si distribuisce codice nativo, che a sua volta le cpu future - a meno di non essere più parte della stessa piattaforma - supporteranno)

se pensi che è grazie a questo che la piattaforma PC è sopravvissuta (/cresciuta) finora, e che per dire, solo adesso (che tutte le implementazioni x86 correnti supportano i 64 bit) ci si è (quasi) affrancati dal DOS e dal codice a 16 bit e i 32 sono il minimo sindacale (anche in quegli ambiti, tipicamente industriali, in cui il sw è installato una volta e lasciato a lavorare per anni o decenni) e se tirendi conto di quanto sia "enorme" nel suo complesso quella parte dell' IT in cui si fa uso di PC X86,
rompere la pipeline non conviene a nessuno...

Apple può avere interesse a farlo (per dissociarsi dalla massa - d' altra parte ha sempre sostenuto che i propri personal non fossero dei PC nemmeno col passaggio a x86 ) ma potrebbe non averne la possibilità (anche se la sua è una piattaforma sostanzialmente chiusa - integrata verticalmente - c'è comunque abbastanza codice di terze parti in circolazione da rendere l' operazione tutt' altro che indolore...)

Ai tempi che furono l'ARM2 realizzato con un quarto dei transitor dell'80286 gli spaccava il cuBo a colpi di pura potenza di calcolo. :read:
Sarà anche un'architettura inefficiente e obesa (Atom ne è uno degli ultimi esempi)
Ocio che l' "architettura" non vuol dire niente, il 286 era una cpu cisc che elaborava un' operazione alla volta, non esisteva un decoder vero e proprio ma era la cpu stessa a costituirlo, non aveva pipeline e ci metteva da 2 a 10 ( o anche di più ) cicli di clock per elaborare un' istruzione, sempre che non dovesse accedere alla ram perchè allora i cicli wait di attesa fioccavano ...
Il primo arm fece scalpore perchè lanciò il concetto di cpu risc, grazie alla pipeline elaborava un' istruzione per ciclo di clock ( almeno in condizioni ideali ) suddividendola in passi stile catena di montaggio, quella è l' innovazione fondamentale, l' instruction set ridotto era solo una conseguenza.
L' attuale struttura delle cpu arm, Intel e AMD è una base risc a cui sono state apportati parecchi miglioramenti per tenere la pipeline sempre piena ( branch predictor, cache sempre più generose, esecuzioni out-of-order ... etc ), e intanto paradossalmente l' ISA dei risc è aumentato esponenzialmente per includervi operazioni sempre più complesse ( le varie SSE per ia-64 ma anche ARM ha aggiunto ThumbEE, Neon e altra roba ) cosicchè al giorno d' oggi le due architetture sono largamente sovrapponibili: una ISA di tipo CISC con un motore RISC agli steroidi.
Paradossalmente si potrebbe prendere una CPU qualsiasi, cambiargli il decoder e fargli elaborare una ISA diversa con relativamente pochi adattamenti.


Stai facendo troppa confusione tra architetture di cpu ed aziende. :read:

Non a caso ho scritto "se AMD decidesse di applicare tutto il know how che ha in termini di capacità di sviluppare roba ad alte prestazioni e tirata al limite dell'inviluppo di potenza ...".
AMD non ARM ltd. ;)

Ops :p
Cmq anche AMD è un nanetto confronto a Intel ;)
I problemi che ha attualmente derivano proprio da questo, ha troppi pochi soldi per competere ...


Poi è vero che la parte decoder sulle cpu per desktop/server è "minima" rispetto al resto, ma non è così ininfluente come potrebbe sembrare a prima vista.

Pensa ad esempio al flop clamoroso di IA64 dovuto in primo luogo al suo set d'istruzioni ed a quello che implicava a cascata riguardo banda di I/O, decoder ed unità di esecuzione.
Nonostante Intel ci si sia svenata dietro in tutti i modi ormai sopravvive solo grazie al contratto capestro di HP che impone ad Intel di continuare a supportare tale cpu.
Ed infatti dopo quella batosta Intel se ne è uscita con la sua attuale strategia "x86 ovunque".

Il problema fondamentale dell' Itanium è che non è compatibile x86 e quindi non gliene frega niente a nessuno :fagiano:
Il discorso decoder per i processori VLIW è molto complesso, un decoder CISC trasforma facilmente le istruzioni in un subset RISC cosicchè le due soluzioni siano equivalenti, un' istruzione complessa può facilmente essere spezzettata e il parallelismo resta gestito dal processore, i VLIW hanno un approccio diverso, il parallelismo esplicito influenza direttamente il compilatore e il modo in cui i programmi dovrebbero essere scritti, peccato che i linguaggi di programmazione più usati e gli algoritmi siano sequenziali, c' è un lavorone da fare per parallelizzare il tutto, e chi ci si mette a farlo ? :stordita:

Ocio che l' "architettura" non vuol dire niente, il 286 era una cpu cisc che elaborava un' operazione alla volta, non esisteva un decoder vero e proprio ma era la cpu stessa a costituirlo, non aveva pipeline e ci metteva da 2 a 10 ( o anche di più ) cicli di clock per elaborare un' istruzione, sempre che non dovesse accedere alla ram perchè allora i cicli wait di attesa fioccavano ...
Il primo arm fece scalpore perchè lanciò il concetto di cpu risc, grazie alla pipeline elaborava un' istruzione per ciclo di clock ( almeno in condizioni ideali ) suddividendola in passi stile catena di montaggio, quella è l' innovazione fondamentale, l' instruction set ridotto era solo una conseguenza.
L' attuale struttura delle cpu arm, Intel e AMD è una base risc a cui sono state apportati parecchi miglioramenti per tenere la pipeline sempre piena ( branch predictor, cache sempre più generose, esecuzioni out-of-order ... etc ), e intanto paradossalmente l' ISA dei risc è aumentato esponenzialmente per includervi operazioni sempre più complesse ( le varie SSE per ia-64 ma anche ARM ha aggiunto ThumbEE, Neon e altra roba ) cosicchè al giorno d' oggi le due architetture sono largamente sovrapponibili: una ISA di tipo CISC con un motore RISC agli steroidi.
Paradossalmente si potrebbe prendere una CPU qualsiasi, cambiargli il decoder e fargli elaborare una ISA diversa con relativamente pochi adattamenti.

Io ho sempre saputo che x86 è CISC e non RISC, mentre ARM è CISC. Però potrebbero aver sì aumentato l'ISA fino a diventare CISC. Però allora non si può più parlare di RISC, visto che esiste la definizione CISC apposta :D O sbaglio?

Se dovessimo fare un raffronto non sarebbe sempre più CISC un'architettura x86 attuale (grazie per la correzione, effettivamente non ci avevo pensato ;) ) che una ARM attuale, no? Altrimenti tutte le differenze andrebbero a farsi benedire e ARM sarebbe tanto diverso da x86 come AMD è diverso da Intel. Se cambiasse solo l'implementazione e 2 o 3 ISA andrebbero diversamente solo a seconda del tipo di implementazione e quindi non ci sarebbero fondamentalmente differenze per preferire un'arch dall'altra se non in base al modello della CPU.

PS. Non sono pienamente d'accordo sul fatto che l'HW si deve adeguare al SW. Attualmente mi sembra più ragionevole un compromesso che tiene sempre conto di prestazioni, difficoltà di realizzazione e costi. Se devo fare un SW che deve fare sempre operazioni di somma su array da 10000 valori (per assurdo), non creo un set di istruzioni apposito nella CPU, sarò io programmatore che userò (sempre per assurdo) diverse concatenazioni di array da 100 valori per mandarli in esecuzione 100 e 100.

Io ho sempre saputo che x86 è CISC e non RISC, mentre ARM è CISC. anche se leggendo la frase probabilmente è quello che intendevi dire ;)
la architettura ARM è RISC
Però potrebbero aver sì aumentato l'ISA fino a diventare CISC. aumentare l' isa aggiungendo istruzioni farebbe magari crescere le dimensioni della tabella degli opcode, e magari richiederebbe di ricorrere al microcodice non bastando pià la logica cablata per il decoder...
ma non farebbe diventare CISC una cpu nata RISC, perchè non verrebbero meno caratteristiche inerenti e distintive di un' architettura RISC:
istruzioni con opcode della stessa lunghezza (piuttosto che di lunghezza variabile)
istruzioni distinte per tipo, con load /store dedicate ai trasferimenti registri <-> memoria - e logiche operanti solo su registri (piuttosto che istruzioni con operandi indifferentemente registro o memoria)
operazioni su registri non distruttive (a=b+c, piuttosto che a=a+b),
registri general purpose in numero consistente (piuttosto che limitato)
Però allora non si può più parlare di RISC, visto che esiste la definizione CISC apposta :D O sbaglio?da una parte si può tenere presente che RISC e CISC sono definizioni nate a posteriori (dopo che a berkeley e stanford si pensò di progettare processori architetturalmente semplici e ortogonali basati sulla constatazione che l' 80% delle istruzioni eseguite ricadevano in un sottoinsieme semplice di quelle supportate dai sistemi esistenti)
dall' altra "CISC" o "RISC" è un' etichetta che si dà alla ISA visibile dal programmatore/compilatore e solo a quella - che l' implementazione adotti "tecniche risc" quali la segmentazione di istruzioni cisc in operazioni primitive che consentano di regolarizzare la pipeline, non rende un X86 RISC
( peraltro a ben vedere le moderne cpu x86 hanno invertito la tendenza... K6 e P6 in fase di decodifica producevano sequenze di microistruzioni "risc-like", immesse in pipeline e schedulate ognuna a parte, ma le macroops delle cpu Athlon e le "fused micro-op" dei Core e degli Atom - aggregati di operazioni elementari schedulati come entità unica e spezzati per l' invio alle unità esecutive all' ultimo - sono tutto meno che primitive, quindi RISC... )
quidni non sbagli ;)

anche se leggendo la frase probabilmente è quello che intendevi dire ;)
la architettura ARM è RISC


Esatto :) A scrivere CISC e RISC ogni 3 parole si mischiamo :p

aumentare l' isa aggiungendo istruzioni farebbe magari crescere le dimensioni della tabella degli opcode, e magari richiederebbe di ricorrere al microcodice non bastando pià la logica cablata per il decoder...
ma non farebbe diventare CISC una cpu nata RISC, perchè non verrebbero meno caratteristiche inerenti e distintive di un' architettura RISC:
istruzioni con opcode della stessa lunghezza (piuttosto che di lunghezza variabile)
istruzioni distinte per tipo, con load /store dedicate ai trasferimenti registri <-> memoria - e logiche operanti solo su registri (piuttosto che istruzioni con operandi indifferentemente registro o memoria)
operazioni su registri non distruttive (a=b+c, piuttosto che a=a+b),
registri general purpose in numero consistente (piuttosto che limitato)
da una parte si può tenere presente che RISC e CISC sono definizioni nate a posteriori (dopo che a berkeley e stanford si pensò di progettare processori architetturalmente semplici e ortogonali basati sulla constatazione che l' 80% delle istruzioni eseguite ricadevano in un sottoinsieme semplice di quelle supportate dai sistemi esistenti)
dall' altra "CISC" o "RISC" è un' etichetta che si dà alla ISA visibile dal programmatore/compilatore e solo a quella - che l' implementazione adotti "tecniche risc" quali la segmentazione di istruzioni cisc in operazioni primitive che consentano di regolarizzare la pipeline, non rende un X86 RISC
( peraltro a ben vedere le moderne cpu x86 hanno invertito la tendenza... K6 e P6 in fase di decodifica producevano sequenze di microistruzioni "risc-like", immesse in pipeline e schedulate ognuna a parte, ma le macroops delle cpu Athlon e le "fused micro-op" dei Core e degli Atom - aggregati di operazioni elementari schedulati come entità unica e spezzati per l' invio alle unità esecutive all' ultimo - sono tutto meno che primitive, quindi RISC... )
quidni non sbagli ;)

Be ma quindi alla fine non si può cmq dire che le due architetture convergano, che è anche il punto iniziale del discorso :D Alla fine quel che fa RISC efficiente rimane caratteristica RISC e per CISC stesso ma opposto discorso :) Cmq mi chiedo sempre perchè Intel abbia scelto CISC, a me sembra sempre meglio una RISC "espansa" tranne che per cose di nicchia :D In fondo, come si disse a Barkley (quella storiella me l'ero dimenticata :D ) la CISC fa tutto sto casino per il 20% di sitruzioni, dove magari c'è un'altro sotogruppo magari del 15% facilmente implementabile RISC per cui per fare una piccola parte delle operazioni si complica di brutto l'architettura, e si rallenta. Visto che si complicano pipeline, parallelismo, registri ecc...

PS. Ma le micro-op non sono precedenti agli Atom?

Il problema fondamentale dell' Itanium è che non è compatibile x86 e quindi non gliene frega niente a nessuno :fagiano:

La compatibilità x86 non era un problema, a parte questo i primi Itanium (pensati per competere con server non-x86) avevano per precauzione (non per vera necessità) l'equivalente di un decoder 486 integrato nel chip (nel senso che supportava le istruzioni 486, non che avesse le prestazioni di un 486) ma nei successivi fu tolto perchè l'emulazione via software dava maggiori prestazioni e perchè serviva principalmente per il boot da cd con bootloader x86 di dischi di installazione con versioni "doppie" del S.O. (per x86 e per Itanium)

Il vero problema erano le prestazioni.

L'idea era che gli Itanium prima avessero preso la fascia alta (occupata in quel periodo dai RISC) e poi sarebbero diventati i successori degli x86 man mano che i 32bit sarebbero diventati strettini (anche per quel motivo Intel non aveva fretta di uscire con una sua versione a 64bit degli x86).
Microsoft si era già impegnata a portare Windows su Itanium e se non sbaglio stava già lavorando dietro le quinte su .Net

Itanium doveva spazzar via i RISC nei server di fascia medio-alta di quel periodo (i POWER, i MIPS64 di SGI, i Prism di HP, gli Alpha ex-DEC di COmpaq, gli Sparc, ecc.).
Spazzar via i Prism non era un problema a prescindere perchè Itanium fu inizialmente sviluppato a braccetto con HP proprio come successore dei Prism.
Compaq stava per essere acquisita da HP ed una delle precondizioni era che la morte programamta degli Alpha avvenisse pianificata prima dell'acquisizione in modo da non innervosire l'antitrust.
Vista l'aria che tirava (Intel che diceva a tutti che avrebbe investito tantissimo su Itanium per farlo diventare l'architettura standard a 64bit per i server per poi più avanti sostituire magari pure gli x86) SGI annunciò a sua volta che sarebbe passata ad Itanium.
Pure IBM annuncio che avrebbe realizzato dei server basati su Itanium (ma avrebbe amntenuto anche la sua linea POWER).

Insomma, Intel sembrava che avesse già vinto su tutta la linea (eccetto per Sun con i suoi Sparc ed UltraSparc) e dovesse uscire sul mercato con la suo nuova cpu.

Solo che quando iniziarono ad essere disponibili i primi benchmark dell'Itanium scoppiò a dir poco un merdone: la prima generazione non saliva di clock come la concorrenza, aveva buone prestazioni floating point ma faceva pena per quel che riguarda gli interi, richiedeva chip enormi e scaldava a bestia (anche rispetto a chip che era normale fossero belli "caldi").

Le cpu Alpha (già con data morte programmata e che erano almeno tre anni che al massimo veniva shrinkate) erano più veloci nelle applicazioni reali e pure gli x86-64 di AMD (perchè Intel non aveva ancora x86 a 64bit) a parità di costo fornivano prestazioni interessanti.

Fu un disastro, ed anche le versioni successive degli Itanium non sono riuscite a salire di clock come la concorrenza (es: i POWER vanno tranquillamente a più di 5GHz di clock) ... inclusa la concorrenza "interna" costituita dagli x86 di Intel stessa.

Per rendere l'idea, la cpu Itanium più recente (Tukwila) raggiunge al massimo 1.73GHz. :sofico:

Secondo me quello che dici è giusto ma non considera una cosa fondamentale: la ricchezza di Intel. Intel è un'azienda che ha dalla sua fondi, fabbriche e know-how necessari per sviluppare al massimo x86. Sarà anche un'architettura inefficiente e obesa (Atom ne è uno degli ultimi esempi) ma riesce a garantire un buon livello di potenza, e con quei tre elementi di poco fa Intel ci metterebbe poco a farla spingere al massimo. A suon di riduzioni di PP la fanno sembrare sempre più efficiente, e di fatto quello che conta è il consumo effettivo.

ARM può sperare con AMD ma non sarebbe in grado di competere per un ingresso di punta nel mercato, non ha le risorse necessarie. In più dovrebbero appoggiarsi a TMSC (che ultimamente non brilla) e Globalfoundries, ma le rese produttive potrebbero non essere sufficienti.

Ad Intel la ricchezza ed il know-how potrebbero non bastare, con gli ARM non ha un unico concorrente, ma tanti, con obiettivi e priorità diverse e non può contrastarli tutti simultaneamente.
AMD è solo il soggetto con maggiori possibilità (per mezzi e know-how) di uscire con un ARM "da server ad alte prestazioni", ma non è l'unico.

Anche senza cercare lo scontro diretto con Intel, le prestazioni dei core ARM stanno aumentando anche solo per il semplice passaggio alla tecnologia produttiva successiva.
Ad un certo punto gli ARM saranno abbastanza potenti e costeranno in rapporto molto meno ed a quel punto ...

per sviluppare implementazioni non ARM della isa ARM mi risulta occorra una licenza architetturale
licenza che intel possedeva (ereditò da Digital e usò per sviluppare le cpu XScale - e poi vendette a Marvell se non erro - e probabilmente si sarà mangiata le mani...) ma che AMD non mi risulta possieda...

Se non sbaglio AMD negli ultimi mesi ha acquisito la licenza per gli ARM.


le istruzioni simd della isa ARMv8 prevedono calcoli su registri a 128 bit (peraltro condivisi con le istruzioni FP scalari), ma un Core che un' ipotetica cpu di classe ARM a 64 bit dovrebbe eguagliare (anzi superare, altrimenti non ci sarebbe alcun incentivo alla migrazione) possiede unità capaci di calcoli su 256 bit per volta (doppio di GFlOPS)
inoltre, trattandosi di una ISA RISC con istruzioni a lunghezza fissa di 32 bit, da una parte questo può implicare un decoder più semplice (se non altro perchè non è necessario fare un matching parallelo su tutti i 16 byte provenienti da una cache line - che potrebbero ognuno essere il primo di una differente istruzione a lunghezza variabile - nè decodificare tutti i prefissi prima dell' opcode vero e proprio)
ma comunque non è detto, dovendo il decoder fare comunque i conti con una varietà di modalità operative, come thumb/thumb2/thumbeee con i suoi opcode a 16 bit, e di indirizzamento - a meno che queste non vengano escluse...

Quello di ARM Ltd mica sono nati ieri ed hanno considerato bene le alternative quando hanno fatto certe scelte.

Se si implementa l'esecuzione out-of-order si possono aggiungere più unita SIMD 128 ed avere le stesse prestazioni di una cpu con la metà delle unita SIMD 256, mentre dall'altro lato con 128bit per registro invece che 256bit diventa più semplice realizzare una versione "risparmiosa" con buone prestazioni.

Poi un decoder capace di interpretare sia istruzioni "ARM 32bit" che thumb è estremamente semplice rispetto ad uno solamente "ARM 32bit", perchè le istruzioni thumb si mappano "a schema fisso" in modo estremamente semplice sulle istruzioni ARM equivalenti quindi in una cpu che supporta entrambi, il "decoder thumb" è solo uno stadio aggiuntivo al decoder "ARM 32bit" e tale stadio aggiuntivo non è a rischio di stalli ed automagicamente circa raddoppia le istruzioni inviabili in esecuzione senza praticamente andare a toccare tutto quello che c'è a valle.

Se non sbaglio AMD negli ultimi mesi ha acquisito la licenza per gli ARM.



Quello di ARM Ltd mica sono nati ieri ed hanno considerato bene le alternative quando hanno fatto certe scelte.

Se si implementa l'esecuzione out-of-order si possono aggiungere più unita SIMD 128 ed avere le stesse prestazioni di una cpu con la metà delle unita SIMD 256, mentre dall'altro lato con 128bit per registro invece che 256bit diventa più semplice realizzare una versione "risparmiosa" con buone prestazioni.

Poi un decoder capace di interpretare sia istruzioni "ARM 32bit" che thumb è estremamente semplice rispetto ad uno solamente "ARM 32bit", perchè le istruzioni thumb si mappano "a schema fisso" in modo estremamente semplice sulle istruzioni ARM equivalenti quindi in una cpu che supporta entrambi, il "decoder thumb" è solo uno stadio aggiuntivo al decoder "ARM 32bit" e tale stadio aggiuntivo non è a rischio di stalli ed automagicamente circa raddoppia le istruzioni inviabili in esecuzione senza praticamente andare a toccare tutto quello che c'è a valle.

Eh fino a questo punto direi che è difficile fare previsioni :) Vedremo nei prossimi mesi :)

Sembra uscito apposta :D http://www.tomshw.it/cont/news/il-boss-di-arm-e-presto-per-suonare-il-requiem-di-intel/40902/1.html

Se non sbaglio AMD negli ultimi mesi ha acquisito la licenza per gli ARM.spulciando in giro non trovo nulla che parli esplicitamente dell' acquisto di una licenza architetturale
solo che AMD introdurrà opteron basati su ARM (ma probabilmente basati sui core sintetizzabili di quest' ultima, non su design propri)
Quello di ARM Ltd mica sono nati ieri ed hanno considerato bene le alternative quando hanno fatto certe scelte.ma nemmeno quelli di intel sono nati ieri - e lo dico storcendo il naso di fronte ad una ISA tutto fuorchè elegante (anche di CISC ci sono esempi di gran lunga migliori, a partire da z8k e 68k) ma (purtroppo) oggi disponibile in forma molto potente

il fatto è che che gli uni e gli altri si sono dati differenti priorità - in un caso retrocompatibilità ad ogni costo (compresa a livello di assembly simbolico tra l' 8080/z80 e l' 8086 - quest' ultimo progettato così come fu anche perchè fosse possibile tradurre 1 a 1 il sw usato sui micro con cp/m, con un tool automatico) inizialmente e prestazioni (anche a discapito dei consumi) più di recente, nell' altro caso semplicità architetturale a discapito delle prestazioni pure
non che quest' ultimo implichi alcunchè rispetto al livello di capacità - anche se è innegabile che le risorse di intel e quelle di arm siano su due livelli diversi, a quel punto un design semplice è favorevole in ottica di manutenibilità (infatti da parte di ARM si sente parlare di errata molto meno che da altri produttori...) - è semplicemente un approccio diverso al compromesso tecnico
Se si implementa l'esecuzione out-of-order si possono aggiungere più unita SIMD 128 ed avere le stesse prestazioni di una cpu con la metà delle unita SIMD 256, mentre dall'altro lato con 128bit per registro invece che 256bit diventa più semplice realizzare una versione "risparmiosa" con buone prestazioni.un sommatore da 256 bit e due sommatori da 128, richiedono grossomodo lo stesso numero di transistor - però limitatamente alla/e ALU, il problema è che oltre alla doppia ALU nel secondo caso si ha anche il doppio delle porte in uscita dallo scheduler (code), il doppio delle strutture dati per il register renaming, la complessità delle rete di bypass cresce se non ricordo male esponenzialmente
e ho in ogni caso bisogno, a monte, di due istruzioni decodificate da inviare alle ALU, quindi due decoder distinti e il doppio della banda...
Poi un decoder capace di interpretare sia istruzioni "ARM 32bit" che thumb è estremamente semplice rispetto ad uno solamente "ARM 32bit", perchè le istruzioni thumb si mappano "a schema fisso" in modo estremamente semplice sulle istruzioni ARM equivalenti quindi in una cpu che supporta entrambi, il "decoder thumb" è solo uno stadio aggiuntivo al decoder "ARM 32bit" e tale stadio aggiuntivo non è a rischio di stalli che sia semplice non lo metto in dubbio,
quello di cui sopra però era un discorso di decoder- e pipeline - "lanes" (quindi di decoder paralleli presenti e impegnati da una parte, e di istruzioni dall' altra) necessarie per svolgere lo stesso lavoro
automagicamente circa raddoppia le istruzioni inviabili in esecuzione senza praticamente andare a toccare tutto quello che c'è a valle.come?
tipicamente un decoder è UN decoder - se è fatto in un certo modo per decodificare e passare allo stadio successivo una istruzione alla volta perchè una istruzione alla volta è quanto lo stadio successivo è in grado di accettare (che è la situazione tipica per una pipeline improntata alla semplicità e regolarità strutturale, come appunto un risc inorder) ne decodificherà sempre al più una per ciclo, che sia a 16 o 32 bit - a meno che non hai informazioni specifiche su ARM/thumb che mostrino che a 16 bit le istruzioni decodificate raddoppiano...

tipicamente un decoder è UN decoder - se è fatto in un certo modo per decodificare e passare allo stadio successivo una istruzione alla volta perchè una istruzione alla volta è quanto lo stadio successivo è in grado di accettare (che è la situazione tipica per una pipeline improntata alla semplicità e regolarità strutturale, come appunto un risc inorder) ne decodificherà sempre al più una per ciclo, che sia a 16 o 32 bit - a meno che non hai informazioni specifiche su ARM/thumb che mostrino che a 16 bit le istruzioni decodificate raddoppiano...

Ho parlato di raddoppio delle istruzioni inviabili in esecuzione, non in raddoppio tout court delle istruzioni eseguite (dipende se basta la compressione del codice o se si hanno gate da spendere in ulteriori migliorie).

Ma anche senza modifiche a valle, si ottengono comunque parecchi benefici.
In modalità thumb la cache istruzioni L1 contiene fino ad un massimo del doppio delle istruzioni e si riducono gli stalli dovuti all'accesso ai livelli successivi di cache (meno accessi da parte della cache istruzioni L1 che vanno ad interferire con quelli della cache dati L1).