Europe: la condamnation de Microsoft est confirmée

taigaIV a écrit:

Avec l arrivee des cpu multicore la donne change. Que les unites de calculs soient sur le meme chip ne changent pas grand chose aux algo de gestions du multitache (pas grand chose ne voulant pas dire rien).

oui mais l'idéal étant de lancer les tâches en parallèle (c'est à dire 2 tâches dans le même cycle d'horloge), dés lors que les cores ne sont vu que comme un seul CPU ça devient impossible :neutre: A moins que j'ai pas compris comme ça fonctionne et là j'suis preneur d'info en lieu et place de remarques désobligeante :jap:

megadub a écrit:
Bon, on est donc bien d'accord, j'ai pas raconté de conneries :o

Tout au plus, j'aurais dû préciser que pour les particuliers qui paye leur license et sont donc souvent en familial, Windows gére le multi-CPU comme un goret... c'est à dire qu'il ne le prend pas en compte :neutre:

m'enfin... peu importe... quand j'affirme quelque chose c'est qu'une source me le confirme et sinon je suppose parce que je ne prétends pas avoir la science infuse :neutre:

---

en tout cas, je te félicite pour ta patience pour avoir cherché ce post :super:

Non, soit tu as un super multi-cpu soit tu ne l as pas, il n y a pas de milieu. Ensuite l implementation de ce support peut etre plus ou moins efficaces. Dire "si tu as 2 CPU, tu as un thread sur chacun d'eux mais ils sont quand même exécuté à la suite" ne correspond pas a ce que l on appel le support SMP (a moins d etre franchement tordus de la part des devs).

megadub a écrit:

taigaIV a écrit:

Avec l arrivee des cpu multicore la donne change. Que les unites de calculs soient sur le meme chip ne changent pas grand chose aux algo de gestions du multitache (pas grand chose ne voulant pas dire rien).

oui mais l'idéal étant de lancer les tâches en parallèle (c'est à dire 2 tâches dans le même cycle d'horloge), dés lors que les cores ne sont vu que comme un seul CPU ça devient impossible :neutre: A moins que j'ai pas compris comme ça fonctionne et là j'suis preneur d'info en lieu et place de remarques désobligeante :jap:

Si c'est le Reverse Hyperthreading à AMD, le truc qui verra probablement jamais le jour, parce que sans contexte le CPU n'a aucune idée de ce que tu lui demandes ... [:shy]

Bon, on est donc bien d'accord, j'ai pas raconté de conneries

Tout au plus, j'aurais dû préciser que pour les particuliers qui paye leur license et sont donc souvent en familial, Windows gére le multi-CPU comme un goret... c'est à dire qu'il ne le prend pas en compte

m'enfin... peu importe... quand j'affirme quelque chose c'est qu'une source me le confirme et sinon je suppose parce que je ne prétends pas avoir la science infus

Ah. Alors désolé Megadub. Et donc MS a mis des restriction sur sa version familiale, et ce sur le parallélisme ??:etonne::peur:

Et ils sont au courant que sérialiser des tâches parallèles ça change l'algorithmie et donc que tu peux avoir des programmes qui partent complètement en vrille ? (Deadlocks mon amour :riva:)

Les boulets ...:pfff: :peur:

v_atekor a écrit:
Ah. Alors désolé Megadub. Et donc MS a mis des restriction sur sa version familiale, et ce sur le parallélisme ??:etonne::peur:

Non ça doit marcher correctement ...
Par contre je l'ai pas testé, mais je vois pas pourquoi ce serait différent, la seule différence vs les version Pro et Server, c'est le nombre de cores et de sockets gérés ...
D'ailleurs tu peux faire du multithread en mono CPU, mono core, c'est tout aussi efficace ... on a pas attendu les multi-cpu pour en tirer avantage ...
Edité le 19/09/2007 à 18:26

megadub a écrit:

taigaIV a écrit:

Avec l arrivee des cpu multicore la donne change. Que les unites de calculs soient sur le meme chip ne changent pas grand chose aux algo de gestions du multitache (pas grand chose ne voulant pas dire rien).

oui mais l'idéal étant de lancer les tâches en parallèle (c'est à dire 2 tâches dans le même cycle d'horloge), dés lors que les cores ne sont vu que comme un seul CPU ça devient impossible :neutre: A moins que j'ai pas compris comme ça fonctionne et là j'suis preneur d'info en lieu et place de remarques désobligeante :jap:

Pourqu oi lancer des taches au meme cycle ?

