Ubuntu Edge improbabile, gli investitori perdono interesse sul progetto di Canonical

[AceGranger]

Originariamente inviato da LMCH

Già, Intel riuscì a stabilire un vero e proprio record: un architettura nuova di zecca basata sul non plus ultra a livello di ricerca teorica e con vagonate di soldi investiti sopra ... che poi si rivelò essere un flop colossale.

Il classico caso di troppi cuochi che rovinano il piatto.

Alla fine l'unico risultato positivo fu a che a colpi di accordi commerciali fece fuori le cpu Alpha e MIPS dal settore dei server di fascia alta ... facendo guadagnare quote di mercato agli Xeon.

Itanium, è nato per gli ambienti Mission Critical, cosa che gli Xeon della fascia media ( attuali E5 ), non sono. Per gli ambienti Mission Critical X86 ci sono anche gli Xeon E7, ma non credo che abbiano una quota di mercato tanto superiore agli Itanum.

Intel è riuscita ad imporre gli Xeon della fascia media per il semplice fatto che l'X86 è piu diffuso, meno sbattimenti per i software, molto piu versatile, piu adattabile e piu economico.

[Giachi6]

Originariamente inviato da pabloski

vabbè, è un forum dopotutto

ed è simpatico leggere le sue arrampicate sugli specchi, soprattutto sapendo che il movente è la convinzione, secondo cui, io sarei un fandroid mandato qui per spingere google+arm

ovviamente, nella sua testa, i nokia lumia non montano arm ma qualcomm, che è tutta un'altra roba ovviamente

quindi lui è il cavaliere winkiacomm che combatte il drago googlarm

Ahaha, ok, per un po' può anche essere divertente, ma io non sarei mai riuscito a ribattere alle sue stronzate tante volte come hai fatto te senza infilarci qualche insulto nel mezzo, sarebbe stato più forte di me .

Originariamente inviato da pabloski

Il perchè i SoC non sono un problema nemmeno in ambito pc, è dovuto al fatto che il tipo e il numero di casi sono pochi. Ok, c'hai i word processor, i web browser, server torrent, ftp, client irc e chi più ne ha più ne metta. Tuttavia tutte quelle funzioni hanno alla base poche componenti ben note. Ad esempio bisogna processare stringhe, fare operazioni su numeri in virgola mobile oppure su interi, eseguire operazioni su vettori e matrici se parliamo di programmi di grafica o giochi.

Ad esempio le gpu seguono la filosofia dei SoC. Cioè si accelera in hardware quanto più possibile. Tuttavia non esistono gpu per direct3d e gpu per opengl. Nè tantomeno una gpu ha un'unità opengl e un'altra direct3d. Questo perchè entrambe le api usano le stesse operazioni, cioè la matematica che ci sta dietro è la stessa.

Alla fin fine, se hai un'unità che è in grado di sommare, in un colpo solo, 2 vettori da 1024 elementi, la puoi usare tanto per opengl tanto per direct3d.

Si, non sono ignorante come quell'altro li , so che la gpu è un cooprocessore grafico, però è presente sempre e comunque in un pc, non è opzionale visto che è da un bel pezzo che la grafica è affidata ad un processore dedicato e non viene più gestita dalla cpu, i problemi sorgono quando ogni SoC integra diversi tipi di cooprocessori.
Rimanendo sulla gpu va però detto che è un cooprocessore poco specializzato, cioè non è paragonabile per esempio al chippino per il linguaggio naturale del Moto X (che può fare solo quello e stop), ed è per quello che è in grado di essere utilizzata da diverse applicazioni. Però, se esistesse una gpu specializzata per l'opengl, essa in opengl distruggerebbe una gpu general purpose no? Tanto quanto una gpu distrugge una cpu nei calcoli per i quali è progettata.
Alla fine il punto è sempre quello, più un chip è specializzato più è rapido a elaborare ciò per cui è stato progettato ma al contempo diventa sempre più inutile per il resto, quindi generalmente si cerca una via di mezzo tra specializzazione e forza bruta che accontenti un po' tutti gli usi.
Però tu sembri suggerire che ARM sia migliore perché in futuro potrà integrare un cooprocessore specifico per ogni compito e francamente la cosa mi sembra molto poco realistica, ci ritroveremo con decine di chippini buoni ognuno per un solo uso o per un ristretto ambito d'utilizzo, con il 90% della cpu inutilizzata.

