Version imprimable
Et, quand tu compiles, tu utilises forcément des threads ? Je suis sûr que l'une de tes deux compils n'était pas parallélisée !Citation:
Envoyé par buggen25
Non, franchement, sans méchanceté, ce n'est même pas de la guerre de clochers, ici. Tu as fait l'effort de lancer des compilations sur plusieurs systèmes et malgré ça, tu vas passer pour un âne devant n'importe quel employeur, si tu tires ce genre de conclusions.
Pour l'un de mes programmes, j'ai le même code sous Windows et sous Linux. Le code sous Windows est 4 fois plus lent que celui sous Linux.Citation:
Envoyé par buggen25
C'est vrai que c'est vraiment approximatif, désolé pour ça !Citation:
Envoyé par r0d
Bon la première fois que j'ai utilisé un ordinateur remonte à il ya 3 ans ce qui est relativement cours:oops:
Concérnant le compilation de Qt sous linux, ben j'ai attendu 5 heures pour que Qt me gènère les fichiers "executables". je suis resté 5 heurs à regarder les instructions défiler.
Concérnant les conditions de compilation :
Sur windows:
Le compilateur est MinGW:( c'est du GNU )
sur cmd je tappe configure, pui make
Sur linux , je rentre dans le dossier comportant les sources de qt
je déclache l'execution de fichier sh "configure"
ensuite je tappe;
gmake
puis j'attend 5 heures 8O
C'est pas du tout le même compilateur que tu utilises, pas forcément les mêmes options de compilation (peut-être plus de bibliothèques additionnelles sous Linux), mais surtout gcc.
GCC 4.x est assez lent, mais ça vaut la peine par la suite (cf mon message précédent).
Il est fort probable que tu n'aies pas tout compilé (ni d'un côté, ni de l'autre, d'ailleurs). ./configure sert notamment à cela : sélectionner les composants qui doivent être construits ou non. Et ceux-ci sont choisis en fonction de ton environnement. Avec MinGW sous Windows, celui-ci devait être minimum, et la compilation t'a construit un truc en rapport.Citation:
Envoyé par buggen25
Ensuite, as-tu vérifié pendant la compilation que le compilateur sous Windows lançait bien des threads ou n'est-ce qu'une supposition ?
Enfin, comme dit plus haut, il faut passer l'option -j à make pour lui demander de lancer plusieurs jobs à la fois (ce ne sont pas à proprement parler des threads, toutefois).
J'ai jamais dit ça, j'ai meme pas pensé à ça !Citation:
Envoyé par Obsidian
Sans comentairesCitation:
Envoyé par Obsidian
Suis le lien http://www.developpez.net/forums/d57...e/#post3428127Citation:
Envoyé par Obsidian
On va pas en faire toute un plat :D
De toute maniere, tous les OS marchent pareil, et je n'ai jamais vu de différence entre Linux et Windows de ce coté... A part, peut-être un accès plus facile sous Windows SDK à certaines fonctions (comme la sélection du CPU préféré pour le thread, la priorité d'execution, ...), mais je ne suis pas un fin connaisseur de tous les noyaux unix (et tous les unix ne sont pas égaux devant les threads).
Quand on "lance" un programme, l'OS crée un "processus" (allocation mémoire, mapping mémoire virtuelle, chargement du code, handles d'entrée/sortie, ...), puis alloue un thread à ce processus (parfois appelé thread principal) pour executer le point d'entrée du processus ("main") qui dépend de l'OS.
Ensuite, rien n'empêche ce thread principal de créer d'autres threads additionels au sein du même processus.
Un thread regroupe un "état de fonctionnement CPU" (code actuel, pile, registres), le passage d'un thread à un autre "coute" cher (mais largement moins que sa création), mais permet entre autre, de continuer à faire des choses pendant qu'on attend autre chose (en général de l'I/O comme la lecture de fichier, le réseau, la carte graphique ou la carte son, ou bien attendre un évenement précis comme une heure donnée, une exception, etc...).
Un thread n'est pas un vrai processus, même sous Linux. On l'appelle processus léger, mais ce n'est pas un processus en tant que tel.
Côté compréhension, nombre de difficultés proviennent du fait qu'un "thread" est (ou pas) une entité gérée par l'ordonnanceur de "processus".Citation:
Envoyé par Matthieu Brucher
Si les threads crées par/dans un processus sont gérées par l'ordonnanceur on parlera de correspondance 1x1 entre l'ensemble des objets gérés par l'ordonnanceur et l'ensemble des threads crées par les processus "actifs".
Il existe un modèle de threading (plus léger) qui fait une correspondance MxN. Dans ce modèle, un process multi-threads dispose d'un ordonnanceur de premier niveau qui les multiplexe sur des threads de 2nd niveau (qui sont elles gérées par l'ordonnanceur de processus).
A ma connaissance, Linux implémente, par défaut, un modèle 1x1.
- W
To the Linux Kernel, there is no concept of a thread. Linux implements all threads as standart processes. ... Instead, a thread is merely a process which shares certain resources. Each thread has a unique task_struct and appear to the kernel as a normal process (which shares resources, such more as an address space, with other processes)
Linux Kernel Development Robert Love
Il faut donc bien distinguer programme, processus et thread. ;)
Grossomodo, dans le noyau linux, le concpet de thread n'existe pas.Citation:
Envoyé par Vespasien
Donc un thread selon linux est juste un processus qui partage quelques ressourcesCitation:
Envoyé par Vespasien
Abvious ;)Citation:
Envoyé par Vespasien
Où M et N sont ?Citation:
Envoyé par wiztricks
Je suppose que M=threads et N=processus.
Ok, mais cet ordonnanceur de premier niveau, lui, fonctionne comment ? Sans être un expert, je me dis qu'il doit être soit coopératif, et dans ce cas, ça implique beaucoup de prérequis, soit préemptif comme les autres et dans ce cas, il fait double emploi avec l'ordonnanceur de processus normal (avec possibilité de concurrence).Citation:
Dans ce modèle, un process multi-threads dispose d'un ordonnanceur de premier niveau qui les multiplexe sur des threads de 2nd niveau (qui sont elles gérées par l'ordonnanceur de processus).
Si on affine l'ordonnanceur pour définir ce qui est partagé ou pas, et que l'on groupe les processus en session (comme ça se fait déjà sur Unix), il n'y plus rien qui distingue un processus d'un thread. Et il me semble que c'est bien ce que fait clone().
Plus précisément M threads de premier niveau qui peuvent être exécutée par N threads de second niveau (inutile d'avoir N grand devant le nombre de CPU par exemple).Citation:
Envoyé par wiztricks Voir le message
Il existe un modèle de threading (plus léger) qui fait une correspondance MxN.
Citation:
Envoyé par Obsidian
Par définition, la préemption sert à suspendre un thread actif suffisament longtemps alors que d'autres threads n'attendent que la libération d'unCitation:
Ok, mais cet ordonnanceur de premier niveau, lui, fonctionne comment ? Sans être un expert, je me dis qu'il doit être soit coopératif, et dans ce cas, ça implique beaucoup de prérequis, soit préemptif comme les autres et dans ce cas, il fait double emploi avec l'ordonnanceur de processus normal (avec possibilité de concurrence).
processeur pour s'exécuter.
On peut donc laisser faire la préemption par l'ordonnanceur de second niveau.
Quelque soit le modèle de threading, un processus est définit par un espace d'adressage virtuel et l'ensemble des threads qui le partagent.Citation:
Si on affine l'ordonnanceur pour définir ce qui est partagé ou pas, et que l'on groupe les processus en session (comme ça se fait déjà sur Unix), il n'y plus rien qui distingue un processus d'un thread. Et il me semble que c'est bien ce que fait clone().
Il y a quelques subtiles différences entre:
- la création de la première thread impliquant celle au préalable de l'espace virtuel
- l'ajout de thread à l'objet précédemment crée.
Et le mélange systématique entre le "quoi" et les implémentations réalisées n'aide pas à faire la différence entre l'essentiel et le spécifique.
- W
Il me semble que sous Linux, l'implémentation du multithreading a changé:
- Avant l'invention de la NPTL, les différents threads d'un processus étaient gérés par le processus lui-même, mais pour le Kernel il n'y avait toujours qu'un et un seul processus.
- Depuis la NPTL, les threads sont des processus qui partagent une grosse part de ressources.
Sous Windows NT, le kernel a toujours fait la différence entre processus et threads. Par contre, j'ignore ce qu'il en est pour les fibres.
Si on garde la définition du multithreading comme étant "plusieurs fils ordonnançables indépendament" qui partagent le même espace d'adressage (virtuel), certaines libraries proposent un mécanisme parfois appelé "user level threads" dans lequel le noyau n'a aucune connaissance des "threads" crées dans/par le processus.Citation:
Envoyé par Médinoc
=> Plusieurs threads sont "multiplexées" dans un même processus.
Cette approche à l'inconvénient de ne pouvoir profiter du nombre de processeurs dont pourrait disposer le système, ce qui limite les capacités de traitement à un seul CPU. Pour ce faire, il faut des entités ordonnançables par le noyau (des kernel threads).
D'ou l'intérêt de différencier:
- "users threads" : threads dont le noyau n'a pas connaissance et qui ne sont ordonnançables que par/depuis le process (ou plus précisément la librarie qui les gère).
- "kernel threads" : threads ordonnançées par le noyau comme le sont des process mais qui partageant nombre de ressources (espace virtuel, mémoire résidente,...) sont un peu différent du processus classique.
Sous Solaris, les "users threads" s'appellent simplement "threads" alors qu'elles sont nommées "fibers" sous Windows. De même les "kernel threads" sont désignées par LWP sous Solaris (LWP = Light Weight Process) et simplement threads sous Solaris.
Windows semble ne proposer que des objets élémentaires fibers et threads, charge au développeur de créer l'ordonnanceur via "switchtofiber" - ce n'est pas des plus simple - alors que Solaris propose un ordonnanceur.
- W
Ce qu'il faut distinguer, c'est les threads noyau, aussi appelés LWP (lightweight processes) et les threads utilisateur.
Les threads noyau sont plus coûteux, passent moins bien à l'échelle, mais ils sont capable d'être placés sur différents cœurs hyperthreadés, cœurs, processeurs, etc.
Les threads utilisateur souffrent du fait que tout appel bloquant bloque tous les threads, ce qui peut se résoudre en remplaçant ces appels par l'équivalent non bloquant et en laissant l'ordonnanceur de threads utilisateur gérer le reste pour donner un comportement bloquant. Une alternative est aussi de déclencher un thread noyau pour ces cas-là.
Linux ne fournit que des threads noyau.
Libre à toi de faire au sein de ces threads noyau d'autres threads utilisateur, ce qu'on appelle du N:M.
C'est un sujet super interressant, je squatte :mrgreen: !
Quelles sont les (autres) différences notoires entre ce que permettent Windows, Linux et solaris?
Par exemple les fibres (que vous m'avez fait découvrir - merci) sont elles disponibles sur ces trois plateformes? Les bacs à threads (traduction perso de thread pool), les conditions et tout ça ?...
euuuhhh merci à tous ...
C'est plutôt "la piscine chlorée de threads où nagent les enfants".Citation:
Envoyé par khazna
Ca devient presque un cours de vocabulaire, non ?
:sm: