/* Topic des codeurs [8] */

nathéo · Le 17/12/2012, à 01:18

Yep, d'ailleurs je m'y assure toujours d'y être (avec ls) avant de lancer le script.

ÉDIT : Bon ça fonctionne tout de même en utilisant la commande ruby, mais pour le coup, je me demande pourquoi avec l'autre je rencontre des soucis.

Dernière modification par nathéo (Le 17/12/2012, à 01:26)

Mindiell · Le 17/12/2012, à 07:46

nathéo a écrit :

et l'en tête #!/usr/bin/env ruby ?

T'as pas oublié un slash ?

nathéo · Le 17/12/2012, à 10:22

Non, c'est bien ça, et google ne me dit pas le contraire...

Dernière modification par nathéo (Le 20/12/2012, à 10:28)

Dr Le Rouge · Le 17/12/2012, à 10:50

Je relance d'un chmod +x.

Mindiell · Le 17/12/2012, à 16:41

Petit souci avec une librairie de programmation par contrainte. A priori, python-constraint est (re)connue, je penche donc pour un problème de mon côté.

J'ai essayé de résoudre le fameux problème SEND + MORE = MONEY, mais il me renvoie plein de réponses qui ne vont pas...
mon code source ne me parait pourtant pas poser de problème :

from constraint import *

def sendMoreMoney():
    problem = Problem()

    # Each variable can be from 0 to 9
    problem.addVariables(['s','e','n','d','m','o','r','y'], list(range(0,10)))

    # Each variable is different from others
    problem.addConstraint(AllDifferentConstraint())

    # Finally, send + more = money
    problem.addConstraint(lambda s,e,n,d,m,o,r,y: ((1000*s + 100*e + 10*n + d) + (1000*m + 100*o + 10*r + e)) == (10000*m + 1000*o + 100*n + 10*e + y))

    return(problem.getSolutions())


if __name__=="__main__":
    result = sendMoreMoney()
    print(len(result))
    print(result)

Les 3 premières des 25 ( ) réponses données :

{'e': 6, 'd': 8, 'm': 5, 'o': 1, 'n': 0, 's': 7, 'r': 3, 'y': 9},
=> 7608
  +5136
  =====
  51069

{'e': 6, 'd': 8, 'm': 5, 'o': 3, 'n': 0, 's': 7, 'r': 2, 'y': 1},
=> 7608
  +5326
  =====
  53061

{'e': 5, 'd': 8, 'm': 4, 'o': 9, 'n': 0, 's': 6, 'r': 3, 'y': 7},
=> 6508
  +4935
  =====
  49057

Vraie solution
=> 9567
  +1085
  =====
  10652

Dernière modification par Mindiell (Le 17/12/2012, à 16:50)

pierrecastor · Le 17/12/2012, à 18:03

Pitite question pour les codeur pro, à votre avis, un projet de ce type :

