Newsgroup: it.comp.lang.c
Titolo: Velocità a 16 e 32 bit

Salve a tutti. Qualcuno saprebbe dirmi in che cosa è più veloce un programma
a 32 bit di uno a 16?
Forse nell'uso delle variable di tipo long?
Grazie a tutti.

 a 32 bit di uno a 16?
In niente. Un programma a 16 bit è generalmente più veloce e compatto di
uno a 32.
EMG

 wrote in message
3797542B...@flashnet.it...


uno a 32.
Su un 8086 o un 286 hai ragione. Dai 386 in poi un prog a 16 bit è più lento
di uno a 32 o 64 bit.
Ciao, Giuseppe
PS. Quella che hai scritto era una battuta, VERO?
---------------------------------------------------------------------------
_Guybrush su IRCNet canale #programmazione
---------------------------------------------------------------------------

 E allora qual'è il vantaggio?
Per gli utenti? Nessuno. Gli unici vantaggi sono stati per le tasche di
Bill Gates...
EMG

 PS. Quella che hai scritto era una battuta, VERO?
Niente affatto. E' una constatazione.
EMG

sarò ben lieto di rivedere la mia posizione.
Beh, sotto DOS se usi i long con un compilatore a 32 bit ottieni un notevole
incremento di velocita'.
Ad esempio
long    i, l;
    l = 0;
    for (i = 0; i < 100000L; i++)
    {
        l += i;
    }
se lo compili con un compilatore a 16 bit va molto piu' piano dello stesso
programma compilato con un compilatore a 32 bit (ossia che supporta
istruzioni a 32 bit).
Marco

...

In questi casi e' sempre difficile - se non impossibile - dare giudizi
assoluti: dipende sempre dall'applicazione e in parete anche dal micro. Se
l'applicazione e' adatta ad essere implementata a 16 bit (non usa long e
non soffre troppo dei limiti di indirizzamento) sara' sempre piu' veloce a
16 bit, a parte il caso in cui venga fatta girare su un Pentium Pro (e
forse anche sul PII ?) che e' stato ottimizzato per i 32 bit.

 incremento di velocita'.
Il tuo è però un esempio fortemente "addomesticato", nel senso che è
inteso a dimostrare la tua tesi e non tiene conto dell'utilizzo reale.
Se prendi un'applicazione di quelle commerciali (magari della Microsoft)
e confronti le versioni a 16 e a 32 bit ti accorgi che quelle a 16 sono,
in generale, un altro pianeta in quanto a velocità e compattezza. Se me
ne spieghi il motivo...
EMG

forse anche sul PII ?) che e' stato ottimizzato per i 32 bit.
Senz'altro. Prima dipende dal micro (se non li regge i 32 bit le somme le
deve sempre spezzare), e poi dall'applicazione. Se l'applicazione usa dati a
32 bit , la compilo con un compilatore a 16 bit (dunque per fare la somma di
due long deve sommare le parti degli int, gestire i riporti e cose varie) va
in un modo. Se la compilo a 32 bit e uso EAX e EDX per fare la somma va
sicuramente piu' veloce.
In generale, comunque, se si usano i 32 bit nelle operazioni il guadagno e'
notevole. Se non li si usano (nel programma) e si compila per un target a 32
bit comunque non e' detto che si perda qualcosa. In molte delle operazioni
(mi riferisco al 386, di cui ho le temporizzazioni) i tempi sono
perfettamente equivalenti.
Marco

ne spieghi il motivo...
Beh, io non lavoro alla Microsoft.
Se "versione a 32 bit" per loro significa solo aumentare la dimensione del
codice per rallentarne la velocita' questo non lo so.. ;-)
Marco

sarò ben lieto di rivedere la mia posizione.
Ho letto i vari messaggi del thread e mi sono fatto un'idea delle tue
opinioni. Tu fai confusione tra Windows come sistema operativo a 32 bit e
ciò che invece una CPU a 32 bit può darti.
Windows (a parte il fatto che nelle versioni non NT è un ibrido tra i 16 e i
32 bit) non è un mostro di velocità e occupa la maggior parte delle risorse
del sistema. Infatti prova a fare girare Win su due macchine: una a 200Mhz e
un'altra a 400Mhz. In teoria nel secondo PC dovrebbe girare ad una velocità
doppia (e anche di più) ma in realtà l'aumento di prestazioni è minimo se
non nullo. Questa "pesantezza" di Windows fa si che le nuove applicazioni a
32 bit che sfruttano le possibilità che mette a disposizione (interfaccia
grafica per prima) vadano più lente delle equivalenti applicazioni scritte
per un ambiente testuale a 16 bit quale il DOS.
Se invece prendi in considerazione una CPU a 32 bit senza nulla che la
appesantisce o con un sistema operativo efficiente questa è molte volte più
veloce del suo equivalente (stessa frequenza) a 16 bit. Non so se hai mai
provato Linux (non in modalità grafica). Offre tutte le opportunità del Win
(librerie dinamiche, multitasking, multithreading, ecc) e altre che Win non
ha (come la gestione lineare della memoria) e lavora ad una velocità molte
volte maggiore: basta provare a fare un "dir" (comando del DOS) di TUTTO il
filesystem (che è intricatissimo). Il DOS impiegherebbe qualche minuto, il
Win un minuto scarso, il Linux qualche secondo (su un Pentium 200Mhz).
Se poi parliamo di scrivere del codice che parta all'avvio della macchina e
che la la sfrutti interamente per i suopi scopi le prestazioni salgono fino
a livelli incredibili (basta fare qualche calcolo per accorgersene).
Ciao, Giuseppe


 codice per rallentarne la velocita' questo non lo so.. ;-)
