GamerFou ta reponse tombe pile poil dans le vrai. Quel plaisir de parler avec une personne consciente de l´espace memoire. Bon, j´arrete la brosse a luire et . .

Donc,

lorsque tu envoie un WM_SETTEXT, en sous main un mecanisme de type WM_COPYDATA est mis en oeuvre ?

Arf ! Poussons un peu plus loin.
Alors lorsqu´une application va s´envoyer de type de message a elle meme, elle va faire une copie des donnée ? ???

Merci billou.

Eh béé...

Le quart de dieu lest impressionné
A vrai dire, je sais juste à peu près comment fonctionnent les messages et à quoi set WM_SetText

Dailleurs jai 2 petites questions:
1/C´est quoi un tube et comment ça se crée?
2/Cest qoui les différences entre un process et un thread? Lequel est plus rapide?

Voilà, je donne mon titre à qui me répondra.
Cest pas trop cool, devenir un 3/4 de dieu?
J´entends déjà la langue pendante de GamerFou.
Bon toutou, va
Sois sage, et tu auras ta pâtée

Pour toi, Dino, les DLL poosèdent parfois des incompabilités selon le compilateur utilisé, nottament entre ceux de Borland et Microsoft. On peut tout de même créer des objets C mais sans optimisation

A mon avis oui il doit se passer un truc comme ca. Le SETTEXT est un message réservé pour le système donc il peut s´y passer n´importequoi.

Pour ce qui est d´utiliser COPYDATA sur une seule application il n´y a, dans ce cas, pas vraiment d´intérêt. Utiliser un pointeur dans lParam peut suffir. L´avatange de COPYDATA est de permettre la communication de données "complexes" (classes, structures, tableaux, chaines etc...) entre 2 applis. Enfin tout ce qui ne peut pas tenir dans WPARAM et LPARAM.

Pour SuperDindon, les pipes (tubes) ce sont des fichiers virtuels en quelque sorte qui permettent à 2 applis (ou threads) de communiquer. L´une des applis écris les données l´autre les lis et vice versa (sachant que le pipe est en mode R/W). Il est donc nécessaire dans certains cas de bloquer le pipe en écriture si l´une des 2 applis est en train d´écrire etc...

Différence entre Process et thread . . bin un process contient un ou plusieurs threads. Un process a son propre environnement d´exécution (c´est en fait ce que l´on a appelé jusque là une appli), et donc les threads créés par ce process auront accès au même environnement (mémoire etc...).
Un thread n´exécute qu´une partie (quelques fonctions) de ton programme en "parallèle" à ton appli (en théorie).
Le process est un programme en entier (un exe quoi).

Sachant qu´il ne s´agit pas du tout de la même chose, je pense pas que l´on puisse comparer quoique ce soit, mais il faut savoir que pour un process, tout un environnement d´exécution sera créé à chaque fois... Pour un threads comme pour un process tu peux définir une priorité d´exécution, ce qui te permet de leur donner plus ou moins d´importance.

1/ ? ??? Un tube ? ?? - Sens 16 Bit->32 bit ? ??

2/
J´assimile le process a un programme. Le process a un espace d´adressage propre (Data, Tas, code, privilege etc . ..)

Le thread est une sous entité d´un process.

Le process possede au moins 1 thread !

Le thread possede lui:

1 pointeur de programme ( donc un contexte et privileges),
1 pile.
Le reste il le partage avec le process.

Te reste plus qu´a comprendre le mechanisme d´election du thread. Le systeme choisi dans les process celui a elire, puis au sein de ce process le thread a elire. Et roule.

Lequel est le plus rapide ? La question n´a pas de sens bien sur.
Attention, creer des threads n´ameloire en rien ( la plus par du temps ) la rapidité d´execution de ton programme . .. T´as toujours qu´un processeur sur ta machine.

Note 1:
Il doit etre bien ennuyant de devinir Dieu de la programmation. Dieu sait tout, et doit bien se faire chier....

Note 2:
J´aimerais savoir de quelle incompatibilités les DLL Borland sont entiché ? C´est un "objet" systeme , non ? Donc doit etre "compatible" systeme, nan ? Personnellement mes DLL je les cree s avec Visual, je les charge dynamiquement.

A+

Exciuse pour les DLL, je me suis gouré, cest pour les DCU quil y a incompabilité, pour l´adressage mémoire, et ce seulement entre Delphi et C++Builder, tous deux de Borland.

Sinon OK, jai compris pour les process et les tubes.

