Reprise du message précédent :
Loana
http://reho.st/http://img.voici.fr [...] -loana.jpg

 
Moi, c'est le fou sorti de l'asile au centre qui me fait peur.  

Dite les experts j'ai une question qui demande une bonne dose d'expertise.
 
Si je veux coder naïvement une solution de calculs distribués entre plusieurs processeurs, comment je pourrais architecturer ça? Genre j'ai plein de traitements indépendants à faire et je veux les dispatcher vers les unités de calcul.
Déja je sais pas comment représenter logiciellement un calcul à faire autrement que par un pointeur de fonction, mais je sais pas si c'est adapté. Ensuite je me dis que pour des calculs simples je vais passer plus de temps dans mon programme à l'encapsuler et le router que à le faire, et du coup il me faut une manière de quantifier la complexité du calcul au runtime.
 
Je sais même pas les mots clés à chercher dans google autour de ça, toute aide est bienveue.

Tu veux pas faire du multithread ?  
Distribué sur plusieurs processeurs de la même machine ?

L'architecture est complètement dépendante du calcul lui-même et de la façon dont il peut être découpé en unités indépendantes et du flux de données circulant entre ces unités. Est-ce qu'il est facilement séparable en une chaîne de traitements distincts, comme du traitement audio ? Est-ce qu'il peut être découpé spatialement ?
Il faut chercher à découper les tâches de façon à minimiser les contentions et les échanges de données entre unités de traitement afin de réduire l'overhead.
Et comme dit BenO, une fois ce découpage effectué, le MT est l'implémentation la plus simple et la plus souple sur une seule machine.

 
C'est pour quel type de matériel ? Un cluster ? Un super computer avec "one system image" ?
 
Si c'est un cluster, il te faut utiliser des librairies spéciales genre libmpi par exemple. Mais ca dépend du type de cluster et de ce qui est installé dessus (exemple : solution PBS).

OpenMP plutôt.
 
Le MT, c'est simple si tu as le bon framework autour. Genre, en première approximation et en restant idiomatique, ce qui va traîner autour de Queue en python, TPL en c#, ou std::future en C++.

du multithread en python, bof quoi

C'était sensé être user friendly ?

Comme dit précédemment, ça dépend de plein de trucs :
- l'algorithme à appliquer dépend des données et traitements (déjà si c'est seulement "possible" c'est un bon début ),
- l'implémentation dépendra du langage et de l'infrastructure matérielle : même machine, machines distinctes en LAN, architecture scalaire type superordinateur...
- Ainsi que des protocoles de communication entre les machines, le cas échéant.
- Et donc enfin des possibilités du langage, Lam's a cité des exemples.
Donc il nous manque à peu près tout pour te répondre .

Java8?? Streams / parallel?

https://www.youtube.com/watch?v=gHMdppJTWYI

Et une bonne chose à faire est d'abord d'optimiser pour une seule machine, avant de s'attaquer à un réseau.

 
Ben ca dépend encore une fois de ce dont on parle. S'il s'agit de programmer pour un cluster, il faut utiliser des librairies spéciales prévues pour cela.

Comme on ne sait pas ce qu'il veut faire... mais avec un cluster, l'overhead peut être tel qu'une seule machine peut faire mieux. Et c'est plus facile de tester et optimiser sur une seule que sur plusieurs. Une fois que t'as fait ce boulot, tu as déjà une meilleure idée de ce qui se passe et de ce qui vaut le coup de "clusteriser".
Par contre, en effet il faut garder la possibilité d'exporter certains calculs.

 
on dawate ?

 
Pas forcément, mais possiblement. (je précise en bas du post)
 

 
Oui, ce sont des calculs indépendants les uns des autres, et le MT va seulement me permettre de partager entre plusieurs cores d'un processeur (ou processeurs) similaires.
 

 
Ce n'est pas fixé, ma réflexion est plus abstraite, je ne veux pas me lier fortement au matériel.  (je précise en bas du post)
 

 
Pour ta dernière phrase, je ne pense pas. J'essaie de faire du DDD et de coder des classes qui vont contenir des calculs indépendanst les uns des autres à faire, et autour des classes qui vont dispatcher ces traitements et réaggréger les résultats. En périphérie de cette appli on aura une couche qui va s'interfacer avec un processeur, une CG, une machine distante, un lave-linge... pour exécuter ces calculs.
Du coup je ne suis pas en train de me soucier pour l'instant du matériel qui va exécuter ces traitements, mais plutôt de comment les représenter et les manipuler.

Pour l'instant comme proof of concept j'utilise openCL pour calculer sur ma CG, et un thread simple pour le processeur.

 
Là en l'occurence un cluster par exemple peut changer complètement la manière de programmer. C'est pour cela d'ailleurs que des super computer dit "one system image" sont apparus, car programmer pour des clusters est souvent contraignant et force à changer l'architecture des programmes.
 
Je te recommande ce lien pour mieux savoir de quoi on parle : http://www.open-mpi.org/

