Discussion :

[jambonstar]

Salut à tout le monde,

Je réalise actuellement une appli de traitement assez lourde. Pour vous donner une idée, je traite quelques milliers d'images de 1024*1024.
Ces traitements prennent 10 minutes. Or se temps ne plait pas du tout au Big Boss .
J'ai beau lui expliquer et lui démontrer qu'aucune ligne n'est superflue dans mon programme, monsieur n'en démord pas.


Voilà pour les faits, ma question : Est-ce qu'un bi processeurs va acceler ce traitement sur un unique 'exe'. Si non, a comment puis-je en tirer avantage :

Merci d'avance.

[portu]

Ce n'est pas Windows qui gère cela quand il y a plusieurs threads ?

Et au niveau du code de traitement, tu es sûr qu'il n'y a pas mieux à faire (Quelques milliers / 600 sec = cela fait déja quelques image à la seconde, c'est déja pas mal vu leur taille mais bon , faut voir quel est le traitement) ?

[jambonstar]

Tu veux connaitre le traitement ?

Alors tu vas sanns doute rire. C'est un programme de scan microscopique.

Un activeX m'envoie par évenements des images de 1388*1036.

Je m'occupe de les réaménagers en images de 1024*1024, sans perdre une miette de tout ces pixels. (soit jusqu'à 3 * 1024 pour rentrer une seule 1388)

Ensuite cette image est découpé en 4 512*512. Et ensuite ramené elle meme à 512.

Et ces 5 images sont envoyés sur un serveur distant (HDD 1000Go / Ethernet 100M)

Ce qui fait enormement de traffic.

D'ailleurs c'est ce traffic qui ralenti tout le reste. Et les écritures sur disque.

Tout le reste se fait à la volée en RAM.

Je repose donc ma question, est ce que ca va me servir un multi processeur ?

[portu]

Donc comme tu l'as dit, le problème vient peut être de la bande passante !
Teste la avant de prendre une décision. Et si vraiment la bande passante est saturée, il faudra se tourner sur du Gigabit ou Du comprassage (Je suppose qu'elle sont déja compressées...).

Et si tu fais le traitement en local (enregistrement local), ca va vraiment plus vite ?

[yarocco]

Si c'est vraiment la bande passante, tu peux faire une appli multi-thread avec l'idee sugeree plus haut : sauvegarde en local.

Donc en reprennant :
-Un thread principal qui recoit les images et les traite.
-Un autre thread qui s'occupe de sauver les images et de les envoyer sur le reseau .

Voila, a partir de la, je pense qu'en multi-proc tu sentira la difference car la charge reseau doit etre assez importante pour le proc et ca doit ralentir les calculs en consequence.
Si tu fais : un thread (1 proc) pour le traitement et un thread (1 proc) pour la sauvegarde et l'envoi je pense que ca ira plus vite.

Ensuite, il faut voir combien de temps prend l'envoi d'une image, le calcul d'une image.
Car si l'envoi d'une image est plus rapide que son traitement, tu n'aura normalement pas besoin de la sauver en local car le thread qui envoi sera en attente de données.

[rvzip64]

Si tu veux tiré partie de processeur bi-core ou multi thread, il faut que ton application soit multi thread , autrement le simple fait de passer sur un autre type de hardware ne changera absolument rien a ton application.

A par bien évidemment si d'autre logiciels tournent en meme temps que le tiens. La, tu auras un gain de temps vu que le thread de ton application et les thread des autres applications seront réparti sur les 2 cores.

Par ma petite expérience et vu la direction qu'est entrain de prendre le monde informatique, je te conseille fortement de penser au maximum tes applications en multithread. Certe tu perds du temps en développement, mais tu en gagne énormement par la suite. Toute mes applications sont pensé de la sorte, aprés c'est moi qui décide ou non d'activer plusieur thread.

Fait quand meme une analyse plus approfondi de ton problème. Pas la peine de partir bille en tete dans du multi thread si tu es limité par le réseaux bien évidemment.


Si tu as besoin d aide n 'hésite pas.

Cordialment

[yarocco]

Toute mes applications sont pensé de la sorte, aprés c'est moi qui décide ou non d'activer plusieur thread.

Si tu developpe multi-thread et que tu n'en active que certains, il risque d'y avoir quelques fonctionnalites en mois non ? (ou bugs en plus)

[rvzip64]

Non pas du tout. En fait quand je fais un thread , il est pensé pour etre autonome. c'est une nouvelle class (je suis pas sur que le terme que j enploi sous juste). Donc aprés il suffti de dire au programme principal combien j'en lance.

Mais c est peut etre pas obligé de faire si compliqué au depart pour toi.

Regarde dans ton code si il y a des parties que tu repetes plusieur fois ,qui sont donc identique et que tu pourrais exécuter en parallèle.

A l aide d 'un petit organigramme on peu trés vite voir si le multi-thread va optimiser ton programme.

[yarocco]

Je ne suis pas l'auteur du thread

Je pense comprendre comment marche ton architecture (multiplie les traitements paralleles et non separer les taches).
Je n'ai pas de de proc multi-coeur (ou multi-proc) donc je n'ai jamais fais de test et ne peux donc pas dire quel est le meilleur algo (parallelisation ou division de l'algo) mais il ne faut pas trop paralleliser (surtout dans le cas d'un mono proc) car le temps de changement de process est assez long et si tu multiplie ces changements, ca va finir pas ralentir ton systeme.

[rvzip64]

mille excuse j ai pas fait gaffe a qui été l auteur.
Oui tu as tout compris, je parallélise les calculs qui sont long plutot que de parallélise des bouts de codes.

J ai fait ce choix car uen fois que le thread est fait il est plus a faire vu que le code est identique et puis faut dire que mes temps de calcul ne sont pas immence alors j ai pas besoin de plus de contrainte.

Aprés tu a aussi entièrement raison sur le fait de ne pas lancé trop de thread car au bout d'un moment ça pénalise énormement.