Tu as n unites d executions, qui (entre autre) ont des instructions, des pointeurs d instructions et des unites de calcul. D un autre cote tu as des processus (certains parlons de processus, processus leger, d autres de taches et de threads ... mais ce n est pas le sujet), pour simplifier autant ne pas faire de disctinctions entre un processus et ces threads (conciderons qu un thread est un processus faisant parti du contexte d un autre). Tous ces processus peuvent soient etre en attente d executions (ils ont des choses a faire) soit en attente de reveil. Le but du jeu est de passer ceux en attente d execution sur une unite d execution. La selection, la synchro et compagnie sont des elements qui vont expliquer qu un gestionnaire est plus efficace qu un autre. Mais tu ne vas pas aller chercher de problemes au cycle d horloge pret. Tout ceci etant tres general et pas tres precis.

catseye : (oui, je pense aussi ... )

catseye a écrit:

v_atekor a écrit:
Ah. Alors désolé Megadub. Et donc MS a mis des restriction sur sa version familiale, et ce sur le parallélisme ??:etonne::peur:

Non ça doit marcher correctement ...
Par contre je l'ai pas testé, mais je vois pas pourquoi ce serait différent, la seule différence vs les version Pro et Server, c'est le nombre de cores et de sockets gérés ...
D'ailleurs tu peux faire du multithread en mono CPU, mono core, c'est tout aussi efficace ... on a pas attendu les multi-cpu pour en tirer avantage ...

Pas attendu, pas attendu c est vite dit, il y a tout de meme pas mal de dev qui s appercoivent que les threads existent et que ca ne sert pas qu a faire jolie (si tu vois ce que je veux dire).

concernant les histoires de pro/fam, je pense que ca aurait couter plus cher a MS de reecrire l algo que de simplement limite sur le nombre de cpu reconnus.

taigaIV a écrit:

catseye a écrit:

v_atekor a écrit:
Ah. Alors désolé Megadub. Et donc MS a mis des restriction sur sa version familiale, et ce sur le parallélisme ??:etonne::peur:

Non ça doit marcher correctement ...
Par contre je l'ai pas testé, mais je vois pas pourquoi ce serait différent, la seule différence vs les version Pro et Server, c'est le nombre de cores et de sockets gérés ...
D'ailleurs tu peux faire du multithread en mono CPU, mono core, c'est tout aussi efficace ... on a pas attendu les multi-cpu pour en tirer avantage ...

Pas attendu, pas attendu c est vite dit, il y a tout de meme pas mal de dev qui s appercoivent que les threads existent et que ca ne sert pas qu a faire jolie (si tu vois ce que je veux dire).

concernant les histoires de pro/fam, je pense que ca aurait couter plus cher a MS de reecrire l algo que de simplement limite sur le nombre de cpu reconnus.

C'est quand même étonnant vu que la première chose un peu 'touchy' qu'on m'a fait ingurgiter en première année de fac était le 'fork' ... :paf:

Moi aussi. Il n empeche que pas mal d application ne sont pas multithreades, voir tous les dev depuis l arrivee des mulitcore

taigaIV a écrit:
Moi aussi. Il n empeche que pas mal d application ne sont pas multithreades, voir tous les dev depuis l arrivee des mulitcore

En même temps développer en séquentiel est à la portée de tout le monde, et ne coute pas grand chose, super simple à débugger etc etc ...
Faire un programme ultra-optimisé, multithreadé, c'est pas que c'est ultra complexe, mais ça prend plus de temps à mettre au point, à tester, optimiser encore etc etc ... peu d'éditeurs sont intéressés à investir en ce sens, le fonctionnel et la vente avant tout ... ;)
Edité le 19/09/2007 à 18:54

taigaIV a écrit:
Non, soit tu as un super multi-cpu soit tu ne l as pas, il n y a pas de milieu. Ensuite l implementation de ce support peut etre plus ou moins efficaces. Dire "si tu as 2 CPU, tu as un thread sur chacun d'eux mais ils sont quand même exécuté à la suite" ne correspond pas a ce que l on appel le support SMP (a moins d etre franchement tordus de la part des devs).

le milieu c'est l'OS qui soumet les threads à chacun des CPU j'imagine un peu genre load-balancing... :neutre:

v_atekor a écrit:
Et ils sont au courant que sérialiser des tâches parallèles ça change l'algorithmie et donc que tu peux avoir des programmes qui partent complètement en vrille ? (Deadlocks mon amour :riva:)

a priori c'est plutôt le parallélisme qui pose problème... si l'OS sérialise y'a pas de lézard sauf que c'est plus lent :/

catseye a écrit:
D'ailleurs tu peux faire du multithread en mono CPU, mono core, c'est tout aussi efficace ... on a pas attendu les multi-cpu pour en tirer avantage ...

certes mais les threads ne peuvent pas être partagé entre plusieurs CPU si l'OS ne le gére pas non ? [:paysan]

