Un projet pour exploiter au mieux le multicore

eLShaman a écrit:

MikeRowSoft a écrit:

KoV a écrit:
Je rappelle que le programmeur ne choisis pas le core d'exécution et encore heureux, car avec la variété des processeurs mono 2 3 4 etc cores il n'en aurait pas fini. C'est ensuite à la compilation et à l'exécution que le système se doit de bien répartir les threads de façon équitable entre chaque thread.
Créer des threads n'est pas plus compliqué qu'autre chose, les faire synchroniser cela demande un peu de réflexion, mais sans plus. Le tout c'est de bien découper son programme.

Si les logiciels ont du mal à se mettre au multi-core c'est avant tout de la faute des concepteurs et aussi des anciens codes sources/conceptions sur lesquels reposent les logiciels.
Par exemple un photoshop n'est pas réécris totalement à chaque version. Donc pour une optimisation multi cores ce la ne se fera pas en quelques jours.

Il est possible pour le programmeur et même utilisateur de choisir quel processeur il doit être utilisé pour les traitement (ex : AVS pour l'encodage vidéo).

Cette blague... Le choix d'un core n'est pas évident pour un utilisateur à moins qu'il n'y ait que des programmes qui dorment et soient concentrés sur un core, dans le cas contraire c'est un choix au hasard.
Quant à un choix par un programme, ça va être marrant de voir chaque programme se baser sur la position des autres : j'imagine que les programme vont passer leur temps à aller de core en core...

Pour AVS lors de l'écriture du script, il est possible pour l'exécution des filtres de choisir quel CPU l'on souhaite qui face le traitement. un peu comme MPI ou tu peux demandé à ce que un calcul soit fait sur une machine bien spécifique... Le choix n'est pas évident quand on est pas programmeur... Pourtant AVS n'est pas toujours utiliser que par des programmeurs, mais qui eu on suffisamment de logique pour savoir comment agencer des tâches!!!

MikeRowSoft a écrit:
Il est simple de savoir combien de cores dispose un CPU, le moins utilisé, de façons a lui donnée du travail... Mais encore faut-il que le code soit écrit pour s'adapter à l'existence et exploitation de plusieurs cores, du code "auto adaptable" indépendant des contraites matériels,le travail du programmeur donc... (Les programmeurs créent aussi des compilateurs). La création de thread est simple, oui, mais encore faut-il que cette thread soit intelligemment distribué par le programme ou le système d'exploitation...

Je n'ai rien compris. Tu le refais en français et avec une seule idée par paragraphe, STP ?

Même Principe que le scheduler utilise, une portion de programme capable de s'adapter en fonction des ressources d'on il dispose... répartition des traitements... Chaque thread doit pouvoir être exécuté de façons distinct sur l'un ou l'autres des processeurs (On apprend celà au niveau BAC +1 en informatique... Tu devrait donc savoir sa...)

MikeRowSoft a écrit:
Le vrai multi-tâche n'existe pour le moment pas, surtout avec l'architecture des OS actuelle...
Exemple avec le photoshop que tu stipule, pourquoi les traitements sur image sont-ils fait par le CPU et mon le GPU?

Il existe du multi-tâche depuis plus de vingt ans...
Quant au traitement d'image sur GPU, ça se fait sous 2 conditions :
1/ que les aller/venues CPU/GPU n'augmentent pas le temps d'un traitement par rapport à celui sur un seul CPU ;
2/ que l'apparaition d'erreurs sur l'image produite par un GPU ne soit pas problématique (ex: pas de défauts sur une image médicale).

Le windows que je suppose que tu utilise est pas du vrai multi-tâche... ce sont des tâches qui s'exécute de façons séquentiel mais si vite quel donne l'impression de multi-tâche... Quand deux tâches sont exécuter une tâche est traité, mi en pause, il y a traitement de l'autre tache, puis mise en pause, puis continuation du traitement de la première, ainsi de suite... multi-tâche, mais pas vraiment... juste du scheduling... Actuellement il est en développement des technologies pour le calcul de données physique sur GPU, sans que le CPU n'ai a faire de traitement, donc les échanges CPU/GPU... Le seul accès qui devrait être fait par le GPU est sur la mémoire système dans le cas ou il n'y aurait pas suffisamment de mémoire sur la carte graphique... Beaucoup des erreurs peuvent être résolu par le flash du firmware de la carte graphique... Tu as déjà entendu parler ou lu des rapport de carte graphique bugger aussi souvant que les CPU? La seul différence vrai différence que je conçois entre un GPU et CPU actuellement est que le GPU est utilisé de façons spécialisé alors que le CPU est utilisé de façons généraliste, mais cela reste mon opignons aussi réservé soit-elle.

MikeRowSoft a écrit:
Ou encore des calculs en traitement audio qui devrait être fait par les cartes son quand elle dispose d'accélération matériel, mais traitement qui très souvent sont fait par le CPU...

Quels traitements ?

Ajout de bruitage, d'effect et autre en temps réel, suppression ou ajout de bruit, le traitement et l'édition audio l'usage de puce comme EMU10K1, EMU10K2, EMU20K1 permet de programmer directement la puce audio...

MikeRowSoft a écrit:
Sur ce point tu as entièrement raisons. Maintenent que les GPU sont dit hautement programmable, va falloir écrire du code nouveau pour que chaque périphérique fasse le travail pour lequel il est dédié (ex : avec vista avec DX10 où la séparation des processus son devrait permettre de la conception de carte son avec une gestion réellement 100% matériel [sans usage CPU] ou à un autre core du CPU dans le cas de carte son pseudo logiciel de façons a soulager le processeur principal qui à déjà beaucoup de processus actif).

Tu vas être déçu d'apprendre que le mixage du son est en software et qu'il y a très peu de chances pour qu'il aille vers le matos (parce que le software est «plus programmable» et «moins cher»).
Quant aux GPU, désolé là aussi de te l'apprendre, mais ils ne sont pas magiques. La programmation dessus n'est pas du tout évidente, même pas pour jouer un peu avec des calculs d'illumination.

Heu... Que fait la Xonar D2X a ton avis? Traitement des instructions DX10 en Hardware alors que la couche audio de DX10 est cessé être software ... Le software est traité par le CPU... Pourquoi devrait-il en être de même si la carte son dispose d'un DSP capable de faire c'est traitement... Pour ton expérience de la vie future... Ce que tu estime difficile ne l'est peut être pas pour un autre...

MikeRowSoft a écrit:
Les projets Linux auront bien plus de chance de prendre une très gros avantage face au distribution payante du fait des entrées possible vers XGL, AIGLX pour l'usage des ressources matériel graphique et ALSA entre autre pour le sonore...

Hein ?

Oui, l'avantage de l'open source, il est possible de faire une proposition en apportant du code et des idées qui pourront être réutilisé par tous... Tu connais des applications graphique qui utiliserait OpenGL pour faire un traitement sur une image? et que ce traitement soit fait sur la carte graphique? pourtant un effect blur n'est pas complique et un ghauss prendrais surement mois de temps sur un gpu que cpu... pourquoi utiliser le cpu alors que le gpu en est capable et qui plus est se trouve être le périphérique spécialisé pour cela?

Et pour le reste du commentaire, j'ai zappé...

Pas étonnant... Cela va être difficile à contre-dire...

(Réponse en gras italique dans le texte)
Edité le 03/05/2008 à 21:48

Proutie66 a écrit:

euh.... comment ca?
Le parallelisme est lié au software....
Ils doivent deviner en avance tes besoins? :etonne2:

Non mais que chaque processeur répartissent de manière équitable les calculs nécessaires, sans perte de temps

je crois que tu négliges l'interdépendance des taches ...

Ne vous méprenez pas... ce n'est pas parce qu'ils ne savent pas programmer sur du multicore, mais juste parceque ça demande un peu plus de temps: "le temps c'est du pognon", les grands patrons chialent parceque el programme va sortir 2 semaines plus tard que prévus, alors hop on code ça pour du monocore...

Très bonne initiative que ce projet, mais une fois de plus pour se mettre au service de ces gros faignants avares...

V3nom a écrit:
Ne vous méprenez pas... ce n'est pas parce qu'ils ne savent pas programmer sur du multicore, mais juste parceque ça demande un peu plus de temps: "le temps c'est du pognon", les grands patrons chialent parceque el programme va sortir 2 semaines plus tard que prévus, alors hop on code ça pour du monocore...

Très bonne initiative que ce projet, mais une fois de plus pour se mettre au service de ces gros faignants avares...

Entièrement d'accord avec toi, sauf sur un point...
Il y a de "gros faignants avares" qui savent données une chance à l'innovation pour peu que l'information d'un projet leur soit parvenu.
Edité le 02/05/2008 à 21:06

V3nom a écrit:
Ne vous méprenez pas... ce n'est pas parce qu'ils ne savent pas programmer sur du multicore, mais juste parceque ça demande un peu plus de temps: "le temps c'est du pognon", les grands patrons chialent parceque el programme va sortir 2 semaines plus tard que prévus, alors hop on code ça pour du monocore...

Très bonne initiative que ce projet, mais une fois de plus pour se mettre au service de ces gros faignants avares...

Ces avares comme tu le dis ci-bien (ah là là les patrons, tous les mêmes) ont un budget et un planning à respecter pour la simple et bonne raison que le développement d'un programme coute très cher. Est tu prêt à payer le double ou le triple de ton jeu favori pour avoir un programme au mieux 50% plus efficace ? En multi-thread c'est encore plus vrai, car malgré ce que tu peux penser, non le développement d'un programme multi-threadé n'est pas à la portée de tout le monde, essaye tu verras ;)