Originariamente inviato da pabloski

Ovviamente. A parità di dimensioni e processo produttivo è così. E bisogna ragionare per bene prima di decidere quale strada intraprendere.

Ma se c'hai da decodificare flussi video 1080p, allora è lampante che c'è convenienza nell'implementare un chip apposito. E no, non c'è bisogno di un chip per ogni singolo formato video. Si va a guardare quali sono le operazioni tipiche dei decoder/encoder video e si accelera quelle. Il resto è implementato in software.

Stesso discorso, se integri un chippino per codifica/decodifica di flussi video un una cpu generica, il 90% o più degli utenti si troverà a pagare un chip che non userà mai o quasi mai, quando con lo stesso prezzo avrebbe potuto avere una cpu più potente ma senza chippino per decodifica ( e chi ne avesse necessità può già ora comprare una scheda d'espansione apposita oppure direttamente un decoder video specifico).
Seguendo questa strada ci ritroveremo ad avere o decine di cpu diverse che differiscono per i vari cooprocessori implementati oppure cpu con parti inutilizzate (visto che nessuno utilizzerebbe tutti i chip specifici inseriti).

ps: sul formato si applica lo steso discorso della gpu, un chip specifico per un determinato formato andrebbe meglio di uno generico per tutti i formati, alla fine bisogna solo scegliere quanto nello specifico si vuole scendere, più ci si specializza meno versatili si diventa guadagnandoci però in prestazioni nel compito specifico.

Originariamente inviato da pabloski

intel ha dovuto, in alcune occasioni, ritornare indietro per non rischiare di fare la fine di ibm con i power...ad esempio i core sono figli dell'architettura P6 e non dell'allora blasonata Netburst

cioè dovettero fare un passo indietro!!!

Beh, l'evoluzione è piena di vicoli ciechi e rami tronchi, non ci vedo nulla di strano, Netburst era progettata per la scalata ai 10 Ghz, una volta capito che la cosa era poco realistica è stata abbandonata

Originariamente inviato da pabloski

la storia di x86 porta a concludere che l'architettura non può migliorare più di tanto, visto che si batte moltissimo sull'aspetto fisico e cioè sui processi produttivi

Vero, però può anche essere che non avendo rivali fin'ora non si sia mai evoluta più di tanto, e per migliorarla si è ricorso al processo produttivo perché era la via più semplice, mentre ora, con la pressione evolutiva introdotta da ARM le cose stanno cambiando e lottando tra di loro magari si miglioreranno a vicenda

Originariamente inviato da pabloski

pessima no, problematica si

ha una storia travagliata, fatta di confronti impietosi con, di volta in volta, alpha, sparc, power, ecc...

sicuramente x86 non è particolarmente brillante

Qui non posso dire nulla visto che non sono ferrato nelle differenze tra queste architetture, però l'esempio di prima, cioè della stagnazione quando manca la competizione rimane valido, x86 avendo il culo parato dalla compatibilità software non ha mai sentito il rischio di estinzione, fin'ora, e quindi potrebbe non aver mai raggiunto il suo pieno potenziale. Insomma, visto che non era necessario non si sono sbattuti più di tanto......

Originariamente inviato da pabloski

potrebbe accadere ma è poco probabile

Chissà, l'evoluzione a volte può sorprendere (non so se si è capito dai miei innumerevoli richiami all'evoluzione ma sono più ferrato in biologia che in informatica e quindi tendo ad applicare le stesse regole anche qui )

Originariamente inviato da pabloski

