Google Books, pace con gli editori

Interessante ma...
Articolo interessante, ma la parte finale sull'emulatore x86 non è molto chiara. Dalla frase sembra di capire che lo sviluppino per ovviare ai problemi di performance, e che abbiano raggiunto il 40% di quelle originali.In realtà lo scopo è legato alla compatibilità delle applicazioni. Il 40% si riferisce alla performance che si avrebbe se l'applicazione fosse nativa per ARM.

... ma l'efficienza computazionale?
Le cpu ARM, hanno dalla loro certamente l'efficienza energetica, ma rispetto alla controparte Atom di Intel sono ancora (e continueranno ad esserlo per un bel pò) in netto ritardo per quanto riguarda quella prestazionale. Per quanto riguarda il lavoro svolto da Elbrus Tech credo che per ottenere il risultato voluto, cioè l'emulazione di un set di istruzioni ben differente, abbiano di certo la necessità di introdurre un qualcosa simile ad un traduttore di codice binario; questo non potrà produrre se non un livello aggiuntivo di inefficienza. Non so, forse alla Elbrus sono in vena di perdite di tempo (e denaro).

Re: ... ma l'efficienza computazionale?
- Scritto da: Totocellux> Le cpu ARM, hanno dalla loro certamente> l'efficienza energetica, ma rispetto alla> controparte Atom di Intel sono ancora (e> continueranno ad esserlo per un bel pò) in netto> ritardo per quanto riguarda quella prestazionale.Quello che conta nelle server farm sono le performance/watt. E gli ARM sono nettamente superiori agli Intel in quello. Tempo 2-3 anni domineranno il settore server. È inevitabile.

Re: ... ma l'efficienza computazionale?
- Scritto da: MacGeek> - Scritto da: Totocellux> > Le cpu ARM, hanno dalla loro certamente> > l'efficienza energetica, ma rispetto alla> > controparte Atom di Intel sono ancora (e> > continueranno ad esserlo per un bel pò) in> netto> > ritardo per quanto riguarda quella> prestazionale.> > Quello che conta nelle server farm sono le> performance/watt. E gli ARM sono nettamente> superiori agli Intel in quello. Tempo 2-3 anni> domineranno il settore server. È> inevitabile.Possono anche consumare un quarto, ma se es. ci mettono 10 volte tanto tempo a fare la stessa operazione, non vedo un grosso guadagno o no?

Re: ... ma l'efficienza computazionale?
- Scritto da: atem> - Scritto da: MacGeek> > - Scritto da: Totocellux> > > Le cpu ARM, hanno dalla loro certamente> > > l'efficienza energetica, ma rispetto> alla> > > controparte Atom di Intel sono ancora (e> > > continueranno ad esserlo per un bel pò)> in> > netto> > > ritardo per quanto riguarda quella> > prestazionale.> > > > Quello che conta nelle server farm sono le> > performance/watt. E gli ARM sono nettamente> > superiori agli Intel in quello. Tempo 2-3> anni> > domineranno il settore server. È> > inevitabile.> Possono anche consumare un quarto, ma se es. ci> mettono 10 volte tanto tempo a fare la stessa> operazione, non vedo un grosso guadagno o> no?Quindi non hai capito la parte che diceva: performance/watt

Re: ... ma l'efficienza computazionale?
la lol 2-3... avessi detto 20-30 ancora ancora... alla intel mica sono scemi stanno lavorand di brutto sull'efficenza e hanno molte più risorse di arm- Scritto da: MacGeek> - Scritto da: Totocellux> > Le cpu ARM, hanno dalla loro certamente> > l'efficienza energetica, ma rispetto alla> > controparte Atom di Intel sono ancora (e> > continueranno ad esserlo per un bel pò) in> netto> > ritardo per quanto riguarda quella> prestazionale.> > Quello che conta nelle server farm sono le> performance/watt. E gli ARM sono nettamente> superiori agli Intel in quello. Tempo 2-3 anni> domineranno il settore server. È> inevitabile.

Re: ... ma l'efficienza computazionale?
- Scritto da: orcoiPoD> la lol 2-3... avessi detto 20-30 ancora ancora...> alla intel mica sono scemi stanno lavorand di> brutto sull'efficenza e hanno molte più risorse> di armPerò Intel è sola e contro ha il MONDO.Guarda solo cosa è riuscita a fare Apple con l'A6.Un proXXXXXre il doppio (almeno) più efficiente dell'ARM di prossima generazione che deve ancora uscire (il Cortex A15). Ad Intel va di lusso che ad Apple i server non interessano...

Re: ... ma l'efficienza computazionale?
- Scritto da: MacGeek> Quello che conta nelle server farm sono le> performance/watt. E gli ARM sono nettamente> superiori agli Intel in quello. Tempo 2-3 anni> domineranno il settore server. È> inevitabile.eh già. Dimmi una cosa: conosci bene la faccenda perchè lavori in una di suddette farm o parli solo per sentito dire?E se ti dicessi che attualmente un sistema equipaggiato con Core i7 3770K, oltre a vincere in prestazioni ed efficienza performance/watt, costerebbe anche meno della soluzione composta da una configurazione cluster di sei boards che utilizzano ognuna un ARM Cortex-A9 dual-core a 1.2GHz, cosa risponderesti? :)- Scritto da: MacGeek> Tempo 2-3 anni> domineranno il settore server. È> inevitabile.Continui a vivere nel mondo dei sogni. Se ti piace proprio, fa pure. :)

