Link alla notizia: http://www.hwupgrade.it/news/telefonia/arm-non-c-e-alcun-bisogno-di-architetture-a-128-bit_49917.html

Alcune indiscrezioni riportavano la possibilità che ARM fosse in fase di test di alcune architetture a 128-bit per le CPU mobile del prossimo futuro. Queste voci sono state stemperate dalla società attraverso un comunicato

Click sul link per visualizzare la notizia.

Condivido.
Certi vantaggi potrebbero esserci soltanto in ambito scientifico, supponendo di farsi carico dell'enorme mole di lavoro necessaria per riconvertire il software.
Già i 64 bit, stando le attuali risorse di sistema dei dispositivi mobili, sono tanti, indipendentemente dai vantaggi prestazionali ottenibili in certe situazioni, tipo riproduzione filmati, giochi, ecc.
Però nell'ottica di un'unificazione, a grandi linee, del codice, cioè che tutti i dispositivi da desktop a mobile si basino sui 64bit, risulta un vantaggio, sebbene dato che le architetture risultano diverse, la cosa è meno immediata.

Quando un'azienda fa una dichiarazione di questo tipo, significa 2 cose
1) non abbiamo ancora un processore a 128 bit
2) qualcun altro sta per presentare un processore a 128 bit

Semplicemente Arm si è trovata a costretta a smentire una speculazione totalmente infondata.

I 64bit sono stati introdotti da Arm da diverso tempo:
http://www.xbitlabs.com/news/cpu/display/20121030140134_ARM_Introduces_First_ARMv8_Cores_Cortex_A53_and_Cortex_A57_Make_Debut.html

naturalmente per l'ambito server.

Ma con gli smartphone/tablet già oggi con 3GB, inevitabile per l'anno prossimo i 64bit, con processi produttivi adeguati.

Una parte della descrizione sembra sia stata presa da qui

http://it.wikipedia.org/wiki/128_bit

Quando un'azienda fa una dichiarazione di questo tipo, significa 2 cose
1) non abbiamo ancora un processore a 128 bit
2) qualcun altro sta per presentare un processore a 128 bit
non ho letto QUESTA news, però il discorso è semplice.
ora che apple ha sbandierto i "suoi" 64 bit l'utente medio crede che una cpu a 64 bit sia meglio e più veloce di una a 32, un po come al tempo delle console 8 bit vs 16 bit 32 bit etc....
in realtà ciò è palesemente falso, e i 128 bit sono totalmente inutili, non solo in abito mobile ma anche in ambito desktop.

Quando un'azienda fa una dichiarazione di questo tipo, significa 2 cose
1) non abbiamo ancora un processore a 128 bit
2) qualcun altro sta per presentare un processore a 128 bit

Arm è un consorzio, una joint venture dei vari licenziatari arm. Se lo dicono loro è perché non c'è intenzione nemmeno nelle roadmap, di nessuno dei affiliati :D

2) qualcun altro sta per presentare un processore a 128 bit
Massì, facciamolo a 256 bit direttamente, così siamo 2 passi avanti invece che uno...
Hai idea dei problemi legati a costruire un processore che usa 128-bit per tutte le istruzioni? E per far cosa poi? Su dai, dimmi per cosa useresti un core general purpose a 128 bit.
Se vuoi fare calcoli a manetta esistono semplicmente delle bellissime unità vettoriali a 512-bit (le nuove AVX di Haswell per esempio). Ma 128 bit per eseguire somme e sottrazioni su interi sono davvero un'assurdità e un costo inutile.
Nessuno credo si metterà a progettare un processore a 128bit.
I core monolotici (tipo x86 per intenderci) ormai hanno dimostrato tutte le loro limitazioni e si va verso la differenziazione delle funzionalità con unità di calcolo separate (queste magari anche sì a 1024-bit nel futuro).

Se vuoi fare calcoli a manetta esistono semplicmente delle bellissime unità vettoriali a 512-bit (le nuove AVX di Haswell per esempio). Ma 128 bit per eseguire somme e sottrazioni su interi sono davvero un'assurdità e un costo inutile.

I core monolotici (tipo x86 per intenderci) ormai hanno dimostrato tutte le loro limitazioni e si va verso la differenziazione delle funzionalità con unità di calcolo separate (queste magari anche sì a 1024-bit nel futuro).

hai centrato in pieno il punto

