# [OFF] Simple Core ou Dual Core ?

## mornik

Bonjour à tous,

Je suis entrain de regarder pour changer de cpu sur ma machine. Aujourd'hui l'offre s'organise autour de 2 types de processeurs : les simple core et les dual core.

Savez vous si le dual core apporte réellement à la compilation ? Est-il bien géré par le noyau linux et par gcc ? Ou est-ce que le gain n'est pas vraiment conséquent (et ne justifie pas la différence de prix).

Merci pour vos lumières.

----------

## kwenspc

le dual core c'est du SMP. donc oui ça apporte VRAIMENT beaucoup. (d'autant plus si le bus mémoire est bien géré)

Grosso modo on peut dire qu'en général un dual core est 1,5fois plus puissant qu'un simple core. Ce qui veut dire que sur certains trucs ça sera des fois nettement plus puissant, et des fois à peine plus. C'est une moyenne donc.

Pour la compilation ça apporte réellement oui. make fera compilé sur les 2 cpu (-j 3) ce qui apporte un foutu gain.

Par contre pour une applie toute simple tu verras pas forcément de différence.

en fait c'est parce que linux va filer cette appli a un cpu, tandis qu'il va se garder de la puissance en reserve en ne faisant bosser l'autre cpu que sur les autres applis. 

Du coup c'est plutôt rare de voir ramer une machine SMP  plutot qu'une machine simple cpu.

Enfin apres il y a pas mal de gros détails genre bus mémoire partagé ou séparé, etc...

----------

## Mickael

Un petit lien sur une archive de la liste française de gentoo :

http://mailgate.supereva.com/linux/linux.gentoo.user.fr/msg05972.html

PERSO : Un dual-core ça fait rêver, mais cela ce configure comment au niveau du noyo. Il parait que le dual-core d'intel est supporté du côté de chez Redhat entreprise et suse.

----------

## E11

Oui, dual-core c'est mieu mais pour le moment pas encore pour tout !

Un gros exemple contre le dual-core actuel : les jeux-vidéos

En effet, il n'utilise presque pas les 2 processeurs et de ce faite il y a perte de pas mal de puissance... (les processeurs composant le dual-core étant quand même bien moins puissant qu'un processeur simple core)

Sous gentoo, par contre, il y a un réel avantage à avoir 2 cpu pour la compilation !

Personnellement je crois que prendre un dual-core est plus regardé vers l'avenir, mais qu'à une condition : que celui-ci soit compatible 64 bits, car si ce n'est pas le cas, ce processeurs sera vite "dépassé" et ne pourra jms profiter des futurs programmes complètement optimisés pour eux. ( Il faut vérifier l'info mais je pense qu'il n'ya pour le moment que AMD qui fait des dual-core 64 bits (c'est ce qui crée des problèmes avec les mac-intels et le futur win car la version 64bits sera la seule à gérer certains systèmes (je sais plus lesquels et pourquoi lol mais j'ai lu ça).

----------

## manu.acl

J'ai une Gentoo sur un AMD 64 X2 4400+ et le dual core est très bien géré.

Même dans les jeux !

----------

## Mickael

 *manu.acl wrote:*   

> J'ai une Gentoo sur un AMD 64 X2 4400+ et le dual core est très bien géré.
> 
> Même dans les jeux !

 

Dans le make.conf et le noyo les spécifications dual-core cela passe où s'il te plaît.

----------

## manu.acl

C'est juste dans le noyau, tu coches SMP...

----------

## kwenspc

En principe il me semble que c'est supporté de base en SMP non?

Support SMP dans le noyau et rulez!

Euh tu es sûr qu'il utiliser presque pas les 2 CPU? en principe il doit alterner sur l'un et l'autre et utiliser du cpu courant toute la puissance dont il a besoin. Enfin en principe...

----------

## Mickael

Au niveau des cflags pas de -O? farfelu?

Au niveau MAKEOPTS pas de -j? farfelu?

===> Ceci impliquerait que l'on configure le make.conf comme pour un processeur doté d'un seul coeur et l'option dans le noyo se chage de distribuer les compilations et les applications entre les deux coeurs?

----------

## manu.acl

 *MickTux wrote:*   

> Au niveau des cflags pas de -O? farfelu?
> 
> Au niveau MAKEOPTS pas de -j? farfelu?
> 
> ===> Ceci impliquerait que l'on configure le make.conf comme pour un processeur doté d'un seul coeur et l'option dans le noyo se chage de distribuer les compilations et les applications entre les deux coeurs?

 

Tu adaptes juste ton MAKEOPTS comme si tu avais 2 cpu. Moi j'ai mis "-j5".

C'est comme tu sens après

----------

## Mickael

 *manu.acl wrote:*   

