Quel est l'effet des déclarations ftype sur les fonctions intégrées dans la SBCL ?

Question

Je me base sur un vieux code Common Lisp écrit par d'autres, qui comprend des lignes telles que la suivante au début de quelques fonctions :

(declare (ftype (function (&rest float) float) + - * min max))

Si je comprends bien, le but est d'indiquer au compilateur que les cinq fonctions énumérées à la fin du formulaire ne recevront que des flottants. Le compilateur peut utiliser cette information pour créer un code plus efficace.

Certains Lisps ne se plaignent pas de cette déclaration (ABCL, CCL, ECL, LispWorks, CLISP), mais la SBCL n'acceptera pas cette déclaration dans la configuration par défaut. Il est possible de faire en sorte que SBCL l'accepte en plaçant

(unlock-package 'common-lisp)

dans le fichier d'initialisation .sbclrc. C'est ce que je fais depuis environ un an. Je suppose que c'est nécessaire parce que +, -, etc. sont dans ce paquet, et le code modifie les déclarations de ces fonctions.

Ma question est la suivante : la déclaration du type de fonction des fonctions intégrées telles que + et min peut-elle avoir un effet bénéfique sur le code compilé dans SBCL ? (Si c'est le cas, alors pourquoi SBCL se plaint-il de ces déclarations par défaut ?) Serait-il préférable de supprimer ces déclarations de type de fonction, et ensuite de se débarrasser de l'attribut unlock-package dans le fichier .sbclrc ?

Merci.

Answer 1

Si je comprends bien, le but est d'indiquer au compilateur que les cinq fonctions énumérées à la fin du formulaire ne recevront que des flottants. Le compilateur peut utiliser cette information pour créer un code plus efficace.

De plus, ils ne renvoient que des flotteurs. Avec certains paramètres d'optimisation, le compilateur Common Lisp ne génère pas de contrôles à l'exécution et peut ne générer que du code pour les calculs de flottants. SBCL peut également afficher des avertissements de compilation dans certains cas, lorsqu'il détecte que le code viole des déclarations de type.

C'est aussi une source d'erreurs, car à partir de maintenant (dans le cadre de la déclaration), des fonctions de base comme + y - sont déclarés ne pas fonctionner sur d'autres types de nombres (entiers, complexes, ...).

Alors, quel est le but de ces déclarations ? Puisqu'il s'agit de code portable (et que la plupart des implémentations n'implémentent pas la vérification de type à la compilation), cela ne peut être qu'à des fins d'optimisation. Une partie de cela pourrait ne pas être nécessaire dans la SBCL, puisqu'elle utilise l'inférence de type.

Pourquoi la SBCL ne permet-elle pas de modifier la fonctionnalité intégrée par défaut ? C'est pour éviter de se tirer une balle dans le pied : vous modifiez le langage de base. Maintenant, les opérations numériques de base peuvent conduire à des erreurs.

Des moyens de gérer ça :

• n'utilisez que des déclarations locales, ne modifiez pas le langage de manière globale. Vous indiquez qu'ils ne sont déclarés que localement - c'est bien.

• déclarer les valeurs des variables à la place

• écrire des fonctions spéciales pour le cas float et les déclarer inline.

• ne déverrouillez le paquet CL que pendant la compilation de ces quelques fonctions. gardez-le verrouillé plus tard.

Ma question est la suivante : la déclaration du type de fonction des fonctions intégrées telles que + et min peut-elle avoir un effet bénéfique sur le code compilé dans la SBCL ?

Vous pouvez vérifier cela en regardant le code désassemblé et aussi en profilant. Assurez-vous que vous compilez la fonction avec le bon paramètre d'optimisation. En Common Lisp, la fonction DISASSEMBLE devrait vous montrer le code machine d'une manière lisible. Le compilateur SBCL devrait également vous indiquer s'il ne peut pas optimiser le code compilé.