ACTION 1 LE MODULE A CREER EN RELATION AC LA PAGE HTML:
-Un champ prénom nom
-Un champ titre du Mail
-Un champ qui permet d'indiquer l'adresse mail de la personne qui est en train de créer la newsletter
-un champ qui permet d'indiquer les adresse mail des destinataires, 15 maximum
-Un champ pour indiquer le message format text personnalisé.
LE TEXTE A UNE TAILLE PERSONALISABLE (petit / moyen/grand par ex)
MAIS UNE SEULE POLICE CORRESPONDANT A CELLE UTILISEE POUR LA NEWSLETTER.
-Un bouton permettant de visualiser la newsletter
-Un bouton permettant de l'envoyer
ACTION 2 INTEGRATION DU PSD EN FORMAT HTML
(voir model ci oint pour évaluer charge de travail

Ca peut se vendre combien ? Avec une interface de ce type, mais en différent :

http://fntv.imagin-ecard.com/

Juste pour avoir une idée.

grim7reaper · Le 17/12/2012, à 19:00

J’en connais un qui va plus se sentir après avoir lu ça…

Pylades · Le 17/12/2012, à 19:15

Oo’, c’est toujours en développement…

En tout cas, ouais, il va être tout émoustillé.

Sinon, t’as mis Rosalind en pause ?

Dernière modification par Πυλάδης (Le 17/12/2012, à 19:16)

grim7reaper · Le 17/12/2012, à 19:19

Πυλάδης a écrit :

Oo’, c’est toujours en développement…

Bah quand tu vois que le Cobol et le Fortran ont encore de nouvelles versions, c’est pas si surprenant que ça.

Πυλάδης a écrit :

Sinon, t’as mis Rosalind en pause ?

Yep, malheureusement
J’espère pouvoir m’y remettre prochainement

J’ai un bout de code pour SUFF qui demande que 2-3 retouches (et il passera sûrement LING dans la volée), quelques pistes pour faire tomber REAR, et 2-3 autres trucs.
Il me manque juste du temps en fait

Dernière modification par grim7reaper (Le 17/12/2012, à 19:21)

Pylades · Le 17/12/2012, à 19:37

Faut pas rêver, LING tu bosses sur une chaîne de 100 kbp… J’ai une version simplifiée (donc qui bouffe moins de mémoire) du code pour SUFF qui résout LING jusqu’à 8 kbp, mais après, ma RAM ne suffit plus. Et je ne vois pas comment améliorer la chose.

Donc je ne sais pas ce que tu as comme algo, peut-être que tu passes large, mais c’est juste histoire de dire que les 100 kbp de LING, c’est violent.

grim7reaper · Le 17/12/2012, à 19:39

Πυλάδης a écrit :

Faut pas rêver, LING tu bosses sur une chaîne de 100 kbp… J’ai une version simplifiée (donc qui bouffe moins de mémoire) du code pour SUFF qui résout LING jusqu’à 8 kbp, mais après, ma RAM ne suffit plus. Et je ne vois pas comment améliorer la chose.
Donc je ne sais pas ce que tu as comme algo, peut-être que tu passes large, mais c’est juste histoire de dire que les 100 kbp de LING, c’est violent.

Bah après je peux être surpris, mais je pense que ça va bien se passer. On verra (bientôt j’espère !)
Je posterai la conso de RAM.

Pylades · Le 17/12/2012, à 19:41

(’fin, j’ai bien une idée… recoder en C. Peut-être que ça suffirait, mais j’y crois peu.)

grim7reaper · Le 17/12/2012, à 19:42

Non, clairement ça doit être faisable en Python.
Je pense que c’est ton approche qui doit pas être bonne

tshirtman · Le 17/12/2012, à 19:58

Je ne vois pas bien l'intérêt de décider avec quel processeur une tache doit être effectué… le programmeur a peu de chance de pouvoir décider ça mieux que l'os, non?

grim7reaper · Le 17/12/2012, à 20:00

Ça a peut-être son intérêt dans l’embarqué (le secteur cible d’Ada à la base), où il n’y a pas toujours d’OS ou d’ordonnanceur (bon, ça reste rare : tu as souvent un ordonnanceur basique, même sans OS complet autour).
Mais bon, ça pourrait être utile dans certains cas. Sur PC, ouais aucune chance que tu décide mieux que l’OS…

Rolinh · Le 18/12/2012, à 09:05

tshirtman a écrit :

Je ne vois pas bien l'intérêt de décider avec quel processeur une tache doit être effectué… le programmeur a peu de chance de pouvoir décider ça mieux que l'os, non?

Je pense que ça a son intérêt lors de calcul parallèle (genre sur supercalculateur) où la décomposition d'un problème en plusieurs sous-problèmes à faire calculer par plusieurs processeurs n'est pas quelque chose qui peut être gérée par un ordonnanceur classique. Dans le cas d'un ordinateur classique, je vois mal l'intérêt. M'enfin, Ada est censé être prévu pour ce genre de calcul?

grim7reaper · Le 18/12/2012, à 11:04

Rolinh a écrit :

tshirtman a écrit :
Je ne vois pas bien l'intérêt de décider avec quel processeur une tache doit être effectué… le programmeur a peu de chance de pouvoir décider ça mieux que l'os, non?
Je pense que ça a son intérêt lors de calcul parallèle (genre sur supercalculateur) où la décomposition d'un problème en plusieurs sous-problèmes à faire calculer par plusieurs processeurs n'est pas quelque chose qui peut être gérée par un ordonnanceur classique.

Bah justement, si.
Toi, en tant que programmeur tu t’arranges pour que ton programme soit découpé en sous-problème (tu t‘y prends comme tu veux, selon ta problématique).
Mais à l’exécution, c’est bien l‘ordonnanceur le mieux placé pour répartir les sous-problèmes sur les unités de calcul.
Choisir, à la compilation, d’envoyer ton code sur le CPU 10 ça peut-être très bon (si le CPU est libre) comme totalement moisi (si le CPU est déjà surchargé).
Non, vraiment ça c’est le boulot d’un ordonnanceur pas du programmeur.

Rolinh a écrit :

Dans le cas d'un ordinateur classique, je vois mal l'intérêt. M'enfin, Ada est censé être prévu pour ce genre de calcul?

Non, Ada c’est plus fait pour de l‘embarqué que pour du HPC.

tshirtman · Le 18/12/2012, à 11:22

Je pense que ça pourrait être *tentant* de se dire qu'on va dédier un coeur à une tache, pour qu'elle n'ai aucun risque d'être sous-priorétisée, mais je pense que c'est risqué, si on touche trop à ça, on peut tout à fait se retrouver à bloquer son programme tout seul, en empéchant justement la tache critique de tourner sur un coeur disponible…

Mais bon, oui, peut être dans l'embarqué, qui est un peu la cible d'ada…

edit: c'est peut être une volonté de rendre les calculs parallèles plus déterministes, mais ça me semble être un combat perdu d'avance…

Dernière modification par tshirtman (Le 18/12/2012, à 11:23)

Rolinh · Le 18/12/2012, à 11:39

@grim7reaper: Bah pas forcément. Je pense à MPI par exemple. Pour prendre un exemple (stupide et simple mais c'est pour illustrer): admettons que l'on veuille calculer la somme des éléments de chaque colonne d'une très grande matrice. En principe, avec MPI, c'est le programmeur qui décide de calculer la colonne i avec le processeur j ou les colonnes i et i+1 par le j, etc. et de rapatrier les résultats sur un processeur déterminé. Par ailleurs, cela se fait aussi manuellement lorsque l'on a des dépendances de calcul à satisfaire. Par exemple, le processeur j doit finir de calculer son sous-problème afin que le processeur k puisse calculer le sien. Le partitionnement et de l’ordonnancement des tâches est une partie essentielle du travail lorsque l'on cherche à faire calculer un algorithme parallèle sur un supercalculateur et c'est un travail effectué manuellement au préalable et qui tient compte de choses comme par exemple l'architecture du supercalculateur, la topologie et les propriétés du réseau d'interconnexions, du fait que l'on doive faire un rééquilibrage des charges statique ou dynamique, etc.
Il y a bien une façon de faire qui consiste à désigner un processeur comme étant le chef d'orchestre qui répartit les calculs mais dans la pratique il se retrouve souvent surchargé et l'on perd en efficacité.
Enfin bon, dans le cas d'un ordinateur classique, je ne dis pas, c'est bien l'ordonnanceur qui est le mieux placé mais ce n'est pas le cas pour le calcul hautement parallèle.

grim7reaper · Le 18/12/2012, à 11:50

Rolinh a écrit :

Le partitionnement et de l’ordonnancement des tâches est une partie essentielle du travail lorsque l'on cherche à faire calculer un algorithme parallèle sur un supercalculateur et c'est un travail effectué manuellement au préalable et qui tient compte de choses comme par exemple l'architecture du supercalculateur, la topologie et les propriétés du réseau d'interconnexions, du fait que l'on doive faire un rééquilibrage des charges statique ou dynamique, etc.

Pour le partionnement oui.
Pour l’ordonnancement, je suis pas d’accord.
De ce que je comprend de ton explication, dès que tu changes ton programmes de machine, faut réécrire tout le code de parallélisation (vu que tu dépends de toutes l‘architecture sous-jacente) !?
C’est de la merde en barre en fait, on se croirait de retour à l’époque de l’assembleur (un code source par famille de machine).
Donc soit ton explication est trop simpliste (ou j’ai mal compris) et en fait il y a un niveau d’abstraction meilleur que « la ligne i sur le processeur k et pas un autre », soit c’est pas un progrès MPI (ce dont je doute quand même).
Qu’il faille tenir compte de l’archi du supercalculateur, c’est une évidence.
Qu’il faille le mettre en dur dans le code source, ça me choque déjà beaucoup plus…
Ha et sinon, on n‘est pas obligé de mettre un seul processeur en chef d’orchestre, sinon il va forcément être débordé oui.

Dernière modification par grim7reaper (Le 18/12/2012, à 11:51)

The Uploader · Le 18/12/2012, à 11:57

(apprends en silence )

Rolinh · Le 18/12/2012, à 12:25

grim7reaper a écrit :

dès que tu changes ton programmes de machine, faut réécrire tout le code de parallélisation (vu que tu dépends de toutes l‘architecture sous-jacente)

Oui, si tu cherches l'optimisation (et c'est généralement le cas si tu fais du calcul de ce genre), il te faut adapter la partie parallélisable de ton code (ce n'est évidemment pas requis pour la partie non parallélisable).

grim7reaper a écrit :

C’est de la merde en barre en fait, on se croirait de retour à l’époque de l’assembleur (un code source par famille de machine).

Bah en même temps, tu ne changes pas de supercalculateur tous les jours hein. ^^
Mais il y a effectivement un travail d'adaptation du code lorsque tu changes de machine. D'ailleurs, cela semble évident lorsque tu considères qu'un code parallélisé n'est pas forcément plus performant si tu utilises deux fois plus de processeurs (en fait, pour déterminer le nombre de processeurs à utiliser, on calcule le speedup et on détermine sa courbe).

Ceci dit, mon explication était trop simpliste trop simpliste et dans les cas simples, il y a peu (ou pas) de modifications à effectuer dans le code. Avec MPI, en fait, il y a plusieurs façons de faire. Tu peux effectivement donner telle tâche à tel processeur en le nommant explicitement (en faisant de la communication point à point typiquement) ou alors tu peux envoyer tes sous problèmes en faisant une "sorte de broadcast" (je simplifie, MPI possède plusieurs fonctions pour faire cela) et dans ce cas, tu ne spécifies pas explicitement à quel processeur tu envoies quoi (dans le cadre de communication collective) . D'ailleurs, je ne pense pas que cela se fait souvent de désigner explicitement que c'est ce processeur là qui calcule telle partie du problème, après, je ne suis pas spécialiste hein j'ai juste un peu joué avec (implémentation de l'équation de la chaleur de Laplace, calcul de Mandelbrot). ^^

Dernière modification par Rolinh (Le 18/12/2012, à 12:29)

grim7reaper · Le 18/12/2012, à 12:39

Rolinh a écrit :

D'ailleurs, cela semble évident lorsque tu considères qu'un code parallélisé n'est pas forcément plus performant si tu utilises deux fois plus de processeurs (en fait, pour déterminer le nombre de processeurs à utiliser, on calcule le speedup et on détermine sa courbe).

Oui, ça je sais .
D’ailleurs, c’est plutôt la loi d'Amdahl qu’on utilise pour décider ça (encore que…, ça reste un gain théorique).

Rolinh a écrit :

Ceci dit, mon explication était trop simpliste trop simpliste et dans les cas simples, il y a peu (ou pas) de modifications à effectuer dans le code. Avec MPI, en fait, il y a plusieurs façons de faire. Tu peux effectivement donner telle tâche à tel processeur en le nommant explicitement (en faisant de la communication point à point typiquement) ou alors tu peux envoyer tes sous problèmes en faisant une "sorte de broadcast" (je simplifie, MPI possède plusieurs fonctions pour faire cela) et dans ce cas, tu ne spécifies pas explicitement à quel processeur tu envoies quoi (dans le cadre de communication collective) . D'ailleurs, je ne pense pas que cela se fait souvent de désigner explicitement que c'est ce processeur là qui calcule telle partie du problème, après, je ne suis pas spécialiste hein j'ai juste un peu joué avec (implémentation de l'équation de la chaleur de Laplace, calcul de Mandelbrot). ^^

