DLL ALGORYTHME DE RECHERCHE DE CHEMIN EN A STAR, A*, FASM
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019
-
27 févr. 2009 à 20:23
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019
-
7 mars 2009 à 20:33
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 7 mars 2009 à 20:33
"rep movs" sont des instructions du temps jadis qu'il convient de remplacer par une boucle perso correctement écrite. Du code perso ne forcera pas obligatoirement les PUSH POP de ESI et EDI, on emploiera les registres libres à ce moment. Depuis le Pentium (c'est pas hier...), une boucle avec des instructions bien parallélisées battra un "rep movs" à tout coup.
Ce qui anéantit gravement les perfs au moins autant, c'est l'APPEL (et donc le FAR JMP suivi du retour) vers la dll externe (kernel32 ici).
Devnix
Messages postés3Date d'inscriptionjeudi 19 juin 2008StatutMembreDernière intervention30 avril 2009 6 mars 2009 à 23:58
Si tu debug RtlMoveMemory tu vois très vite qu'elle est basée sur une instruction "rep movs" qui est difficilement plus optimisable.
Pour les push/pop de ecx et edx, je vais corriger ça.
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 27 févr. 2009 à 20:23
des appels RtlMoveMemory dans du code ASM, ouh la....
Tu nous parlais vitesse, bein c'est pas avec des appels sur dll externe que tu y gagneras, surtout pour un truc si simple à coder en local. Un compilo C correct remplace l'appel par le code inline, il va te battre à tout coup.
idem des ralentissements en entrée et sortie de quasi chaque fonction.
EAX, ACX et EDX sont à considérer comme écrasés après un appel de fonction, inutile de les PUSHer POPer.
L'ASM ne donne aucune garantie de perfs, on sait seulement qu'on "peut" en obtenir avec de très gros efforts d'optimisation suite à une longue pratique.
7 mars 2009 à 20:33
Ce qui anéantit gravement les perfs au moins autant, c'est l'APPEL (et donc le FAR JMP suivi du retour) vers la dll externe (kernel32 ici).
6 mars 2009 à 23:58
Pour les push/pop de ecx et edx, je vais corriger ça.
27 févr. 2009 à 20:23
Tu nous parlais vitesse, bein c'est pas avec des appels sur dll externe que tu y gagneras, surtout pour un truc si simple à coder en local. Un compilo C correct remplace l'appel par le code inline, il va te battre à tout coup.
idem des ralentissements en entrée et sortie de quasi chaque fonction.
EAX, ACX et EDX sont à considérer comme écrasés après un appel de fonction, inutile de les PUSHer POPer.
L'ASM ne donne aucune garantie de perfs, on sait seulement qu'on "peut" en obtenir avec de très gros efforts d'optimisation suite à une longue pratique.