Automate cellulaire en assembleur ( jeu de la vie )
Soyez le premier à donner votre avis sur cette source.
Vue 13 298 fois - Téléchargée 1 425 fois
Description
Le but de ce source est de faire un comparatif de vitesse d'exécution entre le VB et l'assembleur.
Tout d'abord, ce source a été compilé à l'aide de FASM, que je vous invite tous à télécharger car c'est le meilleur compilateur que je connaisse, de plus il est gratuit.
http://flatassembler.net/
Ce source est un automate cellulaire qui reproduit le mouvement de cellules ( voir définition de wikipedia : http://fr.wikipedia.org/wiki/Jeu_de_la_vie )
En ce qui concerne la vitesse d'exécution, j'obtiens plus de 2000 images par seconde en ASM avec une grille de 100*100 tandis qu'en VB je stagne à 6 images par seconde...
Bien que mes programmes ne soit pas forcement optimisé a 100% on obtient quand même une différence de 33 000%...
Bon évidemment le programme en VB je l'ai codé en 2 heures alors que celui en assembleur j'ai mis au moins une 15aine d'heure car niveau calcul avec les division euclidiennes ça a été assez difficile ( si quelqun a un tuto sur l'utilisation des fpu, je suis preneur :) ) donc on pourrai s'interroger sur la rentabilité niveau vitesse d'exécution/vitesse d'écriture du code.
Pour ceux qui s'intéressent au fonctionnement du programme vu que la compréhension du code en assembleur est difficile je vais expliquer un peu.
2 variables sont utilisés pour stoker les adresses des tableaux qui contiendront la grille des cellules :
Cases dd addrtbl1
Cases2 dd addrtbl2
La variable Cases indique l'adresse du tableau en cours d'utilisation, la fonction de calcul marche de la manière suivante :
on lit dans Cases[]
on regarde combien de cases sont activent autour, puis on en déduit si une case doit être active, ou non au quel cas on l'écris dans Cases2[]
une fois que toutes les cases ont étés calculées, on inverse les 2 pointeurs c'est a dire Cases devient Cases2 et vice versa
Au niveau de la conversion Str-Hexa et Hexa-Str, n'ayant pas trouvé de fonction déjà faites, je les ait donc refaites en asm, mais si vous avez une petite api sous la main qui le fait, ça m'arrangerai.
Et si quelqun aurait des conseils sur une quelconque manière d'optimiser mon programme, je suis preneur.
J'aime ces deux langages pour leur particularités :
le VB pour sa rapidité d'écriture du code et l'assembleur pour sa rapidité d'exécution, je ne dirais donc pas qu'un langage est mieux qu'un autre mais qu'il faut savoir choisir l'un ou l'autre à bon escient.
Tout d'abord, ce source a été compilé à l'aide de FASM, que je vous invite tous à télécharger car c'est le meilleur compilateur que je connaisse, de plus il est gratuit.
http://flatassembler.net/
Ce source est un automate cellulaire qui reproduit le mouvement de cellules ( voir définition de wikipedia : http://fr.wikipedia.org/wiki/Jeu_de_la_vie )
En ce qui concerne la vitesse d'exécution, j'obtiens plus de 2000 images par seconde en ASM avec une grille de 100*100 tandis qu'en VB je stagne à 6 images par seconde...
Bien que mes programmes ne soit pas forcement optimisé a 100% on obtient quand même une différence de 33 000%...
Bon évidemment le programme en VB je l'ai codé en 2 heures alors que celui en assembleur j'ai mis au moins une 15aine d'heure car niveau calcul avec les division euclidiennes ça a été assez difficile ( si quelqun a un tuto sur l'utilisation des fpu, je suis preneur :) ) donc on pourrai s'interroger sur la rentabilité niveau vitesse d'exécution/vitesse d'écriture du code.
Pour ceux qui s'intéressent au fonctionnement du programme vu que la compréhension du code en assembleur est difficile je vais expliquer un peu.
2 variables sont utilisés pour stoker les adresses des tableaux qui contiendront la grille des cellules :
Cases dd addrtbl1
Cases2 dd addrtbl2
La variable Cases indique l'adresse du tableau en cours d'utilisation, la fonction de calcul marche de la manière suivante :
on lit dans Cases[]
on regarde combien de cases sont activent autour, puis on en déduit si une case doit être active, ou non au quel cas on l'écris dans Cases2[]
une fois que toutes les cases ont étés calculées, on inverse les 2 pointeurs c'est a dire Cases devient Cases2 et vice versa
Au niveau de la conversion Str-Hexa et Hexa-Str, n'ayant pas trouvé de fonction déjà faites, je les ait donc refaites en asm, mais si vous avez une petite api sous la main qui le fait, ça m'arrangerai.
Et si quelqun aurait des conseils sur une quelconque manière d'optimiser mon programme, je suis preneur.
Source / Exemple :
J'ajoute le lien vers le code en VB : http://www.vbfrance.com/codes/AUTOMATE-CELLULAIRE-JEU-VIE_47062.aspx
Conclusion :
J'aime ces deux langages pour leur particularités :
le VB pour sa rapidité d'écriture du code et l'assembleur pour sa rapidité d'exécution, je ne dirais donc pas qu'un langage est mieux qu'un autre mais qu'il faut savoir choisir l'un ou l'autre à bon escient.
Codes Sources
A voir également
- Automate cellulaire en assembleur ( jeu de la vie )
- Jeu de la vie en c - Forum C / C++ / C++.NET
- Jeu de la vie corrigé python - Forum Python
- Code Jeu de la vie C++ avec classes et vecteurs ✓ - Forum C / C++ / C++.NET
- Jeu memory en ligne - Forum Python
- Automate s7 - Forum C / C++ / C++.NET
9 mai 2009 à 18:02
en plus il ya des faute de génération (exemple : qq fois une cellule seule survie !)
24 juin 2008 à 09:08
@++
23 juin 2008 à 08:26
- OMF
- COFF
- Win32
- ELF (Linux)
- binaire pur (.COM, .SYS)
- 16, 32 et 64 bits
+ d'autres que j'oublie
C'est un assembleur multi plateformes.
22 juin 2008 à 18:13
MASM a l'air pas mal non plus c'est vrai mais il ne permet pas de modifier les sections comme bon de semble comme le fait fasm.
22 juin 2008 à 15:32
déjà, il ne permet pas de faire des objets OMF. Ca commence mal pour etre le meilleur, il est limité...
Donc, qu'apporte-t-il de plus que les autres sinon toute une floppée de macros inutiles et réalisables égalements par tous les autres assembleurs ?
@++
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.