Fox Delta
Bonjour tout le monde,
Ce post part en fait d'une constatation: l'utilisation d'une distribution x86_64 sur un processeur multi-cores n'apporte finalement que peu d'ameliorations de performances par rapport a l'utilisation d'une version i386.
Je ne suis pas suffisamment pointu dans ce domaine pour en connaitre l'explication exacte, mais je soupconne que les commandes que l'on utilise tous les jours ne sont en fait pas capables d'utiliser plusieurs coeurs a la fois.
D'ou ma question: devant la generalisation de telles architectures, existe-t'il un projet visant a reecrire ces commandes en integrant des instructions de type openMP ? Vu ce qu'est Linux, ce serait un projet titanesque, mais vu l'ampleur de la communaute, ca ne serait pas impossible...
Bonne soiree
Renault
Le gain de performance est réel surtout pour des calculs lourds comme F@H, l'encodage, le multimédia, l'archivage de fichiers. Ce n'est pas en naviguant sur le Web que tu trouveras des amélioration d'autant que le CPU est peu utilisée pour cela.
Pour les logiciels cités, bien que j'en fais un usage normal le gain de temps est minime mais là, et d'après les tests de eddy33 c'est de l'ordre de 10-15% maximum ce qui n'est pas négligeable.
Il est vrai que aujourd'hui peu de logiciels sont optimisés, et c'est normal car l'architecture mono-cœur reste dominante surtout chez les OS et que ça demande un vrai travail. ceci dit je crois que certains logiciels libres font des optimisations minimes, mais je doute qu'une refonte en profondeur pour l'exploiter se fasse avant la mort quasi-définitive du 32 bits (et avec l'arrivée des téléphones portables, PDA ou portables low-cost, ça va continuer longtemps). On ne peut pas le faire avant ce moment là car il faudrait soit 2 branches totalement distincts ce qui est problématique ou alors mettrait sur le carreau beaucoup d'utilisateurs. Ceci dit Linux le fait je crois mais d'un côté de la part du noyau, le pilier de la pyramide, c'est nécessaire.
Ceci dit, pour accélérer le processus, faites et propagez la parole suivante :
GNU/Linux (et même Windows il paraît) permet aujourd'hui d'utiliser le mode 64 bits sans faire de concessions et sans plus de problèmes que le 32 bits comme ce fut le cas à une époque. C'est en changeant les mentalités et les faits que ça évoluera.
Fox Delta
En fait, j'utilise un logiciel d'analyse de donnees sismiques compile pour une architecture 64bit, mais ne comportant pas d'instructions de type openMP. Ce qui est rageant, car du coup, l'utilisation de mon processeur est limitee a 50%, soit un seul des deux coeurs. Je travaille en ce moment a ameliorer mes propres codes de calculs pour exploiter mes deux coeurs, mais ce n'est pas gagne.
C'est donc ca qui m'a fait penser au sujet du message.
Je suis tout a fait d'accord avec toi sur le fait qu'une telle refonte provoquerai la creation pure est simple de branches distinctes. Ce qui ne serait pas forcement une bonne chose.
Lorsque j'ecrivais le message, je pensais en particulier a la commande diff qui est en train de travailler chez moi sur des repertoires qui font en gros 300Go. Du coup ca prend un moment, mais je me suis rendu compte que dans le cas particulier de cette commande, le facteur ralentissant n'est pas l'utilisation de la puissance de calcul, mais la vitesse d'acces au disque...
Refuznik
Intel et amd ont donnés les specs pour optimiser l'utilisation des multi-proc ils ne restent plus qu'à coder 😉
Pour la commande dif, une utilisation de ton soft via une bdd ne serait il pas plus intéressant ?
Pikachu_2014
Remarque intéressante, d'autant plus qu'elle fait allusion à OpenMP, mais sur ce dernier point je serais prudent.
L'utilisation des clauses OpenMP ne se fait pas n'importe comment : elle nécessite une connaissance fine des algorithmes implémentés par le programme. On ne parallélise pas n'importe quel boucle (attention aux boucles dont les tours sont interdépendants ; de plus, il convient d'estimer le gain apporté par une parallélisation : ce qu'on gagne en répartissant la tâche, on peut le perdre en temps de communication entre les processus ; enfin le nombre de tours d'une boucle potentiellement parallélisable doit être estimable AVANT compilation, ce qui exclut de fait les boucles while). Par ailleurs l'API OpenMP ne concerne que Fortran et C/C++.
Bref l'optimisation OpenMP ne se fait pas en un claquement de doigts, et nécessite un peubeaucoup de boulot pour de grosses applications.
Cependant, Fedora 9 intègre pour C++ la dernière STL de GNU, dont nombre de fonctions (e.a. celles de manipulation de vecteurs) ont été « OpenMP-isées » 🙂.
Fox Delta
Merci pour vos contributions,
Pour la parallelisation, je pensais suivre un cours a l'IDRIS lorsque j'aurai commence ma these. Je connais un gars qui avait suivi ce cours et en etait tres content.
pascalp
Le problème c'est que la parallelisation est necessaire principalement dans les domaines scientifiques. Hors c'est les scientifiques qui font ces softs et c'est pas des informaticiens, du coup ça coince.
J'ai utilisé openmp, dans les rares cas ou ça marche, j'avais trop d'overhead ce qui reduisait l'avantage à néant. ça necessite de solides connaissances en programmation.
Je sais ou ça doit marcher, le seul soucis c'est que c'est une boucle de minimisation -> while 🙁
ça va s'améliorer avec la disposition de bibliothèques threadés tel que fft, blas et lapack. Mais bon, c'est pas parfait... En fait si, ça marche rudement bien si on utilise le compilo intel avec mkl et qu'on utilise massivement les dites biblios 😃
En ce qui concerne les vecteurs, d'après ce que j'ai lu, c'est pas simple non plus. Il faut faire attention au code source. Une histoire d'alignement à ce qu'il parait... (entre autre).
C'est sur que le gas qui sort analyste programmeur ou autre devrait pouvoir threader pas mal de chose. Mais dans mon domaine, il a aucune chance d'y bosser.
Répartis les données sur 2dd différents et lance 2diffs :p
Tiny-Fedora
Si l'on regarde du côté de la concurence: MacOS X, on voit qu'Apple mise beaucoup sur le multicore (jusqu'a 8 cores!!) et sur l'architecture 64bit.
Donc bon, on peut quand même penser que leur OS exploite quand même assez bien ces technologies.
edit: Si l'on regarde ici (
http://www.apple.com/macosx/snowleopard/) c'est encore plus flagrant :-p
Renault
D'un autre côté, Mac OS X c'est fait pour une seule machine, ou une gamme qui sont toutes 64 bits maintenant. C'est dans la logique des choses qu'ils optimisent car eux ils peuvent faire une seule branche de développement en optimisant car c'est la seule architecteure disponible.
GNU/Linux c'est quand même une trentaine d'architectures différentes, et si les logiciels doivent suivre derrière ça risque d'être dur.
Fox Delta
@pascalp: C'est exactement mon probleme... Je suis scientifique, je fais des calculs lourds, et j'aurai vraiment besoin de cette fameuse parallelisation. Mais meme si j'ai une formation a la programmation, je ne suis pas analyste programmeur, et donc c'est tres difficile de pondre une bonne programmation parallele...
Je regarderai du cote de mkl et du compilateur Intel. J'utilise a l'heure actuelle le Intel Fortran.
En parlant du compilateur Intel, je tiens a signaler que la license a ete modifiee:
Avant, il etait gratuit lorsqu'on n'en faisait pas une utilisation commerciale (i.e. on ne vend pas les softs compiles avec...). Mais maintenant, il est gratuit uniquement si l'utilisateur n'est pas paye pendant qu'il l'utilise... Ce qui restreint d'un coup les conditions d'utilisation. Bon comme on dit, pas vu pas pris... Mais il vaut mieux etre au courant.
eddy33
Salut.
Développe tes programmes en utilisant les threads. Le noyau est capable d'attribuer un thread à un core...
++
Refuznik
Comme dit eddy33, le noyau supporte. Le reste vient de la programmation du soft, jette un coup d'oeil sur la parrallilesation chez intel si ma mémoire est bonne, ils ont monté un site pour ça.
Fox Delta
Merci beaucoup. Je me mets a la tache.
n1ck0
Fox Delta wrote:Bonjour tout le monde,
Ce post part en fait d'une constatation: l'utilisation d'une distribution x86_64 sur un processeur multi-cores n'apporte finalement que peu d'ameliorations de performances par rapport a l'utilisation d'une version i386.
Je ne suis pas suffisamment pointu dans ce domaine pour en connaitre l'explication exacte, mais je soupconne que les commandes que l'on utilise tous les jours ne sont en fait pas capables d'utiliser plusieurs coeurs a la fois.
D'ou ma question: devant la generalisation de telles architectures, existe-t'il un projet visant a reecrire ces commandes en integrant des instructions de type openMP ? Vu ce qu'est Linux, ce serait un projet titanesque, mais vu l'ampleur de la communaute, ca ne serait pas impossible...
Bonne soiree
c'est exact elles sont monothreadées mise à part gcc evidement...
irqbalance gere la charge ainsi deux gros processus seront sur un core separer
tant dis qu un seul sera 70-80% sur un core et 20-30% sur l autre
mais je pense que c est du au switch rapide du processus entre les deux avec toute fois plus de temps passer sur un core
Fox Delta
Oui, j'ai constate quelque chose comme ca, avec un seul processus lance, l'ordinateur a tendance a switcher entre les deux coeurs de temps en temps.
bioinfornatics
celà signiofie que l'on peu modifier le noyau pour le paralléliser et pour le rendre encore plus rapide intéressant
Fox Delta
Tu penses qu'il suffirait d'activer une option dans le noyau et de le recompiler ? J'en doute. Je trouve qu'il fait deja pas mal son travail en distribuant les processus entre les deux coeurs...
En fait, pour qu'un programme soit parallelise, il faut vraiment y penser au moment de sa programmation. Meme si on possede un kernel qui supporte la parallelisation, ca ne servira a rien si le programme ne comportement pas d'instructions de type openMP.
shnoulle
Il me semble que ffmpg utilise les multicoeurs.
Fox Delta
Pour le verifier, il suffirait de chercher les instructions correspondantes dans les sources. grep est notre ami, youpi !