[C/C++] question en terme de vitesse sur les operations de bases

Recherche :

Dernière réponse
Sujet : [C/C++] question en terme de vitesse sur les operations de bases
slvn	bon, avant de debugger, je ferais bien de tout passer en 32 bits si j ai bien compris :d 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 ;)

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

slvn

bon, avant de debugger, je ferais bien de tout passer en 32 bits si j ai bien compris :d

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 ;)

bjbebert

slvn a écrit a écrit :

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 ??

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.

bjone

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........

wpk	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 :D

chrisbk

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 :)

slvn

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...)

chrisbk

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........

greg113

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 ;)

@+

chrisbk

(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 :D

Sinon oui les compilo vont tacher d'optimiser le code ASM généré

slvn	:d 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)

BENB

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 :D

Depuis le 386 il vaut mieux faire par 32bits clairement...

slvn

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 ??