>  *MickTux wrote:*   Au niveau des cflags pas de -O? farfelu?
> 
> Au niveau MAKEOPTS pas de -j? farfelu?
> 
> ===> Ceci impliquerait que l'on configure le make.conf comme pour un processeur doté d'un seul coeur et l'option dans le noyo se chage de distribuer les compilations et les applications entre les deux coeurs? 
> ...

 

Là OK ça semble plus optimisé pour la distribution entre les deux coeurs.

Merci.

----------

## manu.acl

 *kwenspc wrote:*   

> Euh tu es sûr qu'il utiliser presque pas les 2 CPU? en principe il doit alterner sur l'un et l'autre et utiliser du cpu courant toute la puissance dont il a besoin. Enfin en principe...

 

Chez moi l'utilisation des 2 cpu est toujours quasiment égale.

----------

## kwenspc

en principe c'est pas -j<nombre de cpu + 1> non? donc -j3 en principe. 

enfin il est vrai que si on prend chaque cpu seuls ça fait 1+1 et 1+1 donc 4... fin bref. je pense pas que ça soit un pb en fait ^^

----------

## Enlight

C'est simple :

compile du kernel : make -> 7mn, make -j5 1.30 environ.... bref oui au dual core (ou mieux dual CPU + NUMA) au dual channel et au raid (bientôt, bientôt)...   :Very Happy: 

----------

## kwenspc

NUMA? Opteron pawa non?  :Smile: 

bus mémoire séparé et tout

----------

## PabOu

Concernant le -j5 j'aimerais être sur de comprendre.. il s'agit de 2 cpu à 2 coeurs chacun ? ca fait un total de 4, et on rajoute le traditionnel +1 ?

C'est sur qu'une config comme ca, ca doit déchirer ;)

/me pleure avec son Athlon XP 1700 en (2x)133mhz:(

----------

## E11

 *manu.acl wrote:*   

>  *kwenspc wrote:*   Euh tu es sûr qu'il utiliser presque pas les 2 CPU? en principe il doit alterner sur l'un et l'autre et utiliser du cpu courant toute la puissance dont il a besoin. Enfin en principe... 
> 
> Chez moi l'utilisation des 2 cpu est toujours quasiment égale.

 

Oui, évidement, il peut utiliser les 2, mais ça n'enlève rien du faite que le simple CPU puissant sera plus performent que le double moins puissant dans tout ce qui est jeux, ... 

Je ne dis pas ça parce que je suis contre le dual-core (non, non même si je suis pas fan (car ils ont fait ça seulement parce que intel ne savait plus monté en fréquence   :Rolling Eyes: ) je trouve que c'est une bonne avancée (surtt pour gentoo  :Very Happy: ) ) mais parce que j'ai lu dans des tests que le dual-core n'apportait rien au jeu... 

Sinon, j'ai pu lire aussi d'autres tests pour le dual-core et il faut bien avouer que l'architecture des amd est bien plus efficasse que celle des intels actuellement... (Je ne parle pas de la puissance pûr mais bien de la façon dont les processeurs travaillent, communiquent,...)

----------

## kwenspc

Oui chez amd justement grace au NUMA et à l'hyper transport ils sont nettement meilleurs.

Les meilleurs dans le multi-cpu restant encore et toujours les machines SUN mais là c'est autres chose  :Very Happy: 

----------

## nuts

 *PabOu wrote:*   

> Concernant le -j5 j'aimerais être sur de comprendre.. il s'agit de 2 cpu à 2 coeurs chacun ? ca fait un total de 4, et on rajoute le traditionnel +1 ?
> 
> C'est sur qu'une config comme ca, ca doit déchirer 
> 
> /me pleure avec son Athlon XP 1700 en (2x)133mhz:(

 pour le makeopts, il faut pas prendre le nombre comme nombre de cpu + 1, mais le nombre de processus simultané a la compilation. il y avait un article sur un site de FreeBSD qui expliquait que par exemple un x86 a une facheuse tendance a se montrer lent sur les entré/sortie, pour gagner du temps a la compilation il suffit d'augmenter le MAKEOPTS.

De ma propre experience, il faut pas trop pousser, ca m'a causer des probleme de stabilité pendant une compilation.

en Mono-cpu on peut pousser jusqu a -j4 max d'apres mes experiences, car car un tel MAKEOPTS, il est difficil au dela d utiliser sa machine pendant un emerge.

en bi-cpu (distcc) aucun soucis avec un -j7

et bien entendu plus on augmente de cpu/core, plus le -j peut etre augmenter

----------

## geekounet

Perso, j'ai laissé un -j1 à cause de la conso en RAM de certaines compilations. Avec 2 travaux en même temps, ça se met à swapper pas mal des fois, et le pc devient inutilisable pendant ce temps ...

----------

## titoucha

Avec mon dual core AMD64 4400+  j'ai utilisé un -j6 et ça fonctionne très bien la consammation de ram est correcte, je n'ai jamais remarqué de swapping lors de compilation, j'ai 1Go de ram.

J'ai aussi une machine avec un AMD64 3800+ (mono core) et il n'y a pas photo, sur des compilations ou plusieurs programmes en parallèle, le confort du dual core est indéniable, par contre sur un gros programme monolithique (jeux) le mono core plus puissant par core est devant.

J'ai rèclé le problème dans mon cas..... je ne joue pas.   :Twisted Evil: 

----------

## mornik

oui donc y a pas photo visiblement, le dual core est très interressant avec une gentoo.

Merci de vos témoignages.

----------

## Longfield

Juste encore une remarque sur ce thread très intéressant. Les CPUs dual-core sont clairement l'orientation choisie par les deux fabriquant de processeurs x86 (AMD et Intel) et moi qui travaille dans le monde de l'embarqué, je sais que par exemple ARM va très bientôt s'y mettre (ils peuvent théroriquement déjà le faire avec les coeurs ARM11, mais je n'ai encore vu aucune annonce d'un processeur commercial multi-core licencié ARM11).

Donc si l'utilité du dual-core a déjà été démontrée dans le cas d'une utilisation normale du système (multi-tâche, lancement de plusieurs compilations, etc ...) dans les posts plus haut, il ne faut pas oublier que de nombreux programmes qui sont actuellement plus rapides sur un seul coeur (on peut penser aux jeux, mais aussi aux logiciels scientifiques genre Matlab/Mathematica où on fait des simus prenant parfois des heures) vont bientôt être programmées pour tirer parti de ce deuxième core qui tendra à s'imposer partout dans le futur (en créant plus de thread/parallélisme dans l'application).

Donc à mon avis, dans le cadre d'un achat d'une machine neuve, le dual-core est très clairement justifié !!!

edit : et hop, Guru, et même pas dans un post à flood !

----------

## nuts

et pour ceux qui ont deja gouté a l hyperthreading, c'est du pareil mais en plus de confort, car au lieu de dispatcher les ressource en 2 cpu virtuel (donc en gros en multithread ou processus, au lieu d'avoir la puissance du cpu/2) on a 2 cpu au taquet. c'est pas du tout negligeable

----------

## Longfield

 *nuts wrote:*   

> et pour ceux qui ont deja gouté a l hyperthreading, c'est du pareil mais en plus de confort, car au lieu de dispatcher les ressource en 2 cpu virtuel (donc en gros en multithread ou processus, au lieu d'avoir la puissance du cpu/2) on a 2 cpu au taquet. c'est pas du tout negligeable

 

