l'asm est censé être plus rapide quand il est bien écrit. je me pose la question de savoir si dans le cas d'un fichier contenant beaucoup de coordonnées X,Y,Z,Vx,Vy,Vz (dans les 10 000 voirs même 10 ou 100 fois plus) le temps gagné (à les ranger dans le désordre dans un tableau) est vraiment intéressant par rapport au temps de programmation et à la complexité de l'assembleur.

non

mici. mais euh dans quel cas l'assembleur est plus intéressant alors ?

dans le cas d'un fichier, c'est le chargement du fichier qui est le goulot d'étranglement. pas le temps cpu passé à le mettre en mémoire....
 
ton fichier c'est quoi de l'ascii ? des floats écrits direct ?

 
traitement uniquement local au cpu. généralement dans un traitement multimédia avec des tampons en mémoire (audio/video).
 
si tu as une dépendance disque, généralement c'est mort...  
j'éxagère, c'est une question de proportion entre le temps pris par ce qui est calculé, et ce qui est lu...
 
si tu fais que lire des données depuis un fichier, l'asm ne servira à rien...
 
par contre si la lecture/écriture est liée à un codec de compression/décompression vidéo, c'est le codec qu'il faut optimiser en asm (pas la lecture...)
 
---
 
la règle d'or quand tu as un traitement, c'est d'optimiser la boucle la plus imbriquée au dépends des des boucles externes.

c un fichier acsii du style :  
302985 140374 0 0 0 0  
303015 140377 0 0 0 0  
300164 139465 0 -0.0627668 -3.18471e-05 0  
300159 139496 0 -0.062766 -3.09e-05 0  
300155 139526 0 -0.0627957 0.000144583 0  
 
en fait ce qui limite c la vitesse du disque dur car niveau mémoire le C se débrouille très bien. c bien ça ?  
tandis qu'avec des flux en mémoire on n'est pas embété par la vitesse du HD. (correcte ?)

bin si avec "flux en mémoire" tu veux dire du traitement à partir de données déjà en mémoire, heu vi...
 
si tu veux booster tes perfs, dumoins de lecture de tes données, il faut:
 
1) abandonner l'ascii et stocker directement tes floats/structures via des fread/fwrite (à même quantitée d'éléments, le fichier sera plus petit et plus rapide à lire d'un point de vue cpu et disque)
 
2) généralement la meilleure manière de lire un fichier en terme de vitesse, c'est de le "mapper en mémoire"...
 
3) tu peux encore booster le truc dans un sens, en compressant le bordel.  
 
ie si la lecture du fichier est bloquante pour ton appli, autant utiliser la puissance CPU libre pour utiliser un truc comme la zlib pour compresser/décompresser les données à la volée lors de la sauvegarde/relecture de tes fichiers: ils prendront moins de place d'un point de vue disque, et le ratio performances cpu/disque actuel peut permettre d'augmenter la vitesse de chargement du fichier.
 
le tout à expérimenter bien sûr, rien n'est garanti.

Fichier binaire oui. Dans son cas, fichier ascci, c'est la conversion ASCII le goulot.
J'ai été confronté à ce cas : charger des fichiers ASCII contenant des matrices de 1024 * 1392 valeurs.
mettait envirron 10 secondes à charger (convertir en fait, le chargement est très rapide vu le bon dd).
J'ai tout codé à la main : lecture bufferisée et conversion à la mano (valeurs entières uniquement, donc assez facile). Maintenant c'est réglé en moins d'une seconde.
Passer en assembleur ne me ferait presque rien gagner pour beaucoup d'efforts.

 
oui je veux bien.
 
mais si passer en asm ne te ferait rien gagner, c'est parceque à un moment tu est bridé par le sous-système disque.

A un moment oui.
Mais surtout parce que mes maigres connaissances de l'asm ne me permettent pas d'écrire unr routine de conversion plus performante que celle générée par mon compilo.
Même un pro de l'asm, je ne pense pas qu'il pourrait booster plus qu'un facteur de 2 le code C++, qui est très simple. Ensuite oui biensûr c'est les accès disques qui brident.

c'est clair !
 
mais de toutes façon l'asm n'est rentable pour ce genre de trucs.
les bons compilos sont très très efficaces, donc autant reporter un maximum de chose et essayer d'écrire du code qui aide le compilo.
 
et l'autre problème avec l'asm, c'est que les connaissances dans l'optimisation asm ont la même vitesse d'obsolescence que le matériel !!! (mais bon c'est toujours un + d'avoir su faire du code asm optimisé un jour )

[citation=738163,0,8][nom]HelloWorld a écrit[/nomFichier binaire oui. Dans son cas, fichier ascci, c'est la conversion ASCII le goulot.
J'ai été confronté à ce cas : charger des fichiers ASCII contenant des matrices de 1024 * 1392 valeurs.
mettait envirron 10 secondes à charger (convertir en fait, le chargement est très rapide vu le bon dd).
J'ai tout codé à la main : lecture bufferisée et conversion à la mano (valeurs entières uniquement, donc assez facile). Maintenant c'est réglé en moins d'une seconde.
Passer en assembleur ne me ferait presque rien gagner pour beaucoup d'efforts.
[/citation]
 
je suis pas sur de tout comprendre à ta stratégie du moins les termes que tu emploies, qu'entends tu par lecture bufferisée et conversion à la mano (mano = main je pense ) ?
le fait est que je charge le contenu d'un fichier en mémoire avant de l'afficher en openGl et toutes les X secondes je change de fichier.

Lecture bufferisée : j'accède au fichier par lecture de 24Ko. Je remplis donc un buffer et travaille dans ce buffer de 24Ko. Des kil est vide je le relis, etc...
Conversion à la mano = j'utilise une routine maison pour convertir la chaine ASCII en nombre, pas de sscanf, de atoi, ...
 
On peut noter que normalement l'OS minimise l'impact des accès disques en anticipant la lecture du prochain buffer, pendant que je traite celui qui a été lu.

ah ok. bah j'essaiera si j'ai le temps mais ça risque d'être dur. (je dois me coltiner l'affichage de texte en openGL et d'après ce que j'ai vu c la merde lol)