j'aurai une petite question, est-ce qu'un bete programme en mode console gere automatiquement plusieurs core ?
 
j'ai un monocore chez moi , je peux pas tester encore tester, mais prenons cet exemple
 
# include <iostream>
using namespace std ;
int main ()
{
for (int compteur =0;;compteur ++)
{
cout<<compteur<<endl ;
 
}
}
 
est-ce qu'un seul core sera utilisé ? ou tous les core seront utilisé ?

un seul core.
 
il faut que tu fasses des recherches sur le terme "thread" dans google, et aussi sur le terme "sémaphore", pour comprendre le concept.

Oui et non.
 
Sous Windows en tout cas, depuis la version 2000, il est capable de répartir la charge entre deux processeurs, même si le programme est parfaitement mono-thread. La répartition par défaut est d'environ 33%/66%
 
J'avais remarqué ça avec mon serveur, qui est un vrai bi-pro (donc si y'a de l'activité rapportée sur un CPU, c'est qu'il travaille effectivement, pas comme avec un dual-core où il ne s'agit que d'émuler un second processeur matériel, ce qui pourrait expliquer la chose).
 
Cependant, en global, impossible donc de dépasser les 50% d'utilisation de deux CPU avec un programme mono-thread, même si Windows s'amuse à le découper en deux.
 
Donc on en revient à ce qu'à proposé bjone : regarder du côté des threads, et lancer deux threads séparés : là tu pourras utiliser 100% de chacun des deux cores.
 
A noter toujours que sur un dual-core (et non un bi-pro) vu que c'est un seul CPU, de toute façon, si une seule appli mono-thread tourne et charge à 50% le CPU, il n'en reste pas moins qu'elle bouffe en réalité 100% du CPU, c'est juste un problème d'affichage dans Windows (en fait, la carte mère accorde 100% des cycles au core virtuel "CPU 1", et 0% des cycles au core virtuel "CPU 2"

Tu confonds dual core et hyper threading...

Autant pour moi Je croyais que ct la même chose Donc un dual core c'est réellement deux CPU sur un même support ?
 
Enfin, dans tous les cas, logiquement on va quand même remarquer que pour une raison inconnue, Windows split le programme en deux, mais qu'en global son occupation CPU ne dépasse pas 50% s'il n'est qu'en mono-thread.

Oui

 
il le "split" pas, mais il peut le renvoyer sur un autre core pour des raisons d'efficacité globale.
 
par exemple les IRQ sont assignés physiquement à un core, et suivant l'activité "kernel" lié à ce genre de trucs, un process peut être rebalancé sur un autre core. (ce qui explique ce comportement, où dans le même timeslice, le kernel bosse en interne sur un core, et l'autre core fait avancer le process).
 
donc un process qui se retrouve crée sur un core, peut aller faire un bout de sa vie sur un autre.

nan mais tu lis ce que t'écris ? Ca veut juste dire que le scheduler de windows est pourri et qu'il arrete pas de balader les processus ce qui est très couteux.

Il n'empêche qu'une appli mono-thread utilise du coup les deux cores
 
