Discussion :

[Invité]

Bonjour,

Je voudrais faire un programme qui modifie souvent son propre code.

La solution basique est de modifier la fonction voulue dans le code source, recompiler entièrement, exécuter puis de tuer le "vieux" processus. Comme cette opération arrive souvent, il faudrait trouver un moyen de la rendre plus rapide.

En gros, pour l'instant, l'échelle à laquelle je sais modifier le code est celle du programme global. J'aimerais savoir si c'est possible de ne recompiler qu'une classe (dans son propre fichier) puis de la "lier" au programme en cours d'exécution.

Je me demande aussi si ce que l'on appelle une bibliothèque partagée (.dll .so) peut me servir à quelque chose. J'ai pas très bien compris comment ça marche : est-ce qu'une bibliothèque partagée est choisie au début de l'exécution du programme, ou est-ce qu'on peut la changer plein de fois pendant l'exécution ?

Merci d'avance si vous éclairez ma lanterne.

[koala01]

Salut,

Déjà, pourquoi voudrais tu modifier le code d'une classe en cours d'exécution

Je t'avouerai que j'ai du mal à comprendre le but de la manoeuvre: une classe est un objet qui fournit un certain nombre de services clairement définis et non ambigus...

Si tu vient à modifier les services que cet objet est susceptible de rendre en cours d'exécution, comment va tu bien pouvoir faire confiance à ton objet

[Invité]

Merci de ton intérêt.

Je n'ai pas encore réfléchi quelle est la classe à modifier, ni quelle signification ce que cela peut avoir. Pour l'instant je regarde juste si il y a un mécanisme de base qui me permettrait de réaliser le programme que j'ai en tête. La décomposition du programme en objets se fera pas avant un bout de temps. Quand je dit "modifier une classe", c'est parce que c'est la plus petite unité qu'on puisse modifier et recompiler (enfin je pense).

Ce que je voudrais faire c'est un programme qui apprend des expériences qu'il fait et essaye d'améliorer un algorithme. C'est pour ça qu'il doit pouvoir modifier une fonction, pour voir si elle est mieux que la précédente ou pas.

[Mac LAK]

Ce que je voudrais faire c'est un programme qui apprend des expériences qu'il fait et essaye d'améliorer un algorithme. C'est pour ça qu'il doit pouvoir modifier une fonction, pour voir si elle est mieux que la précédente ou pas.

