Link alla notizia: http://www.hwupgrade.it/news/apple/apple-al-lavoro-su-imac-e-macbook-basati-su-architettura-arm_52466.html

Apple avrebbe completato lo sviluppo di Mac e MacBook basati su processori con architettura ARM. Secondo nuovi report, i primi prototipi sarebbero già pronti e funzionanti, in attesa del debutto ufficiale

Click sul link per visualizzare la notizia.

La morte definitiva di quella che fu la migliore macchina professionale tra gli anni 80-90.....

La morte definitiva di quella che fu la migliore macchina professionale tra gli anni 80-90.....

I processori degli anni 80-90 non sono certo quelli di oggi.
Oggi la guerra ai megahertz non esiste più, vince chi offre processori che non scaldano come forni e che consumano pochissimo e guarda caso arm si presta benissimo allo scopo....

A7, il chip alla base degli iPhone e iPad rilasciati nel 2013, è stato definito come in grado di consegnare ai dispositivi mobile performance tipiche dei sistemi desktop, ed è proprio questo aspetto che corrobora il nuovo rumor proveniente dalla Francia: "Il chip A7 è attualmente sottosfruttato su iPhone e iPad, lasciando parte della sua potenza inutilizzata", scrive la fonte.

Non so tu ma a me non dispiacerebbe affatto futuro un MacBookAir senza ventole...;)

http://cdn.memegenerator.net/instances/46720000.jpg

I processori degli anni 80-90 non sono certo quelli di oggi.
Oggi la guerra ai megahertz non esiste più, vince chi offre processori che non scaldano come forni e che consumano pochissimo e guarda caso arm si presta benissimo allo scopo....



Non so tu ma a me non dispiacerebbe affatto futuro un MacBookAir senza ventole...;)

basta mettere un ULV serie Y e ti asfalta qualsiasi Arm e senza ventole.

come ho detto più volte sono convintissimo che ci arriveremo, anche se rimarrà una certa distinzione tra OS X e iOS
credo che sia un po' presto, escluderei un Mac ARM nel 2014 e anche nel 2015 ma prima o poi arriverà di certo

comunque prima dell'uscita del 5S molti (me compreso) pensavano che fosse ancora presto per una cpu a 64bit e siamo stati smentiti, quindi può anche darsi che ci arrivino prima del previsto...

se così fosse ad apple non sanno cosa è successo a win rt :asd:

I processori degli anni 80-90 non sono certo quelli di oggi.
Oggi la guerra ai megahertz non esiste più, vince chi offre processori che non scaldano come forni e che consumano pochissimo e guarda caso arm si presta benissimo allo scopo....

"Vince" a fare cosa?
A fare browsing machines, sì vince chi fa macchine che consumano e scaldano poco.
(Ma a quel punto ti voglio vedere a piazzare una browsing machine a partire da 1800€, il target dei bimbiminchia con le tasche profonde che usano Killing machine per andare su facebook e vedere i pdf della scuola si esaurisce presto...)

Ma lui sta parlando dell'aspetto macchina professionale.

Ti ci voglio vedere a girare Premiere o fare operazioni batch con Lightroom, ancora peggio fare calcoli scientifici/finanziari/generali utilizzando un'architettura ARM, ovvero con una RISC, ovvero un'architettura che non applica operazioni di elaborazione sui registi e non ha implementate via hardware operazioni complesse.

Ci sono differenze di base insormontabili fra ARM e x86, sarebbe alquanto infantile credere che "ARM è il futuro perché consuma poco e fa le stesse cose e la potenza cruda salirà" perché il fatto che consumi poco è intrinsicamente legato al fatto che non fa le stesse cose.

basta mettere un ULV serie Y e ti asfalta qualsiasi Arm e senza ventole.

Già ma Apple nei sistemi desktop non metterà di certo UN arm.
E' scritto chiaramente nell'articolo: configurazioni multi CPU.

"Vince" a fare cosa?
A fare browsing machines, sì vince chi fa macchine che consumano e scaldano poco.
(Ma a quel punto ti voglio vedere a piazzare una browsing machine a partire da 1800€.)

Ma lui sta parlando dell'aspetto macchina professionale.

Ti ci voglio vedere a girare Premiere o fare operazioni batch con Lightroom, ancora peggio fare calcoli scientifici/finanziari/generali utilizzando un'architettura ARM, ovvero con una RISC, ovvero un'architettura che non applica operazioni di elaborazione sui registi e non ha implementate via hardware operazioni complesse.

Ci sono differenze di base insormontabili fra ARM e x86, sarebbe alquanto infantile credere che "ARM è il futuro perché consuma poco e fa le stesse cose e la potenza cruda salirà" perché il fatto che consumi poco è intrinsicamente legato al fatto che non fa le stesse cose.

E' ovvio che nell'articolo parlano di implementazione in sistemi desktop.
Quindi si presume che debbano svolgere le stesse operazioni dei Desktop attuali.
Come questo sarà fatto e implementato da parte di Apple lo vedremo poi.

se così fosse ad apple non sanno cosa è successo a win rt :asd:

Windows RT ha avuto una genesi completamente diversa ed è stato, fino ad ora supportato malissimo da MS!! OS X, dalle sue radici, è sempre stato multipiattaforma e il passaggio da PPC ad Intel nel periodo 2005/2006 ne è testimone. Gli utenti e gli sviluppatori sono stati supportati fino all'avvento di OS X 10.6 Snow Leopard con strumenti come Rosetta che permetteva l'esecuzione di codice PPC su processori Intel.

Precisato questo credo che ARM verrà relegato inizialmente a modelli " low cost " dell'attuale produzione Macintosh, ma ci vorrà del tempo perché vengano messi a punto tutti gli strumenti di supporto per gli sviluppatori e gli utenti e che sia convertita per ARM una discreta parte di applicazioni. Quindi anche io penso che i primi modelli Macintosh ARM verranno presentati nel corso del 2015/16.

E' ovvio che nell'articolo parlano di implementazione in sistemi desktop.
Quindi si presume che debbano svolgere le stesse operazioni dei Desktop attuali.

Te l'ho spiegato: non possono.
A meno che ARM non vuole, come è passata sui 64bit e le operazioni a doppia precisione, passare a tirare fuori processori CISC.

A quel punto non è questione di consumi, ARM come la conosciamo sarebbe solo una marca che fabbrica SIA RISC che CISC che sarebbero due prodotti completamente diversi (così come Intel lo fa, ma i suoi RISC sono poco conosciuti e riservati ad applicazioni industriali o spin-off) e non compatibili.

Anzi a quel punto con tutta probabilità ARM CISC sarebbe compatibile (o addirittura userebbe direttamente) con Intel x86 e non con ARM RISC.
Ovvero a quel punto ARM sarebbe come AMD e ovviamente non ci sarebbe alcun problema.

I PowerPC sono RISC, e hanno fallito nel desktop computing appunto perché dovevano andare a potenze esagerate per poter competere con gli Intel/AMD CISC nei compiti, per forza di cose generici, tipici di un Desktop riservato alla produzione di contenuti.