ricordiamoci che la corsa ai 64 bit ( almeno quella di cui tutti sono a conoscenza ), ha riguardato l'architettura x86 e per due motivi fondati ( all'epoca ): aggiunta di nuovi registri e operazioni aritmetiche a 64 bit, oltre che accesso a più di 4gb senza dover fare i salti mortali

da allora è cambiato tutto

i produttori di SoC arm hanno sempre fatto uso di coprocessori per questo genere di carichi di lavoro, e adesso che c'è il gpgpu, tutto ciò è diventato ulteriormente superfluo

inoltre, a parte x86, le altre architetture non hanno mai sofferto di carenza di registri generali

oggi, la stessa architettura x86 ha virato verso le architetture SoC, addirittura amd sogna un futuro in cui cpu, gpu, dsp e unità di calcolo tutte da inventare, interagiranno tra di loro senza limiti

dunque, cui prodest? a che servono i 128 bit? almeno i 64 bit servono per rimuovere il limite dei 4 gb, ma i 128 non serviranno almeno fino al 3040 :D

ovvio, se di mezzo c'è il marketing, è meglio farli a 64 bit, ma ancora meglio a 128 bit ( che fa più figo )

Una tecnologia nuova non sempre viene utilizzata immediatamente, semplicemente poiche', non essendoci mai stata prima, nessuno ha mai pensato ai modi in cui impiegarla. Agli albori dell'informatica si pensava che nel mondo non sarebbero MAI serviti piu' di 5 / 10 computer; Bill Gates negli anni '80 dichiaro' che non sarebbero serviti MAI piu' di 640KB di memoria di sistema. Esempi cosi' ce ne sono migliaia nel mondo informatico, e tuttavia vengono smentiti costantemente col passare del tempo.
Facciamo l'ipotesi assurda che domani Intel o AMD tirino fuori dal cilindro magico un'architettura a 1024 bit (ovviamente compatibile con il codice x86_64, perche' l'informatica e' come il maiale, non si butta via nulla). Beh in quel caso nessuno vieta di studiare istruzioni a 1024 bit magari riguardanti sistemi matematici complessi, geometrie non euclidee, crittologia, decrittazione, compressione dati, ecc... ecc... Semplicemente se hai una possibilita' in piu' piano piano la sfrutti.
Ma se non sai di averla o nessuno la sviluppa perche' si pensa non sara' utile, semplicemente nessuno inziera' ad usarla...

Arm è un consorzio, una joint venture dei vari licenziatari arm. Se lo dicono loro è perché non c'è intenzione nemmeno nelle roadmap, di nessuno dei affiliati :D

e dove lo hai letto che arm è un consorzio/ joint venture dei licenziatari? topolino o donna moderna?

e dove lo hai letto che arm è un consorzio/ joint venture dei licenziatari? topolino o donna moderna?

non sarò preciso ma tu con quel fare da duro, cavolo, paura e delirio..
"About ARM

ARM Holdings is the world's leading semiconductor intellectual property (IP) company. ARM’s strategy is for our technology to continue to gain share in long-term structural growth markets such as mobile phones, consumer electronics and embedded digital devices. To date, ARM has licensed its technology over 1000 times to more than 350 ARM partners, who have shipped over 45 billion ARM-based chips."

E infatti dice che non e' un consorzio. ARM Holdings significa la "ditta ARM", per farla semplice. Poi il suo bisness e' dare l'architettura in licenza, il che non c'entra nulla con il consorzio.
bye

non sarò preciso ma tu con quel fare da duro, cavolo, paura e delirio..
"About ARM

ARM Holdings is the world's leading semiconductor intellectual property (IP) company. ARM’s strategy is for our technology to continue to gain share in long-term structural growth markets such as mobile phones, consumer electronics and embedded digital devices. To date, ARM has licensed its technology over 1000 times to more than 350 ARM partners, who have shipped over 45 billion ARM-based chips."

non è essere precisi, è dire cose errate.
il fatto che (dal tuo quote) arm ha venduto le sue licenze più di 1000 volte a 350 partner, non vuol dire che è un consorizo, ma che ha 350 clienti.

Una tecnologia nuova non sempre viene utilizzata immediatamente, semplicemente poiche', non essendoci mai stata prima, nessuno ha mai pensato ai modi in cui impiegarla.
Se non è stata sviluppata è perché nessuno ne ha avuto bisogno prima, altrimenti viene sviluppata proprio per risolvere uno specifico problema.
Mi sembra che abbiate le idee confuse su cosa avvvenga nei laboratori di R&D.

Beh in quel caso nessuno vieta di studiare istruzioni a 1024 bit magari riguardanti sistemi matematici complessi, geometrie non euclidee, crittologia, decrittazione, compressione dati, ecc... ecc... Semplicemente se hai una possibilita' in piu' piano piano la sfrutti.
Ma non serve studiare degli algoritmi "fasulli" solo per far andare i bit aggiunti a un nuovo micro. Il fatto è che se fai un micro da 1024-bit sarà necessario fare solo conti di un certo tipo per sfruttarlo, al che va a farsi benedire l'indicazione di General Purpose e diventa Application Specific. Il che significa che del tuo micro da mille bit e dal costo di altrettanti euro ne venderai 1000 in tutto il mondo, al che ti viene da pensare sul perché mai hai fatto una cagat@ del genere e non hai invece pensato di fare un sistema più semplice che usava unità di calcolo esterne da montare solo dove servono (micro per server HPC) o non hai sviluppato una soluzione con delle FPGA per soddisfare quei mille clienti.
Con una FGPA se vuoi oggi ti puoi fare, se sei capace, il chip con tutti i mille bit che vuoi. Ma non vuol dire che andrai più veloce. E infatti non li fa nessuno. Al massimo si fanno delle unità di calcolo ad hoc che sono in grado di fare i conti mille volte più veloce di una CPU General Purpose. E quelle si sfruttano per risolvere qualsiasi tipo di algoritmo super complesso che ti venga in mente.
Almeno, questo è ciò che è avventuo per anni prima del dominio di Intel con la sua politica monolitica e grandi fabbriche per sostenerla.
Oggi che la corsa alla miniaturizzazione si fa più difficile e aumentare le prestazioni di quegli elefanti di X86 si fa una fatica enorme (si continua da un paio di generazioni a raddoppiare i transistor per avere nei casi migliori prestazioni migliori del 15%), forse, si spera, si riuscirà a tornare ad uno sviluppo più intelligente e che permetta a chiunque con le giuste capacità di far avanzare il progresso in questo campo.

Quando dovremmo avere in un sistema più di 16 EB(ExaByte) cioè 16 miliardi di GB di RAM, allora avremmo la necessità dei 128bit.
Non credete che il tempo sia tanto cmq.
Quando si passo da 16 a 32bit negli anni '80 (con 16 Bit il massimo indicizzabile di RAM sono 64K) il nuovo limite dei 4GB sembrava irraggiungibile invece sono bastati una 20ina d'anni

non è essere precisi, è dire cose errate.
il fatto che (dal tuo quote) arm ha venduto le sue licenze più di 1000 volte a 350 partner, non vuol dire che è un consorizo, ma che ha 350 clienti.

Essendo una società per azioni, dentro il cda ci sono intel samsung e soci.. o almeno i loro uomini.

Quando un'azienda fa una dichiarazione di questo tipo, significa 2 cose
1) non abbiamo ancora un processore a 128 bit
2) qualcun altro sta per presentare un processore a 128 bit
ahahah vero... la stessa cosa che ho pensato io!

