Reprise du message précédent :
Y'a la 4670 K aux même prix que la 3570 K.

bon on reprend.
 
thread = processus.
 
GCC ne lance pas 10 processus mais 10 jobs, c'est à dire 10 applications qui prendront une part des fichiers à traiter SANS communications entre elles. chacune est indépendante, chacune a son propre espace mémoire indépendant, c'est GCC qui s'occupe de traiter les dépendances et qui va donc lancer des JOBS, autrement dit des APPLICATIONS, en fonction de ses besoins, et qui va tester les résultats des jobs afin de faire avancer le job global.
 
un processus, ou une thread, est INTERNE à un logiciel et sera contrôlé par d'autres threads, ou processus, partage ses données, sa mémoire, etc, etc.
 
Windows fait souvent la confusion entre jobs / applications et threads, ce qui aide pas.

ni windows ni linux ne font de confusion thread/processus.
sur les deux os tu peux visionner le nombre de threads d'un processus.
Il y a une confusion utilisation/affichage de l'unité des données sur windows mais pas de confusion avec les threads et processus.
Je vois vraiment pas d'où tu sors ça.
 
Tu peux même parfaitement afficher le nombre de threads qu'un processus fait sur windows.
 
 
" The implementation of threads and processes differs from one operating system to another, but in most cases, a thread is contained inside a process."
 
thread != processus au sens strict
 
un processus n'est pas "interne", un thread est interne.
 
Pour le reste à propos de gcc, merci mais je sais déjà tout ça. Pour en revenir à ce dont je parlais, aux moment où tu aura 5 jobs avec gcc, ton fx8 sera sous utilisé, à peine plus de la moitié de la vitesse qu'il peut atteindre.

bon moi je usi une crosshair formula z dans bf4 je suis 60 fps en general avec une r9 270x  
 
avant j'avais une gigabyte 970a ds3 et je tourne avec mon fx 8350 a 30fps les test ne ment pas le i5 est plus puissant certe mais pas enorment  
 
le fx est un i7 2600K et i7 960 donc les perf depend de tous !!!
et chaque procc est different !

pour la simple et bonne raison que sur Unix, les threads ça n'existe pas, il n'y a que des processus lancés  par d'autres processus.
sur Windows, la confusion entre job / applications / processus = threads est faite.
 

Bref, l'OS étant un processus qui lance des applications, les applications sont donc des threads.
thread = processus au sens strict des définitions et des usages.
 

tous les processus sont internes à un autre processus, sauf 1, le processus 0 qui est le processus qui lance l'O/S.
ta définition est donc valable aussi bien pour les threads que les processus, donc thread = processus.
 
 

TU peux lancer 100 jobs avec GCC sans saturer ton processeur, puisque tes processus seront limités par le débit des disques avant de saturer la capacité de ton processeur à les traiter.

Plus personne ne compile en passant par les disques...et ce depuis...ouch...
Pratiquement tout est fait en mémoire.
 
Surtout pour ceux plaçant carrément leurs sources en "ramfs".
Quand tu as décompressé ton archive de programme à compiler en prime tu as déjà mis en cache tous ces fichiers avant compilation. Bon pas valable quand ton système décompresse un tas d'archives ou fait autre chose à coté forcément.
 
Donc lecture et écriture minimale, c'est pas ça qui va te saturer les disques.
 
La conso mémoire explose à cause du non partage de la mémoire pour la compilation, c'est surtout ça qui va te limiter et rentre une compilation ou un rendu contre productif(en temps) en utilisant 100jobs sur un quadcore par exemple(mais bon idem avec un cpu 16cores)
 
 
Maintenant plutôt que de rester sur la théorie, teste, tu verra qu'en temps c'est plus lent qu'avec 6jobs.
 
4 sur un quad ça ne sera pas optimal, 6 ça sera mieux parfois même 7-8, ça dépend de l'appli, après ça devient contre productif.
 
Déjà fait donc j'ai pas besoin de faire ça. Autant en rendu qu'en compilation.
 
Sinon on mettrait 250 workers pour l'execution de script php bah non c'est pas ce qu'on fait, on ajuste le nombre en fonction de la machine, on teste pour voir si ça améliore ou dégrade les perfs puis on valide.

hum.
renseignes-toi sur Jenkins.
dans la dernière entreprise de dev où j'ai officié, on utilisait SVN/MAVEN/JENKINS, parce que c'est pas un dév, une appli, une machine, c'est 3 équipes, une 40 aine de machines, et chacun est responsable de sa partie.
l'intégration se fait par SVN, et le logiciel n'est pas tenable sur un disque ram.
chaque poste compile pour sa part, mais la vraie compilation et les tests sont fait sur un serveur dédié en continu, et c'est pas un fsram.

Ce sont des logiciels déjà considéré comme obsolète en 2010...(me semblait bien que j'avais vu presque tout le monde "autour de moi" délaissé svn et compagnie, j'étais pas sûr mais je voulais confirmer) mais bon ça date aussi p-e d'un moment.
 
ça fait un moment que de nombreuses entreprises ont délaissé tout ça.
 
 
Il y a des logiciels qui nécessitent aussi des quantité "astronomique"(pour une station de travail) de mémoire pour la compilation dans ces cas là ça sera dur d'avoir un ramfs en même temps oui...