Enfin, jaimerais demander lavis des nouveaux dieux de la prog.
Est-ce qu´une application multithreading peut être ralentie si chaque thread lit un fichier différent mais dont tous se trouvent sur le même disque?
Je demande ça car mon moteur, Horizon, utilise une mémoire en totalité SWAP pour certains éléments, et je compte utiliser plusieurs threads pour chaque domaine. Je voudrais savoir si jai fait e bon choix, surtout après ce que vient d ecrire Passage.

Pour finir, jattends des vraies questions. Je rappelle que jai crée ce forum pour proposer mon aide, mais à part LightMan et Trapamoosh, i semble que tout le monde sen tape. Mais si lenvie vous en prend, y a pas à hésiter.

@+

Utiliser plusieur thread ne te fera pas gagner de temps mais plutot en perdre. Il te faudrat de synchoniser a un moment ou a un autre ( attendre la fin du travail d´un thread).

Tous tes thread accedent a la meme ressource physique - Le disque -, donc tu aurat de temps d´attente. C´est forcé et logique.
Par contre si tes pages sont deja engagé en memoire swap, ben la tu gagne en temps.
Mais le temps d´acces physique reste le meme.
Le multithreading te fera perdre du temps car tu ne peut controler exactement l´election de ton thread...

Dans le jeu video,il vaut mieux eviter le thread.
Je ne voit que 2 utilisation d´un thread dans le domaine de jeu video.
1/ Le son - Pas de doute la dessus.
2/ Peut etre dans certains cas pour l´IA, mais faut voir. Un truc du style, tu lances "une reflexion" = 1 thread, pis ton thread met a jour des données que ton moteur de jeu prends en compte (Peut etre sans synchro necessaire). Mais je pense quand meme qu´il vaut mieux ecrire toi meme le scheduling de ton moteur de reflexion, cela te permet de mieux le controler quand au temps CPU passé dedans.

Yep, j´aurai pas dis mieux : )

Le réel avantage du multithreading ne se ressent que dans des applications où tu as besoin de partager les calculs ou les traitements. Les gains en vitesse ne sont vraiment intéressants que dans le cadre d´un système multiprocesseurs. Par exemple les softs de raytrace qui utilisent cela sont nettement accelérés.

Des softs comme Internet Explorer utilisent également les threads dans le cas des download, plutôt que de gérer 2,3 ou 4 downloads en même temps il lui suffit de lancer un thread qui effectue le téléchargement du fichier. Mais il est vrai que les jeux ne sont pas vraiment destinés aux multithreading, car la plupart du temps des besoins de performances à l´exécution sont nécessaires et les threads ne sont pas là pour aider : )

N´oublions pas que lorsqu´un thread fils est exécuté, le programme principal est bloqué (sur du monoprocesseur du moins)...

SuperDindon, y´a pas de problème au niveau des DLL, il y en a juste au niveau des LIB qui ont un format spécifique a chaque compilateur.

Dino

Pour GamerFou :
Le thread de l´application n´est pas "Bloqué" lorsque tu lance un thread ( heureusement car sinon on appelerait cela une fonction : -) )

Lorsque tu cree un thread, celui ci vient en concurrence lors de l´election par le scheduleur avec les autres thread au sein de ton process.

Par contre, tu peux affirmer que sur un systeme monoprocesseur, a un instant T donné il n´y a qu´un seul thread elu.

Bin c´est ce que je disais . .. (mal peut être ? )

Un thread minimal, c´est quoi ? une fonction non ? : o)

J´ai bien dit sur un monoproc :
"N´oublions pas que lorsqu´un thread fils est exécuté, le programme principal est bloqué (sur du MONOPROCESSEUR du moins)... "

OK, je suis votre conseil, les dieux

Sinon j´ai un autre petit problème, je n´ai aucune documentation sur les instructions des micro-processeurs. On les trouve normalement dans le manuel d´utlisiation?(que je trouve plus).

A part ça, je rappelle une fois de plus que je suis prêt à répondre à toutes les questions, de program ou autre

Pour les instructions micro-processeurs, tu trouveras ton bonheur sur le site d´intel. C´est un peu le bordel leur site, y´a trop trucs et un peu n´importe ou, mais apres plusieurs heures tu trouveras quand meme les docs d´instructions. Par contre, je sais que tu peux télécharger les Processeurs-Packs qui sont des SDK processeurs pour gérer les instructions MMX, SSE, SSE2, 3DNOW, etc... mais ils sont dispos juste pour visual, je dis ca car je sais que tu es sous delphi.

Dino.

Pour Gamer fou :

Un thread minimum n´est pas une fonction :
Un fonction ne possede pas (intrinsequement de pointeur de contexte - C´est le thread qui le possede ) de plus a la creation ( appel )de la fonction tu n´a pas de creation d´une pile propre a la fontion, mais elle utilise celle du thread en cours.

Ce que je veux dire par l´appelant n´est pas bloqué c´est:
Tu tu place dans ton thread principal.
Tu cree un thread ( fils )...
Les 2 thread sont elu alternativement ( si tu touches pas au priorité ).
Le parent n´est pas bloqué jusqu´a la mort du fils...
Ils se partagent le temps CPU suivant les regles d´election données par le scheduleur.

Cool ! Vous les avez tous perdu : vous etes tous seuls sur le forum : -)
---
Oui, pendant que le threads fils est execute, le thread parent est suspendu. On est tous daccord (sur systeme mono processeur)

Mais, ceci sera bientot fini, car dans le p4, il y a possibilite d´avoir 2 proc au lieu d un.

Je mexplique : depuis longtemps, les processeurs possede une architecture superscalaire qui permet de realiser plusieur operations simultanement sous certaines conditions : ex :

MOV AX, CX ; les 3 instructions d´ un cycle
MOV AX, BX ; = juste 1 cycle car
MOV AX, DX ; utilisation des registres distincte

necessite de nos jours seulemement 1 cycle d horloge au lieu de 3 (Pour peu que le compilateur fasse correctement les arrangements d instructions).Car

MOV AX, BX ; Imaginer ce que ca peux donner
MOV BX, CX ; si c 3 instructions pouvaient
MOV AX, CX ; etre executer simultanemment : -)

Selon intel, le multithread est un frein a ce systeme. Pour ameliorer les performance, au lieu davoir plusieurs pipelines (chaine dexecution)ayant une entree et une sortie commune, on aurait plusieurs pipelines avec entree/sortie distinctes. On aurait ainsi dans une seule puce plusieurs microprocesseurs simples, mais capable de fonctionnner simultannement. Dans le cas du p4, on peut avoir 2 pipelines separes, soit 2 CPU simples (fonctionnant en parallele) au lieu d un complexe (qui de temps en temps execute plusieurs instructions en meme temps).

Les gains de performances serait de 20%-30% a condition : davoir l´OS adequa (cad driver : -)
et que lapplication utilise du multithread, bien sur : -))

voila, voila !

Bin j´ai jamais dis qu´il était bloqué jusqu´à la fin de l´exécution du thread . . mais quand un thread s´exécute aucun autre n´est exécuté. Ce que je voulais dire par "bloqué" . .. ok je me suis mal exprimé alors!

Super, Dino.
Thanks

Pour toi, arnaud81, je suis impressionné, un peu trop peut-être, beaucoup trop peut-être, par ta réponse, car ce que tu insinues signifie qu´il y a 2 bus pour chaque mémoire, ce qui paraît un peu gros.
Bon , peut-être que si on utilise que les registres...
Enfin bon, je reste un peu perplexe

en fait, non y pas deux bus. les cpu sont sur le meme bus. c pour ca que les performances ne senvolent pas. : -)
y a aussi des caches qui sont la pour eviter que tous se bloque tout le temps : -)

d ailleur, les systemes bi-processeurs ne vont pas deux plus vite que les systemes mono : -)

tous ca a cause effectivement de l acces au bus... et principalement pour la memoire...

Je viens d´acheter une Fuego 2.2DTI Common Rail, ABS (Anti Broutage System), Direction Assistée Manuellement, ESP(Elargissement de la Sortie de Pot ), Vitre avant, Jante en plastique, Peinture imitation bois.

The Fuego Touch.

Arnaud81

Et ça coute deux fois plus cher, pour créer des processeurs comme ça?

RenaultFuego alias MisterUP

Comprends pas trop ce que ça fout sur mon forum.
Enfin bon...
Pour info, l´ABS n´est intégré que dans la version spéciale pour bovins, enfin je pense que tu l´as choisie sur conseil personnel des vendeurs. Tout de façon, t´as du bol, le manuel a été traduit de la langue de boeuf.
Pour la DAM, t´as fait le bon choix, ça correspond parfaitement aux crétins.
L´ESP, cest de la daube, prends plutôt les EPDT(Enjoliveurs Plein De Trous), ça fait bien plus high-tech, et en plus , je sens que ça va devenir la nouvelle mode
Vitre avant, pas bo, la vitre par-terre c´est mieux, on peut voir à quelle vitesse elle fond sous les roues
Jante en plastique, naze, jante en carton pate, cool.
Au final, le seul atout de ta voiture c´est ta peinture qui sera très représentatif de notre beau pays couvert d´arbres et de fleurs, c´est bien connu