Essendo una società per azioni, dentro il cda ci sono intel samsung e soci.. o almeno i loro uomini.In realtà scorrendo la board of directors così non sembra... La ARM sembra più immischiata con i provider di telecomunicazioni, alcuni fondi di investimento tecnologici e, ovviamente, i detentori dei brevetti che usa...

Essendo una società per azioni, dentro il cda ci sono intel samsung e soci.. o almeno i loro uomini.

:mc: :mc: :mc: :mc: :mc:
in realtà non mi pare proprio ma lieto di essere smentito

Quando dovremmo avere in un sistema più di 16 EB(ExaByte) cioè 16 miliardi di GB di RAM, allora avremmo la necessità dei 128bit.
Non credete che il tempo sia tanto cmq.
Quando si passo da 16 a 32bit negli anni '80 (con 16 Bit il massimo indicizzabile di RAM sono 64K) il nuovo limite dei 4GB sembrava irraggiungibile invece sono bastati una 20ina d'anni

beh ma stavolta non bastano certo 20 anni per esaurire lo spazio di indirizzamento a 64bit, va bene il progresso ma stiamo parlando di numeri spaventosi, almeno da quel punto di vista siamo in una botte di ferro per un bel pezzo

Essendo una società per azioni, dentro il cda ci sono intel samsung e soci.. o almeno i loro uomini.