Quand je dis 50% je pèse mes mots en plus, car à part quelques cas assez rares, seule une partie d'un algo est parallélisable, donc les performances ne sont pas toujours à la hauteur des espérances, ni du surcout investi

p0uc a écrit:
En multi-thread c'est encore plus vrai, car malgré ce que tu peux penser, non le développement d'un programme multi-threadé n'est pas à la portée de tout le monde, essaye tu verras ;)

Tout comme la programmation en monocore :D tout comme n'importe quel boulot "bien fait" sur cette planète :ane:

S'ils ont choisit de faire de la programmation, tu ne trouve pas bizarre qu'ils restent toute leur carrière dans une façon de bosser dépassée en 5 voire 10 ans ? C'est la loose d'aller en formation quelques jours pour etre au top pour sa boite ? (me parle pas de cout hein ;))

Et personne jamais n'arrivera à me convaincre que le fait d'être patron empêche de réfléchir :neutre: (quoique je me demande de plus en plus vu le paquet que je vois) mais t'inquiètes je suis pas naïf "malgré ce que tu peux penser" :D, par contre ce que jamais personne n'avoue dans notre belle société de conso, c'est qu'il vaut mieux investir à très court terme, pour avoir un max de blé même si le produit est merdique, plutot qu'à long terme, parceque ça rapport moins que rien les premiers temps... et pourtant ça serait profitable pour TOUT le monde ;) (réfléchit-z... réfléchy-z... réfléchis-y... bref, souvient-t'en-z'en :ane:)
Edité le 02/05/2008 à 20:34

