est ce que c'est le bon forum pour parler matériel ?
actuellement j'ai cet ordinateur :
https://support.apple.com/kb/SP576?locale=fr_FR
j'envisage de passer au PC
j'y connais pas grand chose en matériel,
et j'aimerais ne pas descendre en gamme (ne pas me retrouver avec du
matériel moins bon que ce que j'avais avant)
processeur :
comment retrouver exactement quel est le processeur que j'ai dans mon
ordi ? (pour voir quelles sont précisément ses caractéristiques)
Non, le gain de l'hyperthreading varie de 0 à 30% environ. Il faut que les 2 threads qui "tournent" sur le même coeur physique partagent suffisamment de choses (notamment les datas) pour qu'il y ait un gain significatif.
Je crois que tu te trompes. L'hyperthreading, si j'ai bien compris, c'est deux fils d'exécution mais un seul jeu d'unités de calcul.
Oui, et un seul cache.
Donc au contraire il vaut mieux des processus qui font des choses fondamentalement différentes.
Je n'ai pas compris que le coeur physique pouvait exécuter deux threads en même temps, même sur des opérations différentes. Mais que si l'un des deux threads était en attente (de données par exemple) il pouvait exécuter l'autre. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Le 14/05/2018 à 21:41, Nicolas George a écrit :
pehache , dans le message
<667bfa69d43c6df32dd30b774742ca8d27b657f8@news.nemoweb.net>, a écrit :
Non, le gain de l'hyperthreading varie de 0 à 30% environ. Il faut que les
2 threads qui "tournent" sur le même coeur physique partagent suffisamment
de choses (notamment les datas) pour qu'il y ait un gain significatif.
Je crois que tu te trompes. L'hyperthreading, si j'ai bien compris,
c'est deux fils d'exécution mais un seul jeu d'unités de calcul.
Oui, et un seul cache.
Donc au
contraire il vaut mieux des processus qui font des choses
fondamentalement différentes.
Je n'ai pas compris que le coeur physique pouvait exécuter deux threads
en même temps, même sur des opérations différentes. Mais que si l'un des
deux threads était en attente (de données par exemple) il pouvait
exécuter l'autre.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Non, le gain de l'hyperthreading varie de 0 à 30% environ. Il faut que les 2 threads qui "tournent" sur le même coeur physique partagent suffisamment de choses (notamment les datas) pour qu'il y ait un gain significatif.
Je crois que tu te trompes. L'hyperthreading, si j'ai bien compris, c'est deux fils d'exécution mais un seul jeu d'unités de calcul.
Oui, et un seul cache.
Donc au contraire il vaut mieux des processus qui font des choses fondamentalement différentes.
Je n'ai pas compris que le coeur physique pouvait exécuter deux threads en même temps, même sur des opérations différentes. Mais que si l'un des deux threads était en attente (de données par exemple) il pouvait exécuter l'autre. -- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Jo Engo
Le Tue, 15 May 2018 22:10:20 +0200, pehache a écrit :
Mais que si l'un des deux threads était en attente (de données par exemple)
Le plus probable (ou design nouveau ou exotique du logiciel) est qu'il soit bloqué à cause d'une ressource qu'on ne peut pas mener à 2 ou plusieurs : écrire ou lire (c'est les rédacteurs et les lecteurs : un seul (à la fois) modifie la ressource commune, tandis que le nombre de lecteurs est open) le cache (c'est quoi ? C'est un tas mou ?) aussi bien qu'une zone de mémoire partagée aussi. Donc deux proc frères qui partagent beaucoup de ressources vont *ralentir* le traitement et «désoptimiser» l'usage de la ressource (processeur) (et peut-être attendre les 2 qu'une 3ème les libère d'un verrou, à ce moment les 2 «cœurs logiques» sont sous-exploités). Par contre avec 2 threads étrangères, il n'y a pas ce problème d'accès exclusif à des ressources «partagées». -- Des étoiles sont mortes pour que nous puissions vivre. -+- Preston Cloud -+-
Le Tue, 15 May 2018 22:10:20 +0200, pehache a écrit :
Mais que si l'un des deux threads était en attente (de données par
exemple)
Le plus probable (ou design nouveau ou exotique du logiciel) est qu'il
soit bloqué à cause d'une ressource qu'on ne peut pas mener à 2 ou
plusieurs : écrire ou lire (c'est les rédacteurs et les lecteurs : un
seul (à la fois) modifie la ressource commune, tandis que le nombre de
lecteurs est open) le cache (c'est quoi ? C'est un tas mou ?) aussi bien
qu'une zone de mémoire partagée aussi. Donc deux proc frères qui
partagent beaucoup de ressources vont *ralentir* le traitement et
«désoptimiser» l'usage de la ressource (processeur) (et peut-être
attendre les 2 qu'une 3ème les libère d'un verrou, à ce moment les 2
«cœurs logiques» sont sous-exploités). Par contre avec 2 threads
étrangères, il n'y a pas ce problème d'accès exclusif à des ressources
«partagées».
--
Des étoiles sont mortes pour que nous puissions vivre.
-+- Preston Cloud -+-
Le Tue, 15 May 2018 22:10:20 +0200, pehache a écrit :
Mais que si l'un des deux threads était en attente (de données par exemple)
Le plus probable (ou design nouveau ou exotique du logiciel) est qu'il soit bloqué à cause d'une ressource qu'on ne peut pas mener à 2 ou plusieurs : écrire ou lire (c'est les rédacteurs et les lecteurs : un seul (à la fois) modifie la ressource commune, tandis que le nombre de lecteurs est open) le cache (c'est quoi ? C'est un tas mou ?) aussi bien qu'une zone de mémoire partagée aussi. Donc deux proc frères qui partagent beaucoup de ressources vont *ralentir* le traitement et «désoptimiser» l'usage de la ressource (processeur) (et peut-être attendre les 2 qu'une 3ème les libère d'un verrou, à ce moment les 2 «cœurs logiques» sont sous-exploités). Par contre avec 2 threads étrangères, il n'y a pas ce problème d'accès exclusif à des ressources «partagées». -- Des étoiles sont mortes pour que nous puissions vivre. -+- Preston Cloud -+-
pehache
Le 17/05/2018 à 00:50, Jo Engo a écrit :
Le Tue, 15 May 2018 22:10:20 +0200, pehache a écrit :
Mais que si l'un des deux threads était en attente (de données par exemple)
Le plus probable (ou design nouveau ou exotique du logiciel) est qu'il soit bloqué à cause d'une ressource qu'on ne peut pas mener à 2 ou plusieurs : écrire ou lire (c'est les rédacteurs et les lecteurs : un seul (à la fois) modifie la ressource commune, tandis que le nombre de lecteurs est open) le cache (c'est quoi ? C'est un tas mou ?) aussi bien qu'une zone de mémoire partagée aussi. Donc deux proc frères qui partagent beaucoup de ressources vont *ralentir* le traitement et «désoptimiser» l'usage de la ressource (processeur) (et peut-être attendre les 2 qu'une 3ème les libère d'un verrou, à ce moment les 2 «cœurs logiques» sont sous-exploités). Par contre avec 2 threads étrangères, il n'y a pas ce problème d'accès exclusif à des ressources «partagées».
Ce que tu dis suppose que les deux threads sont réellement exécutés simultanément. Or ce n'est à priori pas le cas (ou alors je n'ai rien compris au fonctionnement)
Le 17/05/2018 à 00:50, Jo Engo a écrit :
Le Tue, 15 May 2018 22:10:20 +0200, pehache a écrit :
Mais que si l'un des deux threads était en attente (de données par
exemple)
Le plus probable (ou design nouveau ou exotique du logiciel) est qu'il
soit bloqué à cause d'une ressource qu'on ne peut pas mener à 2 ou
plusieurs : écrire ou lire (c'est les rédacteurs et les lecteurs : un
seul (à la fois) modifie la ressource commune, tandis que le nombre de
lecteurs est open) le cache (c'est quoi ? C'est un tas mou ?) aussi bien
qu'une zone de mémoire partagée aussi. Donc deux proc frères qui
partagent beaucoup de ressources vont *ralentir* le traitement et
«désoptimiser» l'usage de la ressource (processeur) (et peut-être
attendre les 2 qu'une 3ème les libère d'un verrou, à ce moment les 2
«cœurs logiques» sont sous-exploités). Par contre avec 2 threads
étrangères, il n'y a pas ce problème d'accès exclusif à des ressources
«partagées».
Ce que tu dis suppose que les deux threads sont réellement exécutés
simultanément. Or ce n'est à priori pas le cas (ou alors je n'ai rien
compris au fonctionnement)
Le Tue, 15 May 2018 22:10:20 +0200, pehache a écrit :
Mais que si l'un des deux threads était en attente (de données par exemple)
Le plus probable (ou design nouveau ou exotique du logiciel) est qu'il soit bloqué à cause d'une ressource qu'on ne peut pas mener à 2 ou plusieurs : écrire ou lire (c'est les rédacteurs et les lecteurs : un seul (à la fois) modifie la ressource commune, tandis que le nombre de lecteurs est open) le cache (c'est quoi ? C'est un tas mou ?) aussi bien qu'une zone de mémoire partagée aussi. Donc deux proc frères qui partagent beaucoup de ressources vont *ralentir* le traitement et «désoptimiser» l'usage de la ressource (processeur) (et peut-être attendre les 2 qu'une 3ème les libère d'un verrou, à ce moment les 2 «cœurs logiques» sont sous-exploités). Par contre avec 2 threads étrangères, il n'y a pas ce problème d'accès exclusif à des ressources «partagées».
Ce que tu dis suppose que les deux threads sont réellement exécutés simultanément. Or ce n'est à priori pas le cas (ou alors je n'ai rien compris au fonctionnement)
olivier B.
Le 17/05/2018 à 09:59, pehache a écrit :
Ce que tu dis suppose que les deux threads sont réellement exécutés simultanément. Or ce n'est à priori pas le cas (ou alors je n'ai rien compris au fonctionnement)
Ils ne le sont pas au niveau physique, mais ils le sont au niveau logique. Le fait de faire voir plusieurs cœurs logiques est une ingénieuse solution sur allocation de ressource appliquée aux CPU, technique bien connue dans tout les domaines présentant une forme de mutualisation de moyen, ceci touchant d'autres modèles que l'informatique. Je la trouve ingénieuse car plutôt que faire porter une partie de la sur allocation par le système elle l'a rendu abstraite en s'appuyant sur le standard multicœurs existant, mais de ce que j'ai compris ça n'est plus tout à fait le cas, l'optimisation faisant maintenant porter certaines décisions par l'os ou l'applicatif, mais c'est assez flou pour moi, je l'avoue.
Le 17/05/2018 à 09:59, pehache a écrit :
Ce que tu dis suppose que les deux threads sont réellement exécutés
simultanément. Or ce n'est à priori pas le cas (ou alors je n'ai rien
compris au fonctionnement)
Ils ne le sont pas au niveau physique, mais ils le sont au niveau logique.
Le fait de faire voir plusieurs cœurs logiques est une ingénieuse
solution sur allocation de ressource appliquée aux CPU, technique bien
connue dans tout les domaines présentant une forme de mutualisation de
moyen, ceci touchant d'autres modèles que l'informatique.
Je la trouve ingénieuse car plutôt que faire porter une partie de la sur
allocation par le système elle l'a rendu abstraite en s'appuyant sur le
standard multicœurs existant, mais de ce que j'ai compris ça n'est plus
tout à fait le cas, l'optimisation faisant maintenant porter certaines
décisions par l'os ou l'applicatif, mais c'est assez flou pour moi, je
l'avoue.
Ce que tu dis suppose que les deux threads sont réellement exécutés simultanément. Or ce n'est à priori pas le cas (ou alors je n'ai rien compris au fonctionnement)
Ils ne le sont pas au niveau physique, mais ils le sont au niveau logique. Le fait de faire voir plusieurs cœurs logiques est une ingénieuse solution sur allocation de ressource appliquée aux CPU, technique bien connue dans tout les domaines présentant une forme de mutualisation de moyen, ceci touchant d'autres modèles que l'informatique. Je la trouve ingénieuse car plutôt que faire porter une partie de la sur allocation par le système elle l'a rendu abstraite en s'appuyant sur le standard multicœurs existant, mais de ce que j'ai compris ça n'est plus tout à fait le cas, l'optimisation faisant maintenant porter certaines décisions par l'os ou l'applicatif, mais c'est assez flou pour moi, je l'avoue.
pehache
Le 19/05/2018 à 10:50, olivier B. a écrit :
Le 17/05/2018 à 09:59, pehache a écrit :
Ce que tu dis suppose que les deux threads sont réellement exécutés simultanément. Or ce n'est à priori pas le cas (ou alors je n'ai rien compris au fonctionnement)
Ils ne le sont pas au niveau physique, mais ils le sont au niveau logique.
Donc ils ne le sont pas tout court.
Le fait de faire voir plusieurs cœurs logiques est une ingénieuse solution
Que ce soit ingénieux je n'en doute pas, mais on discutait de la façon dont ça fonctionnait *précisément*.
sur allocation de ressource appliquée aux CPU, technique bien connue dans tout les domaines présentant une forme de mutualisation de moyen, ceci touchant d'autres modèles que l'informatique. Je la trouve ingénieuse car plutôt que faire porter une partie de la sur allocation par le système elle l'a rendu abstraite en s'appuyant sur le standard multicœurs existant, mais de ce que j'ai compris ça n'est plus tout à fait le cas, l'optimisation faisant maintenant porter certaines décisions par l'os ou l'applicatif, mais c'est assez flou pour moi, je l'avoue.
-- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
Le 19/05/2018 à 10:50, olivier B. a écrit :
Le 17/05/2018 à 09:59, pehache a écrit :
Ce que tu dis suppose que les deux threads sont réellement exécutés
simultanément. Or ce n'est à priori pas le cas (ou alors je n'ai rien
compris au fonctionnement)
Ils ne le sont pas au niveau physique, mais ils le sont au niveau logique.
Donc ils ne le sont pas tout court.
Le fait de faire voir plusieurs cœurs logiques est une ingénieuse
solution
Que ce soit ingénieux je n'en doute pas, mais on discutait de la façon
dont ça fonctionnait *précisément*.
sur allocation de ressource appliquée aux CPU, technique bien
connue dans tout les domaines présentant une forme de mutualisation de
moyen, ceci touchant d'autres modèles que l'informatique.
Je la trouve ingénieuse car plutôt que faire porter une partie de la sur
allocation par le système elle l'a rendu abstraite en s'appuyant sur le
standard multicœurs existant, mais de ce que j'ai compris ça n'est plus
tout à fait le cas, l'optimisation faisant maintenant porter certaines
décisions par l'os ou l'applicatif, mais c'est assez flou pour moi, je
l'avoue.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
Ce que tu dis suppose que les deux threads sont réellement exécutés simultanément. Or ce n'est à priori pas le cas (ou alors je n'ai rien compris au fonctionnement)
Ils ne le sont pas au niveau physique, mais ils le sont au niveau logique.
Donc ils ne le sont pas tout court.
Le fait de faire voir plusieurs cœurs logiques est une ingénieuse solution
Que ce soit ingénieux je n'en doute pas, mais on discutait de la façon dont ça fonctionnait *précisément*.
sur allocation de ressource appliquée aux CPU, technique bien connue dans tout les domaines présentant une forme de mutualisation de moyen, ceci touchant d'autres modèles que l'informatique. Je la trouve ingénieuse car plutôt que faire porter une partie de la sur allocation par le système elle l'a rendu abstraite en s'appuyant sur le standard multicœurs existant, mais de ce que j'ai compris ça n'est plus tout à fait le cas, l'optimisation faisant maintenant porter certaines décisions par l'os ou l'applicatif, mais c'est assez flou pour moi, je l'avoue.
-- "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le même sens que les tiennes.", ST sur fr.bio.medecine