tout-à-fait, mais juste pour préciser, l'hyperthreading utilise le fait qu'il y a des dépendances entre les différentes opérations à effecter (RAW par exemple) et utilise les ressources non utilisées dans le processeur et le matériel mis en place pour l'exécution Out Of Order pour faire tourner deux threads sur le même core.

Mais celà existe toujours : on a toujours de l'Hyperthreading sur les core Duo de Intel par exemple. Je pense qu'on peut dire que du point de vue "logique" avec un Core Duo, on a 4 CPUs virtuels (ce qui voudrait dire par exemple l'utilisation du -j5 !) A confirmer, mais il me semble que c'est le cas.

----------

## Enlight

ben -j5 c'est pour avoir 5 threads de compile ou de linkage en parralèlle, le paramètrage du -j doit normalement être compris entre nb_cpu + 1 et 2 * nb_cpu +1 (priorité à la multiplication hein!) donc 5 chez moi.

----------

## mornik

L'hyperthreading, on le trouve dans d'autres cpu que dans les intels ? (je parle pour le x86)

----------

## PabOu

non, l'hyperthreading c'est copyright Intel :\

----------

## nuts

c'est pas copyright, c'est une technologie. et effectivement sur l'architecture tpe x86 il n'y a qu'intel. sur d'autres archi peut etre...

----------

## xaviermiller

perso, l'Hyper Threading me laisse assez froid : à part rajouter de la réactivité quand un thread monopolise 100% du CPU, OK. Mais à part ça, les ressources sont quand même partagées, non ? Donc lancer 2 compilations en même temps n'ira pas plus vite qu'en faire une (enfin, quasi).

Tandis que le multi-core, ça c'est de la balle  :Very Happy:  : je viens de passer d'un Thunderbird 800 (=K7) à un AMD64X2 4400+, et c'est le jour et la nuit  :Wink: 

----------

## manu.acl

 *XavierMiller wrote:*   

> Tandis que le multi-core, ça c'est de la balle  : je viens de passer d'un Thunderbird 800 (=K7) à un AMD64X2 4400+, et c'est le jour et la nuit 

 

C'est si tu ne voyais pas de différence qu'il faudrait t'inquiéter... un TBird 800 c'est pas tout jeune ^^

----------

## PabOu

 *nuts wrote:*   

> c'est pas copyright, c'est une technologie. et effectivement sur l'architecture tpe x86 il n'y a qu'intel. sur d'autres archi peut etre...

 

Oui, une technologie inventée par Intel et protégée par copyright. Tout comme le SSE. Si un fabricant autre qu'Intel désire utiliser cette technologie, il y a quelques (millions de) dollards à faire sortir du porte-feuille.

----------

## Longfield

 *XavierMiller wrote:*   

> perso, l'Hyper Threading me laisse assez froid : à part rajouter de la réactivité quand un thread monopolise 100% du CPU, OK. Mais à part ça, les ressources sont quand même partagées, non ? Donc lancer 2 compilations en même temps n'ira pas plus vite qu'en faire une (enfin, quasi).
> 
> Tandis que le multi-core, ça c'est de la balle  : je viens de passer d'un Thunderbird 800 (=K7) à un AMD64X2 4400+, et c'est le jour et la nuit 

 

On est bien d'accord qu'un multi-core c'est mieux ! Mais ce dont il faut bien se rendre compte, c'est qu'en exécution normale, les resources de ton processeurs sont vraiment sous-exploitées. Pour mieux les exploiter, on fait du super-scalaire ou de l'exécution spéculative. Une autre idée c'est de faire du multithreading pour mieux remplir le pipeline, et donc mieux exploiter les capacités hardware de son processeur. Ce qui est intéressant dans cette technique, c'est qu'il y a très peu de matériel (comprende de transistors) à rajouter dans le proc pour avoir un feature intéressante

Allez, pour vous convaincre, un cours que j'avais suivi à l'époque où les premiers processeur Intel HT sortaient : http://lap.epfl.ch/courses/advcomparch/EPFL-only/TullsenJun96_ExploitingChoiceInstructionFetchAndIssueOnAnImplementableSimultaneousMultithreadingProcessor_ISCA.pdf

----------

## Oupsman

 *nuts wrote:*   

> c'est pas copyright, c'est une technologie. et effectivement sur l'architecture tpe x86 il n'y a qu'intel. sur d'autres archi peut etre...

 

Oui, sur les POWER5 par exemple, et cela s'appele le SMT.

----------

## billiob

 *Longfield wrote:*   

> 
> 
> Allez, pour vous convaincre, un cours que j'avais suivi à l'époque où les premiers processeur Intel HT sortaient : http://lap.epfl.ch/courses/advcomparch/EPFL-only/TullsenJun96_ExploitingChoiceInstructionFetchAndIssueOnAnImplementableSimultaneousMultithreadingProcessor_ISCA.pdf

 

Ca avait l'air bien, mais je ne peux pas y accéder  :Sad:  (demande de login+pass)

----------

## nemo13

 *billiob wrote:*   

>  *Longfield wrote:*   
> 
> Allez, pour vous convaincre, un cours que j'avais suivi à l'époque où les premiers processeur Intel HT sortaient : http://lap.epfl.ch/courses/advcomparch/EPFL-only/TullsenJun96_ExploitingChoiceInstructionFetchAndIssueOnAnImplementableSimultaneousMultithreadingProcessor_ISCA.pdf 
> 
> Ca avait l'air bien, mais je ne peux pas y accéder  (demande de login+pass)

 

pareil ; dommage  :Crying or Very sad: 

----------

## titoucha

Il semble me souvenir que pour faire de l'HT il faut avoir des processeurs avec des longs pipelines pour que cette technologie soie rentable et que sur les Amd par exemple ils utilisent des pipeline courts.

Si quelqu'un pourrait me le confirmer.

----------

## Longfield

 *billiob wrote:*   

>  *Longfield wrote:*   
> 
> Allez, pour vous convaincre, un cours que j'avais suivi à l'époque où les premiers processeur Intel HT sortaient : http://lap.epfl.ch/courses/advcomparch/EPFL-only/TullsenJun96_ExploitingChoiceInstructionFetchAndIssueOnAnImplementableSimultaneousMultithreadingProcessor_ISCA.pdf 
> 
> Ca avait l'air bien, mais je ne peux pas y accéder  (demande de login+pass)

 

effectivement, je vous ai filé le lien de la publication originale (qui est protégée et accessible uniquement depuis l'école) et non du cours à proprement parler qui est là. Dans le cours, l'hyperthreading et appelé SMT, comme sur le Power5 !

----------

