Newsgroup: it.comp.lang.c++
Titolo: quale interi usare?

ciao a tutti,
mi trovo a fare un programma nel quale la maggior parte delle variabili sono
degli interi che rientrano in un range 0->255. Mi chiedevo, dato che in questa
applicazione la velocita' e' un fattore cruciale, č meglio usare tipi di dato
unsigned char, unsigned short, oppure unsigned int? L'occupazione di memoria
non mi interessa, l'importante e' solo la velocita' di esecuzione.
Inoltre, c'e' differenza tra il numero di cicli di clock, se uso unsigned oppure signed?
Paolo

 nsigned oppure signed? 
In che senso?
Se ti riferisci al numero di cicli di clock per prelevare il singolo 
dato, allora no, perché prelevi entrambi i tipi in un solo accesso alla 
memoria (che occupa sempre un numero noto di cicli di clock).
Se ne devi prelevare una quantità maggiore di 1 allora i cicli di clock 
possono differire nei due casi per quanto detto sopra.
Ciao,
Marcello.

 possono differire nei due casi per quanto detto sopra.
In effetti non mi ero spiegato bene: intendevo dire se le operazioni
matematiche (solamente addizioni, sottrazioni, moltiplicazioni e divisioni)
differiscono in termini di velocita' , tra i tipi unsigned e signed (interi). 

 oppure signed?
Penso di no.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 e signed (interi). 
il problema si complica.
Se fai molte più operazioni che accessi in memoria allora ciò che ti 
suggerisce EMG ti dovrebbe portare ad usare interi.
Altrimenti è il contrario.
Scusa. Ma che ti costa usare una definizione centralizzata del tipo ed 
effettuare un benchmark delle due soluzioni? ;-)
Ciao,
Marcello.

 possono differire nei due casi per quanto detto sopra.
Per definizione la versione unsigned ha la stessa dimensione della
versione signed dello stesso tipo. Anche in termini di operazioni non
c'e' motivo perche' ci siano differenze di prestazioni.
Ciao,
Nicola

 In che senso ?
non ho nessun manuale sotto mano, per cui non posso cercare il 
clock effettivo.
Azzardando un parere buttato lì, se non ricordo male l'algebra 
unsigned esegue meno controlli sul flag di riporto (carry), e 
usa solo quello di zero per segnalare overflow (condizione 
peraltro ritenuta non di errore), per cui qualche infimo 
vantaggio potresti pure averlo. Di solito ci sono indicazioni 
più stringenti per suggerire di usare algebra signed/unsigned 
rispetto alla velocità relativa, che imho è davvero molto simile 
come prestazioni. I test (nei cicli) e gli errori, sono spesso 
più subdoli con l'algebra unsigned.
Ad esempio, se hai un contatore unsigned ed esso ha un valore 
iniziale dispari, e tu ad ogni ciclo lo decrementi di due o un 
numero pari (o se hai sfiga anche dispari), e metti una 
condizione di uscita ciclo quando il contatore vale zero, ebbene 
il ciclo ti si looppa per sempre, perché il contatore unsigned 
ti scavalca lo zero da sotto e torna a valere 0xFFFFFFFE o 
simili (valori maggiori di zero). Se non stai attento, lo zero è 
sfuggente nei cicli unsigned, diciamo.,
ciao
Soviet


 c'e' motivo perche' ci siano differenze di prestazioni.
Già. In realtà mi riferivo a prelevare una "quantita maggiore di 1" di 
valori unsigned. Non si è mai parlato di signed.
Saluti,
marcello.

 tipo "operazione singola dati multipli".
Naaa. :-)
Ciao,
marcello.

> Non si è mai parlato di signed.
Mi correggo. Se ne era parlato. Ero io a non averlo letto. :-)
Ciao,
m.

>> un singolo accesso alla memoria. 
non mi risulta, ma forse sono rimasto indietr, che tutti i 
blocchi di 8 bit di ciascun registro siano referenziabili 
indipendentemente e usabili nei calcoli algebrici .... E' così 
nei nuovi processori ?
Se è così allora è ovvio che avresti ragione tu. Nel caso, come 
si chiamano in codice questi sottoregistri ?
Io conosco solo AL, AH, AX, EAX (e analoghi). Ma come si chiama 
ad es. il terzo byte di EAX ? e i 16 bit superiori ?
ciao
Soviet


P.S. ma mi rispondi dal futuro o hai l'orologio avanti di un po' 
? :-)
eh eh he he
ciao
Soviet

 marcello.
Noto con piacere che sei dinuovo tra noi....è sempre bello leggerti.
Concordo pienamente con te :p
suami