Effettivamente penso che sia proprio così.
EMG

 Win un minuto scarso,
Come ti viene in mente una cosa del genere? Quando mai il DOS è stato
più lento di Windows?
EMG

più lento di Windows?
Guarda che, parlando a basso livello, il Win è più veloce del DOS proprio
perchè in parte gira a 32 bit. Poi se per stampare a video un documento di
testo il Win ci impiega molto più del DOS è perchè per farlo deve compiere
un numero di azioni innumerevolmente maggiore di quelle necessarie nel caro
OS testuale.
E poi la storia del comado dir è vera. Prendi un PC con installato Win9x,
fallo partire in DOS puro (da dischetto o da dove vuoi tu), portalo su C:\ e
prova questa riga di comando: "dir /s". Fai la stessa cosa in una finestra
del DOS in Win e poi riferiscimi.


 doppia (e anche di più) 
[...]
Secondo me dovresti rivederla un po' la teoria che ha seguito per dire
questa "cosa non proprio vera" (gentile eufemismo ;-) )
Il tempo di esecuzione di un prg dipende da diversi fattori, non solo
dal clock della CPU, come (forse) sai : velocita' del bus, velocita' e
quantita' della memoria, ecc...
Ciao, Luca.
-- 
 Reply to 
luca....@tiscalinet.it
 UIN : 43385135

Ciao, Luca.
Si, sono stato molto vago riguardo alle configurazioni delle due macchine.
Io intendevo due PC con stessa memoria, stessa velocità di bus e stesse
periferiche installate.
Comunque ti giuro di aver visto con i miei occhi Pentium 200Mhz con 32Mb far
girare Win95 più veloce (soprattutto all'avvio) di Pentium II 350Mhz
32Mb!!!! Saranno le configurazioni interne a determinare questa
differenza... So solo che se una cosa del genere me l'avessero raccontata
non ci avrei creduto.


 Ciao, Giuseppe
Ciao anche te, Luca.


you wrote :
#AlexTaro wrote:
#> 
#> Salve a tutti. Qualcuno saprebbe dirmi in che cosa è più veloce un programma
#> a 32 bit di uno a 16?
#
#In niente. Un programma a 16 bit è generalmente più veloce e compatto di
#uno a 32.
Oddio, non so se questo sia universalmente vero.
Almeno per quanto riguarda la velocita'.
Un programma a 32 bit, ad esempio, puo' eseguire calcoli sui long in
modo piu' veloce di uno a 16 bit, per il fatto che il dato rimane
comunque tutto in un registro e non c'e' bisogno di considerare
riporti e prestiti.
In quanto al set di istruzioni, ci sono comandi evoluti che
racchiudono in se' piu' comandi vecchi e quindi dovrebbe essere piu'
veloce.
Andrea Laforgia        (
andrea_...@bigfoot.com
)
----------------------------------------------------
There is nothing better for understanding a kangaroo
than seeing it jump.
----------------------------------------------------

 Oddio, non so se questo sia universalmente vero.
Oh, ben tornato, eh? :-)
EMG

Commodore64 (bei tempi!), aspettando la richiesta "Press play on tape".
Infatti, soprattutto con l'Office 2000, la sensazione è quella :-)


 processore.
Esatto, nel senso che se raddoppia solo la freq. della CPU, non possono
raddoppiare le prestazioni.


 EMG
-- 
+-------*Le tre leggi del buon utente*-------+
|============================================|
+-1ø:Un utente non puo' nuocere al suo PC ne'|
|    tramite la sua colpevole inerzia permet-|
|    tere che il suo PC subisca un danno.    |
+-2ø:Un utente deve soddisfare le richieste  |
|    di sistema a meno che queste non contra-|
|    stino con la prima legge.               |
+-3ø:Un utente deve pensare ai suoi interessi|
|    installando il software di cui ha biso- |
|    gno a meno che questo non contrasti con |
|    la prima e la seconda legge.            |
|============================================|
+-Legge Zero---------------------------------+
|Un utente non puo' installare Windows, o cau|
|sera' la fine del suo PC e la rovina dell'u-|
|manita' !!!! Cobra(
franc...@iol.it
)      |
|                  (
maraf...@xoommail.com
)|
|============================================|

raddoppiare le prestazioni.
E perchè no? Secondo me raddoppiando la frequenza del processore raddoppia
anche la velocità complessiva della macchina. Se poi vado a inserire delle
migliorie come nuove architetture del processore, aumento della frequenza
del bus, memorie con tempi di risposta ridotti, ecc le prestazioni salgono
ancora.
Naturalmente tutto questo vale non tenendo conto di eventuali colli di
bottiglia come accessi al disco rigido.


anche la velocità complessiva della macchina. Se poi vado a inserire delle
No, perche' la velocita' complessiva di una macchina non e' data solo dalla
frequenza di clock del processore.
Altrimenti si potrebbe accedere tranquillamente alla RAM a 1Mhz un bit alla
volta.
Ad esempio l'aumento che si ha passando da 2x a 4x (moltiplicatore interno
del clock) non e' del 100%, ma un po' meno, perche' il resto della macchina
e' rimasto pari a prima.
Marco

e' rimasto pari a prima.
Sai che mi hai convinto? Non avevo pensato che anche altri fattori come i
tempi di accesso alla RAM posso rappresentare un collo di bottiglia per
l'intero sistema.
Devo rivedere le mie teorie sulle prestazioni dei PC :-)