Re: ... ma l'efficienza computazionale?
- Scritto da: Totocellux> - Scritto da: MacGeek> E se ti dicessi che attualmente un sistema> equipaggiato con Core i7 3770K, oltre a vincere> in prestazioni ed efficienza performance/watt,> costerebbe anche meno della soluzione composta da> una configurazione cluster di sei boards che> utilizzano ognuna un ARM Cortex-A9 dual-core a> 1.2GHz, cosa risponderesti?Che ancora è presto, ma dagli 2-3 anni e il tuo Intel non ha speranza.

Re: ... ma l'efficienza computazionale?
Ahahah hai dato al tuo interlocutore dell'ignorante nel campo delle applicazioni server e poi gli presenti il confronto con l'i7 3370K che è una CPU per applicazione desktop/workstation...Dovevi fare il confronto con gli Xeon.Comunque l'i7 che hai nominato da solo costa 300 al dettaglio.Gli ARM cortex A9 1,2Ghz dual core costano all'ingrosso sotto i $10.Con la cifra dell'i7 ci metti 16 Cortex A9 in parallelo per un totale di 32 core ed hai un consumo ancora inferiore all'i7 che hai nominato.Al prezzo dell'i7 che hai nominato ci prendi un'intera board con 16 Cortex A9 dual core.

Re: ... ma l'efficienza computazionale?
- Scritto da: Totocellux> Le cpu ARM, hanno dalla loro certamente> l'efficienza energetica, ma rispetto alla> controparte Atom di Intel sono ancora (e> continueranno ad esserlo per un bel pò) in netto> ritardo per quanto riguarda quella prestazionale.> performance/watt rappresentano proprio l'efficienza computazionaleARM ha avuto solo clienti embedded e mobile ( da qualche anno ) l'architettura AArch64 è indirizzata specificamente ai segmenti server e workstation e l'arrivo di windows rt li porterà pure su pcquindi non è che arm non sa fare proXXXXXri potenti, è che il mercato in cui ha operato fino ad oggi, richiedeva proXXXXXri parchi nei consumi> differente, abbiano di certo la necessità di> introdurre un qualcosa simile ad un traduttore di> codice binario; questo non potrà produrre se non> un livello aggiuntivo di inefficienza.quella dell'emulatore x86 è una XXXXXXX colossaleemulare un'architettura che si porta dietro un bagaglio di tecnologie legacy, è una scempiaggine pura e semplice> Non so, forse alla Elbrus sono in vena di perdite> di tempo (e> denaro).ognuno è libero di fare ciò che crede, magari troveranno mercati nelle soluzioni cloud, dove c'è tanta potenza di calcolo da sfruttare e la necessità di far girare applicazioni x86

Re: ... ma l'efficienza computazionale?
- Scritto da: collione> quella dell'emulatore x86 è una XXXXXXX colossale> > emulare un'architettura che si porta dietro un> bagaglio di tecnologie legacy, è una scempiaggine> pura e> sempliceAlla apple l'hanno già fatto due volte e non mi sembra siano messi così male

Re: ... ma l'efficienza computazionale?
apple ha fatto l'emulazione power-x86, ovvero un'architettura efficiente emulata su un'altra architettura

