Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Performance Distributions

386 réponses
Avatar
PP
Bonsoir à tous,

hier je suis tombé sur un truc affirmant que la gentoo par le fait
qu'elle compile les programmes sur mesure de son matériel est plus
performante que les distribution en paquet.

Certes, ça parait évident mais dans quelle mesure ? 5% ? 10% ? plus ?

Il me semble que BSD fait un peu pareil, mais je ne connais pas trop

Merci

10 réponses

1 2 3 4 5
Avatar
Stéphan Peccini
pehache-youplaboum wrote:

"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$

Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.



Portnawak.

Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.



J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.

--
Stéphan Peccini
Le blog : <URL:http://pyrenees.peccini.fr>
Les photos : <URL:http://photonature.fr>
Avatar
Nicolas George
PP , dans le message <4ccd3eed$0$3675$, a écrit :
Par contre, pour des applications pouvant utiliser des instruction plus
récentes (multimédia ou dé/compression ou encodage), y a-t-il des
distributions qui utiliseraient des systèmes de package pour compiler
peut-être une partie du code ? C'est juste une question pour savoir.
Il me semble que les .deb exécutent des scripts, ça doit-être dans le
domaine du possible, non ?



Le chargeur dynamique de la glibc permet ce genre de choses pour les
bibliothèques partagées : avant d'aller chercher dans /usr/lib (ou
/usr/loal/lib, etc/), il va chercher dans des sous-répertoires qui dépendent
de l'architecture, du style /usr/lib/tls/i686/sse2/cmov.

Mais ce genre de possibilité est très rarement utile : il faut que les
optimisations existent et soient significatives. Ça arrive pour les
bibliothèques de crypto, par exemple :

~ $ dpkg -L libssl0.9.8
<snip>
/usr/lib/libcrypto.so.0.9.8
/usr/lib/i586/libcrypto.so.0.9.8
/usr/lib/i486/libcrypto.so.0.9.8
/usr/lib/i686/cmov/libcrypto.so.0.9.8
Avatar
PP
Le 31/10/2010 11:04, Stéphan Peccini a écrit :
pehache-youplaboum wrote:

"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$



Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.





Portnawak.

Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.



J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.



Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multic½ur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les c½urs.
À moins que les OS soient merdiques.
Avatar
PP
Le 31/10/2010 11:12, Nicolas George a écrit :
PP , dans le message<4ccd3eed$0$3675$, a écrit :
Par contre, pour des applications pouvant utiliser des instruction plus
récentes (multimédia ou dé/compression ou encodage), y a-t-il des
distributions qui utiliseraient des systèmes de package pour compiler
peut-être une partie du code ? C'est juste une question pour savoir.
Il me semble que les .deb exécutent des scripts, ça doit-être dans le
domaine du possible, non ?



Le chargeur dynamique de la glibc permet ce genre de choses pour les
bibliothèques partagées : avant d'aller chercher dans /usr/lib (ou
/usr/loal/lib, etc/), il va chercher dans des sous-répertoires qui dépendent
de l'architecture, du style /usr/lib/tls/i686/sse2/cmov.

Mais ce genre de possibilité est très rarement utile : il faut que les
optimisations existent et soient significatives. Ça arrive pour les
bibliothèques de crypto, par exemple :

~ $ dpkg -L libssl0.9.8
<snip>
/usr/lib/libcrypto.so.0.9.8
/usr/lib/i586/libcrypto.so.0.9.8
/usr/lib/i486/libcrypto.so.0.9.8
/usr/lib/i686/cmov/libcrypto.so.0.9.8



OKI donc ça c'est le bonne exemple qui montre, qu'en utilisant des
bibliothèques bien pensées voire vraiment optimisées, on peut arriver un
degrés d'optimisation des logiciels dépendants sans être obligés de tout
recompiler.
Je pense que pour des bibliothèques multimédias ou autres il y a ce
genre d'optimisation, non ?
Peut-on imaginer par excès, en reprenant ton exemple, des sous
répertoires des répertoire d'architecture pour se rapprocher au plus
près des instructions des processeurs récents.
Avatar
Nicolas George
PP , dans le message <4ccd43c2$0$672$, a écrit :
Je pense que pour des bibliothèques multimédias ou autres il y a ce
genre d'optimisation, non ?



Oui.

Peut-on imaginer par excès, en reprenant ton exemple, des sous
répertoires des répertoire d'architecture pour se rapprocher au plus
près des instructions des processeurs récents.



Les gains deviennent alors négligeables.
Avatar
JKB
Le Sun, 31 Oct 2010 11:13:37 +0100,
PP écrivait :
Le 31/10/2010 11:04, Stéphan Peccini a écrit :
pehache-youplaboum wrote:

