Il 31/05/2016 15:28, Jack ha scritto:
> Il giorno martedì 31 maggio 2016 11:29:41 UTC+2, Alessandro Selli ha scritto:
>> Il 31/05/2016 09:56, Jack ha scritto:
>>> Il giorno martedì 31 maggio 2016 00:52:48 UTC+2, Alessandro Selli ha scritto:
>>>
>>>> 3) le architetture a 64 bit superano la barriera di 4GiB di
>>>> indirizzamento, oggi insufficiente per una grossa quantità di
>>>
>>> questo e' l'unico punto a favore dei 64bit [1], il resto che hai detto
>>> e' fuffa,
>>
>> Sono realtà evidenti e incontrovertibili.
>
> si ma sono aggiunte che sono indipendenti dai 64 bit. Funzionerebbero tranquillamente anche con 32bit.
No, non sempre. Ad esempio, tutte le istruzioni SIMD (SSE e
successive estensioni) a 32 bit hanno benefici limitati: eseguire le
stesse operazioni su un data pool di soli 32bit limita il beneficio del
parallelismo a livello di data set. Un registro a 32 bit può, ad
esempio, rappresentare massimo quattro set di otto bit sui quali
effettuare la stessa operazione. Un registro a 64bit permette una molto
maggiore utilità dello stesso concetto. E sono ormai quasi vent'anni
che le GPU hanno registri e bus di indirizzamento a 128 bit (RIVA 128 e
ATI Rage 128, uscite nella seconda metà degli anni '90), per queste ed
altre ragioni.
E in ogni caso rimane il fatto che l'industria ha deciso che non vale la
pena castrare tecnologie più avanzate ad un bus e registri ridotti a 32
bit. Sarebbe come fare il backporting delle ultime tecnologie
meccaniche automobilistiche ai motori a spinterogeno. Non ha senso, per
quanto sarebbe in linea di principio possibile, è antieconomico, è
proprio impossibile per varie funzioni che dentro 32bit proprio non ci
possono stare.
> la 1) poi e' una gran stronzata.
> Esempio: Alix 1c (con Via Geode 800Mhz, 32 bit, 256MB ram) fa vedere la polvere
> ad una Raspberry Pi 3 (ARM quadcore 64 bit, 1GB ram)
Stai confrontando le pere con le banane. Confronta i processori dei
produttori di CPU per desktop o laptop, e facci sapere.
> nei trasferimenti via sftp (e in tutto quello che ha a che fare con la crittografia).
E qui stai già ridimensionando il campo ad un campo specifico. Hai
idea di che processore usa il RaspberryPi? Lo hai mai visto in un
portatile, in un desktop?
>>> e' semplicemente conseguenza diretta del fatto che hanno smesso di
>>> sviluppare le architetture a 32bit.
>>
>> Vedi quindi che tutto quello che ho elencato sono realtà, fatti
>> autentici. Ci sei arrivato anche tu.
>
> e' il tuo cervellino che non ce la fa a capire che ci sono features
> delle nuove CPU che dipendono dall'architettura a 64bit (la quantita'
> di memoria indirizzabile), mentre altre (virtualizzazione, crittografia,
> ecc.) sono tecnicamente indipendenti dall'architettura,
Non è vero. Ho già fatto l'esempio delle istruzioni SIMD, per la
crittografia è ancora peggio. Gli algoritmi crittografici beneficiamo
moltissimo dall'architettura a 64 bit rispetto ai 32 bit, e anzi per
questo uso specifico 64 bit sono ancora pochi, tenuto conto che la
dimensione delle chiavi simmetriche più sicure e quindi più usate sono a
256 bit (AES usa chiavi da 128, 192 e 256 bit, ad esempio).
> ma sono presenti solo sulle 64bit perche' sono state sviluppate dopo
> l'avvento dei 64bit.
Stai mettendo il carro davanti ai buoi. L'architettura a 64 bit è
stata sviluppata per potervi implementare tutto quello che in 32 non ci
stava o che sarebbe stato troppo inefficiente implementare. I 64 bit
non sono caduti dal pero, non sono stati imposti a forza bruta sul
mercato per cui ci si è dovuti arrangiare a lavorarci per forza di cose:
i 64 bit sono stati la soluzione a problemi tecnici che necessitavano di
poter operare in ciascun ciclo macchina e per ciascuna pipeline in
dataset più ampi di quello che si poteva fare con i registri e gli
indirizzi a 32 bit.
Ti fissi sempre solo sull'ampiezza del bus di indirizzazmento come se
quello fosse il solo ostacolo tecnologico insormontabile per
l'architettura a 32 bit, ma questo è solamente dovuto alla tua completa
ignoranza di come funzionano oggi i processori a 654bit e quali problemi
computazionali e di algoritmi questi sono stati sviluppati per risolvere
nella maniera più semplice, scalabile, efficiente e veloce. Non hai mai
preso in considerazione neanche il fatto più semplice: registri a 64 bit
permettono di dimezzare i trasferimenti da e verso la cache e la RAM e
permettono di ridurre drasticamente il numero di cicli di istruzioni per
l'elaborazione di vasti set di dati. Solo questi fatti permettono una
migliore efficienza e maggiori prestazioni dei sistemi a 64 bit nella
maggioranza deglil usi moderni delle piattaforme informatiche, anche a
livello di desktop e SOHO. Il gaming ha beneficiato moltissimo
dall'architettura a 64 bit, ottenere le stesse prestazioni nella grafica
e audio ad alta definizione e bassa latenza con soli 32 bit è
impossibile. A meno che non ti contenti di giocare ancora a Prince of
Persia nel III millennio.
La tua ignoranza di queste motivazioni tecniche non costituisce una
prova dell'inutilità dei 64 bit, l'ignoranza costituisce una prova solo
di se stessa.
>>> Non ci sono motivi tecnici che impediscono di portare gli altri punti su un 32bit.
>>
>> E neanche sui 16 bit e neanche sugli 8bit. Se solo avessero
>> continuato a svilupparli, eh?
>
> infatti.
Risibile. Quanta meravigliosa efficienza lavorare ad algoritmi
crittografici con chiavi a 256 bit su in processore che ha registri ad 8
bit (e che deve quindi sprecare 32 cicli di bus o usare 32 registri
simultaneamente per ciascun calcolo di has o per ciascuna iterazione
della blockchain), o usare istruzioni SIMD che permettono, ad esempio,
di aggiornare un vettore di pixel usando un registro ad 8 bit che o
indirizza quattro celle con indirizzi di due bit (che straordinaria
dimensione che avrebbe questo vettore, eh?) o che contiene la mappa
colore di quattro pixel di due bit (autentico Realcolor, vero?).
«È meglio tacewre dando l'impressione di essere stupidi
Che aprire la bocca e togliere ogni dubbio»
(un mai troppo ricordato massimo saggio)
>>> Ciao Jack
>>>
>>> [1] in realta' per applicazioni specifiche (ie. number crunching, ecc.
>>> il 64bit porta vantaggi), ma per il 99% dell'utilizzo avere un
>>> processore a 64bit non porta vantaggi apprezzabili rispetto ad un 32bit.
>>
>> Ormai *tutti* gli usi dei computer e anche degli smartphone, tablet e
>> sistemi embededed beneficiano dell'architettura a 64bit. Tutti i
>
> contando che la maggior parte dei sistemi embedded funzionano a 8, 16, 32 bit non direi proprio.
Quelli del tuo tinello. In realtà nel campo embedded si è passati
alle architetture sia multicore che 64bit prima che nel campo deskop.
Ad esempio, i processori Tile
Le ragioni per cui si è fatto?
1) scalabilità;
2) efficienza energetica;
3) modelli di programmazione più estesi ed elastici (tutto quello che
puoi fare a 32bit lo puoi fare a 64 bit, ma non viceversa).
https://www.researchgate.net/publication/265527779_The_Tile_Processor_A_64-Core_Multicore_for_Embedded_Processing
È chiaro che se tutto quello che devi fare è di leggere le misure di un
sensore di temperatura o di controllare un motore passo passo non hai
bisogno di 64bit, ma neanche di 32, ma qui stiamo di nuovo confrontando
le pere con le banane, è come dire che gli elicotteri sono inutili
perché io posso fare tutto quello che mi serve con la carriola, e si sta
uscendo dal tema che è la dismissione degli applicativi desktop (di
navigazione Internet nello specifico) per le piattaforme consumer a 32bit.
>> sistemi a 32bit sono ormai inutilizzabili per qualunque uso serio di
>> virtualizzazione. Anche nel campo dell'editoria audiovisuale poi i
>
> solamente per via della memoria eh.
Primo: sbagliato, non solo per la memoria. Ad esempio, tutto quello
scritto per le istruzioni SIMD vale tale e quale per la virtualizzazione.
> Non certo per l'ISA.
Si, invece. Riprodurre le ISA a 64 bit in un'architettura a 32 bit è
uno scempio di efficienza e di scalabilità.
> Intel ha introdotto le VT-x nel 2005, sui P4 (a 32 bit).
E quindi?
> Per "l'audiovisuale"(come lo chiami tu), l'unico vantaggio e' la memoria
> (ancora).
No, ho più volte spiegato perché. Ma le ragioni tecniche non le
affronti mai, esponi sempre solamente le tue personali impressioni
soggettive, nate esclusivamente dalla tua profonda ignoranza.
> Non per niente ci si appoggia sempre di piu' alle GPGPU per trattare
> "l'audiovisuale" proprio perche' la cpu arranca.
E sai qual'è uno dei punti di forza delle GPGPU? Il fatto che hanno
registi fino a 512 bit! (GK210 Kepler). Ma tu non lo sapevi, e ti sei
fatto bello della tua beata ignoranza per avere ragione!
>> 64bit sono fondamentali, in quel campo i 32 bit non sono minimamente
>> proponibili. Ma la lista è lunga, mi fermo qui solo perché
>> evidentemente non sto parlando con professionisti né con gente dotata di
>> un minimo di cultura ed esperienza in materia.
>
> ma lol eh.
> Invece a leggere wikipedia ci si fa una cultura della madonna eh.
Confronto a te ci si fa una cultura divina anche leggendo i fondi del
caffé.