Re: ... ma l'efficienza computazionale?
Andiamo per ordine.> esatto, infatti la storia è la seguente> ARM era l'unica ( ed è ancora a quanto ne so ) ad offrire performance/watt superiori a tutti gli altri e per> questo motivo è stata, da sempre, scelta per i sistemi che necessitano di bassi consumi e bassi tdpsi, ma non si può negare che al contempo quesi sistemi presentavano anche relativamente basse capacità elaborative. Il quid è che tale circostanza non ha mai rappresentato un vero e proprio fattore negativo per le esigenze di quei sistemi, e proprio a motivo di ciò non si è mai presentato un vero e proprio punto di frattura che ne giungesse a comprometterne la continuità a livello concettuale.> sul fronte server mancava la potenza bruta ed è il motivo per cui ARM ha lanciato ( non è ancora in commercio per > la precisione ) l'architettura AArch64, che colmerà le lacune sul fronte delle pipeline multiple, aggressiva > parallelizzazione nell'esecuzione delle istruzioni, ecc.... insomma tutte le cose che gli x86 hanno> il tutto però conservando sempre un migliori rapporto performance/watt rispetto agli x861) se ARM ha aggiunto degli elementi di differenziazione dal vecchio progetto, non credi che potrebbero sussistere ora, col nuovo, le concrete probabilità che possa esser cambiato anche qualcosa sul fronte consumi?2) se non è ancora definitivamente in commercio una soluzione completa, definitiva e omnicomprensiva, come facciamo a conoscerne, direttamente e nel dettaglio, gli effettivi consumi? 3) è davvero così certo che la nuova architettura sarà riuscita a colmare quelle lacune prestazionali così in fretta? Secondo me servirà decisamente più tempo .... e nel frattempo Intel continuerà a far bene quello che sa fare meglio.> l'altro vantaggio di ARM è che si possono creare SoC con i più disparati coproXXXXXri integrati, per accelerare > carichi particolari da workstation o server ( tipo calcolo parallelo massiccio, elaborazioni vettoriali su grandi > matrici, ecc... ) in ultimo si possono realizzare soluzioni veramente manycore ( roba da 128 e passa core per ogni chip ) per > accelerare reti neurali, algoritmi per l'IA e compagniaForse avresti dovuto usare il condizionale: "si potrebbero creare SoC", "si potrebbero realizzare soluzioni manycore". Certamente sarebbe un'alternativa pur sempre positiva che quantomeno porterebbe ad un relativo calo dei prezzi. Staremo a vedere, ottimisticamente, cosa ne uscirà fuori in futuro.> dipende da cosa intendi> le cpu ARM non hanno un massiccio numero di ALU, pipeline e quant'altro, tipico invece delle soluzioni x86> ma ARM permette d'integrare chip ad-hoc per certi carichi di lavoro, ad esempio Tegra è una soluzione gpgpu eccellenteSenza stare lì troppo a tecnicizzare, è semplice finalizzare un progetto e al contempo, imho, anche molto complesso portare a termine un prodotto per creare delle analoghe soluzioni gpgpu ad hoc, al di fuori dal mercato delle workstation dedicate.> sulle performance/watt e i costi contribuisce al 90% il fatto che si tratta di board ARM multiple> ma usare un'unica board con chip come quelli della Tilera, permettere di ottemere performance/watt e i costi migliori di x861) finora il concetto cluster multi-board è stato l'unico ad essere largamente abbracciato dai costruttori sinora dedicatisi a soluzioni ARM: un motivo dovrà pur esserci.2) Tilera, per ammissione del proprio management aziendale, sembra interessata al solo mercato networking: il target dei loro prodotti sono per lo più gli apparati di rete e di video-comunicazione. Insomma conoscono bene, in positivo e negativo, le proprie potenzialità; del resto, tralasciando la tecnologia costruttiva a 90nm. Il solo fatto di poter utilizzare nel loro progetto trainante (il TILE-Pro64) un solo controller di memoria (DDR2) ogni 16 proXXXXXri e soprattutto sole due interfacce PCI-E (4 linee ciascuna) di prima generazione, la dice lunga sul target del progetto e in definitiva anche del prodotto.> è l'implementazione che è sbagliata, ma sul fronte ARM ci sono architetture manycore efficientissime> il problema è che fino ad oggi si è puntato ad usare il clustering piuttosto che questi SoC specializzatiE' stata la realtà del mercato a determinare come sia relativamente più semplice utilizzare una soluzione in clustering; al momento è quella largamente più affidabile rispetto a quelle semi-custom adottate da tutte quelle piccole aziende.Ricordiamoci che è in assoluto l'affidabilità del sistema completo a ricoprire il criterio di scelta decisamente più importante che conduce all'acquisto delle macchine in ambito server: questo concetto, entro certi termini, ha anche più importanza dell'efficienza energetica stessa. Se pensiamo a quanto può arrivare a costare un fermo macchina, non è poi così difficile crederlo. E' ovvio, se dovessero coesistere entrambe, allora quella sarebbe la soluzione ottimale da intraprendere.Fintantochè una tecnologia del genere non diventerà matura abbastanza, e cioè fin quando i grandi produttori di server mainboard non la seguiranno anima e corpo, non potrà essere largamente adottata da chi investe soprattutto sull'affidabilità di esercizio.> l'idea di base è di battere intel proprio sul suo terrenoesatto, al momento può esser considerata più che altro solo una idea, apprezzabile, ma nel breve-medio periodo la vedo solo parzialmente concretizzabile.Quello che si dimentica o tralascia facilmente facendo questi parallelismi è che l'efficienza e l'efficacia di una soluzione completa va vista anche alla luce delle performance a valle dei chipset, quindi capacità di I/O lato memorie e lato storage. Ti posso garantire che da questo punto di vista il lavoro svolto dai chipset Intel non ha assolutamente dei veri rivali.> storicamente le implementazioni ARM sono state sempre più efficienti di quelle x86, non vedo perchè quest'ultima non debba eserloproprio perchè, fondamentalmente, col mutare della caratteristica peculiare che aveva contraddistinto i progetti precedenti (mutamenti dovuti al cambio di ambito di utilizzo), sono contestualmente cambiate/aggiunte basilarmente anche alcune differenti specifiche strutturali.

