Sicstus Prolog : contrôle du temps d'exécution

Bonjour,

J'utilise Sicstus Prolog pour développer une intelligence artificielle. Une des contraintes de mon projet est que la demande d'un coup sur le plateau ne doit pas dépasser un certain temps donné. Mon prédicat principal est modifié de façon à s'arrêter au bon moment.

Pour mes mesures de temps, j'utilise walltime (le temps réellement pris pour exécuter le programme) et non runtime (temps d'exécution sur CPU).

Le problème, c'est que parfois (une fois sur 10 peut-être), le programme dépasse le temps imparti. Cela est dû au fait que le programme s'arrête quelques secondes et reprend ensuite. Le prédicat détecte bien que le temps est écoulé, mais il est trop tard.

Si je me base sur runtime pour arrêter le prédicat, le programme s'arrête au bon moment du point de vue runtime, mais un niveau walltime, ça dépasse parfois le temps imparti. Par exemple, si je fixe le temps imparti à 4000 ms, le programme va s'arrêter quand la durée en runtime est à 4000 ms, mais en walltime, ça peut être 6000 ms. Autrement dit, le programme n'a rien fait pendant 2000 ms.

Je sais qu'il existe un module nommé timeout qui permet de limiter le temps d'exécution d'un prédicat, cependant, lorsque le temps est dépassé, le prédicat est arrêté, ce que je ne veux pas car je ne pourrai pas avoir de solution.

Je voulais donc savoir s'il y a un moyen de s'assurer qu'un programme prolog ne puisse pas être interrompu pendant son exécution (ce qui m'étonnerait) ou s'il y a d'autres méthodes pour limiter le temps d'exécution d'un prédicat.

Merci d'avance pour vos réponses.

Bonjour,

Finalement, j'ai trouvé une solution, le problème était double.

La première source de perte de temps était le garbage collector de SICStus. Je l'ai donc désactivé avec la ligne suivante :

Code:

---

set_prolog_flag(gc, off).

---

Il est alors appelé manuellement seulement lorsque cela est sans risque avec le prédicat suivant :

Code:

---

garbage_collect.

---

L'autre source de perte de temps était la gestion des stack overflows de certaines piles internes à SICStus. En effet, lorsque les piles sont pleines, SICStus ré-alloue de la mémoire pour pouvoir y ajouter de nouvelles données. La solution, en ce qui me concerne, à été d'initialiser la taille de ces piles à une taille suffisamment grande pour que SICStus n'ait pas besoin de ré-allouer la mémoire (ou rarement). Pour cela, j'ai ajouté ceci dans un script bash avant de lancer SICStus :

Code:

---

1 2	export GLOBALSTKSIZE=50M export LOCALSTKSIZE=100M

---