Ouais, c’est déjà mieux
C’est surtout la désignation explicite qui me choquait. Je me doutais bien que MPI proposait mieux.

Rolinh · Le 18/12/2012, à 12:50

grim7reaper a écrit :

D’ailleurs, c’est plutôt la loi d'Amdahl qu’on utilise pour décider ça

Oui. Enfin, la loi d'Amdahl sert à déterminer le speedup maximal en utilisant N processeurs. C'est lié quoi.

grim7reaper a écrit :

C’est surtout la désignation explicite qui me choquait. Je me doutais bien que MPI proposait mieux.

Oui effectivement, mon explication était trop simpliste de prime abord.
Ceci dit, il y a certainement des cas où il peut être intéressant de désigner explicitement tel tâche à tel processeur mais on peut très bien s'en passer.

grim7reaper · Le 18/12/2012, à 21:37

Aujourd’hui j’ai enfin pu caler du Python 3 dans mon boulot \o/ ^^

En gros j’ai lancé un modèle pour faire une simulation à l’échelle européenne (c’est dans le cadre d’un projet de recherche Européen, ceci expliquant l’échelle) en passant sur un cluster bien sûr.
Le modèle m’a généré un fichier de sortie par « pixel », soit pas loin de 8000 fichiers ASCII (à ~36 Mo le fichier :]).
Maintenant, pour ce projet les résultats doivent être fournis en NetCDF (un petit format sympatoche).