Re: ... ma l'efficienza computazionale?
> AMD ha una storia decisamente travagliata, talvolta forgiata da pura incompetenza> ricordo ancora il compaq presario con athlon xp, con la cpu che cuoceva le uova e che si bruciò dopo 6 mesi!!> ARM ha invece sempre dimostrato di essere decisamente molto competente e anche di puntare a realizzare cosa che > funzionano bene piuttosto che accelerare il time to marketMa si, brava lo è stata; mantenendosi pur sempre in un mercato molto specifico, in fondo decisamente ristretto. Ora si tratta di un frangente in cui combattere in maniera diretta con un mastino come Intel ..... che finora era rimasto tutto sommato tranquillo, in quanto non era stato chiamato in causa da concorrenti diretti. E se pensiamo ancora una volta ad AMD che a sua volta, in una fase lunga più di qualche anno tempo addietro, era sembrata davvero anche raggiungerla ... Intel è un vero e proprio mastino, da oltre vent'anni non perde un colpo e riesce a mettere sempre in difficoltà i concorrenti, se non altro con la sistematicità delle proprie evoluzioni. Prima o poi riesce a produrre affanno in chiunque: è la storia di questi ultimi decenni a dimostrarlo. E se, da concorrente, perdi anche semplicemente il passo, con la foga poi di dover necessariamente accorciare i tempi, facilmente si rischia di cadere e perdere completamente il contatto. > il punto è che la disputa è terminata anni fa, con la vittoria di RISC> le cpu x86 sono proXXXXXri RISC con sopra un'ISA CISC implementata tramite microcodice> ma del resto pure i RISC hanno aggiunto sempre più istruzioni complesse ed esotiche> come si può, ad esempio, affermare che un ARM sia RISC, quando implementa le istruzioni neon? ormai RISC e CISC > esistono solo nella testa di chi ama le guerre di religionela penso in modo differente, però l'argomento è di una complessità talmente evidente che, seppur con una analisi sugli eventuali punti di contatto reciproci, potrebbe starci di pensarla in due modi differenti su alcune circostanze e, comunque, non trovarsi in definitiva in un completo disaccordo. > non è questione di produrre cpu RISC o CISC, ma di non saper fare business> MIPS aveva il mondo in mano e se l'è fatto soffiare> IBM non è in grado di metter su un piano industriale per vendere seriamente i Power ( ammesso che le interessi, > tanto comunque li rifila ai militari a prezzi esagerati )> le aziende che volevano competere sul terreno di intel hanno tutte fallito miseramente, mentre chi si è > accontentato di crearsi una propria nicchia ( ARM, ma anche Atmel con gli AVR, Freescale con i PowerPC e i 68k, > Sun con le cpu SPARC ) è riuscito a restare fuori dal mirino del monopolista> del resto il fatto che il problema non siano tanto RISC, CISC, qualche watt in più o in meno, lo conferma il > colossale flop di Itanium, ottimo prodotto di intel, sicuramente superiore a x86 su tutti i fronti ma morto prematuramenteParli con chi è stato in passato un profondo ammiratore dell'architettura SPARC; ma la sua valenza non la metterei assolutamente sullo stesso piano di quanto sta accadendo co quella ARM. A IBM non interessa realmente perdere inutilmente forze sul mercato server, i suoi interessi sono molteplici e per alcuni di questi lepuò bastare anche soltanto galleggiare. Per quanto mi riguarda, facendo un punto sulla situazione in generale, la vedo sotto un'altra luce: è stata Intel a non volersi interessare nel condurre una entrata in quella nicchia. Dalla lezione ricevuta su Itanium (architettura superiore, proprio come dici), non ti è mai sorvenuta l'idea che sia proprio globalmente il mercato server, dall'esterno, ad aver dettato in qualche modo differenti condizioni? Considerazione a parte va inquadrata sul fatto che Intel implementa contemporaneamente in casa anche le soluzioni acXXXXXrie come i chipset, fattore di rilevanza, questo, assolutamente da non sottovalutare. Rilevante sia per quanto concerne in generale i processi di ottimizzazione, sia per la spinta da ingenerare verso le scelte effettuate dai maggiori produttori di mainboard.E' decisamente molto complesso per una azienda come ARM intervenire da una parte, facendosi accettare nell'immediato dal mercato le proprie novità, dall'altra. E tutto questo sebbene i prodotti offerti possano anche essere ad un livello tecnologico di avanguardia.E' mia opinione che, come accaduto ripetutamente in passato, sarà quello stesso mercato a decidere il non cambiamento: quantomeno fintantoché Intel si dimostrerà in grado di offrire prodotti dalla resa analoga, in assoluto, a quella fornita con la generazione immediatamente precedente.

Pignoleria
"Server ARM, il attesa dell'arrosto"IN ! Maruccia ma leggi il testo prima di schiacciare "invio" ? :D

Re: Pignoleria
- Scritto da: Anonimo> "Server ARM, il attesa dell'arrosto"> > IN ! Maruccia ma leggi il testo prima di> schiacciare "invio" ?> :D"4336 - Server ARM, il ruggito del gattino.doc"

Re: Pignoleria
- Scritto da: Alfonso Maruccia> - Scritto da: Anonimo> > "Server ARM, il attesa dell'arrosto"> > > > IN ! Maruccia ma leggi il testo prima di> > schiacciare "invio" ?> > :D> > "4336 - Server ARM, il ruggito del gattino.doc" In genere il 50% dei miei titoli viene cambiato in fase di revisione. E io lo so, e lo faccio apposta XD