arm ha sempre bilanciato perfettamente complessità, consumi e potenze di calcolo e soprattutto ha sempre seguito la logica del "fai in hardware le cose pesanti e ripetitive"

Questo perché fin'ora è sempre stata utilizzata per compiti molto specifici, a quanto mi risulta, fare in hardware quasi tutto quando il tutto è molto ampio risulta difficile, per questo non sono così certo dell'assoluta superiorità di ARM.

Per fare un'esempio in campo motoristico, un motore a getto è più efficiente a partita di potenza erogata di un'analogo a pistoni, però è anche molto meno versatile ed è per questo che viene utilizzato solo su determinati veicoli ed il motore a pistoni non si è estinto dopo la sua invenzione.

Originariamente inviato da pabloski

praticamente scontato, anzi sembra più facile che il pc diventi una nicchia ( almeno così dicono gli analisti )

Già, o meglio, sarebbe più giusto dire che sempre più dispositivi diventeranno dei pc ed il desktop vero e proprio rimarrà solo per utilizzi in cui è richiesta una potenza notevole

[pabloski]

Originariamente inviato da Giachi6

so che la gpu è un cooprocessore grafico, però è presente sempre e comunque in un pc, non è opzionale visto che è da un bel pezzo che la grafica è affidata ad un processore dedicato e non viene più gestita dalla cpu, i problemi sorgono quando ogni SoC integra diversi tipi di cooprocessori.

la gpu è l'esatto di quanto dicevo nei post precedenti

in passato il chip grafico leggeva dal framebuffer e inviava i dati allo schermo....Amiga faceva invece come fanno le gpu moderne...il risultato? Amiga batte PC 40 a 0

Originariamente inviato da Giachi6

Rimanendo sulla gpu va però detto che è un cooprocessore poco specializzato, cioè non è paragonabile per esempio al chippino per il linguaggio naturale del Moto X

dipende da cosa s'intende per poco specializzato

per rendere la gpu flessibile ma non inutile, hanno ben pensato di farla diventare un processore simd....alla fin fine fa esattamente quello che fa una normale cpu, solo che contiene una marea di componenti capaci di fare operazioni matematiche su matrici e vettori anche di grandi dimensioni

ma pure le cpu x86 stanno integrando sempre più coprocessori....basti pensare che gli attuali core hanno unità per accelerare gli algoritmi crittografici

il dsp del moto x svolge una sola funzione ( i dsp sono così )...però, anche nel mondo arm, è raro che si adottino soluzioni così drastiche, a meno di non voler creare un SoC specializzato

Originariamente inviato da Giachi6

Però, se esistesse una gpu specializzata per l'opengl, essa in opengl distruggerebbe una gpu general purpose no? Tanto quanto una gpu distrugge una cpu nei calcoli per i quali è progettata.

in teoria, man mano che trasferisci le operazioni verso l'hardware, l'efficienza aumenta

però la flessibilità diminuisce....il giusto compromesso dipende dall'applicazione

gli arm che usiamo sugli smartphone hanno chip acceleratori alla stregua delle gpu, non dei dsp usati dal motorola x

Originariamente inviato da Giachi6

Però tu sembri suggerire che ARM sia migliore perché in futuro potrà integrare un cooprocessore specifico per ogni compito e francamente la cosa mi sembra molto poco realistica, ci ritroveremo con decine di chippini buoni ognuno per un solo uso o per un ristretto ambito d'utilizzo, con il 90% della cpu inutilizzata.

non è un metodo usato solo da arm, anche intel sta facendo lo stesso

arm, da parte sua, sviluppa la cpu, i bus e poche altre cose...i chip dedicati sono affare di chi progetta il SoC

il punto è che qualsiasi caso d'uso, ha una bassa variabilità....se prendi gli attuali pc, ti accorgerei che il lavoro pesante consiste nel gestire la grafica 3d, l'encoding/decoding dei formati audio, l'i/o, ecc... le cpu dei pc sono assistite da un buon numero di chip arm, presenti in varie componenti periferiche

