Interface Python/C++ que choisir ? vos avis svp

[tyrtamos]

Bonjour,

Ça y est!!!

Voilà mon code test:

bib.cpp

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include "bib.h"
 
int add_(int a, int b){
    return a+b;
    }
 
int pgcd_(int a, int b){
    int r;
    while (b!=0) {
        r = a%b;
        a = b;
        b = r;
        }
    return a;
    }

bib.h

Code :

1
2
int add_(int a, int b);
int pgcd_(int a, int b);

calcul.pyx

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#!/usr/bin/python
# -*- coding: utf-8 -*-
from __future__ import division
# Python 2.7
 
from cpython cimport bool, list, dict, tuple, long as llong
 
from cython import cclass, ccall, cfunc, returns as creturns, locals as clocals
 
cdef extern from "bib.h": 
    cdef int add_(int x, int y)
    cdef int pgcd_(int a, int b)
 
#############################################################################
@ccall
@creturns(int)
@clocals(x=int, y=int)
def add(x, y):
    """addition de x et y"""
    return add_(x,y)
 
#############################################################################
@ccall
@creturns(int)
@clocals(a=int, b=int)
def pgcd(a, b):
    """PGCD de a et de b"""
    return pgcd_(a,b)

setup.py:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
 
ext_modules = [Extension("calcul",
                         sources=["calcul.pyx", "bib.cpp"],
                         include_dirs=["."],
                         language="c++"
                        )
              ]
 
setup(
  name = 'Demos',
  ext_modules = ext_modules,
  cmdclass = {'build_ext': build_ext},
)

compilation en console par:

Code :

python setup.py build_ext --inplace

Ce qui donne "calcul.pyd sous Windows, ou "calcul.so" sous Unix

Utilisation:

Code :

1
2
3
4
5
6
7
8
9
10
#!/usr/bin/python
# -*- coding: utf-8 -*-
from __future__ import division
# Python 2.7
 
from calcul import add, pgcd
 
print add(7, 11)
 
print pgcd(56,42)

Ce qui donne les bons résultats (18 et 14)

Contrairement à ce que je pensais, la partie de code en C++ (bib.cpp) n'est pas compilée en bibliothèque indépendante, mais liée au code Cython.

J'ai essayé avec Windows (compilateur Visual C++ et mingw32) et Mint13 compatible Ubuntu 12.04: tout fonctionne parfaitement.

A noter que l'exemple à télécharger fonctionne aussi parfaitement, et contient du code plus complexe (classes C++): si nécessaire, il pourrait être intéressant de s'y reporter.

Ok?

[Edit] niveau performance, la solution du pgcd directement codé en C++ est 4 fois plus rapide que la version en Python pourtant déjà rapide (merci Euclide!). Condition d'essai: 1 million de valeurs de a et de b au hasard, comprises entre 100 et 100000.

[wiztricks]

Salut,

Le wiki Cython contient des tutos montrant comment wrapper C++ ici.

Pour répondre à la question du PO, l'outil le plus efficace dépend du contexte.

Si le seul élément du contexte c'est vous, on peut supposer que vous découvrez ces sujets.

Partez de construction C++ et regardez les difficultés que vous éprouvez à les mettre en œuvre dans un cas ou dans l'autre.
Quelque soit l'outil que vous aurez choisi, pratiquez suffisamment longtemps pour faire le tour du sujet.

Après avoir pris le temps de balayer le sujet avec un de ces outils, passer à un autre ne sera pas un gros soucis: tous ces outils font la même chose seule la mise en œuvre change.
Bon courage,
- W

[fred1599]

Bravo Tyrtamos!!!

Je pige pas les import dans le pyx, tu peux m'expliquer d'où ils viennent, j'ai du zapper des choses dans le tuto?

Sinon pourquoi tout ces décorateurs, je n'ai jamais utilisé cela dans un pyx, et dans beaucoup de fichiers exemples, je ne les vois pas non plus.

[tyrtamos]

Bonjour fred1599,

Envoyé par fred1599

Je pige pas les import dans le pyx, tu peux m'expliquer d'où ils viennent, j'ai du zapper des choses dans le tuto?

Pour le 1er:

Code :

from cpython cimport bool, list, dict, tuple, long as llong

En principe, les types cités dans les déclarations de type sont ceux du C. Il s'agit ici d'introduire les types Python qui pourront être utilisés en Cython (il faudrait aussi "set", etc...). Et le dernier, le "long" de Python, a été rebaptisé par moi "llong" pour éviter le conflit avec le "long" du C (qui n'a pas une longueur arbitraire). Comme je l'ai déjà dit, on peut utiliser les types de Python qui n'existent pas en C, mais plus on le fait et moins c'est rapide. Je suis d'ailleurs déjà tombé sur une fonction plus longue à l'exécution en Cython qu'en pur Python à cause des "long" Python.

Pour le 2e:

Code :

from cython import cclass, ccall, cfunc, returns as creturns, locals as clocals

Ça va avec les décorateurs:
- type d'objet: cclass: classe; cfunc: fonction appelable uniquement à partir du C; ccall: fonction appelable à partir du C et de Python.
- creturns: déclare le type d'objet en retour.
- clocals: déclare le type des arguments et des variables internes des fonctions.

Envoyé par fred1599

Sinon pourquoi tout ces décorateurs, je n'ai jamais utilisé cela dans un pyx, et dans beaucoup de fichiers exemples, je ne les vois pas non plus.

Parmi toutes les possibilités données par le manuel, j'ai choisi la solution "décorateur" (http://docs.cython.org/src/tutorial/pure.html), et ceci pour une raison très précise: dans le cas général, quand je veux accélérer une fonction Python par Cython, j'ai DEJA le code source Python, et je ne veux pas la réécrire! La solution des décorateurs me permet de ne pas avoir à modifier ce code Python mais seulement d'ajouter les déclarations qui manquent pour que Cython sache comment convertir en C! Je trouve ça très pratique.

J'ai d'ailleurs pris la précaution de vérifier que cette solution n'était pas plus longue à l'exécution que la solution qui oblige à ré-écrire le code. Il n'y a que quelques petits problèmes qui restent à résoudre, comme par exemple les initialisations: quand on déclare que x est un "double" (type C), il faut l'initialiser par x=1.0 et non x=1 qui génère une erreur. Mais c'est seulement un bon réflexe à prendre...

Ce n'est cependant pas une "assurance tout risque", car certains codes en pur Python ne se traduisent pas en Cython, ou ne donnent pas la meilleure performance souhaitée: dans ce cas, mais dans ce cas seulement, il faut repenser le code pour l'adapter à Cython.

[fred1599]

Ok, merci Tyrtamos, je vais analyser tes codes, relire la doc, dommage que je sois parti 3 jours, ça va me mettre en haleine pendant tout ce temps. Tu auras sûrement des retours d'ici vendredi ou samedi.

Aussi je souhaiterais chercher une manière plus ressemblante à celle que j'utilisais avec du C et très simple.

Je suis en train de voir du côté de ctypes qui semble bien plus simple pour appeler la lib, je vais chercher.