"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$



Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.





Portnawak.

Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.



J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.



Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multicœur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les cœurs.
À moins que les OS soient merdiques.



Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Avatar
PP
Le 31/10/2010 11:30, Nicolas George a écrit :
PP , dans le message<4ccd43c2$0$672$, a écrit :
Je pense que pour des bibliothèques multimédias ou autres il y a ce
genre d'optimisation, non ?



Oui.

Peut-on imaginer par excès, en reprenant ton exemple, des sous
répertoires des répertoire d'architecture pour se rapprocher au plus
près des instructions des processeurs récents.



Les gains deviennent alors négligeables.



Ben c'est pour cela que je pose la question.
Quand on voit les Intel et AMD "créer" de nouvelles instructions à
chaque génération on peut espérer que ce n'est pas "que" pour soulager
le compilateur !
Quand par exemple on prend les instructions SSE4, c'est pour avoir un
gain significatif important par rapport à l'ancienne méthode, non ?
Les SSE4 par exemple sont plus récentes que l'i686, ou l'x86-64.

Concrètement, si je prend la machine sur laquelle je suis. Un Athlon II
X2 240, supportant le SSE4, est-ce ma Ubuntu utilise ses instructions
pour les applications qui pourraient les utiliser ?

Ce n'est pas une question pour troller, c'est surtout une question pour
essayer de comprendre l'intérêt d'ajouter des instructions aux
processeurs, si on ne les utilise pas par soucis de retrocompatibilité
débile.
Avatar
PP
Le 31/10/2010 12:47, JKB a écrit :
Le Sun, 31 Oct 2010 11:13:37 +0100,
PP écrivait :
Le 31/10/2010 11:04, Stéphan Peccini a écrit :
pehache-youplaboum wrote:

"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$



Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.





Portnawak.

Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.



J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.



Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multic½ur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les c½urs.
À moins que les OS soient merdiques.



Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...



Là on se rapproche de machines indépendantes reliées ensemble dans la
même boite, plus que le multic½eur !
Avatar
JKB
Le Sun, 31 Oct 2010 12:59:24 +0100,
PP écrivait :
Le 31/10/2010 12:47, JKB a écrit :
Le Sun, 31 Oct 2010 11:13:37 +0100,
PP écrivait :
Le 31/10/2010 11:04, Stéphan Peccini a écrit :
pehache-youplaboum wrote:

"Tonton Th" a écrit dans le message de news:
4ccd3625$0$1083$



Pour faire encore plus simple : pas besoin de logiciel "optimisé"
pour le multi-coeur pour tirer pleinement parti des machines
multi-coeurs. Sauf pour les ancètres qui utilisent des OS
monotaches.





Portnawak.

Si un logiciel donné n'a pas été programmé pour faire du parallélisme (que
ce soit en multithreading ou en multiprocessing), il n'utilise qu'un coeur
quoi qu'il arrive.



J'ai des logiciels qui profitent de plusieurs coeurs et d'autres non. Mais
comme mon OS est multi-tâche (je ne suis pas un ancêtre qui utilise un OS
mono-tâche), je peux profiter tout le temps de mes 4 coeurs en lançant des
tâches en parallèle même si toutes celles que je lance ne sont pas
optimisées. Donc on peut très bien tirer parti de son multi-coeurs sans
avoir un seul logiciel optimisé pour le multi-coeur. Portnawak un peu rapide
à mon avis. Et comme j'ai de quoi avoir toujours mes 4 coeurs en fonction,
j'en tire pleinement profit.



Sans être un spécialiste, je suis assez d'accord, quand on voit le
nombre de processus en cours sur un ordinateur, tant windows que Linux,
le multicœur est automatiquement utilisé pour accroitre la rapidité de
la machine car je pense que les processus sont répartis entre les cœurs.
À moins que les OS soient merdiques.



Ouaips, sauf que là, on peut lancer un troll multicoeurs du pauvre
avec plusieurs coeur sur une même puce contre architecture numa...



Là on se rapproche de machines indépendantes reliées ensemble dans la
même boite, plus que le multicœeur !



Certes, mais tu peux avoir une architecture NUMA sur une bête
carte-mère ATX. Ça réduit d'autant les goulets d'étranglement.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Avatar
Nicolas George
PP , dans le message <4ccd58ff$0$5230$, a écrit :
Quand on voit les Intel et AMD "créer" de nouvelles instructions à
chaque génération on peut espérer que ce n'est pas "que" pour soulager
le compilateur !



Non, c'est pour faire gagner du temps à des programmes de calculs intensifs
que tu n'utilises probablement pas.
1 2 3 4 5