i SoC arm per il mobile accelerano in maniera aggressiva le operazioni tipicamente associate alla fruizione di contenuti audio/video ( che poi è quello che pesa sia su pc sia su mobile )

per il resto, esistono da anni SoC arm specializzati per determinati ambiti e si, ogni SoC ha delle particolarità e talvolta incompatibilità con altri SoC sempre basati su arm

Originariamente inviato da Giachi6

Stesso discorso, se integri un chippino per codifica/decodifica di flussi video un una cpu generica, il 90% o più degli utenti si troverà a pagare un chip che non userà mai o quasi mai

infatti intel ha ben pensato di integrare unità per elaborare calcoli vettoriali velocemente

il tipo di calcoli che si usano per grafica, video, audio, ecc....

e ovviamente entrano in gioco le economie di scala, ovvero il chippino si progetta una sola volta, poi se ne producono miliardi a costi di pochi centesimi di euro

Originariamente inviato da Giachi6

, quando con lo stesso prezzo avrebbe potuto avere una cpu più potente ma senza chippino per decodifica ( e chi ne avesse necessità può già ora comprare una scheda d'espansione apposita oppure direttamente un decoder video specifico).

eppure anche x86 sta andando nella stessa direzione, altrimenti come si spiega la grafica integrata nei core?

Originariamente inviato da Giachi6

Seguendo questa strada ci ritroveremo ad avere o decine di cpu diverse che differiscono per i vari cooprocessori implementati oppure cpu con parti inutilizzate (visto che nessuno utilizzerebbe tutti i chip specifici inseriti).

cpu diverse già ce ne sono

per le parti inutilizzate, beh, chi progetta uno smartphone non mette un SoC come quello di Parallela al posto di un Exynos ( se lo fa, farebbe bene a cambiare mestiere )

Originariamente inviato da Giachi6

ps: sul formato si applica lo steso discorso della gpu, un chip specifico per un determinato formato andrebbe meglio di uno generico per tutti i formati, alla fine bisogna solo scegliere quanto nello specifico si vuole scendere, più ci si specializza meno versatili si diventa guadagnandoci però in prestazioni nel compito specifico.

nessun chip è progettato per un singolo formato, sarebbe folle

Originariamente inviato da Giachi6

Beh, l'evoluzione è piena di vicoli ciechi e rami tronchi, non ci vedo nulla di strano, Netburst era progettata per la scalata ai 10 Ghz, una volta capito che la cosa era poco realistica è stata abbandonata

ovviamente 10 ghz è assurdo, tra calore prodotto e tumori in ogni dove

Originariamente inviato da Giachi6

Vero, però può anche essere che non avendo rivali fin'ora non si sia mai evoluta più di tanto, e per migliorarla si è ricorso al processo produttivo perché era la via più semplice, mentre ora, con la pressione evolutiva introdotta da ARM le cose stanno cambiando e lottando tra di loro magari si miglioreranno a vicenda

mi chiedo se possono farlo....arm non è più efficiente solo perchè integrata tanti chip, ma perchè l'architettura della cpu è più efficiente

si comincia con un set d'istruzioni a lunghezza fissa, il che semplifica mostruosamente la circuiteria che esegue il fetch, oltre a non dover avere altri circuiti che calcolano la locazione dove andare a pescare la prossima istruzione

poi c'è tutta la circuiteria per gestire la segmentazione ( che oltretutto nessun sistema operativo moderno usa )

insomma, i chippettini aiutano, ma c'è dell'altro e proprio nella cpu

purtroppo la retrocompatibilità è una lama a doppio taglio e intel ha dovuto fare cose da pazzi con atom ( prima fanno una cpu in-order, poi levano i 64 bit, poi li rimettono, poi la rifanno out-of-order ma con processi produttivi molto migliorati )...tutto questo indica la presenza di enormi difficoltà

Originariamente inviato da Giachi6

Chissà, l'evoluzione a volte può sorprendere (non so se si è capito dai miei innumerevoli richiami all'evoluzione ma sono più ferrato in biologia che in informatica e quindi tendo ad applicare le stesse regole anche qui )