> valido.
Paolo
-- 
A Bright (
http://www.the-brights.net
)
"Anche se detesto quello che dici,
  difendero' fino alla morte il tuo diritto a dirlo."
	(Voltaire)

penserei che la cosa diventi più lenta.
I tempi di accesso alla memoria sono di ordini di grandezza superiori 
rispetto a quelli per le operazioni tra registri.
Saluti,
Marcello.

 ? :-)
La prima che hai detto. ;-)

 Marcello.

 etc. Questo non si può dire a priori.
Sì, anch'io avevo evitato di considerare la gerarchia di cache per 
semplicità.
Ciao,
Marcello.

 operazione dal punto di vista del processore è asincrona. 
mmmm, molto interessante. Devo dire di avere imparato una cosa 
che non sapevo. Anzi, ero convinto che, tempi di latenza a parte 
(comunque piuttosto costanti e prevedibili, in base ai settaggi 
della velocità della ram e del bus che vi accede), l'operazione 
fosse tuttosommato se non sincrona cmq dotata di un timing 
prevedibile, ad es. stimabile usando i più sfavorevoli parametri 
di clock della ram e la peggiore latenza .... asincrono invece 
mi suggerisce una certa indeterminazione dei tempi massimi (cosa 
che davo per scontato nell'accesso a disco ad es.) di attesa. Ma 
ovviamente non ho una conoscenza approfondita di questi 
meccanismi interni nemmeno nei processori che conoscevo 
relativamente meglio, per cui prendo per buona la tua 
precisazione, di cui ti ringrazio.
Già che ci sono ti espongo un altro vecchio "dogma" realativo 
alla velocità in strada di codice ottimizzato a mano : si 
leggeva molti anni fa che non era consigliabile in realtà 
eseguire troppe istruzioni sui soli registri interni, ma era 
efficiente mixarle con istruzioni di spostamento dati alla ram, 
perché le prime, se presenti in alto numero consecutivo, erano 
così rapide che l'unità di prefetch non teneva il passo e presto 
si svuotava la pipeline delle istruzioni eseguibili.
In definitiva diventava penalizzante non tanto l'accesso alla 
RAM (porzione dati) ma quello, sempre alla RAM ma alla porzione 
codice eseguibile. Dicevano che con la coda di prefetch vuota, 
il processore rimaneva in stand by sin quando l'istruzione 
successiva non era reperita dall'apposita pipeline e mandata 
all'unità di esecuzione.
In effetti, a ripensarci, anche se riguarda un aspetto diverso, 
questa teoria è concettualmente in accordo con quanto dicevi tu 
(nel senso che l'accesso alla ram parrebbe limitante rispetto al 
core di operazioni svolte tutte intra-registri). Tuttavia anche 
il semplice accesso al CODICE (non dati) avviene alla ram, e un 
eccesso di operazioni veloci consecutive parrebbe essere 
limitato da ques'ultimo collo di bottiglia.
Diventa allora difficile stimare quanto frequentemente fare 
accessi ai Dati per garantire che cmq la coda di istruzioni non 
si svuoti.
Che ne pensi, sono considerazioni superate dalle architetture 
attuali ?
ciao
Soviet
P.S.
ah .... si, al solito, debbo scusarmi perché il thread (che pure 
una volta tanto non ho lanciato io), sta andando totalmente OT.
P.P.S.
ho provato ogni tanto a lurkare NG di assembly ... ma quelli in 
lingua italiana paiono praticamente avvizziti e spopolati, per 
cui non so molto dove sbattere la testa in caso di dubbi come 
questi (mentre sono convinto che qui dentro si aggirino a piede 
libero svariati ingegneri elettronici e informatici che di 
queste cose ne sanno una barcata)
riciao
Soviet


 attuali ?
Non saprei. Non so quali e quante ottimizzazioni siano presenti nei
moderni processori. Presumo abbastanza da gestire un po' tutte le
casistiche che i differenti profili di codice che elenchi possano
configurare.
Ciao,
Marcello.

 dal progetto della memoria.
Chi fosse interessato ad approfondire l'argomento troverà un tutorial
sulla descrizione del modello di processore basato su registri
generali all'indirizzo seguente (il file si chiama Architettura.pdf):
http://sourceforge.net/project/showfiles.php?group_id=180042&package_id=208070
Saluti,
Marcello Esposito.

 generali all'indirizzo seguente (il file si chiama Architettura.pdf):
bene ! Ci faccio un salto appena ho un po' di tempo, danke
Soviet_Mario
