serge_sans_paille a écrit 264 commentaires

Alors deuxième partie, mais j'ai eu la flemme d'écrire le code cython

Le code d'entrée est le suivant

def zero(n,m): return [[0 for row in xrange(n)] for col in xrange(m)]
def matrix_multiply(m0, m1):
    new_matrix = zero(len(m0),len(m1[0]))
    for i in xrange(len(m0)):
        for j in xrange(len(m1[0])):
            for k in xrange(len(m1)):
                new_matrix[i][j] += m0[i][k]*m1[k][j]
    return new_matrix

Et j'utilise des list et pas de numpy.* en entrée.

python: 1.97s
pypy: 0.200s
shedskin: 0.103s
pythran: 0.06s

ce qui confirme le classement précédent

merci pour les remarques, constructives à défaut d'être encourageantes ;-)

Par acquit de conscience, j'ai lancé un petit bench (un quicksort dont le code cython est donné là et dont le code python est identique aux cdef prêts.

J'ai fait mouliné ça sur des tableaux de flottants numpy.array (sauf pour shedskin qui supporte pas) de taille 10000, à l'aide du module timeit et en prenant la médiane sur 11 runs. Tout ce qui peut être compilé est compilé en -O2.

python: 11.802s
pypy: 0.120s
shedskin: 0.096
pythran: 0.092
cython: 0.060

le classement est au final assez représentatif de ce que l'on pouvait attendre: plus on met d'effort / de contraintes plus on obtient de perfs. 0 efforts pour pypy et de sacré bonnes perfs, pas mal d'annotations avec cython et de très bonnes perfs.

/me va rejouer le même jeu sur un matrix multiply pour voir.

By Jove
Bien sûr Cython devrait être dans le haut de la liste. Et puis le côté incrémental est vraiment chouette :-)

Merci ;-)

tu peux même dire ultra moche :(

bon, j'ai pas l'impression d'avoir le droit de modifier ça…

Approuvé && corrigé !

Initialement je voulais avoir une grosse pastille à chaque section, mais je m'en suis pas sorti…

Bonne idée le _easter egg, il pourrait par exemple changer de couleur, ou grossir un peu (dur à digérer les grosses pastilles).

On pourrait mettre un fantôme sur la dernière page avec un regard qui changerait en fonction de la pastille croquée…

Bon, ce sera pas pour tout de suite non plus hein ;-)

Généralement un \vspace{-X} où X est une unité de mesure genre X =.5em, fait l'affaire.

Il faut l'insérer entre tes deux environnements : elle va produire un espace vertical de taille négative.

sinon en utilisant la vénérable commande fmt

pdftottext recette.pdf - | fmt

Je trouve le résultat assez sympa :p

Dans le monde autotools, on donne le chemin d'installation lors du configure (genre ../configure -- prefix=$HOME/local) ce qui permet de connaître avant la compilation cette précieuses valeur et de la mettre quelque part.

Comment cela fonctionne-t-il sous cmake ? c'est un paramètre du makefile ?

Pouvoir regénérer correctement le système de construction avec autoreconf est malheureusement l'exception et non pas la règle. Et c'est l'empaqueteur qui te parle.

Curieux, il me semble que l'empaqueteur se base sur le tar.gz, et donc plus besoin de tout re-générer ? À moins qu'il y ait besoin de patcher le système de build et donc de re-générer ?

Autotools sait faire, sauf que peu de développeurs savent s'en servir correctement. Le résultat c'est que la compilation out-of-source est dysfonctionnelle sur la plupart des projets gérer par autotools.

Alors qu'un joli make distcheck va vérifier tout seul que la compilation out-of-the-source fonctionne bien (et pleins d'autres choses très agréables d'ailleurs) :(

salut,
j'avais écrit un script qui faisait des choses dans le même genre, il y a peu.
Il prenait des slides en pdf (sortie beamer) une vidéo (du gars (ou de la fille) présentant ses slides et un fichier de temps (nombre de secondes par slide) et te faisait un mix de tout ça dans une belle vidéo.

Par contre pour ton cas, à part lire le timing dans un fichier externe, il faisait pas grand chose de plus.

et par ailleurs un très bon projet !
utilisé il ya quelques années sur grid 5000 avec plaisir :)