cosmobob
Messages postés700Date d'inscriptionmardi 30 décembre 2003StatutMembreDernière intervention27 janvier 2009
-
14 août 2004 à 16:24
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 2004
-
16 août 2004 à 20:42
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 16 août 2004 à 20:42
ben pour tes grands nombres, gere un 128 bits sur 128bits et priorite sur la vitesse
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 16 août 2004 à 20:40
ouais même quasiment 90 % je sais ça, j'utilises le même principe sur calto, mais bon, on peut choisir entre vitesse et mémoire... ça dépend de l'optimisation que l'on choisit...
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 16 août 2004 à 20:36
je vais prendre un exemple parlant
dans les jeux 3d recents, jusqu'a 3/4 du temps de chargement c'est du precalcul
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 16 août 2004 à 20:32
ouais, bof pas sur, pour moi moins on en prends plus on en a de libre et plus on peut lancer de fenêtre en même temps...
magic_Nono
Messages postés1878Date d'inscriptionjeudi 16 octobre 2003StatutMembreDernière intervention16 mars 2011 16 août 2004 à 20:28
parfaitement d'accord djl
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 16 août 2004 à 20:19
n'attache aucune importance à la taille ou autre (surtout si tu parle de sizeof et de pointeur), priorite au tableau statique, ensuite c'est à ta librairie de géré un 128bits sur 128bits effectif
chercher de cette maniere à économiser de la memoire c'est de la desoptimisation
la memoire c'est fait pour etre occupé
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 16 août 2004 à 20:13
si il est statique il pèsera plus lourd que si il est dynamique : on a plus de chance de perdre de la place, par exemple, mettre un nombre de 128 bits maintenant avec ma librairie, votre nombre utilisera 2048 bits au lieu de 128... en dynamique, je m'aprocherais a sizeof(a.valeur[0]) octet de la taille réelle du nombre.
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 16 août 2004 à 20:10
le retour des fonctions pese lourd?
ben retourne ton grand nombre par pointeur, du moment qu'il existe dans le contexte appelant
je vois pas ou est le rapport avec le fait d'utiliser ou non un tableau statique ??
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 16 août 2004 à 19:57
sauf avec ce qu'a dit kirua car les retours de fonctions pèsent lourds...
enfin c'est possible que ça pèse moins lourd que les mallec realloc free...
Je dois donc modifier la base pour ne plus avoir de pertes de place, me mettre en entier 32 ou 64 bits, mais j'ai un book sur le C et ils ne parlent pas des entiers de 64 bits... Dans ce livre Claude delanoy explique que les entiers les plus grands font 32 bits...
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 16 août 2004 à 19:44
kirua > ca depend pas de gcc mais du type d'architecture, long = au moins 32 bits, donc 32 bits en 32 bits, long long (int) depuis c99 pour l'entier 64bits
sinon pour des raison de performance, il faut toujours preferer un tableau statique à une zone allouer dynamiquement
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 16 août 2004 à 17:51
BlackGoddess > const c'est depuis c ansi, ya que en c pre ansi qu'on voit pas de const
et apres verification, le fais de mettre le const permet en effet au compilateur d'optimiser le code, cette regle est loin d'etre depassé
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 16 août 2004 à 14:30
j'en ai aucune idée pour le makefile.
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 16 août 2004 à 14:22
nan je veux dire utilises un nombre qui écris en binaire se met sur 5 cases, si tu utilises des 64 bits, tu utiliseras obligatoirement 64 bits, au lieu de 5 donc 59 bits perdus...
alors qu'avec char tu n'as que 3 bits perdus...
donc le même nombre tiens sur mons de bits, moins de déplacements et d'ocupation mémoire = + de vitesse
mais concrètement le makefile ça donne quoi ?
en ligne de bash ?
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 16 août 2004 à 14:17
pr le makefile, un .o pour chaque .c, et puis tu lies le tout.
pour la base, c'est un mauvais raisonnement. quelle que soit la base, le nombre de bits définis le spectre de données, donc utiliser une plus petit base n'économise pas de la mémoire: tu devras avoir plus de "cases".
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 16 août 2004 à 14:05
kirua, c'est vraiment facile a partir de ça de créer une fonction egal qui apelle test ou une fonctionpluspetitque qui aleppe test et qui retourneras 1 ou 0 mais j'ai trouvé ça un peu con de faire une fonction comme ça.
Pour les déplacements de x octets, ouais, je sais pas si c'est plus long qu'un realoc
Dans la prochaine mise a jour, j'utiliserais des entiers de 32 bits ou de 64 (mais je sais pas lequel me donnera le plus de vitesse car comme l'as dit kirua il y a aussi les déplacements mémoire a la sortie des fonctions, plus on prends une petite "base" moins on risque les déplacements de mémoire inutiles. et puis le proc gère plus rapidement les 32 bits je crois)
Sinon je fais comment mon makefile avec l'astuce de kirua ?
magic_Nono
Messages postés1878Date d'inscriptionjeudi 16 octobre 2003StatutMembreDernière intervention16 mars 2011 16 août 2004 à 13:51
et ULARGE_INTEGER?
et __int64
...
à la limite, on pourrait s'attendre à ce que ce genre de lib soit basée sur ces types...
++
Nono.
BlackGoddess
Messages postés338Date d'inscriptionjeudi 22 août 2002StatutMembreDernière intervention14 juin 2005 16 août 2004 à 10:22
à défaut de mettre des const (ça existe pas en C sauf erreur)
actuellement ca existe en C ... il me semble que c'est depuis le C99.
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 15 août 2004 à 13:56
oui c'est possble en c, une fonction qui initialise et uine qui libere, on voit ca dans toutes les bibliotheques (fopen/fclose, glGenTextures/glDeleteTextures,...)
coucou747 > prend note de ce que kirua à dit, regarde comment sont foutu les bibliotheques (organisation fichiers headers / sources, convention de nommage ) pour rendre ta bibliotheque fonctionnelle
cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 15 août 2004 à 02:48
/*
if (a>b) corespond à if (test(a,b)==3)
if (ab) corespond à if (test(a,b)!=2)
if (a<=b) corespond à if (test(a,b)!=3)
*/
beuurk :( c'est quoi ça, personne ne va retenir ça! à défaut de mettre des const (ça existe pas en C sauf erreur), mets au moins des macros, je pense que ça devrait ajouter bcp en lisibilité et utilisabilité (sinon il faudrait commenter toutes les conditionnelles :/)
on n'inclut pas des .c, tu devrais au contraire inclure le header de grandnombre dans tous les .c et les liés après compilation séparée. du moins, c'est la façon conventionnelle de le faire.
autre chose: toutes tes fonctions renvoient un grandnombre par valeur. ça fait chaque fois 260 octets qui transitent (et qui doivent être copiés chaque fois). c'est dommage.
et puis enfin, "taille", tu le déclares en unsigned long int (long int et int, avec gcc, c'est la même taille, si tu voulais un 64 bits, c'est long long int). mais dans la mesure ou tu limites en dur la taille de ton tableau à 256 "cases", ça sert à rien de vouloir un 64 bits. un unsigned char suffirait même si tu limitais à 255 cases.
d'ailleurs ce système de cases est très dommage, tu devrais proposer un constructeur pour grandnombre dans lequel on précise la taille que l'on désire, avec un destructeur qui s'acquitte de la libération de la mémoire que tu auras allouée dynamiquement. je sais pa comment t'es censé faire ça en C, mais ça doit être possible non? est-ce que la programmation structurelle le permet? je sais qu'en C++ les structures ont été "OO-isées", alors j'ai dû mal à voir la frontière.
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 14 août 2004 à 23:59
oulala mais c'est vraiment compliqué tout ça...
Alors je dois utiliser des variables de 80 bits efficaces et 92 bits perdus ???
Ou alors me limiter a 32 bits ?
de toute façon, ce ne sera pas énormément moins rapide, mais on utiliseras moins de mémoire avec 32 bits au lieu de 80
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 14 août 2004 à 23:16
Le 80 bits est tres long en transfert registre memoire.
Il est conseille sur processeurs modernes d'utiliser les jeux d'instructions ajoutes MMX, P3 et superieur.
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 14 août 2004 à 23:05
d'apres ce lien, long double est equivalent à double sous vc++
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 14 août 2004 à 23:01
c'est quand mem bizarre
coucou747 > pour la version, gcc -v
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 14 août 2004 à 22:55
VS 2003, le 80 bits double je l'ai toujours fait en instructions asm.
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 14 août 2004 à 22:53
moi c'est gcc je sais plus quel version
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 14 août 2004 à 22:51
BruNews > c'est quel compilateur?
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 14 août 2004 à 22:50
comme entier sur 64 bits, tu as long long, ca fais partie du standard c99 donc c'est du c pure
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 14 août 2004 à 22:49
ok, je voulais savoir si c'etait bien pris en compte, mon compilo repond invariablement 8 sur long double.
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 14 août 2004 à 22:45
je n'ais pas vérifié, je fais du C pure, et ces fonctions n'ont pas besoin de librairie autre que stdio donc, je n'ai pas envi de rajouter celle permettant de gérer les nombres 64 bits, je préfère rester aux 32 qui seront plus rapides a gérer.
Même si je met du code pour les découper en 8 pour assigner et les afficher en hexa, je préfère ça aux entiers 64 bits que je ne connais pas
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 14 août 2004 à 22:45
sizeof(long double) renvoi 12 (80 bits mais 96 pour garantir l'alignement en 32bits)
c'est ce que tu voulais savoir?
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 14 août 2004 à 22:30
tu as verife par sizeof ?
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 14 août 2004 à 22:27
c'est bien long double et pas long long double
la difference avec double, le reel est codé sur 80 bits (64 bits pour la mantisse et 15 pour l'exposant )
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 14 août 2004 à 21:35
djl> 'long long double', quelle diff avec double ?
cs_djl
Messages postés3011Date d'inscriptionjeudi 26 septembre 2002StatutMembreDernière intervention27 novembre 20047 14 août 2004 à 21:23
ya aussi long long (entier) et long long double (reel) depuis c99
Hades53
Messages postés231Date d'inscriptionmercredi 12 février 2003StatutMembreDernière intervention 7 juillet 2009 14 août 2004 à 21:16
Niveau 2 ? C'est un peu trop basique pour l'être véritablement..
Et pour moi les grands nombres ça se traite avec du long double ou du _int64.
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 14 août 2004 à 17:00
exact, merci pour cette astuce, je vais modifier ma librairie pour qu'elle soit parfaitemnet utilisable (dans le limite de mes compétences ^^)
cosmobob
Messages postés700Date d'inscriptionmardi 30 décembre 2003StatutMembreDernière intervention27 janvier 20094 14 août 2004 à 16:59
une boucle avec printf("%x",valeur[i]); va bien afficher la valeur hexa de ton grand nombre non ?
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 14 août 2004 à 16:49
oui, je sais tout ça mais comment afficher ce grand nombre a l'écran ensuite ?
faudrait passer par des fonctions de conversions, ect... donc je préfère utiliser ça avec des petites variables de 4 bits.
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 14 août 2004 à 16:35
Tout tranfert entier32 s'effectue en 1 cycle sur proc 32 bits, idem pour l'octet.
cosmobob
Messages postés700Date d'inscriptionmardi 30 décembre 2003StatutMembreDernière intervention27 janvier 20094 14 août 2004 à 16:24
pourquoi utiliser un tableau de char pour gerer un grand entier alors que pour le meme prix, tu as un tableau d'entiers qui contiendra donc plus de trucs ?
les opérations élementaires sur les char ne sont pas plus rapides que celles sur les ints sur les processeurs 32 bits, ou si elles le sont, c'est pas 4 fois plus, mais de l'ordre de quelques % de mieux... tu peux remplacer ton char valeur[256] par un int valeur[64] ...
16 août 2004 à 20:42
16 août 2004 à 20:40
16 août 2004 à 20:36
dans les jeux 3d recents, jusqu'a 3/4 du temps de chargement c'est du precalcul
16 août 2004 à 20:32
16 août 2004 à 20:28
16 août 2004 à 20:19
chercher de cette maniere à économiser de la memoire c'est de la desoptimisation
la memoire c'est fait pour etre occupé
16 août 2004 à 20:13
16 août 2004 à 20:10
ben retourne ton grand nombre par pointeur, du moment qu'il existe dans le contexte appelant
je vois pas ou est le rapport avec le fait d'utiliser ou non un tableau statique ??
16 août 2004 à 19:57
enfin c'est possible que ça pèse moins lourd que les mallec realloc free...
Je dois donc modifier la base pour ne plus avoir de pertes de place, me mettre en entier 32 ou 64 bits, mais j'ai un book sur le C et ils ne parlent pas des entiers de 64 bits... Dans ce livre Claude delanoy explique que les entiers les plus grands font 32 bits...
16 août 2004 à 19:44
sinon pour des raison de performance, il faut toujours preferer un tableau statique à une zone allouer dynamiquement
16 août 2004 à 17:51
et apres verification, le fais de mettre le const permet en effet au compilateur d'optimiser le code, cette regle est loin d'etre depassé
16 août 2004 à 14:30
16 août 2004 à 14:22
alors qu'avec char tu n'as que 3 bits perdus...
donc le même nombre tiens sur mons de bits, moins de déplacements et d'ocupation mémoire = + de vitesse
mais concrètement le makefile ça donne quoi ?
en ligne de bash ?
16 août 2004 à 14:17
pour la base, c'est un mauvais raisonnement. quelle que soit la base, le nombre de bits définis le spectre de données, donc utiliser une plus petit base n'économise pas de la mémoire: tu devras avoir plus de "cases".
16 août 2004 à 14:05
Pour les déplacements de x octets, ouais, je sais pas si c'est plus long qu'un realoc
Dans la prochaine mise a jour, j'utiliserais des entiers de 32 bits ou de 64 (mais je sais pas lequel me donnera le plus de vitesse car comme l'as dit kirua il y a aussi les déplacements mémoire a la sortie des fonctions, plus on prends une petite "base" moins on risque les déplacements de mémoire inutiles. et puis le proc gère plus rapidement les 32 bits je crois)
Sinon je fais comment mon makefile avec l'astuce de kirua ?
16 août 2004 à 13:51
et __int64
...
à la limite, on pourrait s'attendre à ce que ce genre de lib soit basée sur ces types...
++
Nono.
16 août 2004 à 10:22
actuellement ca existe en C ... il me semble que c'est depuis le C99.
15 août 2004 à 13:56
coucou747 > prend note de ce que kirua à dit, regarde comment sont foutu les bibliotheques (organisation fichiers headers / sources, convention de nommage ) pour rendre ta bibliotheque fonctionnelle
15 août 2004 à 02:48
if (a>b) corespond à if (test(a,b)==3)
if (ab) corespond à if (test(a,b)!=2)
if (a<=b) corespond à if (test(a,b)!=3)
*/
beuurk :( c'est quoi ça, personne ne va retenir ça! à défaut de mettre des const (ça existe pas en C sauf erreur), mets au moins des macros, je pense que ça devrait ajouter bcp en lisibilité et utilisabilité (sinon il faudrait commenter toutes les conditionnelles :/)
#include "autre.c"
#include "gestionaffichageetassign.c"
#include "test.c"
#include "somme.c"
#include "difference.c"
#include "produit.c"
#include "decalage.c"
#include "quotient.c"
#include "modulo.c"
on n'inclut pas des .c, tu devrais au contraire inclure le header de grandnombre dans tous les .c et les liés après compilation séparée. du moins, c'est la façon conventionnelle de le faire.
autre chose: toutes tes fonctions renvoient un grandnombre par valeur. ça fait chaque fois 260 octets qui transitent (et qui doivent être copiés chaque fois). c'est dommage.
et puis enfin, "taille", tu le déclares en unsigned long int (long int et int, avec gcc, c'est la même taille, si tu voulais un 64 bits, c'est long long int). mais dans la mesure ou tu limites en dur la taille de ton tableau à 256 "cases", ça sert à rien de vouloir un 64 bits. un unsigned char suffirait même si tu limitais à 255 cases.
d'ailleurs ce système de cases est très dommage, tu devrais proposer un constructeur pour grandnombre dans lequel on précise la taille que l'on désire, avec un destructeur qui s'acquitte de la libération de la mémoire que tu auras allouée dynamiquement. je sais pa comment t'es censé faire ça en C, mais ça doit être possible non? est-ce que la programmation structurelle le permet? je sais qu'en C++ les structures ont été "OO-isées", alors j'ai dû mal à voir la frontière.
14 août 2004 à 23:59
Alors je dois utiliser des variables de 80 bits efficaces et 92 bits perdus ???
Ou alors me limiter a 32 bits ?
de toute façon, ce ne sera pas énormément moins rapide, mais on utiliseras moins de mémoire avec 32 bits au lieu de 80
14 août 2004 à 23:16
Il est conseille sur processeurs modernes d'utiliser les jeux d'instructions ajoutes MMX, P3 et superieur.
14 août 2004 à 23:05
d'apres ce lien, long double est equivalent à double sous vc++
14 août 2004 à 23:01
coucou747 > pour la version, gcc -v
14 août 2004 à 22:55
14 août 2004 à 22:53
14 août 2004 à 22:51
14 août 2004 à 22:50
14 août 2004 à 22:49
14 août 2004 à 22:45
Même si je met du code pour les découper en 8 pour assigner et les afficher en hexa, je préfère ça aux entiers 64 bits que je ne connais pas
14 août 2004 à 22:45
c'est ce que tu voulais savoir?
14 août 2004 à 22:30
14 août 2004 à 22:27
la difference avec double, le reel est codé sur 80 bits (64 bits pour la mantisse et 15 pour l'exposant )
14 août 2004 à 21:35
14 août 2004 à 21:23
14 août 2004 à 21:16
Et pour moi les grands nombres ça se traite avec du long double ou du _int64.
14 août 2004 à 17:00
14 août 2004 à 16:59
14 août 2004 à 16:49
faudrait passer par des fonctions de conversions, ect... donc je préfère utiliser ça avec des petites variables de 4 bits.
14 août 2004 à 16:35
14 août 2004 à 16:24
les opérations élementaires sur les char ne sont pas plus rapides que celles sur les ints sur les processeurs 32 bits, ou si elles le sont, c'est pas 4 fois plus, mais de l'ordre de quelques % de mieux... tu peux remplacer ton char valeur[256] par un int valeur[64] ...