Discussion :

[FullSpeed]

Bonjour


On met tout de suite les choses au clair je suis competence 0 concernant les tread. En ayant a priori besoin je vais m'y mettre mais avant de me lancer je voudrais savoir si elles me donneront bien le resultat desité

Pb;
J'ai un calcul qui est repete 1000 fois à la seconde. Je voudrai augmenter ce nombre.Il est assez aisé de distribuer mon calcul
Maa question est la suivante
J'ai cru comprendre que la thread s"executait lrs du create
Combien de temps lui faut-il pour se lancer?
Est qu'en lancant donc le ttread 1000 dois part seconde je ne vais pas surcharger le pros

Dit autrement: A partir de quel volume de traitement une tread devient opportune?


Merci de vos réponses
Boris

[nouknouk]

Quelques principes qui s'appliquent d'une façon générale:

- lorsqu'on a besoin fréquemment de threads, on ne les recréé pas à chaque fois, mais on instancie un 'pool' de thread une fois pour toute et ces derniers travaillent tant qu'ils ont matière à traiter ; s'endorment en cas de 'famine' et se réveillent dès qu'on leur redonne 'à manger'.

- avoir plus de thread que de coeurs sur le processeur qui exécute le code ne sert à rien d'autre que faire baisser les performances.

- 1ms est une durée bien trop courte en comparaison du temps de switch entre deux threads pour un ordonnanceur de ton OS 'classique' (typiquement de l'ordre de 10 à 20ms), ou même comparée au coût d'acquisition d'un lock. Donc il ne faudra pas envoyer 1000 ordres - un par milliseconde - mais plutôt x ordres contenant chacun 1000/x ordres dispatchés aux x threads.

- si tu as réellement besoin d'une précision de l'ordre de la milliseconde, voire en dessous (typiquement pour de l'acquisition), il vaut mieux soit se tourner vers un OS temps réel, soit vers une carte hardware spécialisée.

[FullSpeed]

- avoir plus de thread que de coeurs sur le processeur qui exécute le code ne sert à rien d'autre que faire baisser les performances.

J'avais fais la même analyse que toi sur les temps d'appel par onntre je ne suis pas tout a fait d'accord sur l'utilirté

ton analyse considere que quand la tread s'execute le traitement principale luiio s'arrete et que finalemenrt il nouis faudra temps tread+temps appli.
Cela me semble faux car le multiteading n'est pas un multitache
La tread n'arret pas le prog mais essaye d'utiliser des ressources du processeur disponibles:

Exemple grossier
dans ton calcul tu a un calcul en enties et un en reels. Tu peux faire dans ton UAL le calcul entiers et prendant ce temps la laisser une tr'ead avec le FPU!
C'est du moins se que j'ai compris du multi*treading.Peut être lme trompes-je?

Merci de ta réponse
(je vais faire autrement mais comme c'est pour un défit je ne dis pâs comment:!)
Boris

[Mac LAK]

- avoir plus de thread que de coeurs sur le processeur qui exécute le code ne sert à rien d'autre que faire baisser les performances.

Faux et archi faux... Cela dépend des temps passé en I/O pour chaque thread, y compris et surtout les locks masqués dûs au bus mémoire unique sur un CPU multicoeurs.
Ta phrase n'est vraie que pour les threads de calcul pur (sans I/O) ET qui ont toutes leurs données dans le cache... Cas relativement rare, quand même.

Je t'encourage à aller voir cette discussion, par exemple, pour en avoir la preuve.

[FullSpeed]

Neuf-Neuf
Je suis alle trop vite a lire ta reponse
Ma solution semble etre le pool
Je ppeux avoir des precision,s:
Si mon code attends juste d'etre activé dans un autre coeur le mécanisme d'activation est peut etre rapise?
Ca me plait bien:

Boris

[Mac LAK]

J'ai cru comprendre que la thread s"executait lrs du create

Pas forcément, on peut aussi le lancer suspendu.

Combien de temps lui faut-il pour se lancer?

Totalement dépendant de l'OS. Heureusement pour toi, Windows est extrêmement doué avec les threads, c'est avec les processus qu'il patine un peu (et le contraire avec Linux). Je ne dirais pas que c'est négligeable, mais pas loin... Toutefois, il ne faut quand même pas lancer un thread pour aller mettre un entier à jour !

Est qu'en lancant donc le ttread 1000 dois part seconde je ne vais pas surcharger le pros

Il faut en fait avoir un thread "prêt" et suspendu (ou en attente sur un mutex), lui filer ses données, et le libérer. Il se remet en "veille" quand il a terminé.

Dit autrement: A partir de quel volume de traitement une tread devient opportune?

Un thread est utile (voire nécessaire...) dès que :

• Le traitement bloque l'application, notamment la boucle de messages Windows.
• La charge CPU induite par le traitement est élevée (souvent 100%).
• On passe plus de temps à attendre qu'à bosser, mais quand c'est "prêt", il faut agir le plus vite possible.
• Il est nécessaire de paralléliser le traitement.

Dans ton cas, tu mets quelques threads en attente sur une FIFO protégée, et ton application principale "remplit" cette FIFO. Chaque thread tente de prendre une donnée dans la FIFO via un sémaphore, se bloque si elle est vide, et se libère automatiquement dès qu'une donnée est présente.
Pour le retour des résultats, là aussi une FIFO, mais orientée dans l'autre sens afin que l'application puisse récupérer les données traitées.

Pas forcément besoin d'un thread pool au sens littéral (c'est une structure existante réellement dans l'API Win32), mais plutôt de plusieurs instances d'un même thread... Un thread pool est particulier, et ton besoin est plus réduit que les possibilités d'un pool. Autant dupliquer un TThread plusieurs fois, c'est dix fois plus rapide à mettre en place.

[Franck SORIANO]

Exemple grossier
dans ton calcul tu a un calcul en enties et un en reels. Tu peux faire dans ton UAL le calcul entiers et prendant ce temps la laisser une tr'ead avec le FPU!
C'est du moins se que j'ai compris du multi*treading.Peut être lme trompes-je?

Le multi-threading ne sert pas à ça. Les processeurs actuels sont déjà capables de faire ce genre d'optimisation, avec un seul coeur, sans avoir recours au multi-threading.
C'était en parti le cas avec les architectures en pipeline, dès le 80486 (sous une forme un peu différente) !
A présent, c'est d'autant plus le cas avec le principe de l'Out-Of-Order exécution : Le processeur n'attend pas nécessairement la fin de l'exécution précédente pour exécuter l'instruction suivante, ce qui lui permet parfois d'exécuter plusieurs instructions en même temps (sur le même coeur) !

Le multi-threading ne permet pas d'intervenir a ce niveau de finesse.

Ta phrase n'est vraie que pour les threads de calcul pur (sans I/O) ET qui ont toutes leurs données dans le cache... Cas relativement rare, quand même.

Cas très rare, j'en conviens. Mais c'est exactement le cas de FullSpeed, puisqu'il cherche à multi-threader son Sudoku solver du Défi Delphi !

Dans ton cas, tu mets quelques threads en attente sur une FIFO protégée, et ton application principale "remplit" cette FIFO. Chaque thread tente de prendre une donnée dans la FIFO via un sémaphore, se bloque si elle est vide, et se libère automatiquement dès qu'une donnée est présente.
Pour le retour des résultats, là aussi une FIFO, mais orientée dans l'autre sens afin que l'application puisse récupérer les données traitées.

FullSpeed, Mac LAK t'a donné la façon normale de travailler en multi-threading.
Cependant, tu te trouves dans un cas très particulier, où le multi-threading n'est pas nécessairement une bonne solution.

Si tu t'approches des perfs de ma solution, le temps de traitement complet doit être inférieur à 1ms.
Or le nombre d'activations nécessaires pour tes threads risque d'être de l'ordre de grandeur du millier... Je pense qu'il faut plus d'une micro-seconde à Windows pour reveiller un thread !

[Mac LAK]

Le multi-threading ne permet pas d'intervenir a ce niveau de finesse.

Je confirme des deux mains : il ne faut pas confondre l'effet d'un double pipeline sur l'exécution du code et le multithreading, ce sont deux choses totalement disjointes.

La première sert notamment à éviter les blocages sur instructions ASM (comme "int", "outport", "inport", etc.), les flushs inutiles du pipeline sur un saut (prédiction de branchement, deuxième pipeline, ...), et le cadeau-bonus, c'est l'exécution simultanée de deux instructions si elles n'ont aucune corrélation entre elles. L'unité de temps dans tout ça, c'est actuellement la picoseconde, le millième de nanoseconde...

La deuxième, c'est l'exécution de plusieurs choses de façon "parallèle" pour un œil humain, et pallier les blocages durant un temps énorme pour un ordinateur (supérieur à la microseconde, donc). L'unité de temps est en général la milliseconde (un milliard de fois plus, hein...), voire la seconde dans le cas des réseaux (un billion (mille milliards) de fois plus lent qu'au niveau pipeline).

Et ce que fait l'un, l'autre en est incapable et réciproquement, de toutes façons.

Cas très rare, j'en conviens. Mais c'est exactement le cas de FullSpeed, puisqu'il cherche à multi-threader son Sudoku solver du Défi Delphi !

Sauf que... Attention aux accès à la VCL pendant ce temps, ou aux propriétés d'un objet, ou encore aux fonctions de la VCL : tout ça peut faire "exploser" le cache, et donc rendre caduque la condition "tout dans le cache".
Très important par exemple si l'on utilise une classe issue de TObject...

Cependant, tu te trouves dans un cas très particulier, où le multi-threading n'est pas nécessairement une bonne solution.

J'aurais tendance à dire que c'est pas forcément une mauvaise solution, mais pas en terme de calcul unitaire en tout cas.
Plutôt dans une approche "un algo, un thread"... Je dis ça parce que je regarde un peu justement pour ce défi moi aussi, enfin sur les miettes de temps libre qu'il me reste (et c'est pas lourd...), et c'est une approche qui peut être intéressante pour pallier le problème de blocage en méthode logique. A condition d'avoir un CPU avec plusieurs cœurs, bien sûr, ce serait inutile et chronophage sur un CPU simple.

Or le nombre d'activations nécessaires pour tes threads risque d'être de l'ordre de grandeur du millier... Je pense qu'il faut plus d'une micro-seconde à Windows pour reveiller un thread !

Entre une vingtaine et un centaine de micros environ si c'est sur un évènement bloquant (type mutex). Jusqu'à un quantum de temps complet sinon (de l'ordre de 20 ms).

[Franck SORIANO]

J'aurais tendance à dire que c'est pas forcément une mauvaise solution, mais pas en terme de calcul unitaire en tout cas.
Plutôt dans une approche "un algo, un thread"... Je dis ça parce que je regarde un peu justement pour ce défi moi aussi, enfin sur les miettes de temps libre qu'il me reste (et c'est pas lourd...), et c'est une approche qui peut être intéressante pour pallier le problème de blocage en méthode logique. A condition d'avoir un CPU avec plusieurs cœurs, bien sûr, ce serait inutile et chronophage sur un CPU simple.

He, ne donne pas ma solution

C'est exactement comme ça que j'ai réalisé ma solution multi-thread. J'ai plusieurs algo de résolution différent (enfin en fait c'est le même paramétré différemment). Et comme je ne sais pas lequel donnera le meilleur résultat, je les essaie tous en parallèle et je garde le premier qui termine (sur un Quad) !
J'ai quand même un petit problème de synchro. Il arrive qu'ils soient plusieurs à terminer en même temps et je rends alors plusieurs solutions identiques !