Le C++ n'est pas franchement le langage idéal pour un code adaptatif de type neuronal / système expert... On utilise en général des langages interprétés pour ça, ou mieux, des langages fonctionnels (interprétés eux aussi), car ils permettent de construire un programme à partir d'un autre programme, sans altérer les performances du programme construit dynamiquement (par rapport au langage, bien sûr : ça restera toujours plus lent que l'équivalent fait en C/C++ et compilé).

On peut faire de l'IA en C/C++, bien sûr, mais l'algorithme doit être compilé : ce sont les données qui évoluent, pas le code. Par exemple, on peut parfaitement faire un réseau neuronal en C++, mais le résultat de ton IA sera des données "interprétées" par le réseau neuronal, et non pas du code C++ compilé !!

Ce que je vois de plus proche de ton besoin, ce serait quelque chose qui oscillerait entre les algos génétiques et les réseaux de neurones... Dans les deux cas, tu vas être désagréablement surpris de la complexité du truc.

Une solution bien plus pratique, au prix de quelques pertes de performances bien sûr, serait d'inclure un interpréteur LUA ou Python dans ton programme, et de travailler ensuite sur des fonctions LUA/Python qui, elles, pourront évoluer librement.
Par contre, tu n'obtiendras pas les perfs d'une fonction équivalente en C ou C++, et en plus tu n'auras JAMAIS la garantie qu'un algo "optimal" dans le langage de script choisi sera lui aussi optimal en C/C++.

[koala01]

Le principal problème, c'est que la compilation est un processus complexe, qui nécessite au minimum pas moins de trois outils distincts:

• le préprocesseur
• le compilateur en lui-même
• l'éditeur de liens

auxquels on peut rajouter, selon le cas, des outils de génération d'archive et autres...

Et il va de soi que chaque outil a ses propres dépendances:

• le préprocesseur et le compilateur doivent pouvoir retrouver les fichiers d'en-tête
• l'éditeur de lien doit pouvoir retrouver les bibliothèques tierces utilisés (voire certaines bibliothèques utilisées par défaut )

Il me semble donc difficile d'envisager de créer une bibliothèque dynamique "à la volée" pour être en mesure de l'utiliser "directement"

Par contre, ce que tu peux envisager de faire, c'est de factoriser au maximum les différentes parties de ton algorithmes (ce qui implique de toutes les compiler au début).

Ton application "choisirait" les parties de l'algorithme en fonction des résultats précédents et validerait ou rejetterait les solutions les moins opportunes.

Si l'application doit pouvoir reprendre là où elle s'est arrêtée, il peut "suffire" de sauvegarder les différentes possibilités déjà testées et la dernière possibilité retenue.

Mais, il faut bien comprendre que l'ordinateur est un truc bête comme mes pieds qui ne connait absolument pas la nuance et qui n'a jamais que l'intelligence que l'on a été en mesure de lui insuffler...

A l'heure actuelle (et sans doute encore pour longtemps) le choix que peut avoir un ordinateur reste limité à oui ou non, même si le chemin qui même à cette dualité essaye d'apporter un maximum de nuance.

On est encore loin des ordinateurs qui commencent à réfléchir par eux mêmes comme on en vois dans I Robot ou dans terminator

[3DArchi]

ce sont les données qui évoluent, pas le code.

On peut faire en C++ du code qui s'auto modifie. Mais t'as de grande chance de voir ton anti-virus râler
@po : je dirais que tu mets la charrue avant les bœufs : tu penses à des détails d'implémentation alors qu'à priori tu ne connais pas encore tes specs ni ta conception.

[Mac LAK]

On peut faire en C++ du code qui s'auto modifie. Mais t'as de grande chance de voir ton anti-virus râler

Pour ma part, j'ai arrêté le code auto-modifiant à l'époque du DOS, avec un tracé de lignes suivant Bresenham en ASM qui "construisait" la boucle optimale directement en écrivant les opcodes... Depuis Win32, c'est effectivement le meilleur moyen de voir ton programme partir en zone de quarantaine sans préavis !

[3DArchi]

en écrivant les opcodes...

Je vois qu'on a eu les mêmes jeux Pour l'anecdote, j'ai vu aussi faire du code auto-modifiant dans un jeux sous Windows 95. Me souviens plus si ça avait dépasser le stade expérimental pour aller en prod.

[Invité]

On peut faire en C++ du code qui s'auto modifie

La modification est écrite en c++ (intéressant) ou il faut manipuler un langage de plus bas niveau (pas intéressant) ?
Ca doit être la deuxième solution, les instructions chargées en mémoire ne peuvent plus être en c++.

tu penses à des détails d'implémentation alors qu'à priori tu ne connais pas encore tes specs

C'est vrai, mais c'est vraiment une opération de base de mon futur programme, donc il faut que je m'assure qu'elle est disponible en c++. Si c'est pas le cas ça sert à rien de faire la conception.

inclure un interpréteur LUA ou Python dans ton programme, et de travailler ensuite sur des fonctions LUA/Python

La perte de performance n'est pas très grave pour le programme chargé de trouver l'algorithme. Ce programme là pourrait être en langage de script. Par contre l'algorithme résultant doit être écrit en c++ (question de rapidité).

mais le résultat de ton IA sera des données "interprétées" par le réseau neuronal, et non pas du code C++ compilé !!

Arg ... ça c'est embêtant, parce que c'est exactement ce que je voulais ...
Comme je l'ai dit plus haut, il y a la solution de tout recompiler qui marche forcément, mais c'est pas très satisfaisant.

Il me semble donc difficile d'envisager de créer une bibliothèque dynamique "à la volée" pour être en mesure de l'utiliser "directement"

Comme en c++ il y a des trucs qui sont déterminés à l'exécution je pensais que ça pouvait se faire. Je vais peut-être devoir me rabattre sur un langage ou il y a plus de trucs déterminés à l'exécution (mais le moins possible).





Je pense que je vais changer de tactique : je vais me faire la main sur les techniques d'apprentissage automatique avec un langage interprété, et je ensuite je reviendrais à la charge pour le faire en c++ compilé (ou un langage un poil plus dynamique, mais ça serait dommage).
Comme ça j'ai pas toutes les difficultés d'un coup.

On utilise en général des langages interprétés pour ça, ou mieux, des langages fonctionnels (interprétés eux aussi)

Vous avez une idée d'un langage de script ou fonctionnel dans lequel un programme peut modifier son code source très simplement et très facilement ? (même s'il est terriblement lent, ça ne me dérange pas du tout)