Ora coi PowerPC fanno cluster di calcolo. Perché? Perché sono molto efficienti a gestire le operazioni semplici importanti per il calcolo scientifico (che alla fine è spesso solo un'elaborazione vettoriale di numeri con le 4 operazioni fondamentali) e scalano facilmente. NON perché hanno potenzialità intrinseche di diventare macchine di produzione Desktop, dato che ad elaborare un video con un codec h264 ci vorrebbe un intero cluster di calcolo che emuli le istruzinoni CISC di una comune workstation con hardware x86.

Già ma Apple nei sistemi desktop non metterà di certo UN arm.
E' scritto chiaramente nell'articolo: configurazioni multi CPU.

si ma tu hai scritto MacBook Air...

prima il mac pro poco pro, ora vogliono passare il resto su arm. Prossimo step dedicarsi alle console :D
Apple, ma che mi combini? Addirittura 4 cpu quadcore e probabilmente le piglierebbe cmq dalle cpu intel.

Ci credo poco a questi rumor, hanno una salda partnership con Intel che ha dimostrato di poter battere arm nel loro campo con Bay trail.
Poi non capisco sta mania dei portatili senza ventola, che fastidio provoca una ventolina?

Anche se ARM potrebbe essere meno efficiente di X86 per far calcoli scientifici (sicuri?)
è pensato apposta per lavorare insieme a coprocessori... ecco che il problema è risolto!
Stessa cosa per la codifica/decodifica video, la gestione degli I/O, l'accelerazione video (sarebbe la GPU), Java*, ecc...

Fare una cosa come Rosetta che converte istruzioni X86 in ARM? E' Banale ormai usando LLVM (OSX è compilato tutto usando Clang, quindi...)...

L'importante è che non cadano nell'orrore di Microsoft un Desktop deve restare tale non diventare un Tablet!

* Alcuni processori ARM integrano un JVM chiamata Jazelle che permette di eseguire Java come fosse codice nativo.

I processori degli anni 80-90 non sono certo quelli di oggi.
Oggi la guerra ai megahertz non esiste più, vince chi offre processori che non scaldano come forni e che consumano pochissimo e guarda caso arm si presta benissimo allo scopo....


Mah
Su un PC il consumo ha importanza relativa, hanno abbandonato ARM perchè ormai non ce la facevano a tenere il ritmo di Intel e adesso vogliono tornarci perchè hanno un processore competitivo, competitivo sì ma per quanto ?
Fare una CPU potente è relativamente facile, il difficile è restare sempre sulla cresta dell' onda, l' A7 è un chip tosto, ma non è mica eterno e quanto ci metterà Apple a sostituirlo ?
Ritorneranno a fare una cpu ogni 4 anni come prima e si ritroveranno nuovamente ad annaspare ?

Windows RT ha avuto una genesi completamente diversa ed è stato, fino ad ora supportato malissimo da MS!!

a dire il vero il supporto di MS è identico a quello di Windows "normale" (stessi update/patch ecc..), al massimo ci sono poche app sullo store :D

Te l'ho spiegato: non possono.
A meno che ARM non vuole, come è passata sui 64bit e le operazioni a doppia precisione, passare a tirare fuori processori CISC.

A quel punto non è questione di consumi, ARM come la conosciamo sarebbe solo una marca che fabbrica SIA RISC che CISC che sarebbero due prodotti completamente diversi (così come Intel lo fa, ma i suoi RISC sono poco conosciuti e riservati ad applicazioni industriali o spin-off) e non compatibili.

Anzi a quel punto con tutta probabilità ARM CISC sarebbe compatibile (o addirittura userebbe direttamente) con Intel x86 e non con ARM RISC.
Ovvero a quel punto ARM sarebbe come AMD e ovviamente non ci sarebbe alcun problema.

I PowerPC sono RISC, e hanno fallito nel desktop computing appunto perché dovevano andare a potenze esagerate per poter competere con gli Intel/AMD CISC nei compiti, per forza di cose generici, tipici di un Desktop riservato alla produzione di contenuti.

Ora coi PowerPC fanno cluster di calcolo. Perché? Perché sono molto efficienti a gestire le operazioni semplici importanti per il calcolo scientifico (che alla fine è spesso solo un'elaborazione vettoriale di numeri con le 4 operazioni fondamentali) e scalano facilmente. NON perché hanno potenzialità intrinseche di diventare macchine di produzione Desktop, dato che ad elaborare un video con un codec h264 ci vorrebbe un intero cluster di calcolo che emuli le istruzinoni CISC di una comune workstation con hardware x86.

Più che altro, sebbene sia anche vero quanto hai scritto, PPC fallì perché Motorola non fu mai capace di raffinare i processi produttivi delle CPU. Gli ultimi PPC montati su desktop, i G5, erano dei forni mostruosi... Il punto di svolta si sarebbe dovuto raggiungere con la generazione successiva ( G6 - riciclata successivamente nel Cell Processor ), ma Motorola vendette le sue fonderie e tutto il reparto CPU, lasciando IBM e soprattutto Apple a terra...

Anche se ARM potrebbe essere meno efficiente di X86 per far calcoli scientifici (sicuri?) .

Come ho scritto sopra in realtà è spesso più efficiente, dipende dai calcoli: se non agiscono troppo sulla memoria e non fanno operazioni strane (potenze frazionarie) è persino più efficiente, altrimenti no.

è pensato apposta per lavorare insieme a coprocessori... ecco che il problema è risolto!

Appunto ecco che ricostruisci una CPU tipo "CISC" con un core centrale a basso consumo RISC e una serie di ancillari che eseguono le istruzioni più complesse, ESATTAMENTE come sono gli Intel x86.

Va bene neh, nulla di male, ma a quel punto come ho detto toglietevi dalla testa ARM = quellochec'ènell'iPhone, perché un tale processore con relativi coprocessori sarebbe del tutto equivalente (sia come potenza, ma anche come struttura) ai desktop, e quindi ARM = una marca che fa SIA i processori dell'iPhone, SIA i processori "tipo AMD" (con istruzioni CISC x86 compatibili).

Magari ARM se la comprerebbe pure AMD a questo punto, e sarebbe un bene, e poi anche i Mac desktop potrebbero montare ARM senza problemi, intesi come dei processori x86 di marca ARM.

Non venitemi a dire "te l'avevo detto" :P

a dire il vero il supporto di MS è identico a quello di Windows "normale" (stessi update/patch ecc..), al massimo ci sono poche app sullo store :D

Per supporto intendo anche la disponibilità di applicazioni... Apple, al tempo dello switch da PPC a Intel risolse con Rosetta per l'utenza e con compilatori ottimizzati per gli sviluppatori.

Per supporto intendo anche la disponibilità di applicazioni... Apple, al tempo dello switch da PPC a Intel risolse con Rosetta per l'utenza e con compilatori ottimizzati per gli sviluppatori.

invece MS ha lasciato a piedi gli sviluppatori?

___

comunque tornato in topic penso che adesso sia un'idea un po' avventata un notebook """professionale""" con arm, però hanno dimostrato di saperci fare con i chip arm, vedi apple A7, quindi in un futuro chissà.. :)

Ci sono differenze di base insormontabili fra ARM e x86, sarebbe alquanto infantile credere che "ARM è il futuro perché consuma poco e fa le stesse cose e la potenza cruda salirà" perché il fatto che consumi poco è intrinsicamente legato al fatto che non fa le stesse cose.
Instruction set e architettura dei processori sono due cose diverse, e in questo discorso non contano una mazza
Fra ARM e x86 la differenza la fa quanto investe Intel e quanto investono gli altri, basta dire che Intel ha le sue fonderie a 22 nm progettate per i suoi chip e non deve rivolgersi a terzi adattandosi ai processi altrui ( a 28 nm oltretutto ) per capire quale vantaggio competitivo possono avere gli x86

Anche se ARM potrebbe essere meno efficiente di X86 per far calcoli scientifici (sicuri?)
Il problema l' ho spiegato qui sopra, l' architettura delle CPU è in realtà molto simile.


Fare una cosa come Rosetta che converte istruzioni X86 in ARM? E' Banale ormai usando LLVM (OSX è compilato tutto usando Clang, quindi...)...
.
E' banale ma terribilmente inefficente, Rosetta funzionava perchè gli x86 erano talmente più veloci dei vecchi PPC che si potevano sobbarcare la traduzione e restare comunque competitivi, ma passare su un processore più lento e fare una conversione è da suicidio

Windows RT ha avuto una genesi completamente diversa ed è stato, fino ad ora supportato malissimo da MS!! OS X, dalle sue radici, è sempre stato multipiattaforma e il passaggio da PPC ad Intel nel periodo 2005/2006 ne è testimone. Gli utenti e gli sviluppatori sono stati supportati fino all'avvento di OS X 10.6 Snow Leopard con strumenti come Rosetta che permetteva l'esecuzione di codice PPC su processori Intel.

Precisato questo credo che ARM verrà relegato inizialmente a modelli " low cost " dell'attuale produzione Macintosh, ma ci vorrà del tempo perché vengano messi a punto tutti gli strumenti di supporto per gli sviluppatori e gli utenti e che sia convertita per ARM una discreta parte di applicazioni. Quindi anche io penso che i primi modelli Macintosh ARM verranno presentati nel corso del 2015/16.
si ma il discorso che faccio io è diverso: a me osx a volte in multitasking si impunta ed ho un mini con i5 dual core e 4gb di ram, figuriamoci su un arm :mc:


se proprio faranno macchine ARM secondo me o ci mettono ios o una specie di iosx (tipo win rt) e faranno una brutta fine

Bhè non mi pare che RT sia una priorità per gli sviluppatori... Ma RT è un OS confinato, al momento, ai tablet Surface... Apple invece doveva garantire continuità al suo core business Macintosh: prodotti differenti per dinamiche di mercato differenti.

Anche se ARM potrebbe essere meno efficiente di X86 per far calcoli scientifici (sicuri?)
è pensato apposta per lavorare insieme a coprocessori... ecco che il problema è risolto!
Stessa cosa per la codifica/decodifica video, la gestione degli I/O, l'accelerazione video (sarebbe la GPU), Java*, ecc...


guarda caso uno dei talk della prossima settimana al WWDC riguarda OpenCL e lo scorso anno c'era un talk per portare le applicazioni di iOS su OS X, niente di che ma un primo passo

comunque per i Macbook Air penso che la cosa sarebbe fattibile, visto l'uso che si fa di quelle macchine

si ma il discorso che faccio io è diverso: a me osx a volte in multitasking si impunta ed ho un mini con i5 dual core e 4gb di ram, figuriamoci su un arm :mc:


se proprio faranno macchine ARM secondo me o ci mettono ios o una specie di iosx (tipo win rt) e faranno una brutta fine

Darwin è il kernel sia di OS X che di iOS... OS X è figlio del progetto " Rhapsody " che venne sviluppato nativamente sia per piattaforma PPC che Intel... Quindi è dal 1997/98 che Apple tiene i suoi piedi in due staffe differenti...
Più che altro, sempre che tutto ciò di cui stiamo discutendo non si riveli vaporware, bisognerà vedere che tipo di Cpu ARM Apple svilupperà e, quando verrano presentati i primi ARM Mac, con quale disponibilità di software nativo.
Il lato positivo è che, ripeto, Apple ha tutto il know how per una operazione di questa portata.

Darwin è il kernel sia di OS X che di iOS... OS X è figlio del progetto " Rhapsody " che venne sviluppato nativamente sia per piattaforma PPC che Intel... Quindi è dal 1997/98 che Apple tiene i suoi piedi in due staffe differenti...
Più che altro, sempre che tutto ciò di cui stiamo discutendo non si riveli vaporware, bisognerà vedere che tipo di Cpu ARM Apple svilupperà e, quando verrano presentati i primi ARM Mac, con quale disponibilità di software nativo.
Il lato positivo è che, ripeto, Apple ha tutto il know how per una operazione di questa portata.
forse non è chiaro il concetto che voglio esprimere: osx porta in dote (cit. hwu :asd:) tutta una serie di software come itunes, safari, iphoto. imovie ecc.ecc. che ripeto stentano su un i5 dual core e 4gb di ram. ora siccome dubito che una cpu arm anche se con millemila core sia meglio di una cpu desktop intel, o alla apple si mettono con la testa e col pensiero a rivoluzionare TUTTO quello che concerne osx oppure un air con cpu arm, secondo il mio punto di vista, scoppia solo al pensiero di far girare in multitasking itunes e safari (per non parlare di app third part tipo photoshop)


ed è quello che ha fatto MS con rt, ha impedito l'installazione di software x86 così da non mostrare tutti i limiti delle cpu arm in ambito "desktop"

comunque per i Macbook Air penso che la cosa sarebbe fattibile, visto l'uso che si fa di quelle macchine

Appunto...Nessuno ha detto che Apple passerà totalmente ad Arm, chi avrà bisogno di potenza non avrà che da scegliere tra MacPro e sistemi Desktop x86.
Io ripeto: a me piacerebbe mica poco avere un Air che resta acceso per 20 ore, non scalda un piffero ed è totalmente fanless.

forse non è chiaro il concetto che voglio esprimere: osx porta in dote (cit. hwu :asd:) tutta una serie di software come itunes, safari, iphoto. imovie ecc.ecc. che ripeto stentano su un i5 dual core e 4gb di ram. ora siccome dubito che una cpu arm anche se con millemila core sia meglio di una cpu desktop intel, o alla apple si mettono con la testa e col pensiero a rivoluzionare TUTTO quello che concerne osx oppure un air con cpu arm, secondo il mio punto di vista, scoppia solo al pensiero di far girare in multitasking itunes e safari (per non parlare di app third part tipo photoshop)


ed è quello che ha fatto MS con rt, ha impedito l'installazione di software x86 così da non mostrare tutti i limiti delle cpu arm in ambito "desktop"


??
Scusa ma che stai dicendo?
Io tutta quella roba che hai elencato la faccio girare sul mio vetusto Imac con un core 2 duo.
L'unica modifica che ho fatto rispetto a quando lo presi originale è stata quella di montarci un SSD e aumentare la ram.
Il resto è identico all'originale, e non stenta di certo.
Se stentano su un i5 con 4GB di RAM allora i problemi sono altri, non certo la potenza che per quei software basta e avanza.

Instruction set e architettura dei processori sono due cose diverse

Mica tanto.
L'istruction set definisce l'architettura e viceversa. Se vuoi applicare operazioni di shift sui registri devi implementare le piste...etc...

A mio parere ci sono un paio di valutazioni.
AMD ha presentato da poco SkyBridge o K12 che è una CPU ibrida X86-ARM.

Una CPU di questo tipo, se con TPD sufficientemente basso potrebbe essere una possibilità di transizione mantenedo le porte aperte a tutte le soluzioni.

A mio parere il salto netto da una architettura all'altra sarebbe un suicidio.
Teniamo conto che a suo tempo la Apple e MAC OS era al quanto in crisi e che il salto verso Intel era obbligato, per dare nuova linfa ai loro prodotti.

Oggi i MAC sono gli unici PC che risentono poco della contrazione del mercato degli stessi. E perdessero compatibilità con X86 e di conseguenza Windows sarebbero problemi... Credo che molti che utilizzano il MAC, abbiano una Partizione Boot Camp o una qualche software di vitualizzazione.
Che senza X86 sarebbero duri da far funzionare.

Parentesi CPU:
A partire dal Pentium la distinzione CISC RISC è da abbandonare in quanto tale CPU utilizzava caratteristiche di una o dell'altra.
Addirittura aveva due pipeline distine per operazioni complesse e operazioni semplici. Per cui oggi pensare alle CPU moderne in termini solo CISC è limitativo.

A partire dal Pentium la distinzione CISC RISC è da abbandonare in quanto tale CPU utilizzava caratteristiche di una o dell'altra.
Addirittura aveva due pipeline distine per operazioni complesse e operazioni semplici. Per cui oggi pensare alle CPU moderne in termini solo CISC è limitativo.

Ma non lo è il contrario.
x86 è sia CISC che RISC quindi pensare in termini "classici" di CISC è morto da un pezzo, ma ARM al contrario è solo RISC quindi la contrapposizione fra i due mondi esiste ancora ed è bella netta.

forse non è chiaro il concetto che voglio esprimere: osx porta in dote (cit. hwu :asd:) tutta una serie di software come itunes, safari, iphoto. imovie ecc.ecc. che ripeto stentano su un i5 dual core e 4gb di ram. ora siccome dubito che una cpu arm anche se con millemila core sia meglio di una cpu desktop intel, o alla apple si mettono con la testa e col pensiero a rivoluzionare TUTTO quello che concerne osx oppure un air con cpu arm, secondo il mio punto di vista, scoppia solo al pensiero di far girare in multitasking itunes e safari (per non parlare di app third part tipo photoshop)


ed è quello che ha fatto MS con rt, ha impedito l'installazione di software x86 così da non mostrare tutti i limiti delle cpu arm in ambito "desktop"

Ma cosa vai dicendo? Sul mio MBA (hw inferiore al mini) ho aperti adesso Mail, iTunes, iPhoto, Safari, Skype, App store, Parallel desktop, iMessage, dropbox e un paio di altre cose in background e nessun impuntamento. Prova a controllare il tuo HDD che è meglio.

Mica tanto.
L'istruction set definisce l'architettura e viceversa. Se vuoi applicare operazioni di shift sui registri devi implementare le piste...etc...
Una visione molto anni '80 ;)
Forse sui libri di scuola si trovano ancora questo tipo di architetture, ma al giorno d' oggi la realtà è parecchio cambiata.
L' architettura interna delle CPU odierne è scollegata dall' ISA che invece si interfaccia a uno strato di trascodifica, altrimenti non si potrebbero implementare pipeline, esecuzioni speculative, previsioni su salti e operazioni out-of-order.
In realtà le architetture interne ARM e x86 sono abbastanza simili ed entrambe molto diverse dalle vecchie RISC/CISC raggiungendo un' efficenza parecchio superiore.

Se ne parla da anni ormai dei fantomatici computer apple basati su ARM, nulla di nuovo insomma.
Oggi le nuove implementazioni di ARM sono molto piu' performanti di quelle dei primi IPAD, ma solo un imbecille puo' pensare che apple voglia prendere un macbook PRO o un imac utilizzato per lavorare con PS e ficcarci dentro ARM.
Potrebbero ad esempio tirare fuori una linea di prodotti dedicati a utenti che non hanno bisogno di potenza di calcolo, ma continuando ad aggiornare gli attuali prodotti basati su CPU X86.
Il primo esempio che mi viene in mente potrebbe essere un nuovo macbook air con processore ARM o un nuovo mac mini, ma ad occhio e croce non prima di due anni.

e tutto il lavoro sw fatto finora?....alle ortiche?....l'ambiente OS x è cresciuto moltissimo negli ultimi anni...molti più software disponibili etc...ora i cambia di nuovo?...cosi tanto per riazzerare tutto??

Solo io ci vedo una volontà di indipendenza di Apple dai fornitori, una ottimizzazione dei costi "ARM A7" rispetto la controparte Intel a prescindere da velocità teoriche e ventoline?

Ricordiamo che ora Apple è un'azienda con risorse ben differenti rispetto a quelle che aveva quando è passata a processori Intel.
Ora è perfettamente in grado di creare processori per conto suo (e l'ha dimostrato con l'A7, che ricordiamo è un dual core da 1,3 Ghz che compete con gli altri ARM quad core da oltre 2 GHz), e la licenza ARM le consente di creare processori davvero ottimizzati per le proprie macchine, mentre con Intel prende il pacchetto chiuso.
Senza poi contare i vantaggi di essere indipendenti da questo punto di vista.
Il passaggio potrebbe essere costoso, ma potrebbe valerne la pena nel lungo periodo.

ancora peggio fare calcoli scientifici/finanziari/generali utilizzando un'architettura ARM, ovvero con una RISC, ovvero un'architettura che non applica operazioni di elaborazione sui registi e non ha implementate via hardware operazioni complesse.

quindi secondo te risc vuol dire l'architettura dei poveracci? :eek:

ps io sono anche un imbecille che crede che apple puo' prendere un arm e infilarlo dentro un imac.
per la semplice ragione che arm e' un' architettura, non una cpu, si puo' fare eccome un incremento mostruoso di prestazioni.
a parte che ormai non si ragiona piu' come singola cpu, ma come multicore, quindi prendi un core arm, replicalo 20 volte sulla stessa cpu e poi vedi le prestazioni.

Ora coi PowerPC fanno cluster di calcolo. Perché? Perché sono molto efficienti a gestire le operazioni semplici importanti per il calcolo scientifico (che alla fine è spesso solo un'elaborazione vettoriale di numeri con le 4 operazioni fondamentali) e scalano facilmente. NON perché hanno potenzialità intrinseche di diventare macchine di produzione Desktop, dato che ad elaborare un video con un codec h264 ci vorrebbe un intero cluster di calcolo che emuli le istruzinoni CISC di una comune workstation con hardware x86.

Stai facendo molta confusione, l'architettura PowerPC deriva dai chip POWER di IBM.

PowerPC nacque come "architettura comune" tra IBM, Motorola ed altre aziende per imporre una cpu standard RISC per pc desktop in alternativa agli x86.
Solo che allora non c'erano Java, .Net ecc. ed il grosso del software per pc poteva girare solo su x86 con Windows.
Apple fu l'unica grande azienda che adottò le cpu PowerPC e produsse computer desktop e portatili in quantitativi significativi (c'erano anche produttori minori che proponevano sistemi con Linux o altri OS) e di li a poco i PowerPC vennero relegati al settore automotive ed embedded "di fascia alta" (con anche versioni militari/spaziali rad-hard tipo il RAD750), l'ultimo successo commerciale noto al pubblico lo si è avuto con la precedente generazione di console per videogiochi (Wii, Xbox360 e PS3 integravano cpu con dei core PowerPC, persino il Cell oltre alle SPU aveva due core PowerPC) ma ora è rimasto solo il Wii-U a farne uso.

Invece nel settore dei supercomputer e dei server di fascia alta i POWER hanno continuato a prendere a ceffoni gli x86 anche senza disporre delle tecnlologie più avanzate di cui disponeva invece Intel con maggiore anticipo.
E non parlo solo di calcolo scientifico, ma anche di tipologie di codice in cui secondo te l'x86 se la cava meglio.
Come se non bastasse scalano molto di più di clock.
Ad esempio il POWER6 nel 2007 implementato a 65nm girava a 5GHz "di serie" ed era pure ottimizzato per emulare con alta efficienza le vecchie architetture dei CISC di IBM.

Questo perche i clienti a cui si rivolge IBM con i POWER non hanno problemi a pagare se gli si garantiscono prestazioni e retrocompatibilità con i sistemi legacy da cui dipendono le loro aziende.
Quindi IBM poteva permettersi si spendere e spandere sul lato costi e consumi a patto che poi ci fossero le prestazioni richieste.

Invece sul lato delle cpu per desktop il requisito di retrocompatibilita giocava a favore degli x86 e si è visto come e' andata.

Ora invece anche sui sistemi desktop i requisiti di retrocompatibilità con x86 stanno diventando sempre meno stringenti, sia perchè si fa sempre meno uso di codice assembly e sia perchè Android, Java VM, .Net e pure il nuovo runtime WinRT sono relativamente indipendenti dal processore.
Inoltre Apple attualmente come compilatore di riferimento spinge Clang (C/C++/Objective-C per LLVM) proprio per non legarsi più ad un architettura specifica.

Ricordiamo che ora Apple è un'azienda con risorse ben differenti rispetto a quelle che aveva quando è passata a processori Intel.
Ora è perfettamente in grado di creare processori per conto suo (e l'ha dimostrato con l'A7, che ricordiamo è un dual core da 1,3 Ghz che compete con gli altri ARM quad core da oltre 2 GHz), e la licenza ARM le consente di creare processori davvero ottimizzati per le proprie macchine, mentre con Intel prende il pacchetto chiuso.
Senza poi contare i vantaggi di essere indipendenti da questo punto di vista.
Il passaggio potrebbe essere costoso, ma potrebbe valerne la pena nel lungo periodo.
Scusa, mi ricordi quante fonderie ha Apple ?
E quante di queste sono a 22nm ?
E quanti processori ha progettato dopo il vecchio A7 che ha già un anno ?


quindi secondo te risc vuol dire l'architettura dei poveracci? :eek:

ps io sono anche un imbecille che crede che apple puo' prendere un arm e infilarlo dentro un imac.
per la semplice ragione che arm e' un' architettura, non una cpu, si puo' fare eccome un incremento mostruoso di prestazioni.
a parte che ormai non si ragiona piu' come singola cpu, ma come multicore, quindi prendi un core arm, replicalo 20 volte sulla stessa cpu e poi vedi le prestazioni.
Andare forte come un x86 è facile
Andare forte come un x86 e costare uguale è invece tutto un altro paio di maniche
Vero che Apple è un marchio premium e può permettersi di costare di più, ma solo fino a un certo punto



Invece nel settore dei supercomputer e dei server di fascia alta i POWER hanno continuato a prendere a ceffoni gli x86 anche senza disporre delle tecnlologie più avanzate di cui disponeva invece Intel con maggiore anticipo.

Oddio
Quando proponi sistemi con 64 CPU e 256 Gb di ram fai presto a prendere a schiaffoni qualsiasi PC x86 :fagiano:
D' altra parte sono sistemi che hanno prezzi d' ingresso a partire da 100.000 $, non puoi mica confrontarli con CPU progettate per stare su un pc che costa 100 volte di meno.
Che poi nella fascia alta Intel ha spinto i suoi fallimentari Itanium :stordita:

Windows RT ha avuto una genesi completamente diversa ed è stato, fino ad ora supportato malissimo da MS!! OS X, dalle sue radici, è sempre stato multipiattaforma e il passaggio da PPC ad Intel nel periodo 2005/2006 ne è testimone.
Windows NT ha girato, e gira, su molte più architetture, se è per questo.
Gli utenti e gli sviluppatori sono stati supportati fino all'avvento di OS X 10.6 Snow Leopard con strumenti come Rosetta che permetteva l'esecuzione di codice PPC su processori Intel.
Più che altro perché mancavano le applicazioni OS X x86.

beh insomma
la strada era stata aperta da Leopard, quando comprai il mac mini, SL era stato da poco rilasciato e c'era già tutto il necessario, tempo pochi mesi e non rimaneva più nulla ad utilizzare rosetta

non dimentichiamo che apple abbandono' ppc perche' le prestazioni non erano all'altezza delle cpu x86. Quando ci fu il passaggio, il boost prestazionale fu davvero enorme. I primi imac x86 davano la polvere ai powermac g5 top di gamma.

Quoto un paio di punti soltanto di questo commento, perché risulta evidente che le architetture degli elaboratori non sono il tuo forte.
Te l'ho spiegato: non possono.
A meno che ARM non vuole, come è passata sui 64bit e le operazioni a doppia precisione, passare a tirare fuori processori CISC.
Le operazioni a doppia precisione sono supportate da tempo dagli ARM.
A quel punto non è questione di consumi, ARM come la conosciamo sarebbe solo una marca che fabbrica SIA RISC che CISC che sarebbero due prodotti completamente diversi (così come Intel lo fa, ma i suoi RISC sono poco conosciuti e riservati ad applicazioni industriali o spin-off) e non compatibili.

Anzi a quel punto con tutta probabilità ARM CISC sarebbe compatibile (o addirittura userebbe direttamente) con Intel x86 e non con ARM RISC.
Ovvero a quel punto ARM sarebbe come AMD e ovviamente non ci sarebbe alcun problema.
Ma anche no. ARM lavora da anni esclusivamente sulla sua architettura RISC, e considerato l'enorme successo che ha avuto e non ha alcun motivo per progettare una CPU CISC. NESSUNO.

Pensare di realizzarne una compatibile con l'x86 di Intel è del tutto privo di senso, visto che non possiede alcuna licenza per l'utilizzo di IA-32, e sta sicuro che Intel non avrebbe alcuna intenzione di rilasciargliene una.

Hai scritto parecchie inesattezze, ma queste non si possono proprio leggere.

Lascia perdere le architetture, e per il futuro ti consiglio di parlare esclusivamente di argomenti di cui tu abbia una discreta conoscenza.

Leggevo altrove che solamente le soluzioni "pro" resterebbero x86 mentre tutto il resto passerebbe gradualmente ad arm, adesso sta a vedere che tempistiche e prestazioni avranno, però se dovesse avverarsi intel perderebbe una gran parte degli ordini dal suo più grande cliente e via di licenziamenti e fab chiuse....:(

Anche se ARM potrebbe essere meno efficiente di X86 per far calcoli scientifici (sicuri?)
è pensato apposta per lavorare insieme a coprocessori... ecco che il problema è risolto!
ALCUNI problemi sarebbero risolti. Non tutti.
Stessa cosa per la codifica/decodifica video, la gestione degli I/O, l'accelerazione video (sarebbe la GPU), Java*, ecc...
Ma non tutto.
Fare una cosa come Rosetta che converte istruzioni X86 in ARM? E' Banale ormai usando LLVM (OSX è compilato tutto usando Clang, quindi...)...
Puoi fare tutto. Sulla carta. Poi bisogna vedere a livello prestazionale cosa otterresti, e lì i risultati sono tutt'altro che scontati.
L'importante è che non cadano nell'orrore di Microsoft un Desktop deve restare tale non diventare un Tablet!
Può essere entrambi.
* Alcuni processori ARM integrano un JVM chiamata Jazelle che permette di eseguire Java come fosse codice nativo.
Soluzione abbandonata da tempo. Infatti ha preferito modificare un po' la sua architettura allo scopo, tirando fuori la modalità ThumbEE (http://www.appuntidigitali.it/10374/thumbee-da-arm-una-virtual-machine-per-tutti-i-linguaggi/).

Più che altro, sebbene sia anche vero quanto hai scritto, PPC fallì perché Motorola non fu mai capace di raffinare i processi produttivi delle CPU. Gli ultimi PPC montati su desktop, i G5, erano dei forni mostruosi...
I G5 erano di IBM, non di Motorola.
Il punto di svolta si sarebbe dovuto raggiungere con la generazione successiva ( G6 - riciclata successivamente nel Cell Processor ), ma Motorola vendette le sue fonderie e tutto il reparto CPU, lasciando IBM e soprattutto Apple a terra...
Ma anche no. IBM realizzò il G5, e probabilmente avrebbe pensato anche al G6, ma col fallimento del G5 semplicemente abbandonò il mercato desktop, al quale era approdata per far contenta Apple.

Motorola ha realizzato ALTRI processori, utilizzati ovviamente da Apple.

In entrambi i casi, Motorola e IBM non erano in grado di garantire prestazione comparabili a quelle offerte da Intel in quest'ambito, che all'epoca poteva contare anche su consumi molto ridotti grazie alla neonata architettura Banias (Centrino).

Per supporto intendo anche la disponibilità di applicazioni... Apple, al tempo dello switch da PPC a Intel risolse con Rosetta per l'utenza e con compilatori ottimizzati per gli sviluppatori.
Compilatori ottimizzati? Mi faresti un esempio, cortesemente?

Il problema l' ho spiegato qui sopra, l' architettura delle CPU è in realtà molto simile.
Non sono d'accordo. Ovviamente per la microarchitettura si utilizzano soluzioni spesso simili (cache, register file, branch predictor, TLB, ecc. ecc.), ma l'ISA riveste in ogni caso una notevole importanza, che ha risvolti non di poco conto, specie a livello prestazionale.

I G5 erano di IBM, non di Motorola.

Ma anche no. IBM realizzò il G5, e probabilmente avrebbe pensato anche al G6, ma col fallimento del G5 semplicemente abbandonò il mercato desktop, al quale era approdata per far contenta Apple.

Motorola ha realizzato ALTRI processori, utilizzati ovviamente da Apple.

In entrambi i casi, Motorola e IBM non erano in grado di garantire prestazione comparabili a quelle offerte da Intel in quest'ambito, che all'epoca poteva contare anche su consumi molto ridotti grazie alla neonata architettura Banias (Centrino).

Motorola al tempo di AIM metteva nel consorzio le sue fonderie e processi di produzione... Mai detto che Motorola avesse disegnato e progettato i PPC!!

A mio parere il salto netto da una architettura all'altra sarebbe un suicidio.
Teniamo conto che a suo tempo la Apple e MAC OS era al quanto in crisi e che il salto verso Intel era obbligato, per dare nuova linfa ai loro prodotti.

Oggi i MAC sono gli unici PC che risentono poco della contrazione del mercato degli stessi. E perdessero compatibilità con X86 e di conseguenza Windows sarebbero problemi... Credo che molti che utilizzano il MAC, abbiano una Partizione Boot Camp o una qualche software di vitualizzazione.
Che senza X86 sarebbero duri da far funzionare.
Esattamente. Uno dei motivi, probabilmente il più importante, che ha portato a un netto aumento della diffusione dei Mac è stato la possibilità di far girare Windows e relativo software annesso.

Cosa che verrebbe meno adottando una CPU ARM, che anche a fronte di un emulatore x86 non sarebbe in grado di garantire adeguate prestazioni.
Parentesi CPU:
A partire dal Pentium la distinzione CISC RISC è da abbandonare in quanto tale CPU utilizzava caratteristiche di una o dell'altra.
Addirittura aveva due pipeline distine per operazioni complesse e operazioni semplici. Per cui oggi pensare alle CPU moderne in termini solo CISC è limitativo.
Non sono d'accordo perché le CPU CISC continuano a mantenere delle differenze non di poco conto. La distinzione fra RISC e CISC rimane.

quindi secondo te risc vuol dire l'architettura dei poveracci? :eek:

ps io sono anche un imbecille che crede che apple puo' prendere un arm e infilarlo dentro un imac.
per la semplice ragione che arm e' un' architettura, non una cpu, si puo' fare eccome un incremento mostruoso di prestazioni.
a parte che ormai non si ragiona piu' come singola cpu, ma come multicore, quindi prendi un core arm, replicalo 20 volte sulla stessa cpu e poi vedi le prestazioni.
20 donne non fanno un bambino in due settimane...

Invece nel settore dei supercomputer e dei server di fascia alta i POWER hanno continuato a prendere a ceffoni gli x86 anche senza disporre delle tecnlologie più avanzate di cui disponeva invece Intel con maggiore anticipo.
E non parlo solo di calcolo scientifico, ma anche di tipologie di codice in cui secondo te l'x86 se la cava meglio.
Come se non bastasse scalano molto di più di clock.
Ad esempio il POWER6 nel 2007 implementato a 65nm girava a 5GHz "di serie" ed era pure ottimizzato per emulare con alta efficienza le vecchie architetture dei CISC di IBM.
Sono due ambiti completamente diversi. IBM, ma potremmo parlare anche di Sun col suo Niagara, punta alle prestazioni complessive, per cui può permettersi anche di tirare fuori architetture come la POWER6 che sono in-order che sono più semplici e scalano maggiormente in frequenza, ma al prezzo di avere prestazioni su singolo core/thread nettamente inferiori.

Intel da sempre predilige prestazioni maggiori su singolo core/thread.
Questo perche i clienti a cui si rivolge IBM con i POWER non hanno problemi a pagare se gli si garantiscono prestazioni e retrocompatibilità con i sistemi legacy da cui dipendono le loro aziende.
Quindi IBM poteva permettersi si spendere e spandere sul lato costi e consumi a patto che poi ci fossero le prestazioni richieste.

Invece sul lato delle cpu per desktop il requisito di retrocompatibilita giocava a favore degli x86 e si è visto come e' andata.

Ora invece anche sui sistemi desktop i requisiti di retrocompatibilità con x86 stanno diventando sempre meno stringenti, sia perchè si fa sempre meno uso di codice assembly e sia perchè Android, Java VM, .Net e pure il nuovo runtime WinRT sono relativamente indipendenti dal processore.
Inoltre Apple attualmente come compilatore di riferimento spinge Clang (C/C++/Objective-C per LLVM) proprio per non legarsi più ad un architettura specifica.
LLVM genera ancora codice binario per la specifica architettura. Per la precisione, i binari che tira fuori mamma Apple sono legati a x64 o ARM, a seconda del target.

Quando i binari faranno uso dell'IL di LLVM allora potremo realmente parlare di codice indipendente dal processore, similmente a quanto avviene per Java e .NET.

Leggevo altrove che solamente le soluzioni "pro" resterebbero x86 mentre tutto il resto passerebbe gradualmente ad arm, adesso sta a vedere che tempistiche e prestazioni avranno, però se dovesse avverarsi intel perderebbe una gran parte degli ordini dal suo più grande cliente e via di licenziamenti e fab chiuse....:(
Apple NON è il più grande cliente di Intel. Anzi.

Motorola al tempo di AIM metteva nel consorzio le sue fonderie e processi di produzione... Mai detto che Motorola avesse disegnato e progettato i PPC!!
Da ciò che avevi scritto sembrava che il G5 fosse opera di Motorola, e che quest'ultima fosse la responsabile dei PowerPC.

Comunque IBM ha sempre avuto le sue fonderie ed è sempre stata pioniera riguardo ai processi produttivi. Dunque non ha mai avuto bisogno di Motorola. ;)

Quoto un paio di punti soltanto di questo commento, perché risulta evidente che le architetture degli elaboratori non sono il tuo forte.

Un paio di punti di questo perché è evidente che, nonostante la competenza nelle architetture degli elaboratori, l'Italiano (assieme ai multiquote) non è il tuo forte.

Le operazioni a doppia precisione sono supportate da tempo dagli ARM.

E ci mancherebbe che non siano supportate. Ma per eseguirle sui registri sono necessari i 64bit, recentemente introdotti.

Ma anche no. ARM lavora da anni esclusivamente sulla sua architettura RISC, e considerato l'enorme successo che ha avuto e non ha alcun motivo per progettare una CPU CISC. NESSUNO.

Che è più o meno quello che sostengo dall'inizio: che non la vedo probabile. D'altronde ARM significa proprio "Advanced RISC Machines", sarebbe quantomeno bizzarro convertirsi a produrre pure CISC.

Tuttavia non posso essere così categorico, dato che non sono il CEO di ARM e non posso sapere cosa bolle in pentola, quanto sarebbe difficile per loro, e cosa avrebbero da guadagnarci sul lungo termine.
Se invece tu fai Segars di cognome e vuoi lasciarci lo scoop, mi fa piacere.

In realtà le architetture interne ARM e x86 sono abbastanza simili ed entrambe molto diverse dalle vecchie RISC/CISC raggiungendo un' efficenza parecchio superiore.

Che siano diverse dal discorso semplicino non ci piove, ma la sostanza rimane la stessa di un tempo:
La CISC per fare un'operazione su (ipotesi) due numeri applica un'istruzione complessa (che è embedded nei transistor della CPU) su due chiavi di registro.
La RISC per fare la stessa operazione due numeri applica diverse istruzioni semplici caricando di volta in volta le linee di codice delle singole operazioni semplici dalla RAM ai registri.

Questo può essere molto più efficiente nel caso che l'operazione da eseguire sia semplice ma non può competere nel caso in cui l'operazione sia composta da molte istruzioni che sono già embedded nella CISC e non nella RISC.

Poi quanto sia difficile per ARM produrre una CISC dal suo stato attuale non ho la più pallida idea, se tu dici che alla fine è relativamente semplice cambiare la ISA per adattare le cose mi fido, quello che sostengo che non sarebbe, come dice la news e credono in molti: "prendiamo A7 che ha un "potenziale inesplorato" e ne infiliamo 1,2,4,8 in un Macbook Air e voilà, il PC perfetto!".

Sarebbe un nuovo processore, chiamiamolo C1 (per Complex), ancora più simile a quelli Intel di quanto lo sia già ora, e questo farebbe di ARM una seconda AMD dal mio punto di vista, più che una "seconda via del computing".

Invece nel settore dei supercomputer e dei server di fascia alta i POWER hanno continuato a prendere a ceffoni gli x86 anche senza disporre delle tecnlologie più avanzate di cui disponeva invece Intel con maggiore anticipo.
E non parlo solo di calcolo scientifico, ma anche di tipologie di codice in cui secondo te l'x86 se la cava meglio.
Come se non bastasse scalano molto di più di clock.
Ad esempio il POWER6 nel 2007 implementato a 65nm girava a 5GHz "di serie" ed era pure ottimizzato per emulare con alta efficienza le vecchie architetture dei CISC di IBM.


si va bè all'epoca, ora perdono quote di mercato di anno in anno in favore delle migliori piattaforme X86.

adesso sta a vedere che tempistiche e prestazioni avranno, però se dovesse avverarsi intel perderebbe una gran parte degli ordini dal suo più grande cliente(

O.o ma li hai visti i fatturati di Apple ? oramai il suo core business sono iPhone e iPad di PCne vende 4 in croce; Dell, HP, Lenovo, Acer, Asus sono tutti clienti nettamente piu grandi di Apple; soltanto Dell fara ordini 10 volte piu grandi.

Un paio di punti di questo perché è evidente che, nonostante la competenza nelle architetture degli elaboratori, l'Italiano (assieme ai multiquote) non è il tuo forte.
Quali problemi ci sarebbero col mio italiano e il quote? Lanciare la pietra e nascondere la mano non è utile alla discussione, ma soltanto per comprendere l'onestà intellettuale dei partecipanti.
E ci mancherebbe che non siano supportate. Ma per eseguirle sui registri sono necessari i 64bit, recentemente introdotti.
Falso. Infatti persino l'8086, che non era certamente un processore a 64 bit, era in grado di eseguire calcoli a precisione doppia e persino estesa (80 bit) con la sua FPU.
Che è più o meno quello che sostengo dall'inizio: che non la vedo probabile. D'altronde ARM significa proprio "Advanced RISC Machines", sarebbe quantomeno bizzarro convertirsi a produrre pure CISC.

Tuttavia non posso essere così categorico, dato che non sono il CEO di ARM e non posso sapere cosa bolle in pentola, quanto sarebbe difficile per loro, e cosa avrebbero da guadagnarci sul lungo termine.
Se invece tu fai Segars di cognome e vuoi lasciarci lo scoop, mi fa piacere.
Non c'è bisogno: basta conoscere la storia dei processori, e di aziende come ARM e Intel, per comprendere che ciò che hai scritto non ha alcun senso.

Ti risulta che Intel abbia voglia di cedere la sua licenza IA-32 alla sua più agguerrita concorrente?

Io in questo sono decisamente categorico: la risposta è NO. Ma se hai evidenza del contrario, fammelo sapere, perché per me sarebbe un'incredibile novità.
Che siano diverse dal discorso semplicino non ci piove, ma la sostanza rimane la stessa di un tempo:
La CISC per fare un'operazione su (ipotesi) due numeri applica un'istruzione complessa (che è embedded nei transistor della CPU)
embbeded? Nei transistor? E dove poteva essere altrimenti?
su due chiavi di registro.
Guarda che non parliamo di spartiti musicali: le "chiavi" di cui parli non esistono nei registri di una CPU...
La RISC per fare la stessa operazione due numeri applica diverse istruzioni semplici caricando di volta in volta le linee di codice
Da quando i RISC caricano linee di codice? Pensavo caricassero istruzioni.
delle singole operazioni semplici dalla RAM ai registri.
E da quando il codice finirebbe nei registri? Non dovrebbero finire nella cache?
Questo può essere molto più efficiente nel caso che l'operazione da eseguire sia semplice ma non può competere nel caso in cui l'operazione sia composta da molte istruzioni che sono già embedded nella CISC e non nella RISC.
Questo riguarda in generale il fatto che un processore abbia o meno a disposizione istruzioni per eseguire compiti specifici. E non riguarda soltanto i CISC, visto che anche i RISC, da tempo, mettono a disposizioni istruzioni molto complesse.

In particolare ARM, che è fra le architetture RISC più "complicate".
Poi quanto sia difficile per ARM produrre una CISC dal suo stato attuale non ho la più pallida idea,
Non avevo alcun dubbio...
se tu dici che alla fine è relativamente semplice cambiare la ISA per adattare le cose mi fido,
Cfranco si riferiva alle tecnologie "comuni" a qualunque processore, sia esso RISC o CISC.
quello che sostengo che non sarebbe, come dice la news e credono in molti: "prendiamo A7 che ha un "potenziale inesplorato" e ne infiliamo 1,2,4,8 in un Macbook Air e voilà, il PC perfetto!".
Su questo concordo.
Sarebbe un nuovo processore, chiamiamolo C1 (per Complex), ancora più simile a quelli Intel di quanto lo sia già ora,
Non sono affatto simili. Tutt'altro.
e questo farebbe di ARM una seconda AMD dal mio punto di vista, più che una "seconda via del computing".
Non c'è pericolo: ARM rimarrà sempre legata alla sua architettura. Anche se da tempo offre ISA CISC, per migliorare la densità del codice.

Quali problemi ci sarebbero col mio italiano e il quote?
Se ci tieni a saperlo:
Con l'Italiano il fatto che quoti la parte in cui ti do ragione come cazzata.
Con il quote, il fatto che esiste il "multiquote" per quotare più autori nello stesso thread (volendo uno può fare anche taglia-incolla) e che sarebbe netiquette farlo, anziché fare 3 reply di fila.

Per il resto mi fa piacere che le cose su cui hai da ridire sono più che altro di notazione, su cui ammetto di non avere una preparazione sufficiente per essere preciso al punto di non fare neanche imprecisioni quando si parla di queste cose.

Se ci tieni a saperlo:
Con l'Italiano il fatto che quoti la parte in cui ti do ragione come cazzata.
Questo non avrebbe nulla a che fare con l'italiano, ma con la logica semmai.

Comunque riporta pure le parti in questioni e fammi vedere dove si applicherebbe ciò che hai scritto.
Con il quote, il fatto che esiste il "multiquote" per quotare più autori nello stesso thread (volendo uno può fare anche taglia-incolla) e che sarebbe netiquette farlo, anziché fare 3 reply di fila.
Non mi risulta che il regolamento di hwupgrade sia cambiato da un po' di anni a questa parte, e se il primo a lamentarsi del multiquote in tutti questi anni che sono iscritto qui e ho partecipato attivamente.
Per il resto mi fa piacere che le cose su cui hai da ridire sono più che altro di notazione, su cui ammetto di non avere una preparazione sufficiente per essere preciso al punto di non fare neanche imprecisioni quando si parla di queste cose.
La tua preparazione non è semplicemente insufficiente; il tuo problema è che parli di cose che sconosci. Di architetture sugli elaboratori ne capisci quanto io di bricolage.

Il buon senso dovrebbe indurre la gente a discutere di cose di cui abbiano una discreta conoscenza.

Che siano diverse dal discorso semplicino non ci piove, ma la sostanza rimane la stessa di un tempo:
La CISC per fare un'operazione su (ipotesi) due numeri applica un'istruzione complessa (che è embedded nei transistor della CPU) su due chiavi di registro.
La RISC per fare la stessa operazione due numeri applica diverse istruzioni semplici caricando di volta in volta le linee di codice delle singole operazioni semplici dalla RAM ai registri.

No
Quello che fa effettivamente la CPU è a scelta del progettista, l' istruzione sorgente viene infatti decodificata da uno strato iniziale e trasformata in micro-op che vengono eseguite dallo strato interno, quali siano le micro-op e come vengano eseguite effettivamente è una scelta di design che può cambiare tra una CPU e un' altra anche se sono compatibili con la stessa ISA, ad esempio quando è uscito l' Athlon 64 AMD ha pubblicizzato molto il fatto che ci fosse un core RISC dentro il processore.


Non sono d'accordo perché le CPU CISC continuano a mantenere delle differenze non di poco conto. La distinzione fra RISC e CISC rimane.
Le differenze tra RISC e CISC erano soprattutto filosofiche, con i RISC che si vantavano del "piccolo è bello" contro gli elefanti.
Col passare del tempo le ( ex ) cpu RISC hanno aggiunto istruzioni su istruzioni e strati su strati di circuiti fino a raggiungere le dimensioni degli x86, mentre gli x86 hanno semplificato l' approccio.
Alla fine tra ARM e x86 l' ISA non ha grosse differenze, soprattutto adesso che la battaglia si gioca sull' efficenza dell' unità a virgola mobile e sulle istruzioni SIMD.

Ed è proprio su questo che dovresti riflettere: guarda pure le SIMD di x86 e ARM, e traine le tue conseguenze. ;)

Se puoi, dai un'occhiata pure al prossimo AVX-512, dove diventa ancor più evidente la differenza fra l'approccio dei CISC e quello dei RISC riguardo alla definizione e funzionamento dell'ISA.

Da ciò che avevi scritto sembrava che il G5 fosse opera di Motorola, e che quest'ultima fosse la responsabile dei PowerPC.

Comunque IBM ha sempre avuto le sue fonderie ed è sempre stata pioniera riguardo ai processi produttivi. Dunque non ha mai avuto bisogno di Motorola. ;)

IBM ha avuto le sue fonderie solo per i suo progetti " high end " e strategici... Quando venne varata AIM gli accordi prevedevano che la maggior parte della produzione venisse affidata a Motorola perché aveva maggiore esperienza nella porzione di CPU in grande quantità ottimizzando al massimo le rese e i processi produttivi.
Nello specifico le mire di Motorola, una volta acquisite le licenze POWER da IBM, erano di migliorare la sua lineup RISC che non stava andando bene e di rivendere i nuovi processori PPC a basso costo anche ad IBM viste le economie di scala. Non a caso le prime due versioni delle cpu PPC, G3 e G4, vennero sviluppate quasi completamente da Motorola.
Ma nonostante un successo iniziale molto caloroso di PPC, Motorola decise di eliminare la divisione CPU creando Freescale e così il G5 venne sviluppato in toto da IBM.

Oddio
Quando proponi sistemi con 64 CPU e 256 Gb di ram fai presto a prendere a schiaffoni qualsiasi PC x86 :fagiano:
D' altra parte sono sistemi che hanno prezzi d' ingresso a partire da 100.000 $, non puoi mica confrontarli con CPU progettate per stare su un pc che costa 100 volte di meno.
Che poi nella fascia alta Intel ha spinto i suoi fallimentari Itanium :stordita:

I POWER si mangiavano vivi gli x86 anche solo confrontando i core, ed oltre a questo erano pensati per scalare di brutto visto che nella loro nicchia le prestazioni contano ancora moltissimo.

Il mio punto era che il supposto vantaggio degli x86 nei confronti dei RISC non è una cosa che dipende da particolarità dell'architettura x86 e che un RISC può benissimo far vedere i sorci verdi al top degli x86 se progettato con analoghi parametri in termini di consumo massimo, area del chip e costo.

Sono due ambiti completamente diversi. IBM, ma potremmo parlare anche di Sun col suo Niagara, punta alle prestazioni complessive, per cui può permettersi anche di tirare fuori architetture come la POWER6 che sono in-order che sono più semplici e scalano maggiormente in frequenza, ma al prezzo di avere prestazioni su singolo core/thread nettamente inferiori.

Per le tipologie di codice che doveva essere eseguito i POWER6 erano superiori anche in un confronto core vs. core.
IBM non è mica come Intel che se ne uscì con i Pentium 4 apparentemente ignorando come era il grosso del codice per applicazioni x86 in circolazione e pensando di poter risolvere tutto salendo di clock.


Intel da sempre predilige prestazioni maggiori su singolo core/thread.

Non è che "Intel predilige", la cosa è legata al software per x86 in circolazione che per come è stato scritto e compilato di solito gira meglio su core con maggior microparallelismo interno.

LLVM genera ancora codice binario per la specifica architettura. Per la precisione, i binari che tira fuori mamma Apple sono legati a x64 o ARM, a seconda del target.

Quando i binari faranno uso dell'IL di LLVM allora potremo realmente parlare di codice indipendente dal processore, similmente a quanto avviene per Java e .NET.

E' solo questione di decidere se spostare o meno la compilazione finale in codice macchina sul device.

Ma si può anche compilare il codice per più target, caricarlo sull'app store e lasciare che vega selezionata automaticamente la versione più adatta al target specifico.

Si riesce già a fare cose simili per il Play Store usando GCC, con Clang e LLVM è pure più facile ed Apple di fatto ha già la toolchain ed l'infrastruttura di supporto per farlo.

IBM ha avuto le sue fonderie solo per i suo progetti " high end " e strategici... Quando venne varata AIM gli accordi prevedevano che la maggior parte della produzione venisse affidata a Motorola perché aveva maggiore esperienza nella porzione di CPU in grande quantità ottimizzando al massimo le rese e i processi produttivi.
Nello specifico le mire di Motorola, una volta acquisite le licenze POWER da IBM, erano di migliorare la sua lineup RISC che non stava andando bene e di rivendere i nuovi processori PPC a basso costo anche ad IBM viste le economie di scala. Non a caso le prime due versioni delle cpu PPC, G3 e G4, vennero sviluppate quasi completamente da Motorola.
Di questo francamente non ricordo. E' passato troppo tempo.
Ma nonostante un successo iniziale molto caloroso di PPC, Motorola decise di eliminare la divisione CPU creando Freescale e così il G5 venne sviluppato in toto da IBM.
Di questo, invece, sì, e scrissi anche un pezzo (http://www.appuntidigitali.it/15709/apple-e-i-processori-non-e-amore-eterno/) a riguardo.

I POWER si mangiavano vivi gli x86 anche solo confrontando i core, ed oltre a questo erano pensati per scalare di brutto visto che nella loro nicchia le prestazioni contano ancora moltissimo.
Non è esatto. Vedi il già citato G5, ad esempio.
Il mio punto era che il supposto vantaggio degli x86 nei confronti dei RISC non è una cosa che dipende da particolarità dell'architettura x86 e che un RISC può benissimo far vedere i sorci verdi al top degli x86 se progettato con analoghi parametri in termini di consumo massimo, area del chip e costo.
Con tutti questi parametri in gioco, è possibile. Ma se parliamo di pure prestazioni, il discorso cambia.
Per le tipologie di codice che doveva essere eseguito i POWER6 erano superiori anche in un confronto core vs. core.
Per le tipologie di codice scelte, esatto.
IBM non è mica come Intel che se ne uscì con i Pentium 4 apparentemente ignorando come era il grosso del codice per applicazioni x86 in circolazione e pensando di poter risolvere tutto salendo di clock.
IBM non è Intel, ma ha fatto sostanzialmente lo stesso proprio col POWER6, scegliendo il maggior clock a discapito delle prestazioni (su singolo core/thread).
Non è che "Intel predilige", la cosa è legata al software per x86 in circolazione che per come è stato scritto e compilato di solito gira meglio su core con maggior microparallelismo interno.
Questo potrebbe essere vero (ma ho i miei dubbi, in quanto non è chiaro lo scenario) se ci fosse una preponderanza di codice assembly.
E' solo questione di decidere se spostare o meno la compilazione finale in codice macchina sul device.
In tal caso sarebbe bastato rimanere su x86 o x64, anziché affidarsi a IL nuovi di zecca.
Ma si può anche compilare il codice per più target, caricarlo sull'app store e lasciare che vega selezionata automaticamente la versione più adatta al target specifico.
Sì, è quel che avviene.
Si riesce già a fare cose simili per il Play Store usando GCC, con Clang e LLVM è pure più facile ed Apple di fatto ha già la toolchain ed l'infrastruttura di supporto per farlo.
Vero. Ma una soluzione simile a .NET, e dunque "universale", non esiste ancora.

In realtà usando LLVM (o pià precisamente Clang) per compilare C/C++/ObjC, ma generando non il codice macchina, ma il bitcode e distribuendolo in quella forma già ottieni qualcosa di molto simile a .NET, certo alcuni problemi li potresti per esempio l'istruzione sizeof() sulle strutture potrebbe non dire la verità (se non sono __packed il processore aggiunge "bratta" per allinearle alla dimensione "ideale"... ideale per lui!) o problemi di endianess (X86/X86-64 è Little Endian, ARM è Big Endian), nulla di insuperabile, comunque, visto che Google lo ha già fatto:

http://en.wikipedia.org/wiki/Google_Native_Client
(uno quindi potrebbe compilare l'applicazione in bitcode, e quando schiacci "download" verrebbe compilata nel tuo codice macchina / presa da una cache e poi scaricata!)

Visto che Apple ha pure i sorgenti del Sistema Operativo (!) è ancora più facile fare quei giochini (e più efficiente visto che si deve avere un runtime diverso).

Per le tipologie di codice che doveva essere eseguito i POWER6 erano superiori anche in un confronto core vs. core.
I primi si
Poi sono rimasti indietro, molto indietro

Il mio punto era che il supposto vantaggio degli x86 nei confronti dei RISC non è una cosa che dipende da particolarità dell'architettura x86 e che un RISC può benissimo far vedere i sorci verdi al top degli x86 se progettato con analoghi parametri in termini di consumo massimo, area del chip e costo.
Io credo che due processori con analoghi parametri abbiano prestazioni paragonabili, indipendentemente da chi li produce
Si possono fare dei "tuning" cercando maggiori prestazioni in un campo piuttosto che in un altro, ad esempio i vecchi x86 andavano fortissimo nelle elaborazione degli interi ma avevano unità a virgola mobile piuttosto deboli e il pentium pro le prendeva dal primo pentium in elaborazioni a 16 bit ma era più efficente a 32 bit, è inevitabile che il design sia un compromesso tra quanto silicio voglio riservare a un certo compito piuttosto che a un altro, a seconda delle mie priorità avrò processori che primeggiano in un settore sacrificando le prestazioni in altri.
Ma, e qui torniamo a bomba sugli ARM, stiamo parlando di lotta ad armi pari, Intel e TMSC non sono certo allo stesso livello quando si parla di processi produttivi, come può un processore disegnato da Apple e fatto fare in una fonderia terza a 28 nm a competere con una cpu disegnata da Intel e stampata in una fonderia disegnata su misura per la sua produzione a 22nm ?

In realtà usando LLVM (o pià precisamente Clang) per compilare C/C++/ObjC, ma generando non il codice macchina, ma il bitcode e distribuendolo in quella forma già ottieni qualcosa di molto simile a .NET,
Senz'altro, ma... non è stato ancora fatto.
certo alcuni problemi li potresti per esempio l'istruzione sizeof() sulle strutture potrebbe non dire la verità (se non sono __packed il processore aggiunge "bratta" per allinearle alla dimensione "ideale"... ideale per lui!) o problemi di endianess (X86/X86-64 è Little Endian, ARM è Big Endian),
Anche ARM è little-endian, ma è in grado di passare a big-endian programmaticamente.
nulla di insuperabile, comunque, visto che Google lo ha già fatto:

http://en.wikipedia.org/wiki/Google_Native_Client
(uno quindi potrebbe compilare l'applicazione in bitcode, e quando schiacci "download" verrebbe compilata nel tuo codice macchina / presa da una cache e poi scaricata!)
E' stato distribuito anche un emulatore Amiga qualche tempo fa, se non ricordo male.
Visto che Apple ha pure i sorgenti del Sistema Operativo (!) è ancora più facile fare quei giochini (e più efficiente visto che si deve avere un runtime diverso).
Infatti, ma il punto è che rimarrà tutto bello sulla carta finché Apple non adotterà l'IL di LLVM per i suoi eseguibili.

Io credo che due processori con analoghi parametri abbiano prestazioni paragonabili, indipendentemente da chi li produce
Si possono fare dei "tuning" cercando maggiori prestazioni in un campo piuttosto che in un altro, ad esempio i vecchi x86 andavano fortissimo nelle elaborazione degli interi ma avevano unità a virgola mobile piuttosto deboli e il pentium pro le prendeva dal primo pentium in elaborazioni a 16 bit ma era più efficente a 32 bit, è inevitabile che il design sia un compromesso tra quanto silicio voglio riservare a un certo compito piuttosto che a un altro, a seconda delle mie priorità avrò processori che primeggiano in un settore sacrificando le prestazioni in altri.
E' corretto, ma l'architettura rimane comunque importante, a seconda degli obiettivi che ci si pone. Se fissi i parametri all'incirca allo stesso modo, l'architettura deve fare la differenza; e non potrebbe essere altrimenti.

Purtroppo non esistono microarchitetture che abbiano tutti i parametri uguali, tranne l'architettura, per cui non si possono fare dei confronti precisi in merito, ma ci si può affidare a delle microarchitetture abbastanza simili per farsi un'idea dell'impatto che possa avere un'architettura. Prendiamo, ad esempio, le migliori implementazioni in-order con due pipeline e con cache simili, e si eseguono dei test. Idem per implementazioni out-of-order con 2, 3, o 4 pipeline.

se così fosse ad apple non sanno cosa è successo a win rt :asd:

Ma winRT è diverso: per quanto poco esso sia, c'è più software per RT di quanto ce ne sia per OSX x86, figuriamoci su ARM

Bhè non mi pare che RT sia una priorità per gli sviluppatori... Ma RT è un OS confinato, al momento, ai tablet Surface... Apple invece doveva garantire continuità al suo core business Macintosh: prodotti differenti per dinamiche di mercato differenti.

per uno sviluppatore il supporto a RT, nel 99% dei casi, viene a costo zero: se fai un'app metro .NET e/o JS perdi più tempo a escludere il supporto ad ARM che a lasciarlo (il target di default è "AnyCPU")

se fai un'app nativa, supportare ARM è questione di cliccare una checkbox nelle proprietà del progetto (oltre a ovviamente testarla e ottimizzarla nel caso di app intensive come i giochi), e in questo caso potresti decidere di non supportarlo (magari hai bisogno di DX11 o i processori ARM semplicemente potrebbero non farcela)

comunque per i Macbook Air penso che la cosa sarebbe fattibile, visto l'uso che si fa di quelle macchine

ehi, io l'Air lo uso come macchina per lo sviluppo :D

ed è quello che ha fatto MS con rt, ha impedito l'installazione di software x86 così da non mostrare tutti i limiti delle cpu arm in ambito "desktop"

mah, credo che il problema più che altro fosse il fatto che


Non c'era software desktop per ARM, dovevano convincere gli sviluppatori a portarlo... ma chi lo avrebbe fatto?
Dovevano dire agli utenti "alcuni software potrai usarli, altri no"


Ma cosa vai dicendo? Sul mio MBA (hw inferiore al mini) ho aperti adesso Mail, iTunes, iPhoto, Safari, Skype, App store, Parallel desktop, iMessage, dropbox e un paio di altre cose in background e nessun impuntamento. Prova a controllare il tuo HDD che è meglio.

sono d'accordo sul suggerimento di controllare l'HDD (ma che HDD cagosi mettono!? l'imac che ho in ufficio ha uno scrausissimo seagate da 5400 rpm, di quelli che non mettono nemmeno negli acer da 300€)

ma per curiosità, quante macchine avresti? :D

Ricordiamo che ora Apple è un'azienda con risorse ben differenti rispetto a quelle che aveva quando è passata a processori Intel.
Ora è perfettamente in grado di creare processori per conto suo (e l'ha dimostrato con l'A7, che ricordiamo è un dual core da 1,3 Ghz che compete con gli altri ARM quad core da oltre 2 GHz), e la licenza ARM le consente di creare processori davvero ottimizzati per le proprie macchine, mentre con Intel prende il pacchetto chiuso.
Senza poi contare i vantaggi di essere indipendenti da questo punto di vista.
Il passaggio potrebbe essere costoso, ma potrebbe valerne la pena nel lungo periodo.

non credo che Intel gli fornisca il "pacchetto chiuso", Intel collabora con i maggiori produttori durante la progettazione dei propri processori, Apple, Microsoft e altri player hanno voce in capitolo

quindi secondo te risc vuol dire l'architettura dei poveracci? :eek:

ps io sono anche un imbecille che crede che apple puo' prendere un arm e infilarlo dentro un imac.
per la semplice ragione che arm e' un' architettura, non una cpu, si puo' fare eccome un incremento mostruoso di prestazioni.
a parte che ormai non si ragiona piu' come singola cpu, ma come multicore, quindi prendi un core arm, replicalo 20 volte sulla stessa cpu e poi vedi le prestazioni.

si, ma i consumi e i costi? :D

In realtà usando LLVM (o pià precisamente Clang) per compilare C/C++/ObjC, ma generando non il codice macchina, ma il bitcode e distribuendolo in quella forma già ottieni qualcosa di molto simile a .NET, certo alcuni problemi li potresti per esempio l'istruzione sizeof() sulle strutture potrebbe non dire la verità (se non sono __packed il processore aggiunge "bratta" per allinearle alla dimensione "ideale"... ideale per lui!) o problemi di endianess (X86/X86-64 è Little Endian, ARM è Big Endian), nulla di insuperabile, comunque, visto che Google lo ha già fatto:

http://en.wikipedia.org/wiki/Google_Native_Client
(uno quindi potrebbe compilare l'applicazione in bitcode, e quando schiacci "download" verrebbe compilata nel tuo codice macchina / presa da una cache e poi scaricata!)

Visto che Apple ha pure i sorgenti del Sistema Operativo (!) è ancora più facile fare quei giochini (e più efficiente visto che si deve avere un runtime diverso).

Tecnicamente è ciò che fa anche MS su Windows Phone con MDIL e le app .NET: lo sviluppatore invia allo Store un'app in IL e quando la scarichi ottieni una versione nativa... e si stanno preparando a fare una cosa simile con le app MUI, con .NET Native

in ogni caso, il problema di un approccio simile è l'essere costretti a passare dallo store... o tornare ai fat binaries come ai tempi del passaggio da 68k a PPC e da PPC a x86 :D

In ogni caso, se venissi corretto da cdimauro su queste cose, ci penserei non due ma tre volte prima di ribattere :D

ehi, io l'Air lo uso come macchina per lo sviluppo :D
Ne ho uno anch'io (primo modello), ma l'hd è praticamente defunto, e sono mesi che devo mettermi a sostituirlo, ma con quell'interfaccia PATA/ZIF è un dramma.

Comunque devo darmi da fare perché a breve servirà almeno un altro computer, visto che la famiglia mi raggiungerà e condividere l'unico che uso non è il massimo (specialmente per me :D).
non credo che Intel gli fornisca il "pacchetto chiuso", Intel collabora con i maggiori produttori durante la progettazione dei propri processori, Apple, Microsoft e altri player hanno voce in capitolo
Questo è senz'altro vero, anche se la gestazione può essere lunga.

Intel non è affatto sorda ai propri partner, ma bisogna capire che mettere a disposizione nuove funzionalità richiede molto tempo. A volte da una richiesta / suggerimento alla commercializzazione del prodotto che la integrano passano parecchi anni.
Tecnicamente è ciò che fa anche MS su Windows Phone con MDIL e le app .NET: lo sviluppatore invia allo Store un'app in IL e quando la scarichi ottieni una versione nativa... e si stanno preparando a fare una cosa simile con le app MUI, con .NET Native

in ogni caso, il problema di un approccio simile è l'essere costretti a passare dallo store... o tornare ai fat binaries come ai tempi del passaggio da 68k a PPC e da PPC a x86 :D
Meglio di no. Il software è stato distribuito su supporto (prima addirittura cartaceo) dalla notte dei tempi, ma ormai il digitale è molto diffuso e... stracomodo.

Preferisco di gran lunga scaricare un prodotto ("su misura") da uno store centralizzato e controllato.
In ogni caso, se venissi corretto da cdimauro su queste cose, ci penserei non due ma tre volte prima di ribattere :D
Tutti possono sbagliare. :) Il mio consiglio è di verificare sempre ciò che viene detto, da chiunque. Alla fine sono i fatti che devono emergere, SE si è intellettualmente onesti e dotati di sufficiente competenza per affrontare una discussione tecnica. ;)

O.o ma li hai visti i fatturati di Apple ? oramai il suo core business sono iPhone e iPad di PCne vende 4 in croce; Dell, HP, Lenovo, Acer, Asus sono tutti clienti nettamente piu grandi di Apple; soltanto Dell fara ordini 10 volte piu grandi.

Ehmm no... di solito guardo altro... poi se a te piace spippolarti con i risultati finanziari delle aziende so cavoli tuoi :ciapet:

Non si capisce, allora, da dove arrivi la tua precedente affermazione in merito. Spippolamenti anche quelli o roba d'altro tipo?

Non si capisce, allora, da dove arrivi la tua precedente affermazione in merito. Spippolamenti anche quelli o roba d'altro tipo?

dall'ignoranza data dal saltare le news sull'andamento delle vendite dei PC ;)

sono d'accordo sul suggerimento di controllare l'HDD (ma che HDD cagosi mettono!? l'imac che ho in ufficio ha uno scrausissimo seagate da 5400 rpm, di quelli che non mettono nemmeno negli acer da 300€)

ma per curiosità, quante macchine avresti? :D



Per gli HDD è sempre lo stesso discorso legato al rumore, mettono i 5400 per la silenziosità a discapito delle prestazioni (molto discutibile come scelta) infatti io nei MBP ho sempre messo uno Scorpio, ma il rumore in più si notava eccome. Un Acer da 300€ fa casino a prescindere quindi questo discorso non viene fatto anche se anche li di solito mettono i 5400.

In che senso quante macchine?
Vivendo in 2 case ho 2 PC gaming, più un MBA, un MacPro in ufficio e uno come HTPC nell'abitazione principale (sfizio che mi sono voluto togliere perciò non scateniamo inutili polemiche a cui non replicherò)
Avevo anche un iMac prima del MacPro ma l'ho passato ad un'altra postazione in ufficio perché non mi serviva più.

In che senso quante macchine?
Vivendo in 2 case ho 2 PC gaming, più un MBA, un MacPro in ufficio e uno come HTPC nell'abitazione principale (sfizio che mi sono voluto togliere perciò non scateniamo inutili polemiche a cui non replicherò)
Avevo anche un iMac prima del MacPro ma l'ho passato ad un'altra postazione in ufficio perché non mi serviva più.

figurati, non era per fare flame :D è che ti ho visto citare la tua esperienza su diverse macchine in diversi post :D

il discorso sugli Acer non era legato strettamente agli RPM, ma alla qualità del disco stesso... non so se è un caso o se sono tutti così, ma le prestazioni di quel disco sono veramente scandalose, peggiori del mio netbook HP del 2010...

Non si capisce, allora, da dove arrivi la tua precedente affermazione in merito. Spippolamenti anche quelli o roba d'altro tipo?

Ho notato che dato l'argomento del discorso tra me e ace appena hai preso la.... palla al balzo per parlare di spippolamenti.... argomento a te caro? :D :ciapet:

dall'ignoranza data dal saltare le news sull'andamento delle vendite dei PC ;)

Direi quasi un ignoranza da peccato capitale.... :asd: :asd: per fortuna che c'è gente come te che impiega buona parte del proprio tempo a leggere tali preziosissime informazioni e far notare a noi poveri ignoranti tali mancanze... :ciapet: :sofico:
Grazie!

Direi quasi un ignoranza da peccato capitale.... :asd: :asd: per fortuna che c'è gente come te che impiega buona parte del proprio tempo a leggere tali preziosissime informazioni e far notare a noi poveri ignoranti tali mancanze... :ciapet: :sofico:
Grazie!

e si, perchè ora 2 news all'anno sono tantissimo tempo :asd:
prego !

e si, perchè ora 2 news all'anno sono tantissimo tempo :asd:
prego !

È troppa roba! :asd:
Solo te ce la puoi fare!:ciapet:

Tecnicamente è ciò che fa anche MS su Windows Phone con MDIL e le app .NET: lo sviluppatore invia allo Store un'app in IL e quando la scarichi ottieni una versione nativa... e si stanno preparando a fare una cosa simile con le app MUI, con .NET Native


Bene! Mi pare la via corretta da seguire... c'ero un po' rimasto male quando con Windows Rt avevano messo da parte .NET che, è IMHO, un lavoro eccellente! (Lo so che hanno copiato da Java, ma l'hanno... finito :mbe: !)


in ogni caso, il problema di un approccio simile è l'essere costretti a passare dallo store... o tornare ai fat binaries come ai tempi del passaggio da 68k a PPC e da PPC a x86 :D


Mica detto sia obbligatorio parlare di store (che poi sono i repository di Linux... fatti bene :p), anche dal sito dello sviluppatore funzionerebbe semplicemente ci dovrebbe essere un API (banalmente lo chiedi al browser stesso) per sapere in che architettura ti trovi e quel punto il server compila oppure, volendo, scarichi il bitcode e lo compili dopo... o ancora meglio lo fai a runtime con una bella Jittata :D


In ogni caso, se venissi corretto da cdimauro su queste cose, ci penserei non due ma tre volte prima di ribattere :D

Non vedo perché se uno non trolla, non ci sono problemi, giusto?
Io sono sinceramente interessato a questi argomenti (Macchine Virtuali, Managed Runtime, JIT, ...) e voglio imparare ancora di più :p

figurati, non era per fare flame :D è che ti ho visto citare la tua esperienza su diverse macchine in diversi post :D

il discorso sugli Acer non era legato strettamente agli RPM, ma alla qualità del disco stesso... non so se è un caso o se sono tutti così, ma le prestazioni di quel disco sono veramente scandalose, peggiori del mio netbook HP del 2010...

Non era riferito a te, ma purtroppo ci sono sempre in agguato i soliti 4-5 "diversamente abili" che prendono la palla al balzo per scatenare polemiche anche coperti dai mod purtroppo, ma per fortuna al momento si sono tenuti lontani da questo thread :)
Diciamo che se entro in un thread e ci voglio partecipare attivamente lo faccio solo se ho esperienze dirette oppure premetto subito la mia ignoranza. Per me l'HW è una passione che ho da quando avevo 6-7 anni e mi hanno regalato lo Spectrum 128K. Invece qui purtroppo proliferano gli espertoni che pur di difendere convinzioni religiose prima di scrivere qualcosa leggono 1 articolo su Wikipedia capendo ad cazzum e s'improvvisano ingegneri informatici, programmatori, ragionieri, consulenti finanziari e quant'altro.
Guarda gli HDD che ho visto sui Mac sono dei normali 5400 in dotazione a tutto gli OEM (spesso erano Hitachi), quindi le prestazioni sono in linea con tutti i 5400 in circolazione, magari potrebbe essere che OSX risente maggiormente di un disco lento, ma ci vorrebbe qualcuno più preparato di me per entrare nel merito.

È troppa roba! :asd:
Solo te ce la puoi fare!:ciapet:

Guarda qui dentro tutti sanno che sono un simpatizzante Apple, ma questo non dovrebbe comportare la cecità e lo scrivere certe cose abominevoli

Leggevo altrove che solamente le soluzioni "pro" resterebbero x86 mentre tutto il resto passerebbe gradualmente ad arm, adesso sta a vedere che tempistiche e prestazioni avranno, però se dovesse avverarsi intel perderebbe una gran parte degli ordini dal suo più grande cliente e via di licenziamenti e fab chiuse....:(

Intel con le CPU che vende per i Mac ci si pulisce il :ciapet: Apple non conta nulla come cliente CPU. I Mac anche se in crescita come vendite e in controtendenza con il resto del mercato è comunque una nicchia ristrettissima e non utilizza nemmeno CPU sulle quali intel ha grandi margini. Quindi definirla come più grande cliente di intel è una scemenza.

Bene! Mi pare la via corretta da seguire... c'ero un po' rimasto male quando con Windows Rt avevano messo da parte .NET che, è IMHO, un lavoro eccellente! (Lo so che hanno copiato da Java, ma l'hanno... finito :mbe: !)

.NET era stato "messo da parte" soltanto prima del rilascio della Consumer Preview, dato che la documentazione e i tool della Dev Preview erano rivolti quasi esclusivamente a JavaScript :asd: .NET è invece vivo e presente, anche su RT

Mica detto sia obbligatorio parlare di store (che poi sono i repository di Linux... fatti bene :p), anche dal sito dello sviluppatore funzionerebbe semplicemente ci dovrebbe essere un API (banalmente lo chiedi al browser stesso) per sapere in che architettura ti trovi e quel punto il server compila oppure, volendo, scarichi il bitcode e lo compili dopo... o ancora meglio lo fai a runtime con una bella Jittata :D

l'architettura è indicata nell'useragent del browser ;) comunque, facendolo a Runtime perdi tutto il vantaggio della compilazione AOT :D si potrebbe scaricare il bytecode e ricompilarlo in locale (un po' come NGEN o mono-aot), cosa che su un desktop potrebbe richiedere qualche minuto... su un ARM pensato per il mobile, anche qualche ora!
Comunque, se può interessarti, qui (http://channel9.msdn.com/Search?term=mdil#ch9Search)trovi i due video che spiegano il funzionamento di MDIL e .NET Native, è abbastanza affascinante :D (guarda prima MDIL e poi .NET Native, dato che il secondo "prosegue" il discorso del primo)

Non vedo perché se uno non trolla, non ci sono problemi, giusto?
Io sono sinceramente interessato a questi argomenti (Macchine Virtuali, Managed Runtime, JIT, ...) e voglio imparare ancora di più :p

forse mi sono spiegato male :D quello che intendevo dire è che se scrivo qualcosa di cui sono convinto e qualcuno mi corregge, ci penso due volte prima di ribattere perché voglio assicurarmi di non sparare boiate :D se poi a correggermi è un esperto dell'argomento come lui, ci penso un'altra volta ancora :D

Non era riferito a te, ma purtroppo ci sono sempre in agguato i soliti 4-5 "diversamente abili" che prendono la palla al balzo per scatenare polemiche anche coperti dai mod purtroppo, ma per fortuna al momento si sono tenuti lontani da questo thread :)
Diciamo che se entro in un thread e ci voglio partecipare attivamente lo faccio solo se ho esperienze dirette oppure premetto subito la mia ignoranza. Per me l'HW è una passione che ho da quando avevo 6-7 anni e mi hanno regalato lo Spectrum 128K. Invece qui purtroppo proliferano gli espertoni che pur di difendere convinzioni religiose prima di scrivere qualcosa leggono 1 articolo su Wikipedia capendo ad cazzum e s'improvvisano ingegneri informatici, programmatori, ragionieri, consulenti finanziari e quant'altro.
Guarda gli HDD che ho visto sui Mac sono dei normali 5400 in dotazione a tutto gli OEM (spesso erano Hitachi), quindi le prestazioni sono in linea con tutti i 5400 in circolazione, magari potrebbe essere che OSX risente maggiormente di un disco lento, ma ci vorrebbe qualcuno più preparato di me per entrare nel merito.

mah, devo fare qualche controllo sul disco allora... ho installato OSX su un disco esterno usb 3 da 5400 RPM e si avvia più velocemente da lì che dal disco interno... forse è la volta buona che me lo faccio cambiare :O (l'hanno preso prima che iniziassi a lavorare da loro, se avessi potuto decidere mi sarei assemblato una macchina più prestante a cui affiancare un mac mini da usare come build server... e probabilmente avremmo anche risparmiato :asd:)

Non è esatto. Vedi il già citato G5, ad esempio.

Il PowerPC 970 "G5" (uscito nel 2003) era stato sviluppato a partire dall'architettura POWER4 (uscita nel 2001) ma era decisamente diverso.

POWER4 ad esempio aveva le estensioni AS/400 ed era progettato per consumare di più (115W), mentre invece il 970 consumava meno, non aveva estensioni AS/400, implementava le estensioni Altivec ed aveva pipeline più lunghe per scalare meglio di clock.
Tutto questo perche il target dei PowerPC era diverso da quello dei POWER.

Sono in vacanza col telefonino e senza flat, per cui sarò sintetico. Non ricordo che IBM avesse tolto istruzioni al G5 perché è passato troppo tempo, comunque a parte questi dettagli è identico al POWER4. Altivec è un vantaggio per il G5, ed è anche il motivo per cui ha le pipeline più lunghe, ma esclusivamente per quest'unità di calcolo (tutto il resto è uguale). POWER4 dalla sua ha il vantaggio della cache L3, che è assente nel G5.
Complessivamente penso che il G5 avesse prestazioni simili o anche superiori, in particolare per codice "desktop".

mah, devo fare qualche controllo sul disco allora... ho installato OSX su un disco esterno usb 3 da 5400 RPM e si avvia più velocemente da lì che dal disco interno... forse è la volta buona che me lo faccio cambiare :O (l'hanno preso prima che iniziassi a lavorare da loro, se avessi potuto decidere mi sarei assemblato una macchina più prestante a cui affiancare un mac mini da usare come build server... e probabilmente avremmo anche risparmiato :asd:)

Se si avvia più velocemente da disco USB allora fai assolutamente vedere quel disco.

Guarda qui dentro tutti sanno che sono un simpatizzante Apple, ma questo non dovrebbe comportare la cecità e lo scrivere certe cose abominevoli


Ti prego, mi spieghi perché dalla frase ironica che ho scritto ad ACE te ne sei uscito con questa risposta?
Vorrei capire che collegamento sinaptico hai fatto... mi incuriosisce tremendamente.... :asd: :asd:

Te la riporto

È troppa roba!
Solo te ce la puoi fare!


Intel con le CPU che vende per i Mac ci si pulisce il :ciapet: Apple non conta nulla come cliente CPU. I Mac anche se in crescita come vendite e in controtendenza con il resto del mercato è comunque una nicchia ristrettissima e non utilizza nemmeno CPU sulle quali intel ha grandi margini. Quindi definirla come più grande cliente di intel è una scemenza.

Che ti devo dire mi dispiace per intel allora....:sofico: :sofico:

Ti prego, mi spieghi perché dalla frase ironica che ho scritto ad ACE te ne sei uscito con questa risposta?
Vorrei capire che collegamento sinaptico hai fatto... mi incuriosisce tremendamente.... :asd: :asd:

Te la riporto

È troppa roba!
Solo te ce la puoi fare!


Che ti devo dire mi dispiace per intel allora....:sofico: :sofico:

Il mio post è abbastanza chiaro e anche i riferimenti alle cose che hai scritto. Se poi hai difficoltà a capire bene l'italiano, mi spiace ,ma non posso aiutarti.

Il mio punto era che il supposto vantaggio degli x86 nei confronti dei RISC non è una cosa che dipende da particolarità dell'architettura x86 e che un RISC può benissimo far vedere i sorci verdi al top degli x86 se progettato con analoghi parametri in termini di consumo massimo, area del chip e costo.

straquoto.

Il mio punto era che il supposto vantaggio degli x86 nei confronti dei RISC non è una cosa che dipende da particolarità dell'architettura x86 e che un RISC può benissimo far vedere i sorci verdi al top degli x86 se progettato con analoghi parametri in termini di consumo massimo, area del chip e costo.

ma senza il vantaggio in termini di consumo, dimensioni e costo, quale resterebbe il vantaggio di ARM? rinunceresti al modesto parco software di Mac OS per cosa?

ma senza il vantaggio in termini di consumo, dimensioni e costo, quale resterebbe il vantaggio di ARM? rinunceresti al modesto parco software di Mac OS per cosa?

Il parco software di Mac OS è per la maggior parte portabile tramite semplice ricompilazione.

Sono ANNI (dalla migrazione da PowerPC ad x86) che Apple sta bene attenta a non restare "bloccata" su una specifica architettura di cpu.
Per questo ad esempio hanno investito su LLVM, hanno spinto per lo sviluppo del compilatore CLang (C/C++/Objective-C) per completarne la toolchain, ecc. ecc.

Idem per Google, Android supporta già ora ARM, x86 e MIPS ed anche le parti in codice nativo possono essere rese portabili tramite selezione automatica delle librerie native, Chrome OS integra pure la compilazione da IL LLVM "portabile" a codice nativo, ecc.

Il grosso vantaggio di un passaggio ad ARM "da server" è lo stesso che hanno i produttori di SoC per dispositivi mobili: maggiori possibiltà di scelta e minori rischi che il produttore del SoC/cpu ti imponga i suoi prezzi o ti costringa ad usare un determinato prodotto perchè non è interessato a realizzare quello che invece per il cliente sarebbe ottimale.

Paradossalmente uno dei grossi problemi che ha avuto Intel per cercare di rientrare nel settore dei dispositivi mobili è stato che era troppo abituata ad imporre prezzo e prodotto.

Il parco software di Mac OS è per la maggior parte portabile tramite semplice ricompilazione.

Sono ANNI (dalla migrazione da PowerPC ad x86) che Apple sta bene attenta a non restare "bloccata" su una specifica architettura di cpu.
Per questo ad esempio hanno investito su LLVM, hanno spinto per lo sviluppo del compilatore CLang (C/C++/Objective-C) per completarne la toolchain, ecc. ecc.

Idem per Google, Android supporta già ora ARM, x86 e MIPS ed anche le parti in codice nativo possono essere rese portabili tramite selezione automatica delle librerie native, Chrome OS integra pure la compilazione da IL LLVM "portabile" a codice nativo, ecc.

Il grosso vantaggio di un passaggio ad ARM "da server" è lo stesso che hanno i produttori di SoC per dispositivi mobili: maggiori possibiltà di scelta e minori rischi che il produttore del SoC/cpu ti imponga i suoi prezzi o ti costringa ad usare un determinato prodotto perchè non è interessato a realizzare quello che invece per il cliente sarebbe ottimale.

Paradossalmente uno dei grossi problemi che ha avuto Intel per cercare di rientrare nel settore dei dispositivi mobili è stato che era troppo abituata ad imporre prezzo e prodotto.

Quindi è in gran parte ricompilabile, fin qui ci siamo... la domanda è: quanto di questo codice verrebbe effettivamente portato?

Quello che dicevo io era: ok, mettiamo caso esca un Mac con ARM, la situazione qual è? Al lancio, avrà molto meno software a disposizione, probabilmente buona parte del nuovo software sarebbe disponibile anche per ARM, ma possiamo dare per scontato che parte del software precedente non verrà portato... e per quale vantaggio? tu stesso hai detto che a parità di consumi (e calore aggiungerei), costo e dimensione sono equivalenti agli x86, quindi a che pro?

Quindi è in gran parte ricompilabile, fin qui ci siamo... la domanda è: quanto di questo codice verrebbe effettivamente portato?

Quello che dicevo io era: ok, mettiamo caso esca un Mac con ARM, la situazione qual è? Al lancio, avrà molto meno software a disposizione, probabilmente buona parte del nuovo software sarebbe disponibile anche per ARM, ma possiamo dare per scontato che parte del software precedente non verrà portato... e per quale vantaggio? tu stesso hai detto che a parità di consumi (e calore aggiungerei), costo e dimensione sono equivalenti agli x86, quindi a che pro?

I primi utilizzatori degli ARM "di fascia alta" molto probabilmente saranno le grosse aziende dotate di server farm, probabilmente con SoC ottimizzati per le loro esigenze.
Nel caso di Apple invece mi aspetto un "iPad per professionisti" con la possibilità di operare in "desktop mode" (compatibile a livello di API con i Mac) abbinato ad una cover-tastiera.
Con un SoC tipo big.LITTLE dove la parte big si attiva solo in modalità desktop.

Ovviamente non a breve.

I primi utilizzatori degli ARM "di fascia alta" molto probabilmente saranno le grosse aziende dotate di server farm, probabilmente con SoC ottimizzati per le loro esigenze.
Nel caso di Apple invece mi aspetto un "iPad per professionisti" con la possibilità di operare in "desktop mode" (compatibile a livello di API con i Mac) abbinato ad una cover-tastiera.
Con un SoC tipo big.LITTLE dove la parte big si attiva solo in modalità desktop.

Ovviamente non a breve.

praticamente una versione ARM di ciò che fanno Windows 8 e i Surface Pro

Nel caso di Apple invece mi aspetto un "iPad per professionisti" con la possibilità di operare in "desktop mode" (compatibile a livello di API con i Mac) abbinato ad una cover-tastiera.
Con un SoC tipo big.LITTLE dove la parte big si attiva solo in modalità desktop.

Ovviamente non a breve.
E a questo scopo è necessario passare ad ARM? Per cosa? Non per avere una migliore efficienza energetica, visto che Bay Trail se la cava egregiamente. Non per ridurre i costi, visti i prezzi a cui Apple è abituata a proporre i suoi dispostivi.

In mancanza di sensibili vantaggi, non ha senso assumersi l'onere di dovere convincere gli sviluppatori di terze parti a portare il loro software su un'architettura diversa (non è detto che basti una semplice ricompilazione).

E a questo scopo è necessario passare ad ARM? Per cosa? Non per avere una migliore efficienza energetica, visto che Bay Trail se la cava egregiamente. Non per ridurre i costi, visti i prezzi a cui Apple è abituata a proporre i suoi dispostivi.

In mancanza di sensibili vantaggi, non ha senso assumersi l'onere di dovere convincere gli sviluppatori di terze parti a portare il loro software su un'architettura diversa (non è detto che basti una semplice ricompilazione).

Esattamente ciò che volevo dire nel post #96

E a questo scopo è necessario passare ad ARM? Per cosa? Non per avere una migliore efficienza energetica, visto che Bay Trail se la cava egregiamente. Non per ridurre i costi, visti i prezzi a cui Apple è abituata a proporre i suoi dispostivi.

In mancanza di sensibili vantaggi, non ha senso assumersi l'onere di dovere convincere gli sviluppatori di terze parti a portare il loro software su un'architettura diversa (non è detto che basti una semplice ricompilazione).

Esattamente ciò che volevo dire nel post #96

Perche in questo modo (a differenza dei Surface) avrebbero un prodotto con un fottio di software gia ottimizzato per esso a livello di prestazioni ed ergonomia (tutte le app gia sviluppate per iPad) ed un fottio di software "desktop" facile da portare su di esso.

Cosa che decisamente non si può dire dei Surface, dove le applicazioni per win32 (ovvero la stragrande maggioranza) bene che vada girano un upscaling solo sui Pro (per la bimbominkiata assurda dei 96dpi) mentre quelle per WinRT sono ancora pochine.

Perche in questo modo (a differenza dei Surface) avrebbero un prodotto con un fottio di software gia ottimizzato per esso a livello di prestazioni ed ergonomia (tutte le app gia sviluppate per iPad) ed un fottio di software "desktop" facile da portare su di esso.

A proposito di questo:
http://www.hwupgrade.it/news/apple/apple-annuncia-mac-os-x-yosemite-nuova-grafica-e-gestione-completa-di-iphone-da-mac_52559.html

Questa maggiore integrazione oltre a tornare utile adesso, torna utile in un ottica a più lungo termine di un dispositivo unico con modalità desktop e tablet.

Perche in questo modo (a differenza dei Surface) avrebbero un prodotto con un fottio di software gia ottimizzato per esso a livello di prestazioni ed ergonomia (tutte le app gia sviluppate per iPad) ed un fottio di software "desktop" facile da portare su di esso.
E per far questo servirebbe
un passaggio ad ARM "da server"
?

E per far questo servirebbe
un passaggio ad ARM "da server"
?

No, ma il prossimo fronte saranno i server, e se anche li ARM avrà successo seguirà la spallata finale.

La spallata finale? Guarda che non è una guerra santa...

Comunque finora ho visto tirare in ballo CPU da server per cercare di far breccia nel mercato desktop, e gente (notizia inclusa) che parla di più CPU, ognuna dotata di più core, sempre per lo stesso motivo.

Se servono così tanti "muscoli" per contrastare ciò che da parecchio tempo Intel mette a disposizione con pochi core, allora può star tranquilla ancora per parecchio tempo. E, inoltre, dimostra ancora una volta che parlare di RISC e CISC ha perfettamente senso...

Il vero motivo per passare ad ARM? Fare una macchina realmente senza ventole... sì esistono gli Atom per "cellulari", ma sono una chiavica... a quel punto, tanto vale, usare ARM, no?

Tu parli di "muscoli", ma per ARM come per il vecchio Motorola 68000 è cosa ovvia e normale averli! Son stati gli X86 che tentarono di fare tutto da "soli" ottenendo 30 anni dopo il risultato di aver creato dei System On Chip come le APU AMD, ma avere tutto "scomposto" è, comunque un vantaggio visto che ti permette di mixare componenti diversi:


Devo fare un cellulare? Co-processore per gestire la parte telefonica, co-processore per gestire la parte multimedia (accelerazione Mpeg2, H264, H265, VC1), co-processore per la geolocalizzazione (un tempo detto "GPS"), co-processore per sensori di movimento, accelerometri, ecc...
Devo fare un player multimediale come le "cinesate" della Futeko? Tolgo la parte telefonica e metto una parte multimedia più "cazz*ta". (Umiliante quando una scatoletta così leggerà un filmato 4K con HEVC e un PC Intel con 8 core da 2.6 Ghz arrancherà :cry: !)
Devo fare un "PC"? Co-processore per calcoli in virgola mobile (roba da uomini veri compresi i Decimal Floating Point... in hardware!), co-processore per gestire la parte multimedia (accelerazione Mpeg2, H264, H265, VC1), co-processore per emulare x86 (impossibile? No, se l'ARM lo fa Intel :Prrr: ), GPU anche NVIDIA coi controcosi...
Devo fare una console da gioco? Co-processore per calcoli in virgola mobile (non Decimal Floating Point, ma Floating Point a 256 Bit sì! O forse si può evitarla e usare direttamente la GPU con CUDA/OpenCL), GPU NVIDIA di alto livello, co-processore per gestire la parte multimedia (accelerazione Mpeg2, H264, H265, VC1), Co-processore per gestire I/O (USB, Rete, Blutooth, ...)
System-on-chip per gestione sistemi realtime: Real Time Process Unit, Co-processore per gestire I/O (Porte USB, 32 seriali RS234/RS422/RS485, fibre ottiche, almeno 2 uscite di rete), co-processore per comunicazione con periferiche "particolari"...


Vedi? Potrei continuare per ore!
Non è detto che si debba iniziare sostituendo tutta la linea, ma per iniziare si può usare ARM per i portatili di "basso" livello, ibridi PC/Tablet cose del genere...

I coprocessori puoi usarli su e per qualunque architettura.

Qui si parlava strettamente dell'architettura, e le differenze fra x86 e ARM (o altri RISC) c'è ed è destinata a rimanere. ;)

@fano: gli atom "per tablet" attuali sono altro che chiaviche, sull'Iconia W510 ho un Clover Trail e mi regge pure Visual Studio 2013, e per quanto ne so Bay Trail è ancora meglio (aspetto di ricevere l'Iconia W4)

@cdimauro
Certo che puoi usare co-processori per qualsiasi architettura! ARM, però, è pensato per questo... è molto più naturale farlo con ARM (come lo era con i vecchi Motorola 68'000), è banale condividere la stessa RAM (cosa AMD sta tentando di fare con APU da anni e solo ora si sta avvicinando), più semplice, infine è programmarli. PS4 che è un X86/64 ha, effettivamente, un co-processore ARM per gestire la Rete (e forse il resto degli I/O?), non è però programmabile per fare altro... per ora :p

Unrealizer, ma com'è la situazione "calore" è freddo come un ARM oppure hai tra le mani un fornetto? Se è la prima lo considero quasi un miracolo!

Unrealizer, ma com'è la situazione "calore" è freddo come un ARM oppure hai tra le mani un fornetto? Se è la prima lo considero quasi un miracolo!

ovviamente con operazioni pesanti scalda, ma non diventa un fornetto... e sia il W510 che il W4 sono fanless ;)

una cosa bella di questi Atom è che supportano Connected Standby, quindi le app e le tile continuano a ricevere notifiche push anche mentre il tablet è in standby

Il vero motivo per passare ad ARM? Fare una macchina realmente senza ventole... sì esistono gli Atom per "cellulari", ma sono una chiavica... a quel punto, tanto vale, usare ARM, no?


no per nulla, i nuovi Atom sono tutt'altro che chiaviche e senza ventola funzionano anche gli ULV core serie Y che si manginao tutti gli ARM che vuoi.
Intel ha gia presentato l'evoluzione su base 14nm, un SOC con architettura core che sara completamente fanless e si rimangera ancora tutti gli arm che vuoi.

http://www.tomshw.it/cont/news/intel-core-m-la-cpu-a-14-nanometri-per-dispositivi-ibridi/56659/1.html

e sono CPU sicuramente migliori per un computer con un vero OS.

@cdimauro
Certo che puoi usare co-processori per qualsiasi architettura! ARM, però, è pensato per questo... è molto più naturale farlo con ARM (come lo era con i vecchi Motorola 68'000),
Era, un tempo, quando i coprocessori erano chip separati dalla CPU, e servivano meccanismi per semplificare la comunicazione fra i due elementi, ove la CPU aveva il ruolo Centrale, per l'appunto, e metteva a disposizione un po' di logica generale per i vari coprocessori.

Ormai i cosiddetti coprocessori sono integrati nel core (FPU, SIMD), o comunque fanno parte del SoC, per cui viene meno l'esigenza del protocollo dei coprocessori.

Tant'è che in ARMv8... è sparito: bye bye coprocessori. Istruzioni general purpose, dell'FPU, dell'unità SIMD o di qualunque altra unità specializzata si mappano normalmente nella opcode table, esattamente come avviene da tempo per x86 (con l'eccezione dell'FPU, per la quale furono riservati i famigerati opcode di "escape"), recuperando prezioso spazio (la opcode table, pur essendo a 32 bit, non è illimitata).
è banale condividere la stessa RAM (cosa AMD sta tentando di fare con APU da anni e solo ora si sta avvicinando),
Questo è compito del memory controller / arbiter. Non serve il protocollo dei coprocessori.
più semplice, infine è programmarli.
Non vedo come.
PS4 che è un X86/64 ha, effettivamente, un co-processore ARM per gestire la Rete (e forse il resto degli I/O?), non è però programmabile per fare altro... per ora :p
Non ho presente il motivo per cui sia stato inserito questo processore ARM nella PS4, ma rientra nella logica di cui sopra: fa parte del SoC.

Il concetto di coprocessore, quindi, è anacronistico. E te lo dice uno che lo ha apprezzato particolarmente ai tempi dei 68K. Ma di questi tempi non ha più senso...

no per nulla, i nuovi Atom sono tutt'altro che chiaviche e senza ventola funzionano anche gli ULV core serie Y che si manginao tutti gli ARM che vuoi.
Intel ha gia presentato l'evoluzione su base 14nm, un SOC con architettura core che sara completamente fanless e si rimangera ancora tutti gli arm che vuoi.

http://www.tomshw.it/cont/news/intel-core-m-la-cpu-a-14-nanometri-per-dispositivi-ibridi/56659/1.html

e sono CPU sicuramente migliori per un computer con un vero OS.
Non so se sia appropriato usare il tempo futuro, visto che ormai un tablet ibrido fanless con Intel Core è già stato annunciato ufficialmente da Asus (ne ha parlato anche la redazione qui (http://www.hwupgrade.it/news/portatili/transformer-book-t300-chi-il-notebook-e-tablet-senza-ventola_52553.html)).

Non solo un Atom non è una chiavica e compete dignitosamente con i SoC ARM, ma secondo me questo Core M li asfalta proprio. :D

Riguardo alla storia ARM + Console, anche il Wii aveva un ARM9 nello stesso package della GPU, veniva utilizzato per la sicurezza e l'I/O... magari PS4 lo usa per le stesse cose + connessione al PSN mentre la console è offline per scaricare update, giochi, notizie ecc ecc?

E' plausibile. Anche perché non serve una grossa potenza di calcolo, e i consumi di un piccolo core ARM come quello sono molto bassi.

La spallata finale? Guarda che non è una guerra santa...

?????
Guerra santa ?
Semplicemente espansione in differenti settori.
Il settore in cui gli x86 sono più forti è ancora quello desktop/notebook (a causa dei vincoli di retrocompatibilità), quindi è prevedibile che sarà l'ultimo ad essere attaccato.


Comunque finora ho visto tirare in ballo CPU da server per cercare di far breccia nel mercato desktop, e gente (notizia inclusa) che parla di più CPU, ognuna dotata di più core, sempre per lo stesso motivo.

Se servono così tanti "muscoli" per contrastare ciò che da parecchio tempo Intel mette a disposizione con pochi core, allora può star tranquilla ancora per parecchio tempo. E, inoltre, dimostra ancora una volta che parlare di RISC e CISC ha perfettamente senso...

Il motivo è che i primi chip basati su ARM "pensati per avere prioritariamente maggiori prestazioni" saranno quelli per server, quelli forniranno un idea più precisa di cosa possono fare gli ARM "in termini di forza bruta" in implementazioni reali con un adeguata infrastruttura di supporto
(tipo ad esempio CCN-508 (http://www.arm.com/products/system-ip/interconnect/corelink-ccn-508.php) ).

Il settore in cui gli x86 sono più forti è ancora quello desktop/notebook (a causa dei vincoli di retrocompatibilità), quindi è prevedibile che sarà l'ultimo ad essere attaccato.
I chip ARM non stanno attaccando un bel niente
Solo che nel settore server c' è spazio per espandersi per gli ARM tanto più che i rapporti consumi, costi e potenza in questo ambito non sono così fondamentali come invece nel settore PC
I vecchi Alpha ormai hanno tirato le cuoia, Itanium boccheggia, Sparc vende il suo T4 a 40 nm e IBM il Power 7 a 45 nm ( dovrebbe arrivare finalmente il Power 8 a 22 nm quest' estate, forse ... )
Di fronte a questi dinosauri gli ARM sono competitivi, ma quando si passa ai processori per PC la concorrenza è molto più agguerrita ...


Il motivo è che i primi chip basati su ARM "pensati per avere prioritariamente maggiori prestazioni" saranno quelli per server, quelli forniranno un idea più precisa di cosa possono fare gli ARM "in termini di forza bruta" in implementazioni reali con un adeguata infrastruttura di supporto
(tipo ad esempio CCN-508 (http://www.arm.com/products/system-ip/interconnect/corelink-ccn-508.php) ).
Resta il problema del divario tecnologico tra Intel e ARM, nei server i costi sono un parametro poco importante, nei PC è fondamentale e competere con tecnologie più vecchie rispetto alla concorrenza è impossibile.

Se nel campo server c' è competizione è "colpa" di Intel, che non ha mai spinto gli x86 in quel settore, gli Xeon sono giusti per mettere su qualche serverino, ma quando ti servono parecchie cpu devi rivolgerti ad altro.
D' altra parte il margine sulle CPU desktop è ridicolo rispetto a quello che Intel si mangia su un Itanium ed è chiaro che sia restia a portare dei processori su cui ci mangia ( relativamente ) poco in un settore dove ha già una CPU su cui ha dei margini enormemente superiori.
Chissà che il fallimento imminente del progetto Itanium non li convinca al grande passo, è indubbio che un cluster su x86 avrebbe costi enormemente inferiori alla concorrenza a parità di potenza.

I chip ARM non stanno attaccando un bel niente

L'attacco lo stanno facendo i produttori di chip ARM. ;)

Solo che nel settore server c' è spazio per espandersi per gli ARM tanto più che i rapporti consumi, costi e potenza in questo ambito non sono così fondamentali come invece nel settore PC
I vecchi Alpha ormai hanno tirato le cuoia, Itanium boccheggia, Sparc vende il suo T4 a 40 nm e IBM il Power 7 a 45 nm ( dovrebbe arrivare finalmente il Power 8 a 22 nm quest' estate, forse ... )
Di fronte a questi dinosauri gli ARM sono competitivi, ma quando si passa ai processori per PC la concorrenza è molto più agguerrita ...

L'espansione sui server probabilmente colpirà per prima Intel, per il semplice motivo che mentre gli altri chip sono legati principalmente ad un singolo produttore che li usa direttamente per i suoi prodotti (HP per gli Itanium grazie al ferreo contratto a suo favore stipulao con Intel, Oracle per gli Sparc, IBM per i POWER), tutti gli altri ormai non è che siano così contenti del ricarico che Intel mette sui suoi chip visto che di fatto è l'unico fornitore a cui possono rivolgersi.


Se nel campo server c' è competizione è "colpa" di Intel, che non ha mai spinto gli x86 in quel settore, gli Xeon sono giusti per mettere su qualche serverino, ma quando ti servono parecchie cpu devi rivolgerti ad altro.

In realtà Intel ci ha provato più e più volte, solo che più un la delle cpu non riesce ad andare mentre sui server conta il sistema complessivo, per questo con gli Itanium si è legata (pure troppo visto che è costretta a produrli e supportarli ancora) con HP.

Per questo gli ARM ora che hanno anche un architettura a 64bit e relative macrocelle per implementare il resto di un chip "da server ad alte prestazioni" sono così interessanti visto che aprono la possibilità di farsi produrre SoC "su misura per i server" senza più dipendere da un unico fornitore.
Google sta già lavorando su qualcosa di simile (non è detto che poi li produrranno, ma si tengono aperta tale possibilità se non altro per far pressione su Intel riguardo i prezzi) ed anche altri probabilmente ci stanno pensando, anche AMD ha fiutato l'opportunità ed ha annunciato prima l'uscita di chip basati su core "standard" A57 a cui seguiranno quelli basati su nuovo core progettato/ottimizzato da loro.

Se nel campo server c' è competizione è "colpa" di Intel, che non ha mai spinto gli x86 in quel settore, gli Xeon sono giusti per mettere su qualche serverino, ma quando ti servono parecchie cpu devi rivolgerti ad altro.
D' altra parte il margine sulle CPU desktop è ridicolo rispetto a quello che Intel si mangia su un Itanium ed è chiaro che sia restia a portare dei processori su cui ci mangia ( relativamente ) poco in un settore dove ha già una CPU su cui ha dei margini enormemente superiori.
Chissà che il fallimento imminente del progetto Itanium non li convinca al grande passo, è indubbio che un cluster su x86 avrebbe costi enormemente inferiori alla concorrenza a parità di potenza.


ma cosa stai dicendo ?

nella lista dei TOP 500 Supercomputer il 79,2%, settantanove, sono Xeon delle fasce media, di cui ben il 68% sono gli ultimi Xeon E5 V1 e V2; il primo nella lista ha 32.000 Xeon...

L'unica fascia dove Intel ha spinto poco con l'X86 è quella Mission Critical dove operava con Itanium che ora verra rimpiazzata in toto dalla serie Xeon E7.

Lo spiraglio che si è venuto a creare per le CPU ARM è dato solo dal ritardo mostruoso che Intel ha accumulato con l'architettura Atom Bay Trail rispetto alle precedenti, motivo per il quale ha accellerato; quest'anno arriveranno i nuovi Atom 14nm che molto probabilmente taglieranno le gambe alle CPU ARM che, gia ora, vedendo quelle presentate da AMD , non reggono il confronto con gli Xeon Bay Trail.

ma cosa stai dicendo ?

nella lista dei TOP 500 Supercomputer il 79,2%, settantanove, sono Xeon delle fasce media, di cui ben il 68% sono gli ultimi Xeon E5 V1 e V2; il primo nella lista ha 32.000 Xeon...

Lascia stare i supercomputer che sono creature piuttosto particolari, con HW e OS custom e funzionalità spesso dedicate a un singolo compito.
Intel non ha mai spinto veramente gli XEON nel campo server e spesso ha volutamente "castrato" le possibilità dei processori desktop in questo settore sia tralasciando volutamente di implementare tecnologie sia evitando di chiedere a Microsoft di sviluppare prodotti dedicati.


L'espansione sui server probabilmente colpirà per prima Intel, per il semplice motivo che mentre gli altri chip sono legati principalmente ad un singolo produttore che li usa direttamente per i suoi prodotti (HP per gli Itanium grazie al ferreo contratto a suo favore stipulao con Intel, Oracle per gli Sparc, IBM per i POWER), tutti gli altri ormai non è che siano così contenti del ricarico che Intel mette sui suoi chip visto che di fatto è l'unico fornitore a cui possono rivolgersi.
Tutti gli altri ... chi ?
I minicomputer in giro sono HP ( Itanium ), IBM ( Power ) e Sun ( Sparc ).

?????
Guerra santa ?
Semplicemente espansione in differenti settori.
Espansione? Scusami, ma "spallata finale" non mi dà l'idea di "espansione", quanto di "eliminazione"... dell'avversario.
Il settore in cui gli x86 sono più forti è ancora quello desktop/notebook (a causa dei vincoli di retrocompatibilità), quindi è prevedibile che sarà l'ultimo ad essere attaccato.
Anche perché c'è parecchio software x86/x64, che difficilmente verrà convertito per ARM. E ARM è tutt'altro che tagliata per l'emulazione di architetture complesse come queste.
Il motivo è che i primi chip basati su ARM "pensati per avere prioritariamente maggiori prestazioni" saranno quelli per server, quelli forniranno un idea più precisa di cosa possono fare gli ARM "in termini di forza bruta" in implementazioni reali con un adeguata infrastruttura di supporto
(tipo ad esempio CCN-508 (http://www.arm.com/products/system-ip/interconnect/corelink-ccn-508.php) ).
Anche Intel sta lavorando in questa direzione, ma dalla sua ha il vantaggio di prestazioni migliori su single core/thread. Per non parlare poi per le prestazioni dell'unità SIMD, che in futuro miglioreranno ulteriormente.

Questi sono fattori da non sottovalutare, e che NON sono destinati a cambiare, perché riflettono i limiti delle due (molto) diverse architetture.
Basti vedere anche l'A7 di Apple: per riuscire ad avere buone prestazioni devono decodificare e inviare alle unità di calcolo ben SETTE istruzioni per ciclo di clock.
Per confronto, i top di gamma di Intel ne decodificano al massimo 4, con diverse limitazioni, e hanno eccellenti prestazioni. Mentre per il settore mobile soluzioni con 2 soli decoder / dispatcher (sempre per ciclo di clock) come BayTrail riescono ad avere mediamente la meglio; e questo senza nemmeno avere a disposizione le unità SIMD più moderne, come AVX/2.

Inoltre, come dicevo prima, puoi mettere quanti core vuoi, ma non puoi pensare di parallelizzare ad libidum le prestazioni allo stesso modo; tutt'altro.
I chip ARM non stanno attaccando un bel niente
Solo che nel settore server c' è spazio per espandersi per gli ARM tanto più che i rapporti consumi, costi e potenza in questo ambito non sono così fondamentali come invece nel settore PC
I vecchi Alpha ormai hanno tirato le cuoia, Itanium boccheggia, Sparc vende il suo T4 a 40 nm e IBM il Power 7 a 45 nm ( dovrebbe arrivare finalmente il Power 8 a 22 nm quest' estate, forse ... )
Di fronte a questi dinosauri gli ARM sono competitivi, ma quando si passa ai processori per PC la concorrenza è molto più agguerrita ...
Ma nemmeno tanto dinosauri. I PowerPC hanno sempre avuto prestazioni superiori agli ARM, su single core/thread. E proprio Google, che è stata citata riguardo agli ARM, di recente ha presentato una scheda madre basata su POWER 8 (se non ricordo male).

Per il resto sostanzialmente concordo.
Se nel campo server c' è competizione è "colpa" di Intel, che non ha mai spinto gli x86 in quel settore, gli Xeon sono giusti per mettere su qualche serverino, ma quando ti servono parecchie cpu devi rivolgerti ad altro.
D' altra parte il margine sulle CPU desktop è ridicolo rispetto a quello che Intel si mangia su un Itanium ed è chiaro che sia restia a portare dei processori su cui ci mangia ( relativamente ) poco in un settore dove ha già una CPU su cui ha dei margini enormemente superiori.
Chissà che il fallimento imminente del progetto Itanium non li convinca al grande passo, è indubbio che un cluster su x86 avrebbe costi enormemente inferiori alla concorrenza a parità di potenza.
La convergenza fra mondo Itanium e Xeon è in atto già da tempo, ma finché rimarrà la linea Itanium IMO non assisteremo a repentini cambiamenti sul fronte Xeon. Questo è un mio personalissimo pensiero, sia chiaro.
L'attacco lo stanno facendo i produttori di chip ARM. ;)
Finché non ci saranno grossi nomi in ambito server a vendere soluzioni ARM, io tutto questo attacco non riesco a vederlo. Per cui concordo, ancora una volta, con quanto ha poi scritto Cfranco.
L'espansione sui server probabilmente colpirà per prima Intel, per il semplice motivo che mentre gli altri chip sono legati principalmente ad un singolo produttore che li usa direttamente per i suoi prodotti (HP per gli Itanium grazie al ferreo contratto a suo favore stipulao con Intel, Oracle per gli Sparc, IBM per i POWER), tutti gli altri ormai non è che siano così contenti del ricarico che Intel mette sui suoi chip visto che di fatto è l'unico fornitore a cui possono rivolgersi.
E la differenza con le altre soluzioni ARM quale sarebbe? Almeno Intel ti offre una piattaforma abbastanza stabile.

Prova a chiedere a Linus Torvalds cosa ne pensa della moltitudine di piattaforme ARM per le quali serve specifico supporto, visto che ognuna di esse praticamente è un mondo a sé stante.

Un esempio pratico lo fornisci tu stesso col CCN-508. Se ti affidi a questa piattaforma, e decidi poi di voler cambiare, chi ti riesce a fornire una soluzione "compatibile" che consente un passaggio indolore?
In realtà Intel ci ha provato più e più volte, solo che più un la delle cpu non riesce ad andare mentre sui server conta il sistema complessivo, per questo con gli Itanium si è legata (pure troppo visto che è costretta a produrli e supportarli ancora) con HP.
Mi pare che fosse HP a esser costretta a supportare Itanium, a causa dei precedenti accordi.
Per questo gli ARM ora che hanno anche un architettura a 64bit e relative macrocelle per implementare il resto di un chip "da server ad alte prestazioni" sono così interessanti visto che aprono la possibilità di farsi produrre SoC "su misura per i server" senza più dipendere da un unico fornitore.
Vedi sopra: ti leghi ugualmente a un produttore.

Poi tutte queste personalizzazioni del core ARM le verrei vedere. Finora noto soltanto SoC basati sullo stesso core licenziato da ARM. Parlo a livello server, ovviamente, ma anche su mobile sono pochi i produttori di chip ARM che offrono una loro, personale, implementazione.
Google sta già lavorando su qualcosa di simile (non è detto che poi li produrranno, ma si tengono aperta tale possibilità se non altro per far pressione su Intel riguardo i prezzi)
Per Google vedi la mia risposta a Cfranco.
ed anche altri probabilmente ci stanno pensando, anche AMD ha fiutato l'opportunità ed ha annunciato prima l'uscita di chip basati su core "standard" A57 a cui seguiranno quelli basati su nuovo core progettato/ottimizzato da loro.
Ottimizzato dove, scusa? E' un core inserito in un loro SoC, ma non mi pare di aver visto alcun cambiamento all'implementazione del core ARM.