taigaIV a écrit:
Tu as n unites d executions, qui (entre autre) ont des instructions, des pointeurs d instructions et des unites de calcul. D un autre cote tu as des processus (certains parlons de processus, processus leger, d autres de taches et de threads ... mais ce n est pas le sujet), pour simplifier autant ne pas faire de disctinctions entre un processus et ces threads (conciderons qu un thread est un processus faisant parti du contexte d un autre). Tous ces processus peuvent soient etre en attente d executions (ils ont des choses a faire) soit en attente de reveil. Le but du jeu est de passer ceux en attente d execution sur une unite d execution. La selection, la synchro et compagnie sont des elements qui vont expliquer qu un gestionnaire est plus efficace qu un autre. Mais tu ne vas pas aller chercher de problemes au cycle d horloge pret. Tout ceci etant tres general et pas tres precis.

là j'avoue que ça dépasse mes compétences ;) mais j'imagine que quand un thread est lancé, en multi-CPU tu sais décomposé le traitement pour le partager entre les CPU... si l'OS ne le fait pas bah, tu soumets des threads sur plusieurs CPU mais les opérations d'un thread seront faites en séquence sur le CPU qui prend le thread en charge ce qui est bien moins intéressant.

En tout cas, c'est comme ça que je le vois :jap:

cat, me gourre-je ? :paf:

---

catseye a écrit:
Faire un programme ultra-optimisé, multithreadé, c'est pas que c'est ultra complexe, mais ça prend plus de temps à mettre au point, à tester, optimiser encore etc etc ... peu d'éditeurs sont intéressés à investir en ce sens, le fonctionnel et la vente avant tout ... ;)

et à voir le nombre de bugs liés à la paralélisation sous Oracle j'veux bien croire que c'est pas évident :ane: (notamment les contentions en mémoire... les fameux latch :/)
Edité le 19/09/2007 à 18:56

De ultra optimise a simplement multithreade il y a un pas tout de meme. Il semble que la puissance brut par core ne va pas augmenter aussi vite que ce que nous avons connus. Il va donc falloir multithreades les usines a gaz pour quelles tournent. Les fondeurs fournissent de plus en plus d outils aux dev pour les aides, ce n est sans doutes pas un hasard

megadub a écrit:
certes mais les threads ne peuvent pas être partagé entre plusieurs CPU si l'OS ne le gére pas non ? [:paysan]

C'est sur, mais dans ce cas, y a quand même un gain potentiel, le scheduler de l'OS donnera plus de temps pour tes processus ... ;)

megadub a écrit:

là j'avoue que ça dépasse mes compétences ;) mais j'imagine que quand un thread est lancé, en multi-CPU tu sais décomposé le traitement pour le partager entre les CPU... si l'OS ne le fait pas bah, tu soumets des threads sur plusieurs CPU mais les opérations d'un thread seront faites en séquence sur le CPU qui prend le thread en charge ce qui est bien moins intéressant.

'tu sais décomposer' ... disons que tu 'saurais' décomposer, mais en fait t'as pas ce contrôle et à la limite t'en veux pas, c'est l'OS qui va le faire ... par défaut un thread est exécuté sur le premier CPU libre, puis le second prend le suivant ... etc etc ...
Les opérations dans un thread ne peuvent pas être partagées comme ça facilement sauf si tu le forces (avec les libs Intel ou OpenMP), mais là ça devient imbittable ton code ... bonne chance pour celui qui va le relire ...

---

taigaIV a écrit:
De ultra optimise a simplement multithreade il y a un pas tout de meme. Il semble que la puissance brut par core ne va pas augmenter aussi vite que ce que nous avons connus. Il va donc falloir multithreades les usines a gaz pour quelles tournent. Les fondeurs fournissent de plus en plus d outils aux dev pour les aides, ce n est sans doutes pas un hasard

T'as regardé OpenMP ? Ben c'est pas de la tarte à utiliser ce truc ... :/ et le gain, je le cherche encore .. :paf:
Edité le 19/09/2007 à 19:02

taigaIV a écrit:
L os en tant que tel non puisqu il ne te founit rien pour le faire.

Et au passage la notion de protection de memoire est arrivee beaucoup plus tard ...

edit pardon j avais oublie le : :paf: element indispensable a la communication sur ce forum

