Apple al lavoro su iMac e MacBook basati su architettura ARM

[cdimauro]

Originariamente inviato da Raghnar-The coWolf-

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.

[Cfranco]

Originariamente inviato da Raghnar-The coWolf-

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.

Originariamente inviato da cdimauro

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.

[cdimauro]

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.

[AlexSwitch]

Originariamente inviato da cdimauro

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.

[LMCH]

Originariamente inviato da Cfranco

Oddio
Quando proponi sistemi con 64 CPU e 256 Gb di ram fai presto a prendere a schiaffoni qualsiasi PC x86
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

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.

[LMCH]

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

Originariamente inviato da cdimauro

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.

[cdimauro]

Originariamente inviato da AlexSwitch

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 a riguardo.

[cdimauro]

Originariamente inviato da LMCH

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.

Originariamente inviato da LMCH

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.

[fano]

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).

[Cfranco]

Originariamente inviato da LMCH

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

Originariamente inviato da LMCH

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 ?

[cdimauro]

Originariamente inviato da fano

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.

[cdimauro]

Originariamente inviato da Cfranco

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.

[Unrealizer]

Originariamente inviato da domthewizard

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

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

Originariamente inviato da AlexSwitch

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)

Originariamente inviato da recoil

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

Originariamente inviato da domthewizard

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

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

Originariamente inviato da Littlesnitch

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?

Originariamente inviato da calabar

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

Originariamente inviato da massimo79m

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

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?

Originariamente inviato da fano

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

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

[cdimauro]

Originariamente inviato da Unrealizer

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

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 ).

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

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

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.

[Vash_85]

Originariamente inviato da AceGranger

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

[cdimauro]

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

[AceGranger]

Originariamente inviato da cdimauro

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

[Littlesnitch]

Originariamente inviato da Unrealizer

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?

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ù.

[Unrealizer]

Originariamente inviato da Littlesnitch

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 è che ti ho visto citare la tua esperienza su diverse macchine in diversi post

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...

[Vash_85]

Originariamente inviato da cdimauro

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?