DIFFERENCES ENTRE 2 FICHIERS (WIN32)
meech
Messages postés
209
Date d'inscription
vendredi 11 avril 2003
Statut
Membre
Dernière intervention
14 août 2007
-
15 mai 2006 à 09:25
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 14 nov. 2006 à 18:52
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 14 nov. 2006 à 18:52
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/37600-differences-entre-2-fichiers-win32
https://codes-sources.commentcamarche.net/source/37600-differences-entre-2-fichiers-win32
14 nov. 2006 à 18:52
J'emploie les registres dont j'ai besoin, les 3 généraux en priorité car les autres doivent être restaurés.
14 nov. 2006 à 12:19
hum
je vois que tu utilises strcat(pbuf, tmp); or justement, moi je parlais d'un genre de bnstrcat programmé en C... à ce compte là c'est sûr que tu le bas à plate couture ^^
hors sujet : quelle est réellement l'utilité du mem_top_down? commit et reserve ok, mais top_down , jamais utilisé :/
ultoa(pdws[i], tmp, 10);
strcat(pbuf, tmp);
strcat(pbuf, szTAB);
pfiouuu ... bourrin, ça ^^
__declspec(naked) char* __fastcall bnultoa(unsigned int dwnum, char* szdst)
{ // ECX dwnum, EDX szdst
?????!!!! comment tu sais CA ?? c'est méga pas portable ou je me trompe ?
ya un standard à ce sujet ? je veux dire, respecté par tous les compilos ( quand je dis tous, on se comprend: VC, GCC, et + si affinités ) ?
le fastcall commence systématiquement par ecx ? ebx contient quoi ? je vois que tu n'en fais pas usage ... pour éviter de le push/poper à chaque fois ? j'avais eu des pbs avec ça effectivement, ebx doit être conservé :/
Je tenterai le même bench avec un bnstrcpy en C... j'attends juste la fin des partiels :p
"Compilé en favorisant vitesse bien entendu."-> hum, c'est juste pour faire plaisir à Gizmo ça ^^ je vois pas ce que ça pourrait changer, strcat l'est déjà, lui ( compilé )
Merci pour le bench, anyway.
13 nov. 2006 à 22:05
chainage de 100 __int64, 2 petites chaines et 200 DWORDs, tout cela dans un unique buffer.
Sur ce simple exercice qui simulerait une partie d'un module de reporting, j'obtiens déjà un rapport de 17 fois supérieur au "standard" C.
Compilé en favorisant vitesse bien entendu.
13 nov. 2006 à 19:06
13 nov. 2006 à 12:57
je ne doute pas que tes fonctions soient plus rapides, mais j'aimerais savoir ce que ça donne IRL.
La différence est tellement énorme entre qqch d'optimisé en asm et qqch d'optimisé ( autant que possible ) en C/C++ prog soi-même?
C'est principalement pour savoir si ça vaut le coup de passer du temps à débugger l'asm ( pas encore assez l'habitude ) plutôt que de savoir que je fais un code C++ qui marche...
merci
20 oct. 2006 à 23:04
Si tu as 20 int64 à mettre dans une ligne séparés par TAB (exemple) sur des milliers et milliers de lignes, tu pourras compiler comme tu voudras avec les fonctions de la lib C, ce sera toujours très lent par rapport à mes fonctions.
Pari à 1000 euros avec mesures des perfs en public quand tu veux.
20 oct. 2006 à 22:28
Je sais que je me reveille un peu tard dans la discussion. Je suis tombé sur ce code parce que ma recherche dans google a fait que je suis tombe par hasard sur ce source.
Pour moi ce source est litteralement "inbitable"... Je connais bien l'assembleur, je connais bien le C mais pour en revenir à une des remarques: on n'a pas besoin de faire un code pas formater pour qu'il soit rapide ni leger ni tout ce que l'on veut...
Certe BruNews nous montre ses talent de codeur fou en assembleur mais si il l'avait un peu mieux formater son code et mis des commentaires je pense que ca aurait eu un impact plus pedagogique comme il le sous entend en le mettant sur le site.
Voilà
A +
Fred
PS : D'autre part tant que j'y pense... pour l'assembleur..., les compilateurs sont "EN GENERAL" bien meilleurs que nous car ils tiennent compte de l'archi du proc...!
Si vous voulez vraiment optimiser certaines partie de code... compiler les avec le bon compilateur et les bonnes options...
4 sept. 2006 à 17:28
Si tu réussi à faire un code aussi rapide et lèger (tu clique et la recherche se fait en moins d'une seconde dans une base de données de plusieurs dizaines de milliers de mots) sans assembleur, sans goto et autres, préviens moi car je ne savais pas que ça existait...
4 sept. 2006 à 17:00
27 juin 2006 à 17:38
Je vais en profiter de ça... Niark, niark, niark !
2 juin 2006 à 16:32
1 juin 2006 à 20:06
Pour ce qui est de l'utilité, je n'ai jms eu a me servir de ce genre de programme. Mais vu qu'il à été crée par BruNews , j'ai le sentiment que il fait ce qu'il doit faire et ce de manière optimisée.
Mais bon je ne saurai le dire, car bien que non allergique au goto, je ne suis non pas allergique a l'asm, mais je ne le connai pas (encore) ou peu (juste les quelque instructions).
20 mai 2006 à 19:50
20 mai 2006 à 19:29
if(condition){inst1;inst2;/*...*/}
//plutôt que ceci:
if (condition) {
inst1;
inst2;
//...
}
// ???
ce ne sont que quelques « Enter », ca serait tellement plus simple a comprendre de cette facon ... comme je t'ai déjà dit, tu es pas le seul à lire tes sources, penses aux autres sinon ne poste pas !
(c'est moi le 4/10, 4 pour l'utilité)
15 mai 2006 à 10:39
15 mai 2006 à 09:25
Bref, c'est certain, ce n'est pas nouveau, nouveau, mais ça a le mérite d'être plutôt bien fait.