Re: Pignoleria
- Scritto da: Alfonso Maruccia> > > "4336 - Server ARM, il ruggito del> gattino.doc" In genere il 50% dei miei titoli> viene cambiato in fase di revisione. E io lo so,> e lo faccio apposta> XDstavolta era meglio il tuo! :D

Re: Pignoleria
- Scritto da: Alfonso Maruccia> - Scritto da: Alfonso Maruccia> > - Scritto da: Anonimo> > > "Server ARM, il attesa dell'arrosto"> > > > > > IN ! Maruccia ma leggi il testo prima di> > > schiacciare "invio" ?> > > :D> > > > "4336 - Server ARM, il ruggito del> gattino.doc" In genere il 50% dei miei titoli> viene cambiato in fase di revisione. E io lo so,> e lo faccio apposta> XDalfo', sei fortunato che ancora annunziata ti tiene, il fatto che ti cambi titolo e' il meno. Ma quale oscuro segreto conosci per ricattarlo in questo modo? non vedo altre spiegazioni che tengano uno come te che con le razzate che ha scritto in questi anni ci si potrebbe fare un libro. Quanche esempio? (carburanti radioattivi, unita' di misura inventate, traduzioni scopizzate da google che invertivano il senso dell'articolo originale, parolaccie nei post di risposta, spocchia a chili... etc) Ti piace vincere facile, eh?

Server ARM-Based
E' da qualche mese che nel mio ufficio sto passando piano piano tutte le infrastrutture interne a sistemi basati su ARM.Attualmente ho 5 mele a2000, però ne uso soltanto 4 in questo momento:- condivisione file;- voip con freeswitch;- vpn;- sviluppo web (apache/nginx + mysql 5.5 + php fastcgi 5.3/5.4)Il quinto lo tengo per gli esperimenti.Devo dire che si comportano veramente bene e, anche se la cosa mi ha richiesto non poco tempo, benché inizialmente usassi ubuntu, sono passato ad una disto compilata da me (crosstools-ng+linaro+buildroot+kernel/uboot patchati per il mele) ... mi sono disperato prima di riuscire a fargli fare il boot ^^Però devo dire che hanno performance eccezionali e, soprattutto, il sistema sta su SD e parte in meno di 10 secondi (dentro c'è solo quello che serve tagliato su misura ^^)Una volta che fanno il boot, i dati li acquisiscono via iscsi su rete.L'unica vera problematica, almeno dell'hardware che sto usando io, è che non è gigabit ... in realtà il sistema lo uso soltanto io quindi, a parte la condivisione file, non mi crea assolutamente problemi.il sistema con lo storage l'ho preferito fare sul mio ex server in quanto ci sono tutti i vari dischi in raid, il mele a2000 permette il collegamento di un disco sata ... ma non si ci può fare il raid e non conosco le performance del chipset presente li su.Però va considerato che il costo di implementazione è stato circa 300, spese di spedizione a parte (ho tolto dall'elenco il mele che non uso, l'ho preso in più per fare esperimenti e come ricambio) ed, inoltre, va anche considerato che mi basta cambiare spostare la scheda SD ed ho spostato il sistema.Non ho perso tempo (per adesso non ne ho) nel tentativo di copiare il tutto sulla nand sia perché la comodità di spostare la SD ed essere operativi è enorme sia perché se per caso dovessi aver bisogno di spazio (anche se attualmente i vari sistemi sono grandi tra i 30mb ed i 100mb) ci sto 1 secondo a metterne una più grande.Per carità, è stato più un esperimento però devo dire che ha funzionato (ed ancora funziona) bene :)Il problema grosso vero e proprio è windows: generalmente ai miei clienti installo linux + libvirt(kvm) su cui metto su tutto virtualizzato, windows compreso (i dischi sono su lvm o iscsi, dipende da quanto è grande l'infrastruttura di rete, e la comodità di backup basati su snapshot è estrema) ... ma in una situazione del genere purtroppo non è possibile mettere windows su quest'hardware (almeno non ancora) :

Re: Server ARM-Based
- Scritto da: daniele_dll _rosica> E' da qualche mese che nel mio ufficio sto> passando piano piano tutte le infrastrutture> interne a sistemi basati su> ARM.> .......> :scusa eh, ma chissenefrega del sistema fighissimo che hai approntato in ufficio? Non mi sembra abbia attinenza con quello scritto nell'articolo

Re: Server ARM-Based
Ha attinenza per quanto riguarda il file server, mysql e apache, che è roba lato server.

