J'ai la même approche par rapport à numpy. 95% du temps, j'arrive à avoir des performances très honorables en utilisant intelligement numpy.
Par contre, parfois, refactoriser pour gagner des perfs grâce à numpy peut sérieusement nuire à la lisibilité du code (si on mélange index tricks, tensordot, einsum et des reshape, ça devient vite incompréhensible), auquel cas j'écris en C++. C'est souvent lorsqu'il y a plusieurs boucles for imbriquées et qu'elles sont difficiles à traduire en numpy. Du coup, pythran me semble intéressant pour ces cas-là si on arrive à avoir des perfs de boucle for proches du C.
[^] # Re: Et par rapport a du pur Python ?
Posté par Jux . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 3.
J'ai la même approche par rapport à numpy. 95% du temps, j'arrive à avoir des performances très honorables en utilisant intelligement numpy.
Par contre, parfois, refactoriser pour gagner des perfs grâce à numpy peut sérieusement nuire à la lisibilité du code (si on mélange index tricks, tensordot, einsum et des reshape, ça devient vite incompréhensible), auquel cas j'écris en C++. C'est souvent lorsqu'il y a plusieurs boucles for imbriquées et qu'elles sont difficiles à traduire en numpy. Du coup, pythran me semble intéressant pour ces cas-là si on arrive à avoir des perfs de boucle for proches du C.