Parafrasando Di Pietro: " che ci azzecca un consorzio con una società per azioni "??

Un consorzio è un gruppo di soggetti indipendenti che uniscono le loro risorse in determinati ambiti finalizzate ad un progetto comune; un esempio di consorzio fu " AIM " ( Apple - IBM - Motorola ) finalizzato alla diffusione della piattaforma Power PC, dove IBM disegnava l'architettura PPC, Motorola si occupava della messa su silicio e Apple era l'end user della piattaforma con il compito di supportarla con il suo OS e strumenti di sviluppo. Nessuna fusione di capitali in una nuova società e nessun board di azionisti.
ARM invece nacque come una vera propria società a se stante nel 1990 come joint venture ( leggasi unione di capitali e di tecnologie ) tra Acorn Computers, Apple e VLSI. A differenza di un consorzio, ARM Ltd. ha un suo board e un suo bilancio e, soprattutto una politica aziendale completamente indipendente.

Sul topic: penso anche io che i 128 bit siano completamente inutili sulle piattaforme mobili… come gran parte degli attuali 64. Per motivi di autonomia energetica nessun tablet, smartphone e altra diavoleria associata, potrà usare quantitativi di Ram sufficienti a giustificare architetture così avanzate...

Citando qualcuno di cui ho dimenticato il nome (:p ) "4 PetaByte di memoria dovrebbero bastare per tutti"... eppure i PC moderni arrivano senza problemi ad 8 GB!

A cosa servono? In buona parte, ad essere onesti, vengono semplicemente sprecati:


2 GB li occupa Windows perchè è, ormai, pesante e non ottimizzato (lo so 8 è meglio di Vista, ma almeno 1 GB se lo ciuccierà per disegnare tutti quei pupazzetti & bamboline, no?)
Firefox con le ultime versioni è molto migliorato... ma se apri tante TAB come faccio io (a volte sono nell'ordine del centinaio) ecco che altri 2 GB se ne vanno
Vi piacerebbe anche usare OpenOffice contemporaneamente, vero? Il mio vecchio PC che di RAM ne aveva 4, ma grazie a Windows XP ne vedeva solo 3 GB iniziava già a swappare! Quello che mi comprerò a breve almeno avrebbe ancora un po' di spazio di manovra...


In ogni caso non credo 4 PB potrebbero mai servire agli utenti desktop, ma magari un 100-200 GB tra 10 anni saranno necessari sia perché il software sarà mal ottimizzato ancora di più o perché in qualche modo troveranno il modo di farceli sentire come necessari (8K di risoluzione, 3D in real time, realtà virtuale, ...?).

Ritornando al discorso 128 Bit, non credo si noterebbe una vera differenza non sono "più veloci"... io credo che il vero limite sia proprio il "bit" perché limitarsi a solo 2 stati?
Gli alimentatori moderni non hanno problemi a generare voltaggi differenti (nelle schede madri girano senza problemi 0, 5 e 12V) e i sensori di oggi sono molto più sensibili di quelli di un tempo; ecco per esempio come potrebbe funzionare un PC trinario:


-5 V = false
0 V = neutral
+5V = true


avere 3 stati già cambierebbe radicalmente le cose... se poi riusciamo a passare a 10 come noi ominidi... ma a quel punto il computer quantistico sarà più conveniente.

Manco un pc domestico ha un processore a 128bit, che senso ha addirittura parlarne per un SoC?

Mah 128 bit potrebbero essere utili per gestire in modo efficiente strutture di dati, specialmente grafica, piu' che per aumentare il range della memoria (alla fine significherebbe anche aumentare il quantitativo di memoria minima necessaria)

Ritornando al discorso 128 Bit, non credo si noterebbe una vera differenza non sono "più veloci"... io credo che il vero limite sia proprio il "bit" perché limitarsi a solo 2 stati?
La strada dei computer non binari è stata percorsa agli albori dell'informatica (nel senso che sono stati costruiti ed utilizzati computer non binari), ma alla fine l'uso del bit si è dimostrato vincente.
Dal momento che ancora oggi utilizziamo le stesse tecnologie del passato (affinate, ridotte di dimensioni, migliorate nei materiali, ma in fin dei conti le stesse), direi che la strada del bit è ancora la migliore.
In futuro chissà, tecnologie del tutto nuove potrebbero far rivalutare questa scelta, il computer quantistico con i suoi qbit ne è un esempio. Ma come puoi facilmente vedere, usare tecnologie del tutto nuove, come quella quantistica, non è affatto semplice.

2) qualcun altro sta per presentare un processore a 128 bit