il punto è che l'evoluzione se ne frega della retrocompatibilità

i vecchi si estinguono, i nuovi emergono...intel sta mantenendo in vita un vecchiaccio

Originariamente inviato da Giachi6

Questo perché fin'ora è sempre stata utilizzata per compiti molto specifici, a quanto mi risulta, fare in hardware quasi tutto quando il tutto è molto ampio risulta difficile, per questo non sono così certo dell'assoluta superiorità di ARM.

progettare hardware è più complesso del progettare software

però ultimamente si è arrivati ad avere una massa critica di ip ( cioè progetti di circuiti ) che svolgono le più disparate funzioni, vengono concessi in licenza a prezzi relativamente abbordabili, la legge di Moore sta rallentando e i cinesi producono a prezzi stracciati ogni sorta di chip e/o scheda elettronica

Originariamente inviato da Giachi6

Per fare un'esempio in campo motoristico, un motore a getto è più efficiente a partita di potenza erogata di un'analogo a pistoni, però è anche molto meno versatile ed è per questo che viene utilizzato solo su determinati veicoli ed il motore a pistoni non si è estinto dopo la sua invenzione.

perchè il motore a getto consuma troppo, è costoso da mantenere, non è scalabile verso il basso ( i jetpack sono stati un fallimento per questo motivo )

Originariamente inviato da Giachi6

Già, o meglio, sarebbe più giusto dire che sempre più dispositivi diventeranno dei pc ed il desktop vero e proprio rimarrà solo per utilizzi in cui è richiesta una potenza notevole

si, il punto è questo....gli smartphone già sono dei pc, nel senso che possono fare tutto quello che fanno i pc....ovviamente qualcuno mi dirà che manca questo o quel programma, ma si tratta di un fattore contingente non potenziale

cioè lo smartphone può far girare photoshop, non lo fa perchè adobe non ha portato photoshop su smartphone

qualche mese fa ho passato 4 giorni e una trentina di post per cercare di far capire questo concetto a maxmax80...il brutto è che continua a ribattere a discorsi tecnici con dati di mercato

e poi c'è il fatto che i produttori di SoC arm sono partiti dal basso e stanno man mano aumentando le capacità dei loro prodotti....ovviamente progettare un SoC più potente richiede tempo e denaro, motivo per cui non abbiamo oggi SoC arm che possano competere con x86 in termini di potenza pura

ce ne sono alcuni, ma sono di nicchia ed usati solo in determinati ambiti

e c'è molto altro da dire, perchè la storia continua con gli fpga e compagnia, che sono bestioline alquanto interessanti e dalle potenzialità strabilianti

[maxmax80]

Originariamente inviato da pabloski

si, il punto è questo....gli smartphone già sono dei pc, nel senso che possono fare tutto quello che fanno i pc....ovviamente qualcuno mi dirà che manca questo o quel programma, ma si tratta di un fattore contingente non potenziale

cioè lo smartphone può far girare photoshop, non lo fa perchè adobe non ha portato photoshop su smartphone

qualche mese fa ho passato 4 giorni e una trentina di post per cercare di far capire questo concetto a maxmax80...il brutto è che continua a ribattere a discorsi tecnici con dati di mercato

e poi c'è il fatto che i produttori di SoC arm sono partiti dal basso e stanno man mano aumentando le capacità dei loro prodotti....ovviamente progettare un SoC più potente richiede tempo e denaro, motivo per cui non abbiamo oggi SoC arm che possano competere con x86 in termini di potenza pura

ce ne sono alcuni, ma sono di nicchia ed usati solo in determinati ambiti

e c'è molto altro da dire, perchè la storia continua con gli fpga e compagnia, che sono bestioline alquanto interessanti e dalle potenzialità strabilianti