De là j’avais plusieurs choix (car l’API est dispo en plusieurs langages) :
- Fortran : heu, comment dire… C’était le choix du gus d’avant et j’en paye encore le prix donc on va éviter hein ^^'
- C : Bof, le format des fichiers ASCII est pas bien sorcier, mais si je pouvais éviter de me palucher un parsing à la main j’apprécierais (et puis il va y avoir un peu de manipulation de vecteur, ça serait bien de passer par un langage qui offre un peu de sucre à ce niveau-là).
- C++ : un peu comme le C (si ce n’est que c’est un peu moins chiant mais toujours pas la panacée).
- Java : mouais, encore du parsing à la mano, rien de bandant pour la manip de vecteur et puis j’en ai un peu ma dose du Java là (quitte à mettre les main dedans, je pars sur du C++).

Voilà pour les bindings officiels, après on trouve aussi un (enfin plusieurs en fait) bindings pour R et Python :
- Python : binding sympa, et puis merde ça me démande de refaire du Python là ^^
- R : langage sympatoche, binding pas mauvais, parsing du fichier en une ligne, beaucoup de sucre au niveau vecteurs. Nouveau langage pour moi (j’ai fait 1-2 petits scripts depuis quelques semaines, mais c’est tout), c’est l’occasion d’approfondir.
Bon, j’arrive pas trop à me décider (Python m’appelle mais j’ai un peu peur niveau parsing (bien que ça soit peanuts à côté de C, C++ et Java, ça semble moins évident que R).

Qu’a cela ne tienne, je fais un petit PoC dans en R et Python, puis un bench tout con : lecture de 5 fichiers.
Bon, là le verdict est sans appel : R met 87s à lire 5 fichiers, Python 3 seulement 12s.
Sachant que j’en ai presque 8000 à taper, le gain est pas négligeable au final.
Donc je suis parti sur Python + netcdf4-python (doc un peu concise mais c’est pas la dèche non plus, et c’est basé sur numpy donc niveau perf’ c’est bon ).
Et magie de numpy + un peu de réflexion, je fais le parsing en une ligne aussi.

Dernière modification par grim7reaper (Le 18/12/2012, à 21:38)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#326 Le 17/12/2012, à 01:18

Re : /* Topic des codeurs [8] */

#327 Le 17/12/2012, à 07:46

Re : /* Topic des codeurs [8] */

#328 Le 17/12/2012, à 10:22

Re : /* Topic des codeurs [8] */

#329 Le 17/12/2012, à 10:50

Re : /* Topic des codeurs [8] */

#330 Le 17/12/2012, à 16:41

Re : /* Topic des codeurs [8] */

#331 Le 17/12/2012, à 18:03

Re : /* Topic des codeurs [8] */

#332 Le 17/12/2012, à 19:00

Re : /* Topic des codeurs [8] */

#333 Le 17/12/2012, à 19:15

Re : /* Topic des codeurs [8] */

#334 Le 17/12/2012, à 19:19

Re : /* Topic des codeurs [8] */

#335 Le 17/12/2012, à 19:37

Re : /* Topic des codeurs [8] */

#336 Le 17/12/2012, à 19:39

Re : /* Topic des codeurs [8] */

#337 Le 17/12/2012, à 19:41

Re : /* Topic des codeurs [8] */

#338 Le 17/12/2012, à 19:42

Re : /* Topic des codeurs [8] */

#339 Le 17/12/2012, à 19:58

Re : /* Topic des codeurs [8] */

#340 Le 17/12/2012, à 20:00

Re : /* Topic des codeurs [8] */

#341 Le 18/12/2012, à 09:05

Re : /* Topic des codeurs [8] */

#342 Le 18/12/2012, à 11:04

Re : /* Topic des codeurs [8] */

#343 Le 18/12/2012, à 11:22

Re : /* Topic des codeurs [8] */

#344 Le 18/12/2012, à 11:39

Re : /* Topic des codeurs [8] */

#345 Le 18/12/2012, à 11:50

Re : /* Topic des codeurs [8] */

#346 Le 18/12/2012, à 11:57

Re : /* Topic des codeurs [8] */

#347 Le 18/12/2012, à 12:25

Re : /* Topic des codeurs [8] */

#348 Le 18/12/2012, à 12:39

Re : /* Topic des codeurs [8] */

#349 Le 18/12/2012, à 12:50

Re : /* Topic des codeurs [8] */

#350 Le 18/12/2012, à 21:37

Re : /* Topic des codeurs [8] */

Pied de page des forums