Ma assolutamente... O.o
E' solo un bus enorme... Ci saranno bus a 128 bit, forse, quando il livello d'integrazione sarà ESTREMAMENTE maggiore rispetto a quello attuale o quando il computer invece di essere basato su una scheda madre lavorerà su un CUBO madre per contenere tutte le piste di rame... >.>
Anche potendo costruire una scheda madre che supporti i 128 bit serve abbastanza potenza per rendere UTILI quei 128 bit, in caso contrario converrebbe comunque usarla come x64 o come x86 tramite emulazione a mio parere... Questo parlando di utilità di avere una definizione così alta dei dati ovviamente.
Sono l'unico dell'idea che bisognerebbe ottimizzare i software PRIMA di esasperare ed OLTRE ad esasperare l'hardware? Alla fin della fiera, se guardiamo il motivo per cui sono richieste tante risorse è più che altro per le applicazioni grafiche, di montaggio video/audio e/o per il gaming... A quel punto direi che sono i programmatori a doversi sbattere a cercare di ottimizzare l'uso di risorse... Se volessi fare un paio di esempi di giochi mal ottimizzati: Supreme commander 1, X-Rebirth. In X-Rebirth vabbè... li l'ottimizzazione proprio è un concetto che NON ESISTE... In supreme commander (per chi non lo sapesse un RTS) i programmatori si sono DIMENTICATI di chiudere i singoli thread delle unità alla morte delle stesse con il risultato che dopo che vengono create tot unità il gioco inizia a rallentare sempre di più fino a diventare ingiocabile, e neanche salvare e ricaricare serve poichè riapre anche i thread delle unità morte (notar bene, secondo me è un gioco stupendo, se non avessero fatto ste cazzate poteva tranquillamente tener testa a starcraft 2 come ai tempi faceva total annihilation con starcraft 1)... Insomma: Una bella merda di coding. Questo era solo un esempio per far capire quanto male usiamo le risorse che abbiamo a disposizione, ovviamente. Non serve un'architettura a 128 bit per ora, solo un migliore utilizzo delle stesse U.U
Alle volte mi manca il mio vecchio pentium 3 500... >.>

Non ho detto che sia facile soprattutto pensando che appunto a parte qualche esperimento e credo una manciata di computer funzionanti in Unione Sovietica poco si è studiato su tecnologie diverse da quella binaria.

Per quanto riguarda la transizione -5 (false) ==> +5 (true) è vero c'è lo 0 (neutral nel mio modello) in mezzo, e per discriminare andrebbe quindi tenuto conto della "durata" ovvero campionare il segnale in modo da avere un onda quadra più chiara... cosa questa che un qualunque convertitore A / D già fa... non credo si avrebbero problemi di efficienza con i sensori moderni... se i Russi lo facevano negli anni '60 vuoi dire che non lo sappiamo fare oggi?

Certo il problema di come memorizzare il "trit" ci sarebbe i dispositivi di memorizzazione in un modo o nell'altro scrivono degli 0 e degli 1... non sarebbe facile, ma prima o poi si dovrà fare questo cambio i PC binari sono "morti" da anni, concordate?
Raggiunti i 3 Ghz si è visto che più oltre non si poteva andare pena dover usare sistemi di raffreddamento da centrale nucleare), ed ecco allora il multicore (che non serve ad una mazza! Perché pochissimo software ancora oggi supporta i più di un core di esecuzione), i 64 bit (che tanto poi 4 PetaByte di RAM in un PC non ci possono stare... è un limite fisico non ci stanno!), poi la GCPU o APU come piace dire ad AMD (e di nuovo non serve ad una mazza visto che è difficilissimo programmare una GPU per qualcosa di diverso da grafica... OpenCL è un delirio! Programmare in assembler è più semplice), poi ri-aggiungiamo i co-processori (come l'Amiga e che Intel negli anni '80 diceva che non servivano ad una mazza) e poi?