ce sont les données qui évoluent, pas le code

Est-ce que ça reste vrai pour les langages interprétés ?

[JolyLoic]

Vous avez une idée d'un langage de script ou fonctionnel dans lequel un programme peut modifier son code source très simplement et très facilement ? (même s'il est terriblement lent, ça ne me dérange pas du tout)

Python par exemple.
Je présume qu'en Lisp, ça doit aussi pouvoir se faire, puisque tout peut se faire en Lisp, d'après ses défenseurs (et rien ne peut se faire par moi en Lisp...)
Et probablement plein d'autres.

Mais j'ai un peu de mal à voir comment tu va générer automatiquement du code qui ait du sens pour ton optimisation... En général, en apprentissage automatique, on modifie des structures de données, pas du code, et le nombre de paramètres variables fait déjà tout exploser...

[Mac LAK]

Je vois qu'on a eu les mêmes jeux

Ah, la bonne époque où l'on pilotait directement le mode 13h ou le mode VESA à partir de BP7...

La modification est écrite en c++ (intéressant) ou il faut manipuler un langage de plus bas niveau (pas intéressant) ?
Ca doit être la deuxième solution, les instructions chargées en mémoire ne peuvent plus être en c++.

On écrit du langage machine, carrément, c'est à dire les octets d'opcode et même pas les mnémoniques ASM. Donc, on écrit "0x90" en mémoire et non pas "NOP", par exemple.
Je ne te cache pas que c'est assez ... abrupt, on va dire, comme méthode.

C'est vrai, mais c'est vraiment une opération de base de mon futur programme, donc il faut que je m'assure qu'elle est disponible en c++. Si c'est pas le cas ça sert à rien de faire la conception.

Les specs ne devraient jamais spécifier le langage cible, c'est la conception qui fait ça... L'opération que tu décris EST faisable, sans AUCUN problème, mais pas avec n'importe quel langage (du moins, pas de façon triviale).

La perte de performance n'est pas très grave pour le programme chargé de trouver l'algorithme. Ce programme là pourrait être en langage de script. Par contre l'algorithme résultant doit être écrit en c++ (question de rapidité).

C'est là que ça coince : l'algo sera écrit en LUA ou Python, et non pas en C++... Et rien ne te garantit qu'un algo optimal Python sera également optimal en C++, et réciproquement.

Arg ... ça c'est embêtant, parce que c'est exactement ce que je voulais ...
Comme je l'ai dit plus haut, il y a la solution de tout recompiler qui marche forcément, mais c'est pas très satisfaisant.

Ou, comme te l'as proposé koala01, de passer par une DLL chargée en mode JIT, que tu peux, elle, recompiler dynamiquement pendant l'exécution... Ceci étant dit, c'est franchement barbare, et tu vas hurler : le niveau d'optimisation dépend AUSSI du compilateur et des réglages appliqués !!!

Vous avez une idée d'un langage de script ou fonctionnel dans lequel un programme peut modifier son code source très simplement et très facilement ? (même s'il est terriblement lent, ça ne me dérange pas du tout)

Oh, t'en as une pelletée... Javascript, LUA, Python, PHP, Lisp, Perl, et j'en oublie sûrement quelques tonnes.

En gros, tout langage interprété qui est capable de prendre une fonction sous forme d'une chaîne / fichier de façon dynamique, et/ou qui possède une fonction de type "eval", est un bon candidat. Je pense qu'il serait beaucoup plus difficile de trouver un langage interprété qui ne soit PAS capable de faire ça...

