Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
Test de l'ISO d'Ubuntu francophone : nous avons besoin de testeurs pour la version francophone d'Ubuntu 14.04. Liens et informations ici.

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

nathéo

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

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)


C'est rarement par le sarcasme qu'on élève son âme.
Le jus de la vigne clarifie l'esprit et l'entendement.
De quoi souffres-tu ? De l'irréel intact dans le réel dévasté ?
N'oubliez pas d'ajouter un [RESOLU] si votre problème est réglé.ᥟathé൭о

Hors ligne

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

Mindiell

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

nathéo a écrit :

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

T'as pas oublié un slash ?

Hors ligne

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

nathéo

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

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)


C'est rarement par le sarcasme qu'on élève son âme.
Le jus de la vigne clarifie l'esprit et l'entendement.
De quoi souffres-tu ? De l'irréel intact dans le réel dévasté ?
N'oubliez pas d'ajouter un [RESOLU] si votre problème est réglé.ᥟathé൭о

Hors ligne

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

Le Rouge

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

Je relance d'un chmod +x.


C'est deux suites de Cauchy qui veulent aller à la soirée 'no limit'. Hélas, à l'entrée le videur leur dit : "désolé, c'est complet !".
mon site perso (π²/6.fr) et mon blog

Hors ligne

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

Mindiell

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

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 hmm :

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 ( yikes ) 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)

Hors ligne

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

pierrecastor

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

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.


C'est cool, les quotes dans la signature, j'en une super, n'est-ce pas ? :lol:

S.O.D.

En ligne

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

grim7reaper

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

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

Hors ligne

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

Pylades

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

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

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


Sinon, t’as mis Rosalind en pause ?

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


“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Hors ligne

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

grim7reaper

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

Πυλάδης 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 hmm
J’espère pouvoir m’y remettre prochainement smile

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 sad

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

Hors ligne

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

Pylades

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

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.


“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Hors ligne

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

grim7reaper

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

Πυλάδης 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.

Hors ligne

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

Pylades

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

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


“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Hors ligne

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

grim7reaper

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

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

Hors ligne

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

tshirtman

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

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?

Hors ligne

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

grim7reaper

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

Ç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…

Hors ligne

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

Rolinh

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

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?


Blog
"If you put a Unix shell to your ear, do you hear the C ?"

Hors ligne

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

grim7reaper

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

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.

Hors ligne

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

tshirtman

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

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)

Hors ligne

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

Rolinh

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

@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.


Blog
"If you put a Unix shell to your ear, do you hear the C ?"

Hors ligne

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

grim7reaper

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

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)

Hors ligne

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

The Uploader

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

(apprends en silence smile )


Passer de Ubuntu 10.04 à Xubuntu 12.04 LTS
Archlinux + KDE sur ASUS N56VV.
ALSA, SysV,  DBus, Xorg = Windows 98 !
systemd, kdbus, ALSA + PulseAudio, Wayland = modern OS (10 years after Windows, but still...) !  Deal with it !

Hors ligne

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

Rolinh

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

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)


Blog
"If you put a Unix shell to your ear, do you hear the C ?"

Hors ligne

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

grim7reaper

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

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 wink.
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 smile
C’est surtout la désignation explicite qui me choquait. Je me doutais bien que MPI proposait mieux.

Hors ligne

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

Rolinh

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

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. wink

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. wink
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.


Blog
"If you put a Unix shell to your ear, do you hear the C ?"

Hors ligne

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

grim7reaper

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

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 smile).
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)

Hors ligne

Haut de page ↑