JEU DE LA VIE

The Meteorologist Messages postés 232 Date d'inscription jeudi 18 janvier 2007 Statut Membre Dernière intervention 3 novembre 2011 - 3 nov. 2011 à 12:30
epineurien Messages postés 83 Date d'inscription samedi 21 mai 2005 Statut Membre Dernière intervention 22 mars 2011 - 8 nov. 2011 à 19:48

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/53719-jeu-de-la-vie

epineurien Messages postés 83 Date d'inscription samedi 21 mai 2005 Statut Membre Dernière intervention 22 mars 2011
8 nov. 2011 à 19:48

Pour Color je ne pense pas que ça vienne d'un problème de mémoire / collection, mais plutôt du fait que les valeurs RVB y sont stockées sous formes de propriétés et non d'attributs. Du coup on récupère la valeur via un accesseur (qui est une fonction) ce qui est sensiblement plus long que de lire directement un attribut, comme dans le cas de ma classe 'Couleur'.

Pour la classe Task je l'avais survolée un moment mais apparemment il s'agit juste d'un 'emballage' autour des ThreadPool, et les objets 'Task' semblent à usage unique. Je vais quand même faire un essai au cas où.

Quand à l'assembleur c'est le langage que j’utilisai (x86) avant de me mettre au C#. Ça laisse des habitudes reconnaissables on dirait ;-)

sgazaix Messages postés 2 Date d'inscription lundi 26 novembre 2007 Statut Membre Dernière intervention 7 novembre 2011
7 nov. 2011 à 15:19

C'est intéressant, même sans P.O.O !
En tout cas, j'ai appris quelque chose, c'est l'essentiel.

Ca me rapelle un jeu de la vie écrit en assembleur Z80, écrit en 1986 ... j'avais touché 300F(et oui, pas de problèmes avec l'euro en ce temps là...) de la revue "Amstrad CPC"!

The Meteorologist Messages postés 232 Date d'inscription jeudi 18 janvier 2007 Statut Membre Dernière intervention 3 novembre 2011 1
6 nov. 2011 à 14:28

Si ton objectif était d'obtenir les meilleurs performances possibles alors c'est assez réussi. Au passage, je salue le soin que tu as apporté à ton code (d'où ma note assez positive). Je trouve juste un peu frustrant que ce code soit si fastidieux à comprendre et à s’approprier pour d'éventuelles modifications. Mais si selon toi cette approche est la plus approprié pour obtenir des performances robustes alors je te fais confiance ;)

Concernant System.Drawing.Color, c'est assez surprenant que cela entraîne une chute des performances. System.Drawing.Color étant une structure elle devrait justement optimiser les performances du fait qu'elle ne laisse aucun déchet (pas de pointeur) et du coup, ne fait jamais intervenir le Garbage Collector.

Un petit conseil : As-tu déjà exploré les solutions du namespace System.Threading.Task ? Il fournit des méthodes pour le traitement parallèle sur plusieurs cores. Cela pourrait éventuellement accroître d'avantage les perf de ton logiciel.

Simon

epineurien Messages postés 83 Date d'inscription samedi 21 mai 2005 Statut Membre Dernière intervention 22 mars 2011
6 nov. 2011 à 11:29

J'ai l'impression que tu te fait une fausse idée de l'objectif de cette source ... J'ai clarifié la présentation, qui n'était peut être pas assez explicite. Le but n'est pas de publier un FrameWork d'automate cellulaire, ou de montrer l'application de la POO sur une problématique qui ne s'y prête pas, mais de montrer comment gagner en vitesse d’exécution en C#.

Concernant ma méthode 'obèse', le contenu de cette boucle est appelé 480.000 fois toutes les 10 millisecondes ... vouloir insérer des appels de fonction ou d'interface dedans pour le seul plaisir d'avoir découpé le code reviendrait à se tirer une balle dans le pied quand on connait le coût réel d'un appel de fonction.

De même, j'ai testé l'utilisation de la classe 'Color' : l'utilisation d'accesseurs (donc de fonctions) pour récupérer les valeurs RVB rallonge de plus de 20% le temps de création total de l'image ... donc je vais rester sur ma version 'Maison'.

Concernant le CheckForIllegalCrossThreads, oui c'était nécessaire dans la mesure où l'architecture du logiciel fait qu'un seul thread à la fois accède à un élément donné de la WinForm. On s'épargne ainsi de devoir accéder à chaque label à travers des 'InvokeRequired + Delegate', qui est une approche relativement lourde.

The Meteorologist Messages postés 232 Date d'inscription jeudi 18 janvier 2007 Statut Membre Dernière intervention 3 novembre 2011 1
5 nov. 2011 à 12:22

Une approche objet aurait pu simplement optimiser la qualité de ton code. Répartir le travail à travers plusieurs entités t'aurait éviter d'avoir des méthodes obèses telle que celle que tu as publié dans la présentation. La majorité des lecteurs ne s'aventureront pas à décrypter une pareille méthode. Tu aurais pu gagner en extensibilité aussi. Définir des interfaces définissants les règles de vie ou de mort d'une cellule par exemple. N'importe qui pourrait ainsi définir ses propres règles sans avoir à lire et comprendre la totalité du code. Certes pour un code personnel je pense que l'approche que tu utilises et la POO sont assez équivalentes dans la mesure ou tu connais sans doute ton code par coeur. Mais lorsqu'il doit être publié et compris par d'autres personnes, l’efficacité de la POO n'est plus à démontrer...

Autre chose, désactiver CheckForIllegalCrossThreads était vraiment nécessaire ?

Simon

epineurien Messages postés 83 Date d'inscription samedi 21 mai 2005 Statut Membre Dernière intervention 22 mars 2011
3 nov. 2011 à 19:56

Pour la classe "Color" effectivement, j'avais oublié qu'on pouvait définir ses propres 'color' directement en RVB. J'y penserais à l'avenir, merci.

En revanche pour la POO, j'avoue ne pas bien voir quel gain il pourrait y avoir ici. La POO est une excellente technique, ça ne veut pas dire qu'elle est la meilleure pour toutes les problématiques. Mais si il y a une technique qui permet d'optimiser le traitement d'un problème comme le "Jeu de la vie" en passant par une approche plus 'objet', ça m'intéresse.
Niveau "programmation pure" le but ici était plutôt de fournir une illustration du ThreadPooling et de la conversion byte[] -> bitmap, qui ne sont pas des techniques excessivement répandues malgré leur intérêt.

Pour finir, j'ai bien vu qu'il y avait déjà beaucoup de "Jeux de la vie" sur le net ou ici ;-)
Mais j'ai toujours trouvé dommage que la majorité ne laisse pas la possibilité de pouvoir 'tester à la main' des formes et suivre leur comportement.

The Meteorologist Messages postés 232 Date d'inscription jeudi 18 janvier 2007 Statut Membre Dernière intervention 3 novembre 2011 1
3 nov. 2011 à 12:30

Bonjour epineurien,

Premièrement pourquoi une classe pixel ? La structure System.Drawing.Color est plus complète et aurait fait l'affaire.

Deuxièmement, étant donné qu'il s'agit du n ième jeu de la vie sur codes-sources, de la POO n'aurait pas été un luxe...

Simon

Discussions similaires

Générateur de regles de jeu...

Programme d'un jeu de la Vie en Python !

Code Jeu de la vie C++ avec classes et vecteurs

"le jeu de la vie"en langage c

jeu solitaire avec carte

Votre réponse

Discussions similaires