Discussion :

[kurul1]

Bonjour � tous

Je viens de lire le tutorial sur les thread dans Borland C++ et cela m'a pas mal �clair�.

N'ayant jamais utilis� de thred, je ne sais pas comment faire pour mon application.

Je travaille avec des fichiers excel, j'extrait tout d'abord les donn�es de ce fichier. Il contient plusieurs feuilles et dans chaques feuilles il y a plusieurs s�ries de donn�es. Je stocke chaque s�rie de donn�es dans un objet (TCalculs qui est une classe de ma cr�ation), que j'ajoute dans une TList pour avoir acc�s � chaque s�rie.

Ensuite pour chaque s�rie, j'effectue des calculs et j'exporte les r�sultats dans un fichier Excel (Un fichier par s�rie).

Mon probl�me est que les s�ries sont �normes et donc le traitement est super long.

Ce que j'aimarais faire, c'est utiliser des thread pour faire des calculs en parall�le sur plusieurs s�ries en m�me temps.

Ma question est, jusqu'� combien de thread peut-on cr�er simultan�ment. Je me doute que je ne vais pas en cr�er trop non plus d'un coup mais pour avoir un ordre d'id�e.

Et deuxi�me question, Etant donn�e que j'ouvre une instance d'excel pour l'�criture, est-ce que cela ne pause pas de probl�me d'en ouvrir plusieurs en m�me temps.

Merci d'avance pour votre aide.

[Altau]

Sans entrer dans les d�tails, je ne crois pas que ton projet de faire tourner en parall�le plusieurs threads gourmands apporte quelque chose, � moins de disposer d'un processeur multi-coeur ou de plusieurs processeurs. Le temps de traitement global sera le m�me, peut �tre m�me sup�rieur. L'int�r�t d'utiliser des threads, � mon avis, est de garder la main pendant un traitement d'une certaine dur�e, surtout si cette dur�e n'est pas due essentiellement � une charge processeur.

[kurul1]

C'est ce que je pensais mais �tant donn� que mon traitement est super long m�me avec un double coeur puisque le PC sur lequel je d�veloppe en est un, je pensais pouvoir gagner du temps

Je vais quand m�me essayer juste pour voir.

Merci pour ta r�ponse.

[yarp]

Il n'y a pas de limite au nombre de thread que tu peux utiliser, un thread est un process donc la limite est combien de process gourmands ta machine peux supporter et aussi bien sur le gestionnaire de threads que tu doit �crire pour manager tout �a.

En ce qui concerne Excel je ne connais pas mais je sais que le mod�le COM (rien � voir avec Excel � priori mais les 2 sont cousins, au moins en terme de lourdeur � besoin de messages pour certaines interfaces et �tant donn� que les threads de la VCL n'ont pas de boucle de message cela pose probl�me pour ces interfaces.
Peut-�tre en est-il de m�me avec Excel, peut-�tre pas, je te signale un pb potentiel.

J'ai aussi ce lien avec des classes de Thread tr�s int�ressantes pour Delphi/CBuilder:
http://www.midnightbeach.com/jon/pub.../MsgWaits.html
Plus �volu�s que le basic TThread, car justement avec message loop et aussi arr�t propre. Si tu commence avec TThread c'est mieux de partir de �a.

yarp
www.senosoft.com

[blondelle]

Salut kurul1:
yarp a raison quand il dit que Ole a une gestion lourde mais aussi lente, et il faut faire attention a l'optimisation du code, surtout dans les boucles comme par exemple dans le code qui suit, pour gagner du temps, on code qu'une fois la variable "vTable" le gain de temps est reellement important

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
 
    vTable = vMSword.OlePropertyGet("ActiveDocument").
    OleFunction("Range").OlePropertyGet("Tables").OleFunction("Item", 1);
    // 
    for(int i=0; i<nColCount; i++)
    {
    int nColWidth = GridCustomers->Columns->Items[i]->Width;
    vTable.OlePropertyGet("Columns").OleFunction("Item", i + 1)
    .OlePropertySet("PreferredWidthType", 3); // wdPreferredWidthPoints
    vTable.OlePropertyGet("Columns").OleFunction("Item", i + 1)
    .OlePropertySet("PreferredWidth", nColWidth);
    }

[kurul1]

Merci � vous pour toutes ces informations

[Neilos]

Il n'y a pas de limite au nombre de thread que tu peux utiliser, un thread est un process donc la limite est combien de process gourmands ta machine peux supporter et aussi bien sur le gestionnaire de threads que tu doit �crire pour manager tout �a.

Mouais il faut garder en t�te qu'un thread consomme tout des m�mes des ressources. Et qui si tu en as trop tu perdras du temps � switcher entre tous les thread.

J'avais d�velopp� un petit moteur de lanc� de rayon multi-thread. J'ai fait au plus simple :

1. d�tecter le nombre de CPU
2. cr�er un thread par CPU
3. forcer chaque thread � tourner sur un autre CPU

C'est � mon avis le seul moyen de bien exploiter les threads et �a marchais tr�s bien !
Attention cependant � l'�criture dans les variables que les threads utilisent...elles sont � limiter au maximum car tu as besoin d'une semaphore dessus, ce qui peux bloquer un peu les threads...

[kurul1]

Je crois que je vais laisser tomber car vue toutes les contraintes que cela engendre, cela risque de ne pas �tre r�alisable vue la configuration du mon exportation, et en plus, compliquer � mettre en oeuvre.

De plus les personnes qui vont utiliser le logiciel n'ont pas de Dual Core donc ca va pas servir a grand chose. Tant pis, ils patianteront.

Merci � tous pour votre aide.