V3nom a écrit:

p0uc a écrit:
En multi-thread c'est encore plus vrai, car malgré ce que tu peux penser, non le développement d'un programme multi-threadé n'est pas à la portée de tout le monde, essaye tu verras ;)

Tout comme la programmation en monocore :D tout comme n'importe quel boulot "bien fait" sur cette planète :ane:

S'ils ont choisit de faire de la programmation, tu ne trouve pas bizarre qu'ils restent toute leur carrière dans une façon de bosser dépassée en 5 voire 10 ans ? C'est la loose d'aller en formation quelques jours pour etre au top pour sa boite ? (me parle pas de cout hein ;))

Et personne jamais n'arrivera à me convaincre que le fait d'être patron empêche de réfléchir :neutre: (quoique je me demande de plus en plus vu le paquet que je vois) mais t'inquiètes je suis pas naïf "malgré ce que tu peux penser" :D, par contre ce que jamais personne n'avoue dans notre belle société de conso, c'est qu'il vaut mieux investir à très court terme, pour avoir un max de blé même si le produit est merdique, plutot qu'à long terme, parceque ça rapport moins que rien les premiers temps... et pourtant ça serait profitable pour TOUT le monde ;) (réfléchit-z... réfléchy-z... réfléchis-y... bref, souvient-t'en-z'en :ane:)