Quindi, in conclusione, la vera "rivoluzione" non si avrà aumentando i bit od altre diavolerie, ma con computer a più "bit" o, meglio, computer quantistici sperando che si muovano a farlo... e che gli convenga certo :p

... certo se poi un computer quantistico, una Intelligenza Artificiale deve essere retro-compatibile con X86 siamo fritti :Prrr:

:mc: :mc: :mc: :mc: :mc:
in realtà non mi pare proprio ma lieto di essere smentito

difficile sapere la mappa del potere e la distribuzione dei pacchetti azionari ma fidati che se io devo usare a pagamento una tua tecnologia che mi fa fare profitto, e tu mi rendi disponibili share della tua azienda, io cercherò di comprarti pian piano e arm è la gallina dalle uova d'oro in questo decennio: uno per compensare il costo delle royalties, due per pilotare verso i miei interessi le decisioni del consiglio (togliendo aria magari a samsung od apple), tre impedire che la gallina possa morire per scelte improprie, affondando anche il mio business.
E ricorda che non lo farò direttamente, per evitare conflitti di interessi e posizioni dominanti, bensì attraverso una matriosca di uomini e società che trattano valori azionistici.

Per il resto la questione dei bit è come quella dei megapixel, servono solo al 99% degli acquirenti per bullarsi al bar con gli amici dopo la partita. :D

@fano

Un campionamento è una operazione generalmente lenta rispetto alle velocità che puoi teoricamente raggiungere dall' elettronica impiegata(necessita di svariati cicli di clock), oltre che a necessitare di un elevato numero di transistor.Con l'attuale tecnologia a due stati su cmos fare reti combinatorie , anche molto complicate, che riescono a cambiare stato in un ciclo di clock è invece 'banale' . Riusciresti a costruire un computer lentissimo che passa più tempo a campionare il segnale che a eseguire operazioni, oltre che a occupare uno spazio mostruoso.