[Mac LAK]

He, ne donne pas ma solution

Ben, d'un autre côté, c'est logique : j'ai un quad aussi, donc rester sur 25% de mon CPU me file des boutons...

J'ai quand même un petit problème de synchro. Il arrive qu'ils soient plusieurs à terminer en même temps et je rends alors plusieurs solutions identiques !

Essaie avec les fonctions Interlocked*, ça devrait résoudre ton souci.

[FullSpeed]

Meci de vos remarques plus précises les unes que les autres
Il v&a falloir que je sois bon : Franck ira voir:
je vois les espions du défir
Tu as raison de faire chauffer tes cœurs iol va y avoir du sport!!
Mon problème exact est le suivant

J'ai une liste L1 avec X milliers d'entrées
J'ai un module de calcul qui travaille sur un extrait de L1
le shéma est le suivant

je fais un calcul je fabrique une liste avec . je calcule un nouveau resultat avec l'extrait et je recommande
En fait l'extrait est une liste différente physiquement de L1 donc quand je fais mon calcul la liste L1 est parfaitement accessible
en fonction des treads je verrai si je gagne a avoir deux listes(en realite j'ai deux listes pour pouvoir partager)
L'architecture envisagée est une tread qui calcule des sous listes en permanence et le principal qui fait le calcul: 81 fois....(tiens donc)

Mais tres sincèrement merci

Frank fais attention a ta gorge; tu vas attraper un rhume quand je vais passer!

Dommage que l'on soit concurrent sur ce coup je suis sur que bien treade ma soluce est cartonne.

Boris (attention au Fullspeed il est en train de se reveiler)