le temps que mets un processeurs a agir sur des registres des 8 bits ( ex:  8 bits + 8bits) est il 4 fois inferieur au temps que le processeur mettre a faire 32 bits + 32 bits
 
autrement dit, pour faire des operations des beaucoups de bits sur beaucoups de bits, vaut il mieux scinder cela en paquet des 8 bits, ou en paquet des 32 bits ??

slvn a écrit a écrit : le temps que mets un processeurs a agir sur des registres des 8 bits ( ex:  8 bits + 8bits) est il 4 fois inferieur au temps que le processeur mettre a faire 32 bits + 32 bits   autrement dit, pour faire des operations des beaucoups de bits sur beaucoups de bits, vaut il mieux scinder cela en paquet des 8 bits, ou en paquet des 32 bits ??

Quel proc ?
dur un 8088 ca doit se valoir
 
Depuis le 386 il vaut mieux faire par 32bits clairement...

c est pour un proc 32 bits (amd)
 
j avias entendu dire que certain, compilo arrivaient a "optimiser" le code  
 
(pour preuve, le meme programme s execute en 330 ms quand il est compilé avec borland C++, et 800 ms avec Visula C++ )   (sur le meme pc qui est un TB 1,2)

(pour tes difs de vitesse fait bien gaffe a compiler en release sous visu)
 
Sinon vaut mieux direct du 32, les proco se demerdent encore bien quand meme
 
Sinon oui les compilo vont tacher d'optimiser le code ASM généré

Tu peux aussi incruster du code assembleur dans ton code C/C++, l'avantage c'est que tes opérations se feront directement dans les registres du processeur, ce qui est nettement plus rapide que ta mémoire vive
 
Vive les registres
 
@+

greg113 a écrit a écrit : Tu peux aussi incruster du code assembleur dans ton code C/C++, l'avantage c'est que tes opérations se feront directement dans les registres du processeur, ce qui est nettement plus rapide que ta mémoire vive   Vive les registres   @+

 
?
 
Aux dernieres nouvelles tes calculs se font toujours via les registres (enfin, fo au moins une operande qui soit un registre), que ce soit quand c'est toi qui ecrit le code ASM ou le compilo
 
regarde le code généré par VC par ex........

il parle d optimisation je pense
 
 
 
... quant a Visual C++ je viens de l passer en realease -> 200 ms !! (ca serait bien que tu m explique a quoi ca sert car ca l air eficace )
!!!!! attention !!!! c est a prendre aver des pincettes, car le prog sert a "crypter" et quand je passe VCC en release, le cryptage ne marche pu !!!
(l entrée une fois decryptée est differente...)

Visu propose par defaut deux modes de compilation : debug et release
 
en debug, visu optimise que dalle, insere dans ton code des infos qui permettront le debug de ton prog
Conséquence : programme lent et taille du prog importante
 
 
En release, visu va optimiser ton code et virer tout ce qui etait necessaire pour le debug  
resultat: vitesse d'execution accrue et taille du prog qui chute
 
 
normalement si un programme fonctionne en debug il tournera aussi en release . Si jamais ce n'est pas le cas c'est que t'as merdé quelque part dans ton code (le premier truc qui me vient a l'esprit c'est un depassement de capacité, genre ecrire en truc[20] alors que truc va que jusqu'a 10 . ce genre de truc passe parfois 'silencieusement' en debug, mais pas en release . Verifie bien tout ca, donc

surtout qu'en debug, visual initialise tes variables, et checke la memoire à chaque allocation (ce qu'il fait plu en release)=> il peut y avoir quelques petites differences entre le debug et la release pour les programmes un peu euh, comment dirais-je.... pas propres sur eux

sinon fo pas oublier que certain compilos font de très bonnes optimisations de code, mais que leur temps d'initialiasation de leur run-time est 1 poil plus long........

Une opération binaire de base (décalages, additions, masques...) n'est pas plus longue en 32 bits qu'en 8.
Donc, au maximum, utilise du 32 bits.

bon, avant de debugger, je ferais bien de tout passer en 32 bits si j ai bien compris
 
ce qui est drole, c est qu avec borland, le programme marche  
(cryptage -> decrytage  ok)
pareil, en mode debug de VCC
 
mais sous linux, (g++) et avec visual (release)
crypte -> decrypte -> sortie != entrée pas de bug,  je viens de faire un cypteur decrypteur aleatoire !
 
merci pour vos reponses