Tu as bien deux processus en mémoire (l'un pouvant interrompre l'autre), cette possibilité est fourni par l'OS qui permet de charger de tels modules résident, même s'il contrôle pas grand chose et s'ils n'y aucune protection :) Après y a une aide du matos, les interruptions comme ils y a une aide, beaucoup plus évoluée sur les CPU actuels (gestion de la mémoire virtuelle / protégée par exemple => C'est pas que l'OS qui le fait, le CPU fait l'essentiel du boulot).

Mais oui, j'ai poussé le raisonnement jusqu'à la limite et peut-être au-delà, le " :paf: " est donc très important :D

catseye a écrit:

taigaIV a écrit:
L os en tant que tel non puisqu il ne te founit rien pour le faire.

Et au passage la notion de protection de memoire est arrivee beaucoup plus tard ...

Disons qu'un while(1) dans une interruption va calmer net ton OS ...:paf:

Non parce qu'on a tué les mauvais programmeurs :o :ane:
Edité le 19/09/2007 à 19:02

taigaIV a écrit:
De ultra optimise a simplement multithreade il y a un pas tout de meme. Il semble que la puissance brut par core ne va pas augmenter aussi vite que ce que nous avons connus. Il va donc falloir multithreades les usines a gaz pour quelles tournent. Les fondeurs fournissent de plus en plus d outils aux dev pour les aides, ce n est sans doutes pas un hasard

le problème étant que le gain du multi-core est pas super évident si les threads sont pas décomposés... pour moi, le réel intérêt c'est surtout la montée en charge du nombre de threads et d'éviter d'avoir le PC qui freeze dés que tu lances une grosse appli mangeuse de CPU :/

catseye a écrit:
C'est sur, mais dans ce cas, y a quand même un gain potentiel, le scheduler de l'OS donnera plus de temps pour tes processus ... ;)

oui, comme je dis, à l'extrème tu peux faire 10 petites instructions sur le 1° CPU pendant qu'une grosse instruction tourne sur le 2°... du coup du passe le temps de la plus longue instruction au lieu d'attendre la fin des 11 instructions. mais si tu peux partager la plus longue entre les 2 CPU tu peux espérer mieux t'en tirer... enfin, je pense :ane:

catseye a écrit:
'tu sais décomposer' ... disons que tu 'saurais' décomposer

Oui, tu peux pourvu que l'OS le permette :paf:

catseye a écrit:
et le gain, je le cherche encore .. :paf:

j'imagine que certaines applis sont plus enclines à en profiter que d'autres, notamment celles qui font du calcul genre SGBD, DAO, etc... c'est sûr qu'une appli passerait sont temps en I/O au lieu de CPU ça n'aide pas :neutre:

megadub a écrit:

catseye a écrit:
C'est sur, mais dans ce cas, y a quand même un gain potentiel, le scheduler de l'OS donnera plus de temps pour tes processus ... ;)

oui, comme je dis, à l'extrème tu peux faire 10 petites instructions sur le 1° CPU pendant qu'une grosse instruction tourne sur le 2°... du coup du passe le temps de la plus longue instruction au lieu d'attendre la fin des 11 instructions. mais si tu peux partager la plus longue entre les 2 CPU tu peux espérer mieux t'en tirer... enfin, je pense :ane:

On ne peut pas raisonner en instruction, mais uniquement en threads. On n'affecte pas un thread à un CPU pour chaque instruction, car le changement de CPU est lourd et que ça pénalise. Il faut pas le faire trop souvent ce qui rend la manip franchement ardue. Or établir à l'idéal par avance la charge que vont nécessiter les threads c'est tout sauf évident, et en fait y a que le dev qui peut avoir une idée de l'importance des traitements qu'il soumet, des relations entres les threads et de l'impact des I/O. La répartition de l'OS c'est plus ou moins bourrin, parce faite en aveugle :/ Avantage par contre, c'est que le dev n'a pas a y penser et que dans certains cas c'est absolument pas gênant ou très peu impactant.
Edité le 19/09/2007 à 19:39

a priori c'est plutôt le parallélisme qui pose problème... si l'OS sérialise y'a pas de lézard sauf que c'est plus lent

Ca dépend de ce que tu entends par sérialisation.
Soit tu exécute une petite séquence de chaque thread, en basculant rapidement de l'un à l'autre sur un monocpu, soit les deux en // sur chaque cpu, et il n'y a pas (peu) de problèmes d'algorithmie. C'est du temps partagé/smp tout à fait classique, sans restriction aucune.

Soit tu attends la fin d'un thread pour exécuter l'autre, et tu plantes tous les programmes multithreadés/ multitaches. Tu as des deadlocks dans tous les sens.Plus rien de fonctionne.

Donc en résumé : soit tu autorise le multithreading, et tu le fait fonctionner normalement, soit tu ne le supporte pas, et tu mets de restrictions.

Je n ai absoluement pas eu le temps de regarder OpenMP ou autre, en revanche il me semblait qu Intel et AMD mettaient tous les deux des lib a destinations des dev.

Concernant le scheduler, la preemptivite et elements assimilable, il me semble que tout ceci depend de ce que l on veut faire. Les differentes strategies ont leurs avantages et leurs inconvenients, tu ne vas gerer les choses de la meme facon si tu veux faire du temps reel par exemple.
Edité le 20/09/2007 à 10:58