Apple al lavoro su iMac e MacBook basati su architettura ARM

[Vash_85]

Originariamente inviato da AceGranger

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

Direi quasi un ignoranza da peccato capitale.... 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...
Grazie!

[AceGranger]

Originariamente inviato da Vash_85

Direi quasi un ignoranza da peccato capitale.... 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...
Grazie!

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

[Vash_85]

Originariamente inviato da AceGranger

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

È troppa roba!
Solo te ce la puoi fare!

[fano]

Originariamente inviato da Unrealizer

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

Originariamente inviato da Unrealizer

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

Mica detto sia obbligatorio parlare di store (che poi sono i repository di Linux... fatti bene ), 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

Originariamente inviato da Unrealizer

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

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ù

[Littlesnitch]

Originariamente inviato da Unrealizer

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

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.

[Littlesnitch]

Originariamente inviato da Vash_85

È troppa roba!
Solo te ce la puoi fare!

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

Originariamente inviato da Vash_85

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

[Unrealizer]

Originariamente inviato da fano

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

.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 .NET è invece vivo e presente, anche su RT

Mica detto sia obbligatorio parlare di store (che poi sono i repository di Linux... fatti bene ), 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

l'architettura è indicata nell'useragent del browser comunque, facendolo a Runtime perdi tutto il vantaggio della compilazione AOT 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 trovi i due video che spiegano il funzionamento di MDIL e .NET Native, è abbastanza affascinante (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ù

forse mi sono spiegato male 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 se poi a correggermi è un esperto dell'argomento come lui, ci penso un'altra volta ancora

Originariamente inviato da Littlesnitch

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

[LMCH]

Originariamente inviato da cdimauro

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.

[cdimauro]

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

[Littlesnitch]

Originariamente inviato da Unrealizer

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

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

[Vash_85]

Originariamente inviato da Littlesnitch

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

Te la riporto

È troppa roba!
Solo te ce la puoi fare!

Originariamente inviato da Littlesnitch

Intel con le CPU che vende per i Mac ci si pulisce il 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....

[Littlesnitch]

Originariamente inviato da Vash_85

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

Te la riporto

È troppa roba!
Solo te ce la puoi fare!


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

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.

[massimo79m]

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.

straquoto.

[Unrealizer]

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.

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?

[LMCH]

Originariamente inviato da Unrealizer

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.

[Unrealizer]

Originariamente inviato da LMCH

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?

[LMCH]

Originariamente inviato da Unrealizer

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.

[Unrealizer]

Originariamente inviato da LMCH

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

[litocat]

Originariamente inviato da LMCH

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

[Unrealizer]

Originariamente inviato da litocat

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