se eviti di citarmi così dopo le polemiche di ieri ed oggi è anche meglio.

detto questo Photoshop su tablet ti dicono tutti che è imbarazzante attualmente.


quando i tablet ARM saranno carrozzati per supportare applicazioni più pesanti saremo tutti ben felici di constatarlo.

hai appena detto tu stesso che come potenza pura X86 è ancora attualmente meglio.
domani si vedrà.


p.s. Intel ha anche implementato le GPU nei suoi processori per tagliare progressivamente via la fetta di mercato delle GPU discrete di bassa e media fascia.
per usi lavorativi pesanti o di gaming pesante, una GPU discreta è ancora d' obbligo

[pabloski]

Originariamente inviato da maxmax80

hai appena detto tu stesso che come potenza pura X86 è ancora attualmente meglio.

non per architettura ma perchè chi produce SoC arm è interessato ai bassi consumi più che all'elevata potenza

e infatti ci sono SoC arm per server che competono con gli xeon

Originariamente inviato da maxmax80

p.s. Intel ha anche implementato le GPU nei suoi processori per tagliare progressivamente via la fetta di mercato delle GPU discrete di bassa e media fascia.

se era solo questo il motivo, poteva benissimo metterle nei chipset

il vero motivo è che così si ottiene maggiore efficienza ( è intel stessa a dirlo ), costi ridotti e si può sfruttare l'accelerazione offerta dalla gpu ( che è sempre presente in questo caso ) per il gpgpu

Originariamente inviato da maxmax80

per usi lavorativi pesanti o di gaming pesante, una GPU discreta è ancora d' obbligo

bah, solidworks non mi dà problemi con una radeon x1600, figurati con una moderna gma di intel

semmai è il gaming il problema

[maxmax80]

Originariamente inviato da pabloski

non per architettura ma perchè chi produce SoC arm è interessato ai bassi consumi più che all'elevata potenza

e infatti ci sono SoC arm per server che competono con gli xeon

lo sapevo che tiravi in ballo ancora il famoso confronto con gli Xeon in ambito server,
peccato che qui si sta parlando di ambito tablet vs desktop e tu stesso hai detto che l' x86 ha dalla sua -per ora- la potenza

Originariamente inviato da pabloski

se era solo questo il motivo, poteva benissimo metterle nei chipset

potevano benissimo metterlo anche sul retro della mobo.
il chipset ha già accorpato NB+SB, ed evidentemente se (altre ad ARM) anche AMD fa le APU forse è la strada giusta mettere GPU & CPU insieme..
e non vedo perché intel avrebbe dovuto fare diversamente,
visto che una cpu con gpu integrata è molto più appetibile per il potenziale cliente.

detto questo fra l' implementazione di gpu "normali" (integrate da intel, arm ed anche da amd (anche se le sue sono più spinte)) e l' utilizzo di VGA PCI dalle performanche superiore, ne passa un abisso

Originariamente inviato da pabloski

il vero motivo è che così si ottiene maggiore efficienza ( è intel stessa a dirlo ), costi ridotti e si può sfruttare l'accelerazione offerta dalla gpu ( che è sempre presente in questo caso ) per il gpgpu

questo dell' efficienza di arm lo hai ripetuto fino alla nausea, abbiamo capito.
adesso pure le gpgpu tiri in ballo?
che sono una nicchia che non c' entrano con l' Ubuntu touch per smarphone!!
divaghi sempre..

[LMCH]

Originariamente inviato da AceGranger

Itanium, è nato per gli ambienti Mission Critical,

No, ricordo benissimo i primi articoli nelle riviste del settore quando ancora veniva chiamato "architettura EPIC" e poi IA-64 anni prima che venisse chiamato Itanium.
Secondo i piani iniziali doveva essere l'architettura "standard" a 64bit di Intel, da far debuttare prima nei server di fascia alta e poi piano piano sostituire gli x86 (che sarebbero "morti" come cpu a 32bit) quando il mercato gradualmente prima dall'alto e poi verso il basso avrebbe fatto la transizione verso i 64bit.
E' per quel motivo che Intel si ritrovò a dover inseguire AMD per quel che riguarda gli x86 a 64bit.