Mal c'est certain, mais elle les utilise quand même

 
ça dépends.
effectivement, ça pourri le L1/L2 entre autres si il change tout les timeslices, maintenant si c'est dû à un pic d'activité kernel dû à des IRQs ou autre (carte Gigabit/scsi qui s'énerve), ça peut être judicieux de basculer "définitivement" (du moins pour de nombreuses portions de temps) le process/thread vers un autre core.

 
non. il utilise pas, il se "déplace". (et c'est pas "mal" si c'est pour la raison que j'ai cité)
utiliser, ce serait utiliser les deux core en même temps, ce qui n'est pas le cas.

Pas en même temps.

justement, c'est la fête du flapping. Heureusement qu'on peut gérer les affinités

boah, après faut voir les heuristiques & co qui contrôlent le bordel...

show us the code

mahuf ?

ouais, c bon, confondu hyper-daube avec dual-daube, j'y peut rien si ça fait 10 ans que l'informatique est devenue grand public et qu'à cause de ça on nous pond toutes les deux semaines une nouvelle techno vieille de 50 ans avec un nom différent, j'arrive pas à suivre
 
je veux mon goupil

pour rebondir, le mutl-thread en C++, ca s'attaque fort bien avec boost::thread. Pour du numerique pur, NT2 a un support SMP prevu pour dans genre pas longtemps.

pi y a des trucs mignons dans gcc et ses prochaines versions

 
oui revenons à nos moutons qui goupillent au dessus de la cloture du thread.

j'imagine qu'il y a surement des calculs qui nécessite imperativement que le calcul precedent soit fini. donc dans ce cas la il n'y a aucune optimisation multi core possible ?
 
Par exemple si j'ai une tres grande liste, et que dans tous les elements de la liste j'ai un nombre qui m'indique quel element de la liste je dois verifier.
 
au debut je suis en donc en 1 on m'indique que je dois aller verifier en 4563, en regardant le 4563eme element de la liste on m'indique que je dois aller en 456 etc jusqu'a ce qu'on trouve la sortie.
j'ai du mal a comprendre comment decouper en 2 partie independante ce calcul, car pour aller a l'etape suivante il faut effectuer le "calcul" precedent..

C'est pour ça qu'il faut réfléchir un peu avant à la manière de découper les tâches et les données.  
Sinon c'est indémerdable avec plusieurs threads.
Et c'est encore plus vrai pour les GPU type G80 où il faut faire tourner plusieurs centaines de tâches pour que les perfs commencent à être intéressantes.

Ben déjà, tu peux mettre dans ce cas là deux types de threads :
1/ Si le fonctionnement de ton programme ne dépend pas du résultat final (genre tu sérialises un immense arbre en mémoire pour le sauvegarder sur le disque... une fois que t'as indiqué à la GUI qu'il ne faut plus jouer avec, rien n'empêche l'utilisateur de faire autrechose pendant que ça enregistre), tu peux déjà faire tourner cette tâche particulière dans un thread séparé, histoire que la GUI réponde. L'exemple typique, c'est Windows et la gestion de la souris : la souris tourne dans un thread complètement séparé, la preuve, que le PC soit en train de freeze comme un tarré ou non, on peut généralement continuer à bouger la souris, même si plus rien d'autre ne répond : c'est idiot de t'empêcher de bouger la souris simplement parceque ça rame.
2/ Toujours en ce qui concerne l'exemple de l'arbre immense en mémoire, on distingue deux choses : le parcours de l'arbre/serialisation sous forme de flux binaire pour l'écriture disque, et les accès disques eux-même. Du que l'ATAPI c'est fini depuis bien longtemps, le CPU est disponible pendant que le disque dur patine dans la choucroutte pour écrire sur le disque. Tu vas donc faire deux threads séparés : un fournisseur, et un consommateur. Le fournisseur parcours ton arbre et le sérialise, puis envoie au consommateur le flux binaire qu'il va écrire sur le disque. Ceci va te permettre d'écrire en continu sur le disque, même si les calculs en mémoire sont assez lourds, sans pour autant mettre en pause les calculs en mémoire le temps que le disque écrire chaque bloc. Bref, tu peux t'attendre à un gain énorme dans ce cas précis. Je m'étais amusé à faire un programme d'encryption de fichiers, avec et sans threads, c'était jusqu'à 400% plus rapide ! Effectivement, non seulement le fournisseur (encryption) ne se met plus en pause à chaque écriture, mais en plus tu peux plus aisément faire une gestion de cache pour les écriture (écrire par blocs de 512 Ko plutôt qu'octet par octet).
3/ Enfin, toujours en reprenant le principe l'arbre, tu peux avoir un thread qui parcours l'arbre, pendant qu'il lance des fils qui s'occupent de sérialiser chaque noeuds (la le gain me semble moins évident, et tu vas te heurter à une multiplication de threads qui pourraient bien foutre en l'air la pile si tu ne fais pas gaffe).
 
Typiquement, tout ce qui "prend du temps" sans être "bloquant pour l'utilisation" peut être passé en threads. Ca va des échanges réseaux aux traîtements d'infos en passant par les accès disques et l'affichage de la GUI.
Ensuite, il faut savoir que si des threads dépendent les uns des autres, il y a toujours des fonctions qui permettent de les mettre en attente.
Par exemple, en C#, on peut lancer depuis un thread t1 ceci : "t2.Join()" : t1 va se mettre en attente jusqu'à ce que t2 ait fini.
Autre exemple, tu sauvegardes sur le HD. C'est trop long, t'as fait une boulette. Depuis le thread de la GUI, tu peux gérer un bouton anuler, qui va faire un "threadBackup.Kill()" histoire de ne pas faire rammer le PC pour rien, et shooter le backup en cours. Si ton threads d'écriture disque est gavé jusqu'à la gueule, il peut aussi faire un "threadFournisseur.Suspend()" histoire de souffler un peu, etc. On peut donc parfaitement gérer les dépendances, donc même des taches apparement pas trop sérialisable peuvent le devenir.
 
Le plus chiant avec les threads en fait, c'est les accès mémoire aux objets partagés : vive les états incohérents en mémoire

C'est de qui déjà la phrase genre style "les threads c'est pour gens trop con pour écrire un automate" ?

 
Je sais pas masi je l'ajoute à mon book de citations à ressortir

 
Tu ne peux pas forcement paralleliser n'importe quel programme. Le probleme que tu donnes est intrinsequement sequentiel, tu ne pourras pas l'accelerer avec du multicore sans faire de calculs redondants.

c'était en anglais, je n'arrive pas à retrouver la formulation exacte

 
Si il avait un tas ou un B-arbre à la place d'une bête liste, y aurait moyen de le couper en deux et d'effectivement pour voir paralleliser la chose. en gros si 1 demande de verifier 5 qui demande de verifier 3 et que 2 demande de verifier 8 et 8 de verifier 4 on aurait une structure genre :
 

 
et couper sur la racine assure de pouvoir verifier deux sous-ensemble disjoints.

machin alpha, beta, toussa, y a de toutes façons une méthodologie pour travailler ce genre de problème

ouais aussi ,un alpha-élagage

Un machin qui en case x te demande d'aller en case y et répète l'opération en boucle, ça commence à ressembler vachement à une machine de turing quand même
 

aussi

 
jvois pas ou ta un gain de perfomance dans ton example  consomateur/fournisseur, sachant que windows fait deja exactement la meme chose lorsque tu appele les api qui permettent decrire sur le disque , il fait egalement le meme systeme (un thread soccupe daller ecrire des qu'il peut ) , et ce dans les deux sens...  (rien avoir avec la cache materielle du disque )

 
Mise à part si le C++ prend des libertés que le C# ne prend pas (l'inverse ne m'étonnerait pas, mais dans ce sens...) les instructions de base d'accès disque sont synchrones.
Elles sont d'ailleurs synchrones pour une bête et simple raison : tu lances l'enregistrement un byte[] sur le disque.
Si à la ligne suivante, tu t'amuses à détruire l'objet (ce qui est relativement logique) il fait quoi ton programme ? Je doute que les fonctions de base laissent un risque aussi important... Aucun développement ne serait possible sans utilisation de threads. Et maintenant, c'est bien beau, si c'est assynchrone... Mais pour un programme basique, tu crois que tout le monde va se faire chier à faire un callback pour décider à quel moment vider proprement le byte[] ? Vas-y la seconde page de n'importe quel bouquin de C++...
Après l'exemple sprintf("hello world" ), t'as 4 pages de code pour l'exemple deux, qui consiste à écrire "hello world" dans un fichier
 
A partir de là, quand tu lances l'écriture d'un flux volumineux sur le disque, ton programme ne fait plus rien jusqu'à ce que ce soit terminé.
 
Il y a certainement parmis les instructions de base, des méthodes assynchrones, mais elles utilisent bien un thread séparé...

Si, il y a bien un gain de performance, et d'ailleurs je trouve que pour une fois MagicBuzz l'explique plutot correctement. Le fait de threader ton programme te permet de pipeliner l'ecriture et le calcul : ainsi tu ecris le resultat du coup d'avant pendant que tu calcules le resultat du coup d'apres.  

Un read est synchrone, pas un write. Donc c'est une affirmation fausse.

tout à fait.

ben ça doit être gai...*
 
pis alors le coup du read synchrone mais pas le write, c'est trop fort...
donc j'ai le droit de travailler pendant que le prog écrit, mais pas pendant qu'il lit ? si ça c'est pas du mongolisme primaire...
 
si y'a pourtant bien un truc qui devrait être assynchrone, c'est bien la lecture, rien ne m'empêche de commencer à traîter ce qui est déjà lu pendant que je continue de charger mon fichier...
 
 
* : donc vous confirmer que si j'écris sur le disque le contenu mémoire situé à une adresse (un byte[] passé par référence par exemple), et qu'un fois écrit je commence à modifier ce dernier (genre le détruire puisqu'il ne me sert plus à rien), alors je vais écrire n'importe quoi dans mon fichier ?
 
que windows gère son propre cache logiciel, et diffère les écritures, je veux bien. mais quand j'écris 2 Go d'un coup dans un fichier, ça me ferait bien mal que la milliseconde suivant l'appel j'aie de nouveau la main dans mon programme

genre style t'as un truc entre ton programme et ton disque dur qui s'appelle un quernail. Quand tu fais un appel système genre write, il copie le buffer de données, lance le travail, et te rends la main. Inutile de bloquer un programme sur un write tant que les buffer de destination de sont pas plein (genre pipe, socket où ça va se produire rapidement).
 
Bah donc tu vas avoir mal : ça prendra un peu plus que quelques millisecondes, mais si t'as suffisemment de RAM, et bien ça ira vite.
 
C'est tellement asynchrone que dans toutes tes API, tu vas trouver des méthodes sync/fsync ...