Je sais pas si tu as investi sur dans Windows 98 et surtout si tu t'en sers toujours? Pourtant il n'y a que dix ans...
Si tu as installer linux... celle qui est installer sur ton ordinateur et que tu utilise actuellement est la dernier version ou celle qui t'a fais découvrir linux?
C'est dans la nature humaine de changer certaine chose souvent et de garder d'autre plus longtemps...
Chacun y trouve sont itéraient dans cette société de consommation, le patron à vendre son produit et en tirer des bénéfices et le salarier à avoir un salaire.
Edité le 02/05/2008 à 21:52

oui nous voudrions que les jeux exploite enfin toute les puissances des multi-coeur et pourquoi pas aussi du fait qu'ils soit 64 bits .
on n'oublie trop souvent que les applis sont 32 bits !!!

Ça ne veut rien dire, tout dépend du type d'application.

MikeRowSoft a écrit:
C'est dans la nature humaine de changer certaine chose souvent et de garder d'autre plus longtemps...

la phrase vague par excellence ? :D (c'est dans la nature humaine de se lever tôt le matin... et des fois de faire la grasse mat' aussi :ane:)

j'utilise principalement winxp, mais régulièrement je reviens à win98, 95 et même dos (oui je saute win3.11 hein :D), je commence aussi à lorgner sur vista pour pouvoir aider ma clientelle, et linux par pure curiosité (car aucune utilité pour moi)... Maintenant je vois pas où tu voulait en venir à savoir ça...
Quant aux intérêts patron/salarié... heuu :D ... tu veux vraiment qu'on en discute de ça ? ;) (en privé pour pas lasser tout le monde)

ps: surtout que je parlais entreprises/clients
Edité le 02/05/2008 à 22:23

V3nom a écrit:

MikeRowSoft a écrit:
C'est dans la nature humaine de changer certaine chose souvent et de garder d'autre plus longtemps...

la phrase vague par excellence ? :D (c'est dans la nature humaine de se lever tôt le matin... et des fois de faire la grasse mat' aussi :ane:)

j'utilise principalement winxp, mais régulièrement je reviens à win98, 95 et même dos (oui je saute win3.11 hein :D), je commence aussi à lorgner sur vista pour pouvoir aider ma clientelle, et linux par pure curiosité (car aucune utilité pour moi)... Maintenant je vois pas où tu voulait en venir à savoir ça...
Quant aux intérêts patron/salarié... heuu :D ... tu veux vraiment qu'on en discute de ça ? ;) (en privé pour pas lasser tout le monde)

ps: surtout que je parlais entreprises/clients

Je vois qu'il y en a qui on en eu un philosophe qui sommeil ;)
C'était juste pour répondre sur les investissements à court et long terme. En une phrase on obtient :
Bien que l'on achète des produits que l'on possède à long terme, leurs utilisation n'est que court terme...

