d'applis exploitent mal le multicore. Je croyais qu'il suffisant de recompiler ;>) Effectivement c'est un probleme d'architecture de base, cela implique de tout repenser a la base, mais cela n'a rien avoir avec la puissance du proc si le process en lui même est adapté. Dire que la puissance ne passe que par de l'Intel cisc est un concept qui a sacrement changé ces dernieres années. Les cartes graphiques par leur conception se rapprochent plus d'une philosophie arm que d'intel ...... et pourtant cuda et opencl les exploitent a merveille.
car beaucoup
d'applis exploitent mal le multicore.
Je croyais qu'il suffisant de recompiler ;>)
Effectivement c'est un probleme d'architecture de base, cela implique de
tout repenser a la base, mais cela n'a rien avoir avec la puissance du proc
si le process en lui même est adapté. Dire que la puissance ne passe que par
de l'Intel cisc est un concept qui a sacrement changé ces dernieres années.
Les cartes graphiques par leur conception se rapprochent plus d'une
philosophie arm que d'intel ...... et pourtant cuda et opencl les exploitent
a merveille.
d'applis exploitent mal le multicore. Je croyais qu'il suffisant de recompiler ;>) Effectivement c'est un probleme d'architecture de base, cela implique de tout repenser a la base, mais cela n'a rien avoir avec la puissance du proc si le process en lui même est adapté. Dire que la puissance ne passe que par de l'Intel cisc est un concept qui a sacrement changé ces dernieres années. Les cartes graphiques par leur conception se rapprochent plus d'une philosophie arm que d'intel ...... et pourtant cuda et opencl les exploitent a merveille.
d'applis exploitent mal le multicore. Je croyais qu'il suffisant de recompiler ;>)
Oui, tu recompiles et ça tourne. Après il peut y avoir des questions d'optimisations plus ou moins spécifiques.
Effectivement c'est un probleme d'architecture de base, cela implique de tout repenser a la base, mais cela n'a rien avoir avec la puissance du proc si le process en lui même est adapté.
Il y a des process qui ne sont pas adaptables au multicore et qui ne peuvent pas exploiter efficacement plus d'un coeur à la fois, quels que soient les efforts de programmation que tu déploies. D'autres qui sont adaptables mais au prix d'un effort important et d'une grosse complexification du code (donc maintenance plus difficile etc...).
Dire que la puissance ne passe que par de l'Intel cisc
Qui est en fait depuis longtemps du risc avec une couche de conversion cisc-->risc
est un concept qui a sacrement changé ces dernieres années. Les cartes graphiques par leur conception se rapprochent plus d'une philosophie arm que d'intel ......
Non pas du tout. Le parallélisme ARM ou x86 c'est du MIMD, celui des GPU c'est du SIMD. ARM et x86 ont le même modèle de parallélisme.
et pourtant cuda et opencl les exploitent a merveille.
cuda ou opencl ne sont pas des baguettes magiques qui rendent parallèles les algos qui ne le sont pas à la base. Plus encore qu'avec le multicore "classique", le parallélisme des GPU n'est applicable qu'à des types de calculs bien spécifiques. Ceci étant je ne vois pas pourquoi il faut opposer x86 et GPU, qui cohabitent très bien depuis toujours dans les PC. Les GPU jouent aujourd'hui plus ou moins le rôle des coprocesseurs arithmétiques d'hier, soulageant le CPU pour certaines tâches spécialisées.
Le 03/10/2016 à 18:42, Pascal-J a écrit :
car beaucoup
d'applis exploitent mal le multicore.
Je croyais qu'il suffisant de recompiler ;>)
Oui, tu recompiles et ça tourne.
Après il peut y avoir des questions d'optimisations plus ou moins
spécifiques.
Effectivement c'est un probleme d'architecture de base, cela implique de
tout repenser a la base, mais cela n'a rien avoir avec la puissance du proc
si le process en lui même est adapté.
Il y a des process qui ne sont pas adaptables au multicore et qui ne
peuvent pas exploiter efficacement plus d'un coeur à la fois, quels que
soient les efforts de programmation que tu déploies. D'autres qui sont
adaptables mais au prix d'un effort important et d'une grosse
complexification du code (donc maintenance plus difficile etc...).
Dire que la puissance ne passe que par
de l'Intel cisc
Qui est en fait depuis longtemps du risc avec une couche de conversion
cisc-->risc
est un concept qui a sacrement changé ces dernieres années.
Les cartes graphiques par leur conception se rapprochent plus d'une
philosophie arm que d'intel ......
Non pas du tout. Le parallélisme ARM ou x86 c'est du MIMD, celui des GPU
c'est du SIMD. ARM et x86 ont le même modèle de parallélisme.
et pourtant cuda et opencl les exploitent
a merveille.
cuda ou opencl ne sont pas des baguettes magiques qui rendent parallèles
les algos qui ne le sont pas à la base. Plus encore qu'avec le multicore
"classique", le parallélisme des GPU n'est applicable qu'à des types de
calculs bien spécifiques.
Ceci étant je ne vois pas pourquoi il faut opposer x86 et GPU, qui
cohabitent très bien depuis toujours dans les PC. Les GPU jouent
aujourd'hui plus ou moins le rôle des coprocesseurs arithmétiques d'hier,
soulageant le CPU pour certaines tâches spécialisées.
d'applis exploitent mal le multicore. Je croyais qu'il suffisant de recompiler ;>)
Oui, tu recompiles et ça tourne. Après il peut y avoir des questions d'optimisations plus ou moins spécifiques.
Effectivement c'est un probleme d'architecture de base, cela implique de tout repenser a la base, mais cela n'a rien avoir avec la puissance du proc si le process en lui même est adapté.
Il y a des process qui ne sont pas adaptables au multicore et qui ne peuvent pas exploiter efficacement plus d'un coeur à la fois, quels que soient les efforts de programmation que tu déploies. D'autres qui sont adaptables mais au prix d'un effort important et d'une grosse complexification du code (donc maintenance plus difficile etc...).
Dire que la puissance ne passe que par de l'Intel cisc
Qui est en fait depuis longtemps du risc avec une couche de conversion cisc-->risc
est un concept qui a sacrement changé ces dernieres années. Les cartes graphiques par leur conception se rapprochent plus d'une philosophie arm que d'intel ......
Non pas du tout. Le parallélisme ARM ou x86 c'est du MIMD, celui des GPU c'est du SIMD. ARM et x86 ont le même modèle de parallélisme.
et pourtant cuda et opencl les exploitent a merveille.
cuda ou opencl ne sont pas des baguettes magiques qui rendent parallèles les algos qui ne le sont pas à la base. Plus encore qu'avec le multicore "classique", le parallélisme des GPU n'est applicable qu'à des types de calculs bien spécifiques. Ceci étant je ne vois pas pourquoi il faut opposer x86 et GPU, qui cohabitent très bien depuis toujours dans les PC. Les GPU jouent aujourd'hui plus ou moins le rôle des coprocesseurs arithmétiques d'hier, soulageant le CPU pour certaines tâches spécialisées.
Sinmian
'lut, On Mon, 3 Oct 2016 19:17:56 +0200, Francis Chartier wrote:
Il faut d'ailleurs saluer la vision des designers du MacPro6,1 : il ressemble au choix à une poubelle ou un cendrier, et pourra être rapidement recyclé sous le bureau sans grand effort.
Tu crois qu'en la bourrant de coton*, on peut vapoter avec ? Bon, vu la portabilité du bousin, autant y mettre un bottom-feeder sur le pack de 24 ou le fut de gibolin. -- envoyé depuis mon PC * ou un mouton (halal ou kasher, on va pas mégoter)
'lut,
On Mon, 3 Oct 2016 19:17:56 +0200, Francis Chartier wrote:
Il faut d'ailleurs saluer la vision des designers du MacPro6,1 : il
ressemble au choix à une poubelle ou un cendrier, et pourra être
rapidement recyclé sous le bureau sans grand effort.
Tu crois qu'en la bourrant de coton*, on peut vapoter avec ?
Bon, vu la portabilité du bousin, autant y mettre un bottom-feeder sur le
pack de 24 ou le fut de gibolin.
--
envoyé depuis mon PC
* ou un mouton (halal ou kasher, on va pas mégoter)
'lut, On Mon, 3 Oct 2016 19:17:56 +0200, Francis Chartier wrote:
Il faut d'ailleurs saluer la vision des designers du MacPro6,1 : il ressemble au choix à une poubelle ou un cendrier, et pourra être rapidement recyclé sous le bureau sans grand effort.
Tu crois qu'en la bourrant de coton*, on peut vapoter avec ? Bon, vu la portabilité du bousin, autant y mettre un bottom-feeder sur le pack de 24 ou le fut de gibolin. -- envoyé depuis mon PC * ou un mouton (halal ou kasher, on va pas mégoter)
Le Moustique
Le 03/10/2016 19:48, Sinmian a écrit :
Il faut d'ailleurs saluer la vision des designers du MacPro6,1 : il
ressemble au choix à une poubelle ou un cendrier,
Tu crois qu'en la bourrant de coton*, on peut vapoter avec ?
Mékilékon! :-D Bon, je fournis le tuyau pour en faire un narguilé, tu t'occupes du reste?
* ou un mouton (halal ou kasher, on va pas mégoter)
Mégoter à propos de vapoteuse, c'est abusif. :-) (Le mouton me rappelle une histoire salace, que je ne raconterai pas ici). -- /) -:oo= Guillaume ) Je nettoyais mon clavier, et le coup est parti tout seul.
Le 03/10/2016 19:48, Sinmian a écrit :
Il faut d'ailleurs saluer la vision des designers du MacPro6,1 : il
>ressemble au choix à une poubelle ou un cendrier,
Tu crois qu'en la bourrant de coton*, on peut vapoter avec ?
Mékilékon! :-D
Bon, je fournis le tuyau pour en faire un narguilé, tu t'occupes du reste?
* ou un mouton (halal ou kasher, on va pas mégoter)
Mégoter à propos de vapoteuse, c'est abusif. :-)
(Le mouton me rappelle une histoire salace, que je ne raconterai pas ici).
--
/)
-:oo= Guillaume
)
Je nettoyais mon clavier, et le coup est parti tout seul.
Il faut d'ailleurs saluer la vision des designers du MacPro6,1 : il
ressemble au choix à une poubelle ou un cendrier,
Tu crois qu'en la bourrant de coton*, on peut vapoter avec ?
Mékilékon! :-D Bon, je fournis le tuyau pour en faire un narguilé, tu t'occupes du reste?
* ou un mouton (halal ou kasher, on va pas mégoter)
Mégoter à propos de vapoteuse, c'est abusif. :-) (Le mouton me rappelle une histoire salace, que je ne raconterai pas ici). -- /) -:oo= Guillaume ) Je nettoyais mon clavier, et le coup est parti tout seul.
Sinmian
On Mon, 3 Oct 2016 20:59:28 +0200, Le Moustique wrote:
Bon, je fournis le tuyau pour en faire un narguilé, tu t'occupes du reste?
Je viens de faire infuser trois boîtes de couscous garbit, ça repose, là... Le plus dur sera de faire passer les boulettes et les merguez.
Mégoter à propos de vapoteuse, c'est abusif. :-)
Ergoter n'aurait pas rimé.
(Le mouton me rappelle une histoire salace, que je ne raconterai pas ici).
Je pensais à exactement la même, avec des éléphantes ? M'enfin, salace, bah... rah-gna-gnesque, tout au plus. -- envoyé depuis mon PC
On Mon, 3 Oct 2016 20:59:28 +0200, Le Moustique wrote:
Bon, je fournis le tuyau pour en faire un narguilé, tu t'occupes du reste?
Je viens de faire infuser trois boîtes de couscous garbit, ça repose, là...
Le plus dur sera de faire passer les boulettes et les merguez.
Mégoter à propos de vapoteuse, c'est abusif. :-)
Ergoter n'aurait pas rimé.
(Le mouton me rappelle une histoire salace, que je ne raconterai pas ici).
Je pensais à exactement la même, avec des éléphantes ? M'enfin, salace,
bah... rah-gna-gnesque, tout au plus.
On Mon, 3 Oct 2016 20:59:28 +0200, Le Moustique wrote:
Bon, je fournis le tuyau pour en faire un narguilé, tu t'occupes du reste?
Je viens de faire infuser trois boîtes de couscous garbit, ça repose, là... Le plus dur sera de faire passer les boulettes et les merguez.
Mégoter à propos de vapoteuse, c'est abusif. :-)
Ergoter n'aurait pas rimé.
(Le mouton me rappelle une histoire salace, que je ne raconterai pas ici).
Je pensais à exactement la même, avec des éléphantes ? M'enfin, salace, bah... rah-gna-gnesque, tout au plus. -- envoyé depuis mon PC
pdorange
Pascal-J wrote:
C'est un peu plus complexe que cela, tu connais la version de photoshop pour Linux par exemple (hors émulation wine bien sur) ?
Non c'est pas plus complexe, le passage d'un logiciel d'une plateforme à l'autre (Intel > ARM par exemple) est un simple recompilation du code source ; dans la mesure (c'est quand même la postulat de l'enfilade) ou l'architecture système reste la même (MacOS). Là dans ton exemple tu changes d'OS et donc les API. Le problème n'est alors plus matériel, mais logiciel (API pour être plus exact).
De plus entre des processeurs risk et cisk la structure est suffisamment différente pour poser des gros soucis, surtout quand des fonctions sont directement incluses en logiciel, par exemple dans un autre fil récent avec la portabilité sur les processeurs intel actuel de direct x 12 prévu pour les skylake.
Code source mal foutu c'est tout. A partir ou le code source d'un logiciel est dépendant de l'architecture bas niveau de la plateforme matériel, soit c'est un logiciel (plutot un pilote en général) bas niveau spécifique, soit c'est un problème de conception. -- Pierre-Alain Dorange Moof <http://clarus.chez-alice.fr/> Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
Pascal-J <nomail@nofor.fr> wrote:
C'est un peu plus complexe que cela, tu connais la version de photoshop pour
Linux par exemple (hors émulation wine bien sur) ?
Non c'est pas plus complexe, le passage d'un logiciel d'une plateforme à
l'autre (Intel > ARM par exemple) est un simple recompilation du code
source ; dans la mesure (c'est quand même la postulat de l'enfilade) ou
l'architecture système reste la même (MacOS). Là dans ton exemple tu
changes d'OS et donc les API. Le problème n'est alors plus matériel,
mais logiciel (API pour être plus exact).
De plus
entre des processeurs risk et cisk la structure est suffisamment différente
pour poser des gros soucis, surtout quand des fonctions sont directement
incluses en logiciel, par exemple dans un autre fil récent avec la
portabilité sur les processeurs intel actuel de direct x 12 prévu pour les
skylake.
Code source mal foutu c'est tout. A partir ou le code source d'un
logiciel est dépendant de l'architecture bas niveau de la plateforme
matériel, soit c'est un logiciel (plutot un pilote en général) bas
niveau spécifique, soit c'est un problème de conception.
C'est un peu plus complexe que cela, tu connais la version de photoshop pour Linux par exemple (hors émulation wine bien sur) ?
Non c'est pas plus complexe, le passage d'un logiciel d'une plateforme à l'autre (Intel > ARM par exemple) est un simple recompilation du code source ; dans la mesure (c'est quand même la postulat de l'enfilade) ou l'architecture système reste la même (MacOS). Là dans ton exemple tu changes d'OS et donc les API. Le problème n'est alors plus matériel, mais logiciel (API pour être plus exact).
De plus entre des processeurs risk et cisk la structure est suffisamment différente pour poser des gros soucis, surtout quand des fonctions sont directement incluses en logiciel, par exemple dans un autre fil récent avec la portabilité sur les processeurs intel actuel de direct x 12 prévu pour les skylake.
Code source mal foutu c'est tout. A partir ou le code source d'un logiciel est dépendant de l'architecture bas niveau de la plateforme matériel, soit c'est un logiciel (plutot un pilote en général) bas niveau spécifique, soit c'est un problème de conception. -- Pierre-Alain Dorange Moof <http://clarus.chez-alice.fr/> Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