Re: Server ARM-Based
i motivi del sucXXXXX di tale piattaforma li hai ben elencati nel tuo commento- Scritto da: daniele_dll _rosica> ad una disto compilata da me> (crosstools-ng+linaro+buildroot+kernel/uboot> patchati per il mele) ... mi sono disperato primail primo> meno di 10 secondi (dentro c'è solo quello che> serve tagliato su misura> ^^)il secondo> anche considerato che mi basta cambiare spostare> la scheda SD ed ho spostato il> sistema.il terzol'ottimizzazione di cui godono le distribuzioni basate su arm, non la trovi nel mondo x86, dove sei costretto a compilare tutto per un'isa baseline e poi chi c'ha il proXXXXXre più nuovo s'arrangia e arranca nel poter utilizzare tutte le istruzioni che il suo proXXXXXre gli mette a disposizionesenza contare il fatto che c'è molta ricerca dietro l'implementazione di SoC armad esempio, giorni fa leggevo di una startup che ha ficcato 64 cpu arm in un chippino di pochi mm^2roba che con x86 puoi solo sognare

Re: Server ARM-Based
- Scritto da: collione> i motivi del sucXXXXX di tale piattaforma li hai> ben elencati nel tuo> commento> > - Scritto da: daniele_dll _rosica> > > ad una disto compilata da me> > (crosstools-ng+linaro+buildroot+kernel/uboot> > patchati per il mele) ... mi sono disperato> prima> > il primo> > > meno di 10 secondi (dentro c'è solo quello> che> > serve tagliato su misura> > ^^)> > il secondo> > > anche considerato che mi basta cambiare> spostare> > la scheda SD ed ho spostato il> > sistema.> > il terzo> > l'ottimizzazione di cui godono le distribuzioni> basate su arm, non la trovi nel mondo x86, dove> sei costretto a compilare tutto per un'isa> baseline e poi chi c'ha il proXXXXXre più nuovo> s'arrangia e arranca nel poter utilizzare tutte> le istruzioni che il suo proXXXXXre gli mette a> disposizione> > senza contare il fatto che c'è molta ricerca> dietro l'implementazione di SoC> armAlla Intel invece dormono vero?> ad esempio, giorni fa leggevo di una startup che> ha ficcato 64 cpu arm in un chippino di pochi> mm^2> > roba che con x86 puoi solo sognareroba come questa:http://www.intel.com/content/www/us/en/architecture-and-technology/many-integrated-core/intel-many-integrated-core-architecture.html

Re: Server ARM-Based
un altro difensore di intel?siete ridicoli ormai, fatevi un giro su google e vedete quanta carne al fuoco c'è sul fronte armsenza contare che intel è una singola azienda, nel fronte arm ci sono centinaia di aziende tra creatori di IP ed implementatori di SoCinoltre, ti faccio notare, che l'architettura manycore di intel ancora non si è vista, mentre le manycore arm vengono vendute già da qualche anno ( tilera su tutti )ma informarvi prima di sparate XXXXXte, no eh!?!sei peggio di quell'altro troll di nome e cognome, la cui ignoranza è grande quanto il tdp di un core i7 (rotfl)

Re: Server ARM-Based
che c'entra windows 8 con la cpu?

Re: Server ARM-Based
- Scritto da: bancai> > 10secondi senza serverX?a cosa ti serve X su un server?al massimo se proprio mi serve qualche software che fa uso di X (ma esclusivamente per le configurazioni) lo avvierei esportando il display, di averlo direttamente avviato li su per fargli tirar via memoria e cicli di proXXXXXre solo per usarlo 1 volta ogni morte di papa (augurandogli una lunga vita) non mi sembra il caso -.-'

Re: Server ARM-Based
- Scritto da: daniele_dll _rosica> - Scritto da: bancai> > > > 10secondi senza serverX?> > a cosa ti serve X su un server?> > al massimo se proprio mi serve qualche software> che fa uso di X (ma esclusivamente per le> configurazioni) lo avvierei esportando il> display, di averlo direttamente avviato li su per> fargli tirar via memoria e cicli di proXXXXXre> solo per usarlo 1 volta ogni morte di papa> (augurandogli una lunga vita) non mi sembra il> caso> -.-'quindi i 10 secondi sono per avviare solo la shell..

Re: Server ARM-Based
- Scritto da: bancai>> quindi i 10 secondi sono per avviare solo la> shell..premesso che i vari sistemi fanno il boot da una sd XXXXXfa il boot completo e mi avvia la shell:- boot del kernel con tutte le sue varie necessità;- il sistema parte con l'initrd (inutile a dire la verità in questo contesto, ma non mi andava di sbattermi per modificare la struttura che mi ero fatto tempo addietro, anche qui probabilmente un paio di secondi);- creazione dei device (tengo udev, ma un set dei device statici andrebbe bene lo stesso visto che non è un pc e non c'è rischio che i device cambino e quindi andrei solo qui a recuperare almeno un paio di secondi);- boot dei software (dipende da cosa fa la macchina, si va da un apache/nginx/php-fastcgi/mysql a un samba e basta o ancora da freeswitch/nginx/php-fastcgi/memcache ad un semplice server vpn con openvpn)- parte la shellper finire, guarda che l'hardware è di fascia bassa ... sono sicuro che windows parte in una manciata di secondi ... ma su un hardware 4/5 volte più veloce (e non solo in termini di CPU ma anche in termini di disco visto che si fa il confronto tra una SSD ed una SD ... non so se mi spiego)

ma che geni!!!
- Eliminare gli x86.- introdurre gli arm- XXXXX non ho soft compatibile allora introduco un emulatore x86ricompilare per arm no, eh?

Re: ma che geni!!!
- Scritto da: attonito> - Eliminare gli x86.> - introdurre gli arm> - XXXXX non ho soft compatibile allora introduco> un emulatore> x86> > ricompilare per arm no, eh?non è sempre possibile ricompilare, questa specie di qemu penso sarà utile....

Re: ma che geni!!!
- Scritto da: bancai> - Scritto da: attonito> > - Eliminare gli x86.> > - introdurre gli arm> > - XXXXX non ho soft compatibile allora introduco> > un emulatore> > x86> > > > ricompilare per arm no, eh?> > non è sempre possibile ricompilare, questa specie> di qemu penso sarà> utile....Esiste una versione di qemu in grado di avviare direttamente l'eseguibile per architettura differente in grado di usare però le librerie native del sistema.Ovviamente questo porta con se tutta una serie di problematiche non indifferenti (anche la semplice convenzione di chiamata mi domando come venga gestita) però ha il grosso vantaggio di andare in emulazione solo per una parte ridotta ... non sarà veloce come il sistema nativo ma visto che non deve emulare tutto il kernel ed il pc intero ma fondamentalmente deve eseguire ("ricompilare") solo l'eseguibile principale e/o eventuali librerie proprietarie su cui poggia c'è un bel risparmio di lavoro!Qui qualche info utile sul supporto alla ricompilazione dinamica di qemuhttp://livexp.boot-land.net/Tools/LiveXP/qEmu/qemu-tech.html#SEC9

per tutti i trollini x86
ecco qua i fatti di cui parlavo http://www.anandtech.com/show/5770/lava-xolo-x900-review-the-first-intel-medfield-phone

Re: per tutti i trollini x86
- Scritto da: collione> ecco qua i fatti di cui parlavo> http://www.anandtech.com/show/5770/lava-xolo-x900-Quelli che ti smentiscono come al solito?"The good news is that the whole x86 can't be power efficient argument appears to be completely debunked with the release of a single device""The Atom Z2460 in the X900 is a competent dual-core Cortex A9 competitor with competitive battery life and power draw, and no doubt Z2580 (its dual core, SGX544MP2 high end counterpart clearly targeted at Windows 8 platforms) will be equally as competitive against quad core A9s"The x86 power myth is finally bustedtraduco o ci riesci da solo?

Re: per tutti i trollini x86
vedo che, come al solito, ti sei fermato alla prima pagina e hai estratto solo le parti che ti convengonoin quel test si afferma che l'atom si batte bene, ma sul comparto grafico crolla miseramenteregge solo nel calcolo aritmetico, ma al prezzo di far la batteria un niente in confronto agli armcome al solito dimostri la tua totale incompetenza

Re: per tutti i trollini x86
> in quel test si afferma che l'atom si batte bene,> ma sul comparto grafico crolla> miseramenteE come al solito tu non leggi... We're either bumping into a memory bandwidth limit or some other CPU/driver limitation. Either way, Intel definitely needs a faster GPU. We'll get it but not until early next year with the 544MP2 in the Atom Z2580.Può essere un problema di driver, di memoria o cpu... non lo sanno. E comunque giusto per farti sembrare ancora un filino più ignorante, il comparto grafico dei SOC arm non è arm e quello di intel non è intel ... E comunque la GPU più veloce arriverà early next year ovvero nel 2013. > regge solo nel calcolo aritmetico, ma al prezzo> di far la batteria un niente in confronto agli> arm> > come al solito dimostri la tua totale incompetenzaCome al solito dimostri che il tuo cervello ha crashato, riporta il paragrafo dove si trae questa conclusione...Ti riporto per la seconda volta "The Atom Z2460 in the X900 is a competent dual-core Cortex A9 competitor with competitive battery life and power draw"E te lo traduco perché non voglio affaticare troppo il tuo cervello:"L'atom Z2460 nel X900 è un soddisfacente concorrente del cortex a9 dual core con una durata di batteria e consumo competitivo."Inutile dire (tranne a te) che lo Z2460 è l'atom di fascia bassa nonché il primo dispositivo realmente mirato a questo mercato, inutile notare che al primo colpo Intel è stata competitiva.

Virtualizzazione
Visto che oramai la stragrande maggioranza dei data center usa virtualizzazione non sono così convinto che l'efficienza di ARM sia così superiore. In fondo su un server Intel fai girare decine di macchine virtuali e quindi il consumo per ogni workload risulta basso. In altri termini i vantaggi evidenti su dispositivi mobili non mi sembrano così evidenti sui server.Chi vivrà vedrà.

Re: Virtualizzazione
l'efficienza è a livello di cpu, quella di cui parli tu era invece la sottoutilizzazione della cpu la virtualizzazione sfrutta meglio la cpu, ma il fatto che x86 abbia performance/watt inferiori ad arm non lo si può cambiare con un software

Re: Virtualizzazione
- Scritto da: collione> la virtualizzazione sfrutta meglio la cpu, ma il> fatto che x86 abbia performance/watt inferiori ad> arm non lo si può cambiare con un> softwareIo parlo di migliori consumi legati ai workload. Qualcuno ha fatto studi del genere?

Ahhh ma allora
Lo voglio piccoloLo voglio potenteLo voglio che consuma pocoMini Mac do you need it?

Re: Ahhh ma allora
Parliamo di server. I fermacarte con OS bucherellato non contano.

Re: Ahhh ma allora
- Scritto da: Davidoff> Parliamo di server. I fermacarte con OS> bucherellato non> contano.Eh beh perchè i buchi di windows o lolLinux non si contano eh.E comunque non hai capito il concetto, come da buon cantinaro.

Re: Ahhh ma allora
> > Parliamo di server. I fermacarte con OS> > bucherellato non> > contano.> > Eh beh perchè i buchi di windows o lolLinux non> si contano> eh.> > E comunque non hai capito il concetto, come da> buon> cantinaro.il mac mini monta un i5, non è sicuramente un chip all'avanguardia

Re: Ahhh ma allora
da quando il mac mini usa cpu arm??parliamo di watt ( a una cifra ) non decine di watt!!!

Re: Ahhh ma allora
- Scritto da: collione> da quando il mac mini usa cpu arm??> > parliamo di watt ( a una cifra ) non decine di> watt!!!Non hai capito il concetto.In soldoni è che tutti vorrebbero (perchè ad oggi come il buon Mariuccia dice) tutti lo vorrebbero piccolo, potente il giusto e consuma poco.Il minimac di ieri e di oggi.Perchè lo sai si che dal punto di vista Arm e implementazione HW e SW Apple è avanti anni luce rispetto alle altre major?-----------------------------------------------------------Modificato dall' autore il 07 ottobre 2012 18.19-----------------------------------------------------------

Re: Ahhh ma allora
apple avanti anni luce? ma in quale universo parallelo? semplicemente i mac mini non offrivano e non offrono lo stesso rapporto performance/watt degli armper questo motivo il tuo commento è fuori luogo

Re: Ahhh ma allora
- Scritto da: maxsix> Lo voglio piccolo> Lo voglio potente> Lo voglio che consuma poco> > Mini Mac do you need it?Se è veramente così vantaggioso, perché lo usate solo tu e Ruppolo?

Re: Ahhh ma allora
> Se è veramente così vantaggioso, perché lo usate> solo tu e> Ruppolo?probabilmente lo usano davvero.

Re: Ahhh ma allora
- Scritto da: Funz> - Scritto da: maxsix> > Lo voglio piccolo> > Lo voglio potente> > Lo voglio che consuma poco> > > > Mini Mac do you need it?> > Se è veramente così vantaggioso, perché lo usate> solo tu e> Ruppolo?Sto parlando di concept.E comunque lo uso eccome, quando lo compri a 200 euro usato, avoja che lo usi.

Re: Ahhh ma allora
Brutta bestia l'ottusità.Ti ripeto si sta parlando di server non di fermacarte. In ambito server OSX è fondamentalmente inutile, insomma un giocattolino per macachi. L'oggettino carino che proponi va bene dentro una casa. Te lo dico chiaramente che forse ci arrivi: Server != potenza bruta (o meglio non vi è una corrispondenza biunivoca). Tu suggerisci quel giocattolino ma per fare cosa? Firewall? e butto i soldi con le cosette carine quando con la stessa cifra (anzi spesso minore) posso ottenere prodotti più performanti? Database? Arm per ora non è adatto. Altri usi? OSX inutileQui non si sta parlando di uno che si fa il serverino casalingo ma di grosse aziende che progettano di produrne basati su architettura Arm ma siccome voi macachi siete abituati all'elettronica di consumo non ci arrivate.Il mac-mini è un oggettino sfizioso per casa ma fine. Non voglio essere volgare ma come al solito dimostri di essere un ottuso con le mele sugli occhi.

Re: Ahhh ma allora
- Scritto da: Davidoff> Brutta bestia l'ottusità.> Ti ripeto si sta parlando di server non di> fermacarte. In ambito server OSX è> fondamentalmente inutile, insomma un giocattolino> per macachi. L'oggettino carino che proponi va> bene dentro una casa. Te lo dico chiaramente che> forse ci arrivi: Server != potenza bruta (o> meglio non vi è una corrispondenza biunivoca).> > Tu suggerisci quel giocattolino ma per fare cosa?> Firewall? e butto i soldi con le cosette carine> quando con la stessa cifra (anzi spesso minore)> posso ottenere prodotti più performanti?> Database? Arm per ora non è adatto. Altri usi?> OSX> inutile> Dove ti sei perso il fatto che VMware Fusion è il miglior virtualizzatore che c'è in giro.Dove ti sei perso il fatto che thunderbird è il miglior bus ad oggi in circolazione.Dove ti sei perso il fatto che oggi, a parte Ransperry PI, il minimac è quello che si avvicina al concetto di server compatto, che consuma poco e con prestazioni di tutto rispetto.E' che voi cantinari della fava date dagli ottusi agli altri ma non vi rendete conto di quanto vi manchi il senso pratico delle cose.Insomma siete inutili.