In ogni caso per un Computer quantistico, che può avere più stati e non solo 0 e 1, un sistema per misurare questi altri stati andrà fatto (leggo ora che il primo Quantum Computer esiste già ce l'hanno solo Google e la NASA... non è economico viene 15.000.000 $ :D)... anche se, se ho capito bene, alla fine del "campionamento" i qubit collassano nei classici 0 e 1... ma non è che ho capito molta cosa Wiki voleva dire mi sembrava Star Trek quando cercano di spiegare come funziona il teletrasporto ("Il teletrasporto funziona per mezzo di una Matrice Quantica interpolata con il coseno di phi espresso in steradianti diviso per la radice quadrata di PI Greco * il Numero di Neplero" :mbe: ).


Il problema, è che con un sistema a più livelli avresti mediamente molti più transistor che stanno in uno stadio intermedio tra la conduzione e l'interdizione durante una transizione. Questa è anche una delle cause fisiche del perchè un circuito logico a semiconduttore consuma. Anche supponendo di non avere il problema sopra descritto, per limiti intrinseci dei sistemi a semiconduttore, per evitare problemi legati alla rumorosità dei transistor il computer dovrebbe utilizzare una tensione proporzionale al numero dei livelli utilizzati. Poichè la potenza dissipata va come il quadrato della tensione avresti una CPU che consuma enormemente di più di quelle attuali.

Poi beh, di esperimenti nel campo dei calcolatori ce ne sono infiniti (computer analogici, idraulici , meccanici, biologici etc etc) poi però per i limiti sopra citati la scelta di utilizzare la logica binaria su semiconduttore è stata vincente. Non dico che sia impossibile un computer a multilivelli 'utile', in un futuro non prossimo, ma dovranno essere utilizzate tecnologie costruttive radicalmente differenti dalle attuali.


La mia impressione, errata magari, è che un computer a più bit non fu sviluppato perché negli anni '60 non era pratico, non lo è nemmeno oggi perché non ci si studiò più sopra, se lo avessero fatto avremmo campionatori multi-stato in realtime...
in un certo senso sono quasi 30 anni che i PC non cambiano in fondo, in fondo son tutti 486 a frequenze elevate, che credono di avere più core, che credono di andare a 32 (ma in realtà durante il boot si presentano come 486 a 16 o "modalità reale") o a 64 Bit (AMD64 avendo retrocompatibilità con il passato è un accrocchio, Intel aveva ragione a voler buttare via X86 con Itanium, peccato che il mercato la pensasse diversamente :cry: ), ...


Si, però anche qui aumenti il grado di complessità, consumo, e lentezza, rispetto a un sistema puramente binario.


Beh nella fase iniziale magari ci saranno dei convertitori da multi-bit a bit per gestire le periferiche esterne, poi pian, piano ci faranno cambiare tutto :Prrr:

Ci sono stati prototipi di dischi (simil Blu Ray mi pare) in cui l'informazione veniva memorizzata utilizzando più lenti colorate diversamente quindi, anche qui, non più solo 0 e 1, ma anche 2, 3 , 4... si potrebbero sposare perfettamente con un computer multi stato, no?


Ti do ragione sul fatto che molte cose che stanno spuntando in questo periodo sono una 'pezza' al fatto che è ormai difficile aumentare la velocità del calcolo seriale. Detto questo io non la vedo in maniera così tragica visto che i computer casalinghi attuali hanno una velocità ragguardevole, e chi necessita di più potenza può permettersi di scrivere codice parallelizzato (per esempio, io non vedo l'ora che esca lo standard OpenACC su gcc) o basato su soluzioni custom. Per quel che mi riguarda guardo anche di buon occhio le soluzioni basate su fpga (alcuni dicono che con i memristori questa diventerà una tecnologia 'popolare').


Io lo vedo come un limite, non perché 3 GHz (che poi son realmente 2.6... 3 solo col "turbo") siano pochi in assoluto, ma perché le applicazioni sono così mal scritte che ti ciucciano un core in un attimo e NON riescono a capire che ce ne sono altri!
Un esempio: prova a settare FFDSHOW con l'opzione per migliorare la qualità dei DIVX quella più trugna... la qualità diventa indistinguibile da un DVD / Bluray, ma guarda la CPU in task manager vedi? La CPU è "solo" al 25%, ma il video va a scatti... perché? Perché FFDSHOW vede un solo core ecco perché! OK i codec LAV e CoreAVC supportano l'accelerazione via GPU (persino Intel Quick Sync ero riuscito a far funzionare prima che il mio PC tirasse le cuoia), ma la qualità è inferiore a quella che potrebbe darmi FFDSHOW con tutti i filtri abilitati... peccato che ci vorrebbe un PC con un solo dannato core, ma a 6-7 Ghz :muro: !

Ho dato un'occhiata a OpenACC se ho capito bene si tratta di usare dei pragma per istruire il compilatore a compilare il codice per la GPU invece che per la CPU, giusto?

Certo meglio che dover scrivere i kernel direttamente nel linguaggio della CPU però mi sembra ancora troppo macchinoso... io, invece, trovo interessante HSA: tu scrivi codice in C++ o Java senza scrivere codice particolare, ma NON compili per la CPU o GPU, ma per una macchina virtuale, sarà essa con l'aiuto di LLVM a ricompilare per CPU, GPU o e questo è molto interessante eventuali altri coprocessori presenti nel sistema (per esempio se stiamo scrivendo un decoder video e abbia una scheda acceleratrice apposita viene usata quella invece della CPU o GPU!).

Le future versione di JAVA non compileranno più in bytecode, ma direttamente in questo nuovo linguaggio (Progetto SUMATRA) togliendo la necessità di un'ulteriore conversione.

Tutto molto bello, vero? Peccato che Intel e Microsoft (e al 99% anche NVIDIA) metteranno i bastoni tra le ruote e quindi resterà una tecnologia di nicchia destinata ad essere dimenticata come altri mille accrocchi per mantenere in vita tecnologie ormai morte!


Poi beh, prima o poi faranno uscire anche i maledetti computer al grafene :P

Speriamo di vederli prima di andare in pensione... va a finire che tornando IT faranno invece il 486 a 128 BIT, poi a 256, 512... altro che :D

difficile sapere la mappa del potere e la distribuzione dei pacchetti azionari ma fidati che se io devo usare a pagamento una tua tecnologia che mi fa fare profitto, e tu mi rendi disponibili share della tua azienda, io cercherò di comprarti pian piano e arm è la gallina dalle uova d'oro in questo decennio: uno per compensare il costo delle royalties, due per pilotare verso i miei interessi le decisioni del consiglio (togliendo aria magari a samsung od apple), tre impedire che la gallina possa morire per scelte improprie, affondando anche il mio business.
E ricorda che non lo farò direttamente, per evitare conflitti di interessi e posizioni dominanti, bensì attraverso una matriosca di uomini e società che trattano valori azionistici.

Per il resto la questione dei bit è come quella dei megapixel, servono solo al 99% degli acquirenti per bullarsi al bar con gli amici dopo la partita. :D

si con questo concordo, ma è un qualcosa di diverso e sotterraneo, e impossibile da verificare

in un certo senso sono quasi 30 anni che i PC non cambiano in fondo, in fondo son tutti 486 a frequenze elevate, che credono di avere più core, che credono di andare a 32 (ma in realtà durante il boot si presentano come 486 a 16 o "modalità reale") o a 64 Bit (AMD64 avendo retrocompatibilità con il passato è un accrocchio, Intel aveva ragione a voler buttare via X86 con Itanium, peccato che il mercato la pensasse diversamente :cry: ), ...

Ma hai presente come era l'Itanium ? :sofico:

A confronto x86-64 sembrava un capolavoro di pulizia, design e lungimiranza.
Non sto scherzando, l'Itanium era una mostruosità "progettata da un comitato" (nel senso di tanti progettisti ognuno con potere decisionale ed ognuno con una feature da inserire costi quel che costi).

In origine doveva essere una cpu VLIW (Very Large Instruction Word) a parallelismo esplicito.
Ma poi hanno inserito la compressione delle istruzioni, nel senso che invece di avere un istruzione "ampia" di lunghezza fissa che corrispondeva a più istruzioni, hanno utilizzato istruzioni più corte che andavano composte insieme dal decoder (utilizzando dei flag nelle istruzioni).
Poi hanno aggiunto un fottio di registri (equivalenti nel loro insieme a 4KByte di memoria, se ricordo bene) perchè con tante istruzioni potenzialmente in esecuzione simultanea sulle pipeline servono anche tanti registri per i dati temporanei, ma questo set di registri enorme "visibili al compilatore" comportava un aumento dei tempi di accesso (più simili a quelli di una cache L1 che a dei veri e veloci registri) a causa della decodifica più complessa ... dell'indirizzo dei singoli registri.
Poi visto che c'erano tante istruzioni potenzialmente in esecuzione, hanno aggiunto dei bit di predicazione (nel senso di predicato logico, non di preghiera) che permettono di "annullare" istruzioni in uscita dalle pipeline se il loro predicato risulta falso ( in modo da evitare di dove per forza usare la jump prediction, iniziando ad eseguire contemopranemanete due o più diramazioni di flusso ed "annullando" quelle che poi risaltano non essere la diramazione valida).
Oltre a questo hanno aggiunto altra roba ancora, incluso un intero core 486. :eek:
A quel punto si sono accorti (sorpresa!) che non salivano bene di clock
(troppa circuiteria con interdipendenze e che scaldava a bestia)
ma hanno pensato bene di compensare la cosa con cache enormi (alvando i costi ma ottenendo così prestazioni migliori).

Infine quando sono usciti sul mercato con la prima versione ... divenne evidente che avevano esagerato con le unita floating point a scapito di quelle integer con il risultato che in certi tipi di calcolo (tipo software gestionale) un x86 andava più veloce. :doh:
Non parliamo poi delle cpu RISC di punta tipo gli Alpha che gli piglivano a claci in cu:ciapet:o su tutta la linea in termini di prestazioni di un sistema completo (perchè alla fine è quello che conta).

Ed infine la ciliegina sulla torta: tante delle feature "fantastiche" degli Itanium richiedevano un compilatore super-ottimizzante che le riuscisse a sfruttare, solo che il compilatore disponibile allora non era così "fantastico" (e neanche quelli successivi).

In IBM devono essersi fatti grasse risate quella volta, perchè avevano già studiato cosa si poteva ottenere da un VLIW pimpato per bene ed avevano concluso che gli conveniva continuare a puntare sui RISC e renderli multi-core (come infatti hanno fatto con i POWER di fascia alta).

Fu anche a causa del disastro tecnologico di Itanium che poi in Intel decisero (a torto) di puntare solo sull'architettura x86.

Vorrei sapere cosa se ne farebbero gli utonti medi alle prese con Facciabook di sistemi a 128 bit :D