In article <1hm49y1.taixon18wxfbjN%, (Olivier Goldberg) wrote:
Momoclic wrote:
Parfaitement d'accord, mais il n'en reste pas moins vrai qu'une même appli fonctionne plus vite sur un double cour que sur un simple. Même si elle n'est pas optimisé pour 2 processeurs, puisque c'est la CPU elle même qui optimise le traitement (ou sous-traitement ?).
C'est surtout parce qu'il y a toujours de très nombreuses tâches qui tournent simultanément, et que même si d'aventure una appli non optimisée multiproc/core n'avait qu'une seule tâche, toutes celles du système ou des autres applis pourront être traitées par l'un des autres proc/cores.
------------ Olivier, tu aurais un lien où cette gestion des tâches par le CPU ou les coeurs ainsi que la part de l'OS, des I/O etc. serait expliqué, simplement si possible ?
Jean-Pierre
In article <1hm49y1.taixon18wxfbjN%listes2@ogoldberg.net>,
listes2@ogoldberg.net (Olivier Goldberg) wrote:
Momoclic <decliq@OTEZ_MOIfree.fr> wrote:
Parfaitement d'accord, mais il n'en reste pas moins vrai qu'une même appli
fonctionne plus vite sur un double cour que sur un simple. Même si elle
n'est pas optimisé pour 2 processeurs, puisque c'est la CPU elle même qui
optimise le traitement (ou sous-traitement ?).
C'est surtout parce qu'il y a toujours de très nombreuses tâches qui
tournent simultanément, et que même si d'aventure una appli non
optimisée multiproc/core n'avait qu'une seule tâche, toutes celles du
système ou des autres applis pourront être traitées par l'un des autres
proc/cores.
------------
Olivier, tu aurais un lien où cette gestion des tâches par le CPU ou les
coeurs ainsi que la part de l'OS, des I/O etc. serait expliqué,
simplement si possible ?
In article <1hm49y1.taixon18wxfbjN%, (Olivier Goldberg) wrote:
Momoclic wrote:
Parfaitement d'accord, mais il n'en reste pas moins vrai qu'une même appli fonctionne plus vite sur un double cour que sur un simple. Même si elle n'est pas optimisé pour 2 processeurs, puisque c'est la CPU elle même qui optimise le traitement (ou sous-traitement ?).
C'est surtout parce qu'il y a toujours de très nombreuses tâches qui tournent simultanément, et que même si d'aventure una appli non optimisée multiproc/core n'avait qu'une seule tâche, toutes celles du système ou des autres applis pourront être traitées par l'un des autres proc/cores.
------------ Olivier, tu aurais un lien où cette gestion des tâches par le CPU ou les coeurs ainsi que la part de l'OS, des I/O etc. serait expliqué, simplement si possible ?
Jean-Pierre
jean-pierre poindessault
In article <20060923131840817553@[10.0.0.1]>, (manet) wrote:
patpro ~ patrick proniewski wrote:
Malgré tout, plus tu as de core plus tu peux faire tourner de choses en même temps sans perte de performance.
voilà ; le multiproc, c'est ce qui te permet de faire plusieurs choses plein pot en meme temps ;...... Là est bien le problème:
tu écris "permet" (présent), mais j'aurai envie d'écrire "peut permettre". Mais il faut bien que quelque part, quelqu'un ou quelque chose partage et distribue les tâches (scheduler, hard, soft, les deux ?). Si on repense au parallélisme du Velocity Engine, il fallait quand même que les programmes soient prévus pour.
Il n'y aurait pas dans le coin un brillant étudiant qui aurait suivi (et compris) un joli cours là-dessus ?
Jean-Pierre
In article <20060923131840817553@[10.0.0.1]>, pmanet@invivo.edu (manet)
wrote:
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Malgré tout, plus tu as de core plus tu peux faire tourner de choses en
même temps sans perte de performance.
voilà ; le multiproc, c'est ce qui te permet de faire plusieurs choses
plein pot en meme temps ;......
Là est bien le problème:
tu écris "permet" (présent), mais j'aurai envie d'écrire "peut
permettre".
Mais il faut bien que quelque part, quelqu'un ou quelque chose partage
et distribue les tâches (scheduler, hard, soft, les deux ?).
Si on repense au parallélisme du Velocity Engine, il fallait quand même
que les programmes soient prévus pour.
Il n'y aurait pas dans le coin un brillant étudiant qui aurait suivi
(et compris) un joli cours là-dessus ?
In article <20060923131840817553@[10.0.0.1]>, (manet) wrote:
patpro ~ patrick proniewski wrote:
Malgré tout, plus tu as de core plus tu peux faire tourner de choses en même temps sans perte de performance.
voilà ; le multiproc, c'est ce qui te permet de faire plusieurs choses plein pot en meme temps ;...... Là est bien le problème:
tu écris "permet" (présent), mais j'aurai envie d'écrire "peut permettre". Mais il faut bien que quelque part, quelqu'un ou quelque chose partage et distribue les tâches (scheduler, hard, soft, les deux ?). Si on repense au parallélisme du Velocity Engine, il fallait quand même que les programmes soient prévus pour.
Il n'y aurait pas dans le coin un brillant étudiant qui aurait suivi (et compris) un joli cours là-dessus ?
Jean-Pierre
listes2
jean-pierre poindessault wrote:
Olivier, tu aurais un lien où cette gestion des tâches par le CPU ou les coeurs ainsi que la part de l'OS, des I/O etc. serait expliqué,
Non, désolé. Ce que j'en comprends viens de mes lectures ici et là, sur le web et les forums, depuis le développement du multiprocesseur sur Mac.
-- Olivier Goldberg
Pour le courrier personnel, écrire à: olivier (at) ogoldberg (point) net Mon blog: http://anesthe-site.be/blog
- parallels installe Windows dans un fichier image disque à lui,
Mais parallels peut-il utiliser une partition Windows? (que ce soit celle de Bootcamp ou d'un PC)
-- Olivier Goldberg
Pour le courrier personnel, écrire à: olivier (at) ogoldberg (point) net Mon blog: http://anesthe-site.be/blog
Alain Godet
- Clavier Mac supporté avec les pilotes du kit BootCamp Alors là, ça m'épate : j'ai un clavier Apple Bluetooth, et les drivers
Apple de BootCamp ne le reconnaissent pas dans Parallel. J'ai donc été obligé de bidouiller avec des freewares trouvés à droite à gauche pour remapper correctement l'ensemble et maintenant, c'est parfait !
-- Cordialement
Alain Godet ajouter un t avant le @ pour répondre...
- Clavier Mac supporté avec les pilotes du kit BootCamp
Alors là, ça m'épate : j'ai un clavier Apple Bluetooth, et les drivers
Apple de BootCamp ne le reconnaissent pas dans Parallel.
J'ai donc été obligé de bidouiller avec des freewares trouvés à droite à
gauche pour remapper correctement l'ensemble et maintenant, c'est parfait !
--
Cordialement
Alain Godet
ajouter un t avant le @ pour répondre...
- Clavier Mac supporté avec les pilotes du kit BootCamp Alors là, ça m'épate : j'ai un clavier Apple Bluetooth, et les drivers
Apple de BootCamp ne le reconnaissent pas dans Parallel. J'ai donc été obligé de bidouiller avec des freewares trouvés à droite à gauche pour remapper correctement l'ensemble et maintenant, c'est parfait !
-- Cordialement
Alain Godet ajouter un t avant le @ pour répondre...
pmanet
jean-pierre poindessault wrote:
tu écris "permet" (présent), mais j'aurai envie d'écrire "peut permettre".
la difficulté, c'est à l'intérieur d'une meme application ; il faut que le developpeur l'ai prevu.
mais si ce sont des logiciels différents, c'est le système qui distribue, et là c'est sans problème. Il suffit de voir avec un top dans le terminal : il y a souvent une appli qui prend 100%, et les autres qui se partagent le reste.
C'est typique si tu as Classic : à lui tout seul et sans rien faire, il te bouffe un bon bout de ton proc ; pendant ce temps là, FMP peut tourner à fond, c'est quand meme un sacré avantage.
tu écris "permet" (présent), mais j'aurai envie d'écrire "peut
permettre".
la difficulté, c'est à l'intérieur d'une meme application ; il faut que
le developpeur l'ai prevu.
mais si ce sont des logiciels différents, c'est le système qui
distribue, et là c'est sans problème. Il suffit de voir avec un top dans
le terminal : il y a souvent une appli qui prend 100%, et les autres qui
se partagent le reste.
C'est typique si tu as Classic : à lui tout seul et sans rien faire, il
te bouffe un bon bout de ton proc ; pendant ce temps là, FMP peut
tourner à fond, c'est quand meme un sacré avantage.
tu écris "permet" (présent), mais j'aurai envie d'écrire "peut permettre".
la difficulté, c'est à l'intérieur d'une meme application ; il faut que le developpeur l'ai prevu.
mais si ce sont des logiciels différents, c'est le système qui distribue, et là c'est sans problème. Il suffit de voir avec un top dans le terminal : il y a souvent une appli qui prend 100%, et les autres qui se partagent le reste.
C'est typique si tu as Classic : à lui tout seul et sans rien faire, il te bouffe un bon bout de ton proc ; pendant ce temps là, FMP peut tourner à fond, c'est quand meme un sacré avantage.
-- Philippe Manet
jean-pierre poindessault
In article <200609231934272173697@[10.0.0.1]>, (manet) wrote:
jean-pierre poindessault wrote:
tu écris "permet" (présent), mais j'aurai envie d'écrire "peut permettre".
la difficulté, c'est à l'intérieur d'une meme application ; il faut que le developpeur l'ai prevu.
mais si ce sont des logiciels différents, c'est le système qui distribue, et là c'est sans problème. Il suffit de voir avec un top dans le terminal : il y a souvent une appli qui prend 100%, et les autres qui se partagent le reste.
C'est typique si tu as Classic : à lui tout seul et sans rien faire, il te bouffe un bon bout de ton proc ; pendant ce temps là, FMP peut tourner à fond, c'est quand meme un sacré avantage.
--------- Là, OK. Tu écris, "c'est le système qui distribue", je comprends "le système d'explotation" Ailleurs, Olivier écrit "C'est l'OS qui va répartir la charge." Là, c'est clair, et je vous rejoins en pensant que l'on peut avoir tous les "cores" que l'on veut, si l'OS n'est pas prévu pour (le scheduler), cela ne sert à rien. Dans le cas de Classic, ce n'est pas du tout étonnant que ce soit un mono-process vis à vis d'OS X. Classic, si il est comme OS 7 à 8, doit posséder son propre scheduler "round robin" (tranches de 16ms si je me souviens de mes expériences temps réel avec Labview -1993) où chaque process (programme) se voit attribuer une tranche de temps avant de passer la main. Cette stratégie aurait été remplacée par le multitâches/préemptif d'OS X. Encore que pour le préemptif, il faut m'expliquer la gestion des priorités. Il y a des applmis temps réel sous OS X ? Windows qui était censé l'être a posé d'énormes problèmes aux développeurs de systèmes d'acquisition (mesure).
Bon, JP, il faut que tu demandes à tes étudiants des années 80/90 de te ramener les cours que tu faisais à l'époque (DEC RT11, RSX 11, Ada,temps réel, etc.) ! :-))
Jean-Pierre
In article <200609231934272173697@[10.0.0.1]>,
pmanet@invivo.edu (manet) wrote:
tu écris "permet" (présent), mais j'aurai envie d'écrire "peut
permettre".
la difficulté, c'est à l'intérieur d'une meme application ; il faut que
le developpeur l'ai prevu.
mais si ce sont des logiciels différents, c'est le système qui
distribue, et là c'est sans problème. Il suffit de voir avec un top dans
le terminal : il y a souvent une appli qui prend 100%, et les autres qui
se partagent le reste.
C'est typique si tu as Classic : à lui tout seul et sans rien faire, il
te bouffe un bon bout de ton proc ; pendant ce temps là, FMP peut
tourner à fond, c'est quand meme un sacré avantage.
---------
Là, OK.
Tu écris, "c'est le système qui distribue", je comprends "le système
d'explotation"
Ailleurs, Olivier écrit "C'est l'OS qui va répartir la charge."
Là, c'est clair, et je vous rejoins en pensant que l'on peut avoir tous
les "cores" que l'on veut, si l'OS n'est pas prévu pour (le scheduler),
cela ne sert à rien.
Dans le cas de Classic, ce n'est pas du tout étonnant que ce soit un
mono-process vis à vis d'OS X.
Classic, si il est comme OS 7 à 8, doit posséder son propre scheduler
"round robin" (tranches de 16ms si je me souviens de mes expériences
temps réel avec Labview -1993) où chaque process (programme) se voit
attribuer une tranche de temps avant de passer la main.
Cette stratégie aurait été remplacée par le multitâches/préemptif d'OS X.
Encore que pour le préemptif, il faut m'expliquer la gestion des
priorités. Il y a des applmis temps réel sous OS X ?
Windows qui était censé l'être a posé d'énormes problèmes aux
développeurs de systèmes d'acquisition (mesure).
Bon, JP, il faut que tu demandes à tes étudiants des années 80/90 de te
ramener les cours que tu faisais à l'époque (DEC RT11, RSX 11, Ada,temps
réel, etc.) ! :-))
In article <200609231934272173697@[10.0.0.1]>, (manet) wrote:
jean-pierre poindessault wrote:
tu écris "permet" (présent), mais j'aurai envie d'écrire "peut permettre".
la difficulté, c'est à l'intérieur d'une meme application ; il faut que le developpeur l'ai prevu.
mais si ce sont des logiciels différents, c'est le système qui distribue, et là c'est sans problème. Il suffit de voir avec un top dans le terminal : il y a souvent une appli qui prend 100%, et les autres qui se partagent le reste.
C'est typique si tu as Classic : à lui tout seul et sans rien faire, il te bouffe un bon bout de ton proc ; pendant ce temps là, FMP peut tourner à fond, c'est quand meme un sacré avantage.
--------- Là, OK. Tu écris, "c'est le système qui distribue", je comprends "le système d'explotation" Ailleurs, Olivier écrit "C'est l'OS qui va répartir la charge." Là, c'est clair, et je vous rejoins en pensant que l'on peut avoir tous les "cores" que l'on veut, si l'OS n'est pas prévu pour (le scheduler), cela ne sert à rien. Dans le cas de Classic, ce n'est pas du tout étonnant que ce soit un mono-process vis à vis d'OS X. Classic, si il est comme OS 7 à 8, doit posséder son propre scheduler "round robin" (tranches de 16ms si je me souviens de mes expériences temps réel avec Labview -1993) où chaque process (programme) se voit attribuer une tranche de temps avant de passer la main. Cette stratégie aurait été remplacée par le multitâches/préemptif d'OS X. Encore que pour le préemptif, il faut m'expliquer la gestion des priorités. Il y a des applmis temps réel sous OS X ? Windows qui était censé l'être a posé d'énormes problèmes aux développeurs de systèmes d'acquisition (mesure).
Bon, JP, il faut que tu demandes à tes étudiants des années 80/90 de te ramener les cours que tu faisais à l'époque (DEC RT11, RSX 11, Ada,temps réel, etc.) ! :-))
Jean-Pierre
listes2
jean-pierre poindessault wrote:
Encore que pour le préemptif, il faut m'expliquer la gestion des priorités. Il y a des applmis temps réel sous OS X ?
Les priorités sont gérées par Mac OS X, mais ne me demande pas les détails. Il me semble aussi qu'il est censé pouvoir faire tourner des applis temps réel, mais je n'ai jamais testé.
-- Olivier Goldberg
Pour le courrier personnel, écrire à: olivier (at) ogoldberg (point) net Mon blog: http://anesthe-site.be/blog
Encore que pour le préemptif, il faut m'expliquer la gestion des
priorités. Il y a des applmis temps réel sous OS X ?
Les priorités sont gérées par Mac OS X, mais ne me demande pas les
détails.
Il me semble aussi qu'il est censé pouvoir faire tourner des applis
temps réel, mais je n'ai jamais testé.
--
Olivier Goldberg
Pour le courrier personnel, écrire à: olivier (at) ogoldberg (point) net
Mon blog: http://anesthe-site.be/blog
Encore que pour le préemptif, il faut m'expliquer la gestion des priorités. Il y a des applmis temps réel sous OS X ?
Les priorités sont gérées par Mac OS X, mais ne me demande pas les détails. Il me semble aussi qu'il est censé pouvoir faire tourner des applis temps réel, mais je n'ai jamais testé.
-- Olivier Goldberg
Pour le courrier personnel, écrire à: olivier (at) ogoldberg (point) net Mon blog: http://anesthe-site.be/blog
address
Alain Godet wrote:
- Clavier Mac supporté avec les pilotes du kit BootCamp Alors là, ça m'épate : j'ai un clavier Apple Bluetooth, et les drivers
Apple de BootCamp ne le reconnaissent pas dans Parallel. J'ai donc été obligé de bidouiller avec des freewares trouvés à droite à gauche pour remapper correctement l'ensemble et maintenant, c'est parfait !
Interessant. Si tu as le temps, je suis preneur pour tout conseil dans ce sens. J'ai galéré des heures pour trouver le @ et le ... j'ai fini par utiliser le clavier virtuel Windows, franchement pas pratique! -- ric at pixelligence dot com
Alain Godet <algode@wanadoo.fr> wrote:
- Clavier Mac supporté avec les pilotes du kit BootCamp
Alors là, ça m'épate : j'ai un clavier Apple Bluetooth, et les drivers
Apple de BootCamp ne le reconnaissent pas dans Parallel.
J'ai donc été obligé de bidouiller avec des freewares trouvés à droite à
gauche pour remapper correctement l'ensemble et maintenant, c'est parfait !
Interessant. Si tu as le temps, je suis preneur pour tout conseil dans
ce sens. J'ai galéré des heures pour trouver le @ et le ... j'ai fini
par utiliser le clavier virtuel Windows, franchement pas pratique!
--
ric at pixelligence dot com
- Clavier Mac supporté avec les pilotes du kit BootCamp Alors là, ça m'épate : j'ai un clavier Apple Bluetooth, et les drivers
Apple de BootCamp ne le reconnaissent pas dans Parallel. J'ai donc été obligé de bidouiller avec des freewares trouvés à droite à gauche pour remapper correctement l'ensemble et maintenant, c'est parfait !
Interessant. Si tu as le temps, je suis preneur pour tout conseil dans ce sens. J'ai galéré des heures pour trouver le @ et le ... j'ai fini par utiliser le clavier virtuel Windows, franchement pas pratique! -- ric at pixelligence dot com