De savoir que le patron est une banane et que le salarié se nourri du jus extrait de ce fruit afin de vivre ou que le patron se délecte du jus de connaissance extrait de son salarié est une bonne conception de la vie (valable aussi pour les relations entreprises/clients où les entreprises on ce besoin de jus de banane que seul les clients peuvent leurs donner et où le client vient chercher ce jus de banane qui lui permet de s'épanouir).

ps: pas utile d'en rediscuter en privé ;)
Edité le 03/05/2008 à 19:16

Le multithreading c'est malsain pour les programmeurs, faut aussi penser que ces braves types n'ont pas envie de tout réapprendre et de se compliquer la tâche (haha) pour je ne sais quoi. Faut arrêter les gars avec votre multithreading, une montée en fréquence bien gérée en utilisant la théorie de Neuwemard et puis c'est bon.

Je crois qu'à notre époque la raison se fait de plus en plus rare :/

Si ça peu aider aussi a faire avancer les choses...mais 3ans heu...long.D'autre boîtes indépendantes devraient s'y mettre aussi ça ne serait que bénéfique a la programmation.
Ca reste un bonne news...

je comprend mieux maintenant, pourquoi un des developpeurs de jeux video pour playstation3 disait dans une vidéo sur youtube, que developper sur PS3 etait 20 fois plus dur que developper sur PS2, les habitudes devaient être changés, tout une methode de travail à repenser.

XData a écrit:
Le multithreading c'est malsain pour les programmeurs, faut aussi penser que ces braves types n'ont pas envie de tout réapprendre et de se compliquer la tâche (haha) pour je ne sais quoi. Faut arrêter les gars avec votre multithreading, une montée en fréquence bien gérée en utilisant la théorie de Neuwemard et puis c'est bon.

Je crois qu'à notre époque la raison se fait de plus en plus rare :/

:MDR

Mettons tous un frein à l'immobilisme ! (comprenne qui pourra :ane:)

C'est un peu hélas la mode générale actuelle, Education Nationale en tête de proue : ne rien changer aux traditions séculaires, ça risquerait de s'améliorer :p (bon là c'est un peu le camarade syndiqué qui sommeil :ane: mais après faut pas s'étonner que la France s'enlise... pas pour tout le monde c'est vrai semble-t-il...)

Mettons tous un frein à l'immobilisme ! (comprenne qui pourra :ane:)
"
C'est un peu hélas la mode générale actuelle, Education Nationale en tête de proue : ne rien changer aux traditions séculaires, ça risquerait de s'améliorer :p (bon là c'est un peu le camarade syndiqué qui sommeil :ane: mais après faut pas s'étonner que la France s'enlise... pas pour tout le monde c'est vrai semble-t-il...)"


+10

Une etude sur 3 ans..? Au vue de la vitesse d'évolution du matos PC, il y auraun vrai décalage.

Concernant le multi core, le problème n'est pas faire un proramme full multi core, mais d'un faire compatible single core + optimisé multi core..sachant que la philosophie de dev n'est pas d tout la même

Je ne parle pas pour les 3 ou 4 coeur, mais seulement pour les 2 coeurs...

Je ne me plaindrai pas que la majorité des programmes soit mono-tache...

Je me rends compte que depuis que j'ai un dual-core, je n'ai plus de ralentissement quand je fait tourner plusieurs applications monotâche en même temps.
Je n'arrive même plus à bloquer la souris ou le clavier sous windows XP comme je l'ai si souvent fait avec un MonoProc des que les ressouces CPU commence à manquer...

Ce qui me ferai peur à les voir developper tous des programme multi core, c'est que leur gestion soit moins bonne que celle de Windows, et qu'on se retrouvent avec des Freezes comme avant en monoproc à cause d'un processus trop gourmand...

:-) Pensez aux utilisateurs de Vista, à qui il faut déjà 1 Core complet pour faire tourner l'OS et qui a déjà beaucoup de mal à laisser l'autre Core pour les applications ce qu'il se passerait si on disait à ces applications qu'elles peuvent utiliser les 2 cores ! :-)

Mettre les applications en multi core sera très certainement une bonne chose, mais ça dépend beaucoup du type d'application (Toutes n'en ont pas besoin), et de la qualité de la gestion des tâches qui sera implémenté...

Bon un petit retour rapide sur plusieurs points:
Les GPU sont déjà massivement parallèles. Pas la peine de parler de SLI/Xfire : un GPU est composé de dizaines de pipelines traitant chacun en parallèle le même triangle/shader sur plusieurs pixels pour accélérer le calcul (voir même sur certaines radeons, traitant plusieurs shaders&triangles en parallèle).