Solo quando il disastro dell'Itanium non si poteva più negare in Intel adottarono la classica strategia della volpe e l'uva e ridimensionarono gli obiettivi riguardo quella famiglia di processori.

[pabloski]

Originariamente inviato da maxmax80

lo sapevo che tiravi in ballo ancora il famoso confronto con gli Xeon in ambito server,
peccato che qui si sta parlando di ambito tablet vs desktop e tu stesso hai detto che l' x86 ha dalla sua -per ora- la potenza

l'ambito non c'entra quando si parla di architetture

Originariamente inviato da maxmax80

potevano benissimo metterlo anche sul retro della mobo.
il chipset ha già accorpato NB+SB, ed evidentemente se (altre ad ARM) anche AMD fa le APU forse è la strada giusta mettere GPU & CPU insieme..
e non vedo perché intel avrebbe dovuto fare diversamente,
visto che una cpu con gpu integrata è molto più appetibile per il potenziale cliente.

appunto, ARM lo fa da 30 anni e gli altri stanno seguendo la stessa strada

Originariamente inviato da maxmax80

detto questo fra l' implementazione di gpu "normali" (integrate da intel, arm ed anche da amd (anche se le sue sono più spinte)) e l' utilizzo di VGA PCI dalle performanche superiore, ne passa un abisso

puoi benissimo integrare una gpu discreta in una cpu...chi te lo vieta?

Originariamente inviato da maxmax80

questo dell' efficienza di arm lo hai ripetuto fino alla nausea, abbiamo capito.
adesso pure le gpgpu tiri in ballo?
che sono una nicchia che non c' entrano con l' Ubuntu touch per smarphone!!
divaghi sempre..

il fatto che tu non riesca a cogliere il perchè la situazione delle gpu è simile a quella dei SoC arm, non implica che io stia divagando

la gpu cos'é? e i SoC cosa integrano? se rispondi a queste due domande, capisci perchè le gpu seguono la filosofia, chiamiamola di ARM, e non quella delle cpu classiche ( che poi nemmeno x86 segue più quella filosofia )

e sai l'ultima? le cpu x86 attuali sono dei RISC che emulano un set d'istruzioni CISC!!!

[coschizza]

Originariamente inviato da pabloski

l'ambito non c'entra quando si parla di architetture

e sai l'ultima? le cpu x86 attuali sono dei RISC che emulano un set d'istruzioni CISC!!!

l'ambito centra sempre quando di parla di architetture perche un architettura nesce per lavorare al meglio in un determinato segmento non in tutti.

Le cpu attuali atom e i futuri atom silvermont non sono dei risc che emulano il set x86 cisc, questo vale solo per la serie di cpu desktop/server, per l'architettura a basso consumo l'intel ha mantenuto un approccio che mantenesse le istruzioni x86 su tutta la pipeline perche la conversione da cisc a risc porta via troppo spazio del die e consuma troppe risorse nel decoder e serve solo quando si devono puntare ad alte prestazioni.
Quindi gli atom odierni e futuri dopo aver fatto il fetch delle istruzioni le passano al decoder che pero a differenza delle cpu di classe superiore non le traducono in microops ma continua a usare le istruzioni x86 come base delle pipeline.

Amd con il core bobcat e in nuovo jaguar fa esattamente la stessa cosa.

[pabloski]

Originariamente inviato da coschizza

l'ambito centra sempre quando di parla di architetture perche un architettura nesce per lavorare al meglio in un determinato segmento non in tutti.

ma quando si tratta di ambiti estremamente differenti

usare il SoC di Parallela per eseguire espressioni regolari sarebbe folle, il SoC non è minimamente ottimizzato per quel genere di carico di lavoro

