serge_sans_paille a écrit 251 commentaires

En tout cas c'est dans le tutoriel officiel.

Comme quoi l'apprentissage par induction dont je suis friand a ses limites :-).

Oui, j'ai vu cet idiome de nombreuses fois. Ça ressemble furieusement à ça http://en.wikipedia.org/wiki/Option_type.

On dirait que les softeux ont toujours autant de mal avec le hardware.

Ça c'est sûr :-) trois années passées à m'y frotter (le moins possible) n'ont malheureusement pas apportées de grands changements :-(

le nombre de transistors d'une puce double tous les 18 mois/ 2 ans pour le même prix.

Il me semblait que c'était à surface constante, d'où problème de « mur de la chaleur » etc. Pareillement les moulti-cœurs ne changent rien au problème d'intégration.

C'est surtout une histoire de cout de développement qui explose.

Oui. La difficulté de programmation de l'archi n'y est pas étrangère, puisqu'il faut embaucher des développeurs spécialisés au lieu de développeurs généralistes.

Pour le moment, j'ai des compteurs de références sur chacun des conteneurs (liste / ensemble uniquement donc). Comme il n'y a pas de classes utilisateur, je ne pense pas qu'il soit possible de créer des références croisées.

Ça suffit, non ?

Dans ce cas, on peut quand même s'en sortir en déléguant l'évaluation de la condition à l'exécution, ce qui a quelques défauts (dont augmentation de la taille du code) mais pas mal d'avantages aussi.

Un cas classique pour gérer l'aliasing:

#include <stdint.h>
void foo(size_t n,   float a[n], float b[n]) {
  // aucune garantie que a et b ne se chevauchent pas partiellement ou totalement
  for(size_t i=1;i< n ; i++) { // cette boucle n'est parallèle que si a et b ne se chevauchent pas
    a[i] = 2*b[i-1];
  }

Dans ce cas un petit test dynamique permet de suppléer aux carences de l'analyse statique

void foo(size_t n,   float a[n], float b[n]) {
  if( &a[n]<=&b[0] || &b[n] <= &a[0] ) foo_parallel(n,a,b);
  else foo_sequential(n,a,b);
}

icc fait ça à fond !

Il y a déjà pymothoa qui vise à faire ça.

Deux arguments pour la génération de C++:

1. Cela simplifie grandement la génération de code, le debug etc. D'après les test faits jusqu'à présent, c'est pas dégueux niveaui perf non plus :-)

2. pythran vise à être compatible OpenMP (à faire à faire, ça devrait être prêt pour les PyconFR). Et là encore c'est plus facile à faire au niveau source qu'au niveau bytecode

Sinon lire l'excellente thèse de Serge Guelton sur les atouts de la compilation source-à-source ;-)

D'après la doc pypy tu as raison.

Tu ne peux vraiment pas présager la durée de vie de tes variables, ni comment elles vont être utilisées. Tu peux juste faire des suppositions en l'air…

Curieux, j'aurais dit tout le contraire. Prenons un exemple

def higher_frequency(l,n):
  """Assumes l contains n kind of values."""
  histo= [0]*n
  for v in l:
    histo[v]+=1
  return max(histo)

Le compilateur a toutes les informations pour décider que histo est un tableau avec une durée de vie faible, qu'il n'est jamais aliasé et que sa taille ne change pas après sa définition. Au lieu d'utiliser une classe tableau générique (implémentant un compteur de référence etc) on peut basculer sur un tableau natif.

Pythran ne le fait pas …

Oui. Contrairement à ce que le nom laisse penser d'ailleurs :-(. Mais le source est sans appel.

Je ne pense pas :-)
C'est juste que ce benchmark mettait en avant le mauvais comportement de pythran en cas de création de nombreux tableaux.

mouarf l'aut'

Bah non j'ai sorti l'huile de coude et j'ai optimisé le générateur de code, avec optim' mises dans le journal :-)

Merci!
Je viens de tester la version dans debian sid pour les deux exemples précédents et c'est pas GG

quicksort: 8.64s
matmul:2.06s

Et en regardant le code généré, c'est assez proche d'un cython sans annotations de types…

il n'y a pas de repas gratuits !

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.