Paralléliser un jeu sur plusieurs core n'est pas spécialement difficile : il suffit de calculer certaines unités sur chaque thread/core.
La grande difficulté est le jeu en réseau : le jeu doit être déterministe et s'exécuter de la même façon sur chaque console ou PC! Ce qui signifie que l'on ne peut pas laisser aléatoire l'ordre d'exécution de la simu entre les ordinateurs : vous seriez contents si sur le PC "A" votre tir serait calculé avant qu'un ennemi n'ait bougé, le touchant, mais que sur le PC "B" l'ennemi aurait été déplacé en premier, évitant votre tir? Qui aurait raison?

parfois moins rapide en 64bits... n importe quoi

si un soft peu etre moins rapide sous vista 64 que sous vista 32 c est justement qu il est 32bits 100% le dis soft et est donc lancé dans un espace dédié independant (c'est les processus svchost.exe)
pour qu'en cas de plantage il n'y ai que CE soft qui plante

alors que sous xp64 sauf erreur tout les soft 32 etait regroupé dans le meme espace (donc en cas de plantage d'un soft 32... ça entrainait souvent tout les soft 32 dans le plantage avec)

donc peut y avoir une baisse LEGERE de perf du fait de "securiser" le dit soft 32bit

maintenant lorsqu'il s agit d'un soft ecris proprement en 64bits le gain avec les cpus actuel peut etre jusqu'à 15% en ordre général... désolé mais ça reste une belle progression de performance

et qui pourrait augmenter de maniere exponentiel si en plus on developpait la programmation parallele (bref du multicore 64bits et pas juste du multicore 32bits le 64bits il est dans tout les core hein)

je tiend à rappeler que de nombreux registre tres bien exploité dans certains domaine sont 64bits voir 128bits et personne s'en plein (notamment les registre SSE dans le domaine de traitement video)

ensuite tirer la langue à 15% de perf en + en 64bits alors que de toute facon vous payé un cpu qui fait du 64bits à la demande... faut etre debile

j achete un cpu 64bits mais non je crache sur 15% de perf en plus que j'ai payé de toute facon

vista 64 il est au meme prix que vista 32 hein (sauf si vous achetez vista 32 là faut commander le cd vista 64 par la suite pour 15€)

vista 64 il fait tourné les appli 32 et 64... vista 32 il fait tourné que les appli 32

apres si certains se penchait vraiment sur les dossier d architecture x86-64 comparé au x86

vous verriez que si le 64bits ce developpait l'architecture x86-64 à une belle de marge de progression que ne peut avoir le x86

marge que les fondeurs amd et intel n'ont pas encore exploité... tout simplement car il y avait pas matiere à le faire car le marché n'est pas encore pret

(ça sert à rien de faire un cpu qui est 50% plus perf en 64bits qu'en 32nbits si y a que 5% des utilisateurs qui peuvent en profiter... faut mieux exploiter la possibilité de pouvoir ajouter plus de transistor grace à de nouvelle finesse de gravure

l'evolution des registre SSE est un bel exemple... il va dans le sens ou beaucoup de monde exploite les registre SSE sans meme sans rendre compte

maintenant avec les macintel et le dernier mac os leopard
il n'est pas impossible que nehalem marque encore plus le pas de puissance entre le x86 et le x86-64

car là il y a un marché reel du 64bits qui n existe pas encore reellement sous windows

microsoft à fait une connerie il aurait du ne sortir que vista en version 64

et entendre des bruit comme quoi microsoft compte proposer une version 32bits de "seven"

c'est vraiment debile de microsoft si il persiste à proposer un "seven" 32bits

pour ceux qui ont fait le pas à vista 64
les preuve sont là il n' ya pas d'incompatibilité majeur à vista 64
si un prog 32bits ne marche pas sur vista 64 (cas plutot rare) c est que l'editeur ni met pas du sien

mais dans la majorité des cas les soft 32bits n'ont pas eu besoin de mise à jour pour tourner sur du vista 64 bits

microsoft à bien fait les choses avec cet OS sur le point de la compatibilité... et il n'y avait pas à attendre le SP1

de plus cette possibilité d'envoyer les eventuel rapport d erreur à microsoft dans vista, montre clairement la volonté d'en faire un OS bien plus robuste que ne l'était XP