ma parlare di workstation o server è praticamente uguale, visto che si tratta di ambienti eterogenei, dove i carichi di lavoro sono estremamente variegati ( cioè c'è un pò di tutto )

l'unica differenza tra server e pc/workstation è la velocità dell'I/O ( i server leggono e scrivono molti dati su disco ) e la banda di memoria...ma proprio su quest'ultima, ARM mostra una flessibilità impressionante, addirittura si arriva a situazioni ( come quella della board Novena, board amatoriale!!! ) che ha una memory bandwidth molto elevata

Originariamente inviato da coschizza

Le cpu attuali atom e i futuri atom silvermont non sono dei risc che emulano il set x86 cisc, questo vale solo per la serie di cpu desktop/server, per l'architettura a basso consumo l'intel ha mantenuto un approccio che mantenesse le istruzioni x86 su tutta la pipeline perche la conversione da cisc a risc porta via troppo spazio del die e consuma troppe risorse nel decoder e serve solo quando si devono puntare ad alte prestazioni.

il che però non implica maggiore efficienza, altrimenti intel avrebbe seguito questa strada anche per le cpu core

[coschizza]

Originariamente inviato da pabloski

l'unica differenza tra server e pc/workstation è la velocità dell'I/O ( i server leggono e scrivono molti dati su disco ) e la banda di memoria.e

le differenze sono anche altre dal controllo degli errori su tutta la catena di esecuzione alla memoria e le cache ecc.
arm ora non ha nessun soc per server di fatto e nemmeno un architettura a 64bit, poi ci sono tutte le parti riguardanti la virtualizzazione e altre feature che per ovvi motivi ora ancora non sono sviluppate.

E manca sopratutto ancora un supporto software adeguato che è ancora piu importante, ma finche non ci sara l'hardware è normale che questo manchi.

[pabloski]

Originariamente inviato da coschizza

le differenze sono anche altre dal controllo degli errori su tutta la catena di esecuzione alla memoria e le cache ecc.

l'ECC è una funzionalità del controller di memoria ( non sempre interno alla cpu ), mentre per le cache si usa il controllo di parità ( ed è presente anche nelle cpu per pc )

Originariamente inviato da coschizza

arm ora non ha nessun soc per server di fatto e nemmeno un architettura a 64bit, poi ci sono tutte le parti riguardanti la virtualizzazione e altre feature che per ovvi motivi ora ancora non sono sviluppate.

AArch64 è l'architettura a 64 bit e sono disponibili già i core a53 e a57 e hanno pure la virtualizzazione

riguardo le altre feature, a quali ti riferisci? pensa che gli arm supportano pure l'accelerazione di aes e sha1/sha2, quindi non so a quali caratteristiche ti stai riferendo

e c'ha pure il supporto jtag, che gli x86 non hanno ( giusto per citare qualche plus )

c'hanno pure il supporto alle pagine di memoria non executable ( se ti riferivi a questa feature )

e ci sono pure le estensioni jazelle, ovvero accelerazione hardware per java!!! mica male

[coschizza]

Originariamente inviato da pabloski

AArch64 è l'architettura a 64 bit e sono disponibili già i core a53 e a57 e hanno pure la virtualizzazione

io parlavo di quelle che essite ora non quello che esisterà, dobbiamo parlare di quello che esiste e possiamo misurare non basarci su delle slide.

[pabloski]

Originariamente inviato da coschizza

io parlavo di quelle che essite ora non quello che esisterà, dobbiamo parlare di quello che esiste e possiamo misurare non basarci su delle slide.

Infatti http://www.anandtech.com/show/5098/a...irst-armv8-soc

2011!!!!

e quoto

"As the X-Gene implements the ARMv8 ISA it is a full 64-bit architecture that is backwards compatible with 32-bit ARMv7. The CPU features hardware virtualization acceleration, MMU virtualization, advanced SIMD instructions"

"Despite the aggressive architecture, each core is estimated to consume only 2W per core. Like most mobile SoCs, the entire chip will idle at around 300mW."

slide eh!?!