Résultats de la recherche sur « morphos »
-
-
-
je vois pas le rapport entre les template et la vitesse du code
Ensuite baeucoup de choses sont normalement « inline » donc pas tant de saut de méthodes qu’on le pense.
Ensuite l’histoire des exceptions y a un proverbe qui dit « ne s’use que si l’on s’en sert », bhein les exceptions c’est en peu pareils : ça ralentit que si l’on s’en sert (i.e. si y en a une de levée)
Mais au final vaut-il mieux un code sûr, réutilisable, avec gestion d’exceptions mais un peu moins lent,
ou un code qui déchire sa mère niveau vitesse, mais qui
1) n’est pas réutilisable et nécessite une réécriture partielle à chaque fois que l’on souhaite l’utiliser,
2) se banane avec un joli crash dès qu’un truc non attendu se présente ?
Moi j’ai choisi : vive le C++ et vive la STL… Après libre à chacun de faire ses choix, perso recoder les méthodes de gestion de pile à chaque projet moi ça me gonfle, j’écris un template de gestion de pile et après je l’utilise dans tous les projets…
EDIT: une petite note : je n’ai jamais dit que les iostream étaient plus rapides que de passer directement par les méthodes système d’accès au fichier. C’est évident que ce sera plus lent puisque leur implémentation se base justement sur elles… C’est comme de dire qu’avec la SDL c’est plus lent que de passer par la graphics.library et Intuition… J’ai juste voulu dire que les iostreams ne sont pas si lents que ce que la rumeur générale tend à le dire.
-
-
-
bhein euh moi non plus
/ … -
Alex a écrit :
YomGui:
PS: je vois dans ta signature un projet que je reconnais bien t’as avancé de ton côté ?
Euh… non.
-
-
-
Alex:
Oui il n’y a que ca comme dependances.
Faudrait juste changer les tests sur le define __MORPHOS__ en __AMIGA__. Ah y a aussi une petite magouille avec la fonction for_each() je ne sais plus ou.
Tiens moi au courant.
PS: j’ai porter et compiler ce truc sur le PC/Win de ref avec AmiDevCPP… pour dire que c’est simple
-
C’est pas du binaire. les fichiers de data sont des fichiers textes ou ils ecrivent souvent des float.
Ah Ok, mais faudra que je vérifie, il me semble que normalement un petit
float monfloat;ostream << monfloat; puis un istream >> monfloat;
devrait normalement fonctionner direct, après il est possible d’utiliser des manipulateurs pour fixer les formats de ces float.
Ca évite de passer par une chaine temporaire puis de passer par un sscanf (en plus dans les iostreams il y a déjà une vérification des erreurs qui est toute faite et qui peut même lever une exception si on lui demande gentiment (c.f. la méthode exceptions( ) )…
Si tu t’y connais mieux que moi en C++ (c’est pas tres dur…) tu peux toujours ameliorer le code pour qu’il fonctionne plus vite
Attention je n’ai rien dis de tel, je pense que question portage/dev tu te poses là y a pas à discuter tes compétences, c’est clair 😮 ! Je voulais juste faire une remarque sur la vitesse de iostreams c’est tout.
Après je voudrais bien regarder le code mais vu que je n’ai pas MOS, faudrait que je puisse le compiler sous OS4 pour voir, y a vraiment que cxe que tu disais au début comme dépendances ?
Au passage, la version de reference que j’utilise (WinXP sur un bi-pent 3GHz/2GB) demarre en qq secondes,
Ah oui mais aussi si tu compare un bi-pentium 3Ghz/2GO de ram avec nos pauv’G4 1Ghz/512MO voir 1GO de ram aussi c’est normal qu’il est une différence
il doit donc y avoir un pb dans la libstdc++ pour une telle difference.
Ca c’est tout à fait possible malheureusement je ne pourrais pas te dire en faisant la comparaison sur mon XE G4/800Mhz/512Mo à moins que je ne tente de faire le portage vite fait… Faudrait que je regarde les dépendances et croiser les doigts pour que ça n’utilise pas des trucs qu’on n’a pas dans notre implémentation d’OGL
-
Dieu a encore frappé !!
Merci Yomgui
PS sur Make Human : la version X86 ne sauve qu’en WaveFront (.OBJ) donc faut passer par de l’import pour récuperer les fichiers dans Blender.
Mais vu le temps gagné pour designer un perso, qui s’en pleindra ?
-
Alex:
C’est pas du binaire. les fichiers de data sont des fichiers textes ou ils ecrivent souvent des float.
Je te laisse regarder le code source, par exemple animorph/src/VertexVector.cpp.
Si tu t’y connais mieux que moi en C++ (c’est pas tres dur…) tu peux toujours ameliorer le code pour qu’il fonctionne plus vite
Au passage, la version de reference que j’utilise (WinXP sur un bi-pent 3GHz/2GB) demarre en qq secondes, il doit donc y avoir un pb dans la libstdc++ pour une telle difference.
Ah pour info, ce n’est pas le code original. Je l’ai modifie.
Ils utilisent un buffer statique « char *buff[MAX_blabla_LINE]; »
qu’ils remplissent dans une boucle while() avec iostream.getline(). Ensuite ils font le sscanf() dessus.
Je me suis permis d’utiliser iostream.gets() histoire de ne pas bouffer 1024 octets (taille du buffer) betement dans cette boucle.
… pou run buffer qu’ils ne modifient pas.
-
Ensuite j’ai tente de savoir pourquoi c’est si long au demarrage et la j’ai vu que c’est entierement dus au chargement de fichiers par l’utilisation de la classe ifstream et sscanf()…
Là, désolé, Yomgui mais je peux pas te laisser dire ça : bien employés les iostream sont très puissants et pas si lents qu’on veut bien le laisser entendre…
Maintenant c’est certain que s’ils utilisent les iostream pour lire des chaînes de caractères, puis des sscanf (qui dit en passant risque de compromettre leur « augmenter la stabilite et la fiabilité ») pour convertir en int bhien c’est certain que ça doit ramer sa mère !
… les méthodes istream::read() et ostream::write() ne sont pas pour les chiens quand on désire lire du binaire….
-