/**
    /**
     * Renvoi une date formattée pour correspondre au format attendu par le xsd
     * @return date formatée
     * @throws FileNotFoundException si le fichier XSD n'est pas trouvé
     */
    private String getFormattedDate() throws FileNotFoundException{
 
        //Récupération du fichier XSD
        String xsdPath = PropertiesUtils.get("intercoV2.xsd.path" );
 
        final StringBuffer fichierXsd = new StringBuffer (xsdPath);
        if (!fichierXsd.toString().endsWith("/" ) && !fichierXsd.toString().endsWith("\\" )) {
            fichierXsd.append('/');
        }
        fichierXsd.append("GIPSE-EMSYS_ACK_Nominatif.xsd" );
 
        File xsdFile = new File(fichierXsd.toString());
 
        //Récupération du format de date souhaité (sous forme de pattern regex)
        String pattern = "";
        BufferedReader bReader = null;
 
        try{
 
            //Initialisation des buffer
            final InputStream ips = new FileInputStream(xsdFile);
            final InputStreamReader ipsr = new InputStreamReader(ips);
            bReader = new BufferedReader(ipsr);
 
            String ligne;
 
            //Extraction du pattern de date contenu dans le xsd
            while( (ligne = bReader.readLine()) != null ){
 
                if(ligne.contains("<xs:pattern" )){
 
                    pattern = ligne.substring( (ligne.indexOf("\"" ) + 1), ligne.lastIndexOf("\"" ));
                    break;
 
                }
 
            }
 
        } catch(IOException ioe){
            throw new FileNotFoundException(ioe.getMessage());
        } finally {
 
            try{
                if(bReader != null){
                    bReader.close();
                }
            } catch (IOException ioe){
                LOG.error("Erreur en fermeture du flux sur : " + bReader.toString());
            }
        }
 
        //Calcul de la date formatée à retourner
        DateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy HH:mm:ss" );
        String formattedDate = dateFormat.format(new Date());
 
        if(formattedDate.matches(pattern)){
            return formattedDate;
        } else {
            dateFormat = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss" );
            return dateFormat.format(new Date());
        }
 
    }

Ce truc.. Mais ce truc.;

http://www.itworld.com/article/289 [...] ality.html
je pense que c'est lié.

/**
    /**
     * Renvoi une date formattée pour correspondre au format attendu par le xsd
     * @return date formatée
     * @throws FileNotFoundException si le fichier XSD n'est pas trouvé
     */
    private String getFormattedDate() throws FileNotFoundException{
...
 
    }

 
Magnifique    

Il a pas un peu grossi Serge Lama ?

nraynaud > Tu bosses actuellement ?
Tu es mobile dans des zones sinistrées ?

  Vélizy ?

fait péter ton pitch (en MP?)

 
hey, ho, c'est pas sinistrté
 
bon, ok, il y avait pas de courant ce matin là bas, mai quadn même

//Récupération du fichier XSD
        String xsdPath = PropertiesUtils.get("intercoV2.xsd.path" );
 
        final StringBuffer fichierXsd = new StringBuffer (xsdPath);
        if (!fichierXsd.toString().endsWith("/" ) && !fichierXsd.toString().endsWith("\\" )) {
            fichierXsd.append('/');
        }
        fichierXsd.append("GIPSE-EMSYS_ACK_Nominatif.xsd" );
 
        File xsdFile = new File(fichierXsd.toString());

j'aime bien l'imbroglio de merde pour retrouver le fichier aussi

y'a un détail que j'ai toujours trouvé formidable en java, c'est l'exception dans le close(). Parce que si le close() échoue, t'es pas dans la merde, en théorie, le stream est encore ouvert (ce que j'ai beaucoup de mal à croire), et à part fermer un truc qui est dans un état douteux, je sais pas quoi faire d'autre.
J'ai la flemme de vérifier, mais je serai pas étonné que le close() d'une socket TCP qui se serait préalablement barrée en couille échoue, et à part jeter ses resources côté programme, je sais pas ce qu'on peut faire de mieux. Que tu reçoives le ack du close ou pas, ça change pas ta life quand t'essayais de la fermer. T'étais déjà sympa avec l'autre bout de le prévenir que tu veux arrêter.

Avec les autocloseable maintenant c'est caché sous le tapis ce problème, mais je plussoie sur le fond.

ou alors les sockets TCP c'est comme les nanas: on met un minimum de formes quand on les largue, parce qu'elle ont des copines bien gaulées et qu'elles pourraient ne plus prendre tes appels non plus ?

M'enfin, même si elle te fout une baffe dans la gueule quand tu la largues, je vois pas ce que tu peux faire d'autre que continuer à plus être avec.

C'est presque mignon tant d'innocence.

//Récupération du fichier XSD
        String xsdPath = PropertiesUtils.get("intercoV2.xsd.path" );
 
        final StringBuffer fichierXsd = new StringBuffer (xsdPath);
        if (!fichierXsd.toString().endsWith("/" ) && !fichierXsd.toString().endsWith("\\" )) {
            fichierXsd.append('/');
        }
        fichierXsd.append("GIPSE-EMSYS_ACK_Nominatif.xsd" );
 
        File xsdFile = new File(fichierXsd.toString());

Ça m'a l'air d'être du code pas complètement anormal pour du java pre 1.7 sans Filesystem. Fondamentalement c'est juste un truc genre

os.path.join(PropertiesUtils.get('intercoV2.xsd.path'), 'GIPSE-EMSYS_ACK_Nominatif.xsd')

sauf qu'il y a pas d'API pour, donc faut voir si le path de base a un terminateur (qui peut être \\ sous Windows) et faire le join à la main si non.

os.path.join(PropertiesUtils.get('intercoV2.xsd.path'), 'GIPSE-EMSYS_ACK_Nominatif.xsd')

 
Sauf que tu as File.separator pour eviter de manipuler les slashs, et instancier un StringBuffer pour faire deux concaténations c'est pire que laisser en string, vu que chaque appel à toString() recrée un string.

Dire que je trouve que je bosse sur un truc mal codé et lent, avec une architecture dégueulasse... Ben là d'un coup je me sens presque privilégié