SWAP DE VARIABLE NUMERIQUE SANS BUFFER
e_NeX
Messages postés
104
Date d'inscription
mardi 9 mars 2004
Statut
Membre
Dernière intervention
30 novembre 2009
-
12 sept. 2006 à 01:53
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 12 sept. 2006 à 16:30
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 12 sept. 2006 à 16:30
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/39523-swap-de-variable-numerique-sans-buffer
https://codes-sources.commentcamarche.net/source/39523-swap-de-variable-numerique-sans-buffer
12 sept. 2006 à 16:30
12 sept. 2006 à 16:26
De plus il n'y a pas de magie c'est le principe de la pile LIFO. Ce que l'on critique c'est surtout que ce code ne marche pas !!! suffit de faire a = 32767 et paf ça plante ! pas besoin de faire un dessin c'est une mauvaise methode et je ne vois pas ce qui peut justifier son utilité desolé mais c'est la verité.
Ce n'est pas de la mauvaise humeur et je ne joue pas non plus les grosses têtes, je remet juste les points sur les I. Apres on va dire que le VB beneficie d'une mauvaise image mais c'est logique si on laisse passer des choses pareil. Ya pas de honte a ce tromper et je serais le premier a le faire si j'ai tord.
Soyons un peu serieu, appliquons nous un minimum !
@+
12 sept. 2006 à 15:56
12 sept. 2006 à 15:48
j'ai jamais dis que cette méthode était mieux que le swap ordinaire!!!
je n'ai jamais dis qu'elle optimisait le code ( quoi que je l'ai posté dans la mauvaise catégorie)
mais reste tout de meme qu'avec des "petites valeures" entière, le bout de code fonctionne!!!
et c'est le principal!!!
12 sept. 2006 à 13:03
Classique inline (sans commentaire !) :
a1 00 00 00 00 mov eax, DWORD PTR _Module1
8b 0d 04 00 00 00 mov ecx, DWORD PTR _Module1+4
89 0d 00 00 00 00 mov DWORD PTR _Module1, ecx
a3 04 00 00 00 mov DWORD PTR _Module1+4, eax
Classique modulaire :
8b 54 24 08 mov edx, DWORD PTR _b$[esp-4]
8b 44 24 04 mov eax, DWORD PTR _a$[esp-4]
8b 08 mov ecx, DWORD PTR [eax]
56 push esi
8b 32 mov esi, DWORD PTR [edx]
89 30 mov DWORD PTR [eax], esi
89 0a mov DWORD PTR [edx], ecx
5e pop esi
Par calcule inline :
8b 15 04 00 00 00 mov edx, DWORD PTR _Module1+4
8b 0d 00 00 00 00 mov ecx, DWORD PTR _Module1
03 ca add ecx, edx
2b c8 sub ecx, eax
a3 04 00 00 00 mov DWORD PTR _Module1+4, eax
89 0d 00 00 00 00 mov DWORD PTR _Module1, ecx
Par calcule modulaire :
8b 54 24 08 mov edx, DWORD PTR _b$[esp-4]
8b 44 24 04 mov eax, DWORD PTR _a$[esp-4]
8b 0a mov ecx, DWORD PTR [edx]
56 push esi
8b 30 mov esi, DWORD PTR [eax]
03 f1 add esi, ecx
89 30 mov DWORD PTR [eax], esi
8b ce mov ecx, esi
2b 0a sub ecx, DWORD PTR [edx]
89 0a mov DWORD PTR [edx], ecx
29 08 sub DWORD PTR [eax], ecx
5e pop esi
Ta methode est "differente" je te l'accorde mais elle n'a strictement aucun interet que ce soit dans la pratique comme dans la theorie. Je concoi l'excitation de ta trouvaille personnel cela dit il faut reflechir un minimum avant de poster une source. Ce poser une simple question : "Cela en vaux t'il la peine ?"
@+
12 sept. 2006 à 12:37
qq remarques:
- c'est un exercice de base que font tous les etudiants en info la première semaine de la première année.
- le but est de montrer qu'il ne faut JAMAIS faire ça, simplement parce que si a et b sont 2 entiers, rien ne dit que la somme de a est b tient dans un entier.
juste pour rire, exécute le code avec a = 32767 et b=32767 => BOUM!
12 sept. 2006 à 12:33
Ton algo est tout à fait valide au niveau binaire, passerait nickel en C (la perte de cycles serait d'ailleurs bien moins importante). Tu peux donc le garder sous le coude.
Avec VB et ses 'types' à la noix, faut l'oublier comme tout un tas d'autres choses.
12 sept. 2006 à 12:06
@+
12 sept. 2006 à 11:53
sinon ca ne fai que reinventer la roue ;)
merci pour la source
12 sept. 2006 à 11:19
Heureusement que tout le monde ne met pas des sources amusantes comme ça alors... ;-)
12 sept. 2006 à 11:10
tout d'abord : intéressant de voir le résultat en ASM. Mais je ne suis pas convaincu qu'il soit nécessaire de commencer dans un language de très bas niveau (ASM) ou assez bas niveau (C) pour passer ENSUITE vers un language comme le VB.
Enfin, bon, aucune importance.
Concernant la méthode employée, il est clair qu'elle est (bien) moins rapide et claire qu'un simple passage "par une variable tiers".
Plus grave, elle ne respecte pas le type de donnée.
J'entend par là qu'une Integer est limitée de -32768 à 32767.
Donc si on fait :
Private Sub Form_Load()
Dim a As Integer
Dim b As Integer
a = 20000
b = 17000
MsgBox "a " & a & " et b " & b
a = a + b
b = a + (-b)
a = a + (-b)
MsgBox "a " & a & " et b " & b
End Sub
il y aura un gros problème...
Mais je crois qu'il faut ni prendre cette source comme une optimisation (evidemment), ni même comme une découverte mathématique, mais comme une source qui nous fait dire "Ah ouais, c'est un peu nul comme truc mais j'y avais jamais pensé !"
Enfin bon, @+ et bonne continuation.
(PS : je pose cette question ici car il me semble que des personnes présentes ici étaient sur le topic en question : pourquoi la source "language de prog en français sans ocx + compilateur" a t-elle été supprimée par les admins ?)
12 sept. 2006 à 07:14
je ne jugerai pas ici de l'utilité de la chose.
12 sept. 2006 à 06:39
12 sept. 2006 à 03:08
12 sept. 2006 à 02:52
12 sept. 2006 à 02:51
mais ce que je voulais dire c'est que je ne cherche pas un gain de performance!!!
le cas contraire je l'aurais indiqué!!!
c'est un bout de code comme les autres qui permet d'une manière différente de faire un swap mathématiquement ( ou logiquement ).
mais tout de même, merci pour l'info ;) c'est moins rapide mais c'est amusant!!!
12 sept. 2006 à 02:44
Pas parce que tu l'as écrite dans l'éditeur VB qu'elle existera.
12 sept. 2006 à 02:39
mais en VB j'y suis depuis plus de 5 ans ( je ne me proclame pas expert du tout )
mais ici:
swapTRADI(a as integer, b as integer)
dim tmp as integer
tmp = a
a = b
b = tmp
END FUNC
tu déclare la variable tmp ....
moi je propose une démarche mathématique qui permet d'éradiquer cette variable la!!!
tel est le but du code!!
maintenant j'ai peut-être mal du comprendre le message que tu voulais véhiculer...
12 sept. 2006 à 02:35
Ceci sera aussi inutile en snippet que ça l'est ici. C'est assurément le résultat d'une ignorance de l'informatique induite par une pratique de pseudo langage avant l'étude de code bas niveau.
On va donc essayer d'expulser les croyances néfastes.
Pour simplicité de démo, disons que a est dans EAX, b dans EDX
swapTRADI(a as integer, b as integer)
dim tmp as integer
tmp = a
a = b
b = tmp
END FUNC
Compilo fera:
swapTRADI(a as integer, b as integer)
mov ecx, eax
mov eax, edx
mov edx, ecx
END FUNC
Voyons version e_Nex
swapENEX(a as integer, b as integer)
a = a + b
b = a + (-b)
a = a + (-b)
END FUNC
Compilo fera:
swapENEX(a as integer, b as integer)
lea eax, [eax+edx]
not edx
lea edx, [eax+edx+1]
mov ecx, edx
not ecx
lea eax, [eax+ecx+1]
END FUNC
Il devrait être assez clair aux yeux de tous que ta version de swap est d'un contre productif absolu.
Vitesse sera +- 3 fois plus lente, la taille du code +- 3 fois plus importante également.
N'allez pas croire que ce que vous déclarez en variables se retrouve obligatoirement dans le binaire généré, il n'en est rien.
Le processeur a des registres et un compilo sait s'en servir.
Il faut toujours privilégier l'efficacité du prog à qlq "beauté" du code dans l'éditeur, l'utilisateur final ne le verra pas et s'en contrefout.
Conclusion: ASM et C devraient être obligatoirement sus avant de faire autre chose.
12 sept. 2006 à 01:53