Est-ce que ça reste vrai pour les langages interprétés ?

Justement, non : un langage interprété peut construire un programme de façon dynamique, même si cela a bien sûr un coût sur la vitesse d'exécution.
Après, il faut bien comprendre quand même que ce n'est pas quelque chose de "courant", et qu'il est assez rare (en dehors peut-être du domaine de l'IA et, justement, des interpréteurs) d'avoir réellement besoin d'une telle fonction. La plupart du temps, avoir "besoin" d'une telle fonctionnalité est plutôt le signe d'une erreur de conception.

[Médinoc]

Je vois qu'on a eu les mêmes jeux Pour l'anecdote, j'ai vu aussi faire du code auto-modifiant dans un jeux sous Windows 95. Me souviens plus si ça avait dépasser le stade expérimental pour aller en prod.

J'ai vu ça assez souvent dans la communauté Calculatrices TI, où les contraintes existent à la fois en performance et en mémoire. Ainsi, dans certaines bibliothèques, les fonctions d'affichage d'image se modifiaient en début d'appel pour déterminer s'il fallait utiliser OR, AND ou EOR (XOR)...

Sous un OS moderne, il arrive plus souvent de créer du code à la volée, notamment pour des fonctions callback.

[Invité]

Ok, donc je vais essayer avec un langage interprété. LUA je pense car la capacité d'interfacage avec le c++ pourrait me servir.

Merci beaucoup à tous pour vos explications.

[Mac LAK]

Ok, donc je vais essayer avec un langage interprété. LUA je pense car la capacité d'interfacage avec le c++ pourrait me servir.

Python s'interface également très bien avec C++, donc c'est plutôt une question de "goût" personnel pour chacun de ces deux langages qu'un problème technique potentiel.

[Luc Hermitte]

Le C++ n'est pas franchement le langage idéal pour un code adaptatif de type neuronal / système expert...

Le neuronal n'a rien d'auto-modifiant, c'est que des maths. Et les multiplications de matrices, et autres mises à jour de ces dernières, on maitrise très bien en C++.

A la limite, on peut imaginer rajouter des algos d'apprentissage, mais pour ça 1- arrêter le programme ne coute rien (non mais vous avez vu le coût en temps de l'étude sur comment préparer les données?) 2- les plugins ça marche très bien. 3- les trucs ajoutés sont le résultat de longues heures de travail par une personne, cela ne sera jamais magique. Surtout avec les RdNA.


Pour l'automodif de code, j'en étais resté au fait que les algo gen sur du code LISP ne donnaient rien de concluant -- et LISP me parait plus adapté que les langages impératifs pour ce genre de choses... (maintenant je m'amuserais plus en Prolog, mais toujours pas pour faire de l'automodifiant automagique qui est une chimère)

[Mac LAK]

Le neuronal n'a rien d'auto-modifiant, c'est que des maths.

Certes, j'ai fait un abus de langage, je l'admet. Disons plutôt que c'est plus simple à faire avec d'autres langages qui permettent le code auto-modifiant... Bien entendu, on peut le faire en C++, c'est juste qu'il y a beaucoup plus rapide que ce langage pour écrire / prototyper un tel système.

[Luc Hermitte]

Certes, j'ai fait un abus de langage, je l'admet. Disons plutôt que c'est plus simple à faire avec d'autres langages qui permettent le code auto-modifiant... Bien entendu, on peut le faire en C++, c'est juste qu'il y a beaucoup plus rapide que ce langage pour écrire / prototyper un tel système.

Pour faire du code automodifiant, je suis entièrement d'accord, le C++ n'est pas adapté pour des raisons techniques premièrement (car compilé), et probablement pour son côté impératif ensuite (surtout si c'est lui qui doit décider de s'automodifier comme un grand)

Pour ce qui est de prototyper des RdNs (ta réponse me laisse douter du sujet derrière le "prototypage"), effectivement, matlab ou SNNS sont 100 fois plus adaptés. Et pour l'implémentation, le C++ marche bien, et vite (ces systèmes sont déjà assez lents comme ça à converger).