Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Discussions Générales Omniprésence de l'x86 est-il une bonne chose pour Linux ?

Omniprésence de l'x86 est-il une bonne chose pour Linux ?

176 réponses
Avatar
PP
Bonsoir à tous,

en lisant un peu partout sur internet des news, notamment les dernières
sur www.blogarm.net, je m'attriste de l'omniprésence de l'architecture
x86 partout.

Cette dernière semble être de plus en plus compétitive face aux
spécialistes du secteur comme ARM par exemple dans l'embarqué et les
SoC. Peut-être pas du point de vue technique mais au moins marketing !

Ma peur de voir encore une fois le couple WIntel envahir le marché de
nous imposer une vision uniforme est effrayante.

Le seul point positif peut-être de cette histoire, c'est que Linux
pourrait être choisi encore plus facilement pour tous les matériels
équipés en x86. Ce qui ouvrirait une perspective de personnalisation de
nos équipement encore plus grande !?

Qu'en pensez-vous ?
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
9 10 11 12 13
Avatar
PP
Le 30/09/2010 15:41, JKB a écrit :

C'est déprimant ce que tu dis !



Non, pourquoi ?



Bonsoir,

Je reviens à la charge, que penses-tu de cette article ?

http://www.lemagit.fr/article/sun-hp-serveurs-ibm-datacenter-stockage-unix-emc-nas-hds-cluster-fcoe-san-iscsi-netapp-joyent/5965/1/dossier-infrastructures-2010-convergence-service-reduction-des-couts-2eme-partie/
Avatar
Emmanuel Florac
Le Thu, 30 Sep 2010 16:14:24 +0200, PP a écrit:


Mais pourquoi ne s'interessent-il pas au marché grand public ? Intel/AMD
cassant toutes possibilités de gain, nous sommes alors réduit à utiliser
nos usines à gaz !!!
Personnellement je me tate pour m'acheter un petit truc mobile qui va
bien sans ventilo. Pour ne pas le nommé, le TOSHIBA AC100.



Autre possibilité bien tentante : OpenPandora....

--
Question: How does a large software project get to be one year late?
Answer: One day at a time!
Fred Brooks
Avatar
JKB
Le Thu, 30 Sep 2010 22:11:10 +0200,
PP écrivait :
Le 30/09/2010 15:41, JKB a écrit :

C'est déprimant ce que tu dis !



Non, pourquoi ?



Bonsoir,

Je reviens à la charge, que penses-tu de cette article ?




Que tu ne sais pas couper un lien.

http://www.lemagit.fr/article/sun-hp-serveurs-ibm-datacenter-stockage-unix-emc-nas-hds-cluster-fcoe-san-iscsi-netapp-joyent/5965/1/dossier-infrastructures-2010-convergence-service-reduction-des-couts-2eme-partie/




Je l'ai lu en diagonale. Il y a du bon et du très mauvais dans ce
papier et le type ne sait visiblement pas de quoi il parle. Il a
simplement mis bout à bout des benchs sans regarder ce qu'il y avait
derrière.

1/ Il confond Unix et architecture. Un serveur peut être Unix sous
x86. Pour lui, Unix signifie architecture différente de x86. Premier
point.
2/ Il oublie qu'aujourd'hui, il y a des palanquées (malheureusement)
d'administrateurs aux pieds tendres pour Linux et FreeBSD et
nettement moins pour les autres systèmes. Ça biaise particulièrement
les stats.
3/ Comparer la puissance d'un Sparc Tx à un x86 est une immense
connerie parce qu'il faut comparer ce qui est comparable. Si tu
prends un T1, il faut le comparer avec un core2duo. La puissance
consommée est du même ordre de grandeur, mais le T1 fait tourner 32
threads. Rapportée au thread, le T1 gagne haut la main. Si tu
programmes correctement le truc, même le T1 à 1 GHz éclate un
core2duo à 2,5 GHz. Même remarque pour les T2+ à comparer avec des i
quelque chose (en virgule flottante, un T2 tourne à peu près 5 fois
plus vite qu'un T1 à même fréquence). Quant aux T3, je n'ai pas encore
eu l'occasion de tester, mais le fossé entre le i7 et le T3 doit encore
être plus grand puisque le T3 fait tourner 128 threads.
4/ Parler de l'IA64 Tukwila qui ne sort pas est d'une bêtise crasse
puisque le IA64 présente le même problème que les processeurs RISC.
Seul HP et Bull (il me semble que tous les autres fabricants ont
abandonné l'IA64) contribuent avec Intel au développement et une
nouvelle puce signifie une amélioration significative du circuit. Ce
n'est pas comme un processeur CISC où on rajoute des circuit de
gestion anexe (pipe-line, prédictions...) qui permettent de gratter
des cycles et de faire accroire que les performances augmentent.
Entre nous, HP aurait intérêt à ressusciter l'alpha plutôt que de
continuer dans la voie de l'IA64.

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 01/10/2010 09:50, JKB a écrit :

Je reviens à la charge, que penses-tu de cette article ?




Que tu ne sais pas couper un lien.



En effet, je ne savais pas comment faire ! ;)

http://www.lemagit.fr/article/sun-hp-serveurs-ibm-datacenter-stockage-unix-emc-nas-hds-cluster-fcoe-san-iscsi-netapp-joyent/5965/1/dossier-infrastructures-2010-convergence-service-reduction-des-couts-2eme-partie/




Je l'ai lu en diagonale. Il y a du bon et du très mauvais dans ce
papier et le type ne sait visiblement pas de quoi il parle. Il a
simplement mis bout à bout des benchs sans regarder ce qu'il y avait
derrière.

1/ Il confond Unix et architecture. Un serveur peut être Unix sous
x86. Pour lui, Unix signifie architecture différente de x86. Premier
point.



J'avais en effet, remarqué ce truc.
Il parle d'Unix, pour parler de serveur autre que x86

2/ Il oublie qu'aujourd'hui, il y a des palanquées (malheureusement)
d'administrateurs aux pieds tendres pour Linux et FreeBSD et
nettement moins pour les autres systèmes. Ça biaise particulièrement
les stats.
3/ Comparer la puissance d'un Sparc Tx à un x86 est une immense
connerie parce qu'il faut comparer ce qui est comparable. Si tu
prends un T1, il faut le comparer avec un core2duo. La puissance
consommée est du même ordre de grandeur, mais le T1 fait tourner 32
threads. Rapportée au thread, le T1 gagne haut la main. Si tu
programmes correctement le truc, même le T1 à 1 GHz éclate un
core2duo à 2,5 GHz. Même remarque pour les T2+ à comparer avec des i
quelque chose (en virgule flottante, un T2 tourne à peu près 5 fois
plus vite qu'un T1 à même fréquence). Quant aux T3, je n'ai pas encore
eu l'occasion de tester, mais le fossé entre le i7 et le T3 doit encore
être plus grand puisque le T3 fait tourner 128 threads.



Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en multicœur ?
Ce qui est aussi un handicap en faveur du x86, non ?

4/ Parler de l'IA64 Tukwila qui ne sort pas est d'une bêtise crasse
puisque le IA64 présente le même problème que les processeurs RISC.
Seul HP et Bull (il me semble que tous les autres fabricants ont
abandonné l'IA64) contribuent avec Intel au développement et une
nouvelle puce signifie une amélioration significative du circuit. Ce
n'est pas comme un processeur CISC où on rajoute des circuit de
gestion annexe (pipe-line, prédictions...) qui permettent de gratter
des cycles et de faire accroire que les performances augmentent.
Entre nous, HP aurait intérêt à ressusciter l'alpha plutôt que de
continuer dans la voie de l'IA64.



C'est certainement la puissance d'Intel d'avoir un gros pouvoir de
développement rapide et en masse et en "puissance" apparente.
Avatar
JKB
Le Fri, 01 Oct 2010 12:56:32 +0200,
PP écrivait :
Le 01/10/2010 09:50, JKB a écrit :
2/ Il oublie qu'aujourd'hui, il y a des palanquées (malheureusement)
d'administrateurs aux pieds tendres pour Linux et FreeBSD et
nettement moins pour les autres systèmes. Ça biaise particulièrement
les stats.
3/ Comparer la puissance d'un Sparc Tx à un x86 est une immense
connerie parce qu'il faut comparer ce qui est comparable. Si tu
prends un T1, il faut le comparer avec un core2duo. La puissance
consommée est du même ordre de grandeur, mais le T1 fait tourner 32
threads. Rapportée au thread, le T1 gagne haut la main. Si tu
programmes correctement le truc, même le T1 à 1 GHz éclate un
core2duo à 2,5 GHz. Même remarque pour les T2+ à comparer avec des i
quelque chose (en virgule flottante, un T2 tourne à peu près 5 fois
plus vite qu'un T1 à même fréquence). Quant aux T3, je n'ai pas encore
eu l'occasion de tester, mais le fossé entre le i7 et le T3 doit encore
être plus grand puisque le T3 fait tourner 128 threads.



Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en multicœur ?



La réponse est clairement non pour l'immense majorité des
développeurs. Et des rustines façon openmp ne sont pas là pour
arranger les choses quand on voit les aberrations générées.

Ce qui est aussi un handicap en faveur du x86, non ?



Non, parce que les RISC ont un avantage pour eux, la consommation.
Lorsque tu seras obliger de comparer un x86 i72 avec 128 coeurs à un
T3 128 threads, je ne suis pas sûr que le x86 gagnera. L'avenir,
pour le x86 est aussi à la programmation multithreadée. Mais pour
cela, il faut des artistes. Toutes les bibliothèques permettant
soi-disant de faire ça le font mal parce que chaque parallélisation
est différente.

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
pehache-tolai
On 1 oct, 14:25, JKB wrote:

> Comme tu l'écris, si le truc est bien programmé !
> Est-ce les programmeurs sous x86, savent bien programmer en multicœur ?

        La réponse est clairement non pour l'immense majorité des
        développeurs.



Autrement dit, tous des cons, sauf JKB...


Et des rustines façon openmp ne sont pas là pour
        arranger les choses quand on voit les aberrations gén érées.



OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.

--
pehache
Avatar
PP
Le 01/10/2010 16:54, pehache-tolai a écrit :
On 1 oct, 14:25, JKB wrote:

Comme tu l'écris, si le truc est bien programmé !
Est-ce les programmeurs sous x86, savent bien programmer en multicœur ?



La réponse est clairement non pour l'immense majorité des
développeurs.



Autrement dit, tous des cons, sauf JKB...




je ne vois pas pourquoi tu dis cela.
JKB a un point vu plutôt interessant je trouve.
Il ne se contente pas de regarder l'amélioration des performances des
processeurs, mais de voir comment ils y arrivent.
Je suis assez convaincu par JKB, même si je suis de plus en plus
désappointé par le réactivité de Intel et de son x86.

Enfin, bon, je garde espoir, le Toshiba AC100 ferait tourner enfin une
Ubuntu 10.10, ce qui est je pense un évenement majeur!

imaginez la logithèque linux, accessible à un netbook de ce genre ...

ET même si ARM tegra2 c'est 32bits c'est pas bien, au moins c'est
différent et certainement mieux en terme d'héritage technologique !


Et des rustines façon openmp ne sont pas là pour
arranger les choses quand on voit les aberrations générées.



OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.



ouai le genre de fonction des processeurs dont les publications sont
discrètes au point que personne ne les utilisent parce que personne ne
sait comment ça marche sauf son copain Microsoft !
Comme je disais sur un autre forum, le brevet ne doit pas être dans
l'instruction, mais dans la façon de la cabler !
C'est trop facile de dire, telle instruction, se code comme cela, pour
faire cela, et surtout faut payer pour la cabler !
Avatar
ST
On 10/1/10 10:54 PM, pehache-tolai wrote:

Autrement dit, tous des cons, sauf JKB...



Ben comment ! tu savais pas ?

OpenMP fonctionne très bien quand on l'utilise correctement et à ce
pour quoi il est fait.



Alors OpenMP aurait été écrit par JKB !
Avatar
Richard
Le 30/09/2010 09:11, JKB a écrit :

Maintenant tout ça a un coût en consommation, c'est
certain, mais ce coût on le réduit en améliorant les processeurs.



Permets-moi d'en douter. L'évolution du x86 ne se fait pas en
optimisant la circuiterie, mais en rajoutant des tas de rustines
pour contourner les problèmes de l'architecture. Au final, tu as un
processeur qui consomme de plus en plus et qui doit être le pire en
terme de rapport entre la puissance consommée et le puissance de
calcul. La seule chose qui le sauve encore, c'est la finesse de
gravure qui le rend moins consommateur, mais cette course à une
limite : non seulement les circuits rajoutés atteindront très
rapidement leur limites, mais les autres fondeur qui font du vrai
RISC vont aussi atteindre ses performances avec des consommations
largement moindres.



Je crois comme Michel Talon que l'avantage du RISC sur le CISC est
aujourd'hui nul. Le gros des transistors d'un CPU actuel, ce sont les
mémoires caches. Le surplus de circuiterie pour traduire les
instructions CISC en micro-instruction RISC est complétement négligeable.
J'ai même ouï dire que, les instructions CISC étant plus courtes que les
RISC, leur lecture en mémoire est plus efficace que sur un processeur RISC.

Le débat RISC contre CISC est même sans doute dépassé. Aujourd'hui c'est
plus la comparaison GPU/CPU qui est en vogue.

--
Richard
Avatar
PP
Le 02/10/2010 09:08, Richard a écrit :
Le 30/09/2010 09:11, JKB a écrit :

Maintenant tout ça a un coût en consommation, c'est
certain, mais ce coût on le réduit en améliorant les processeurs.



Permets-moi d'en douter. L'évolution du x86 ne se fait pas en
optimisant la circuiterie, mais en rajoutant des tas de rustines
pour contourner les problèmes de l'architecture. Au final, tu as un
processeur qui consomme de plus en plus et qui doit être le pire en
terme de rapport entre la puissance consommée et le puissance de
calcul. La seule chose qui le sauve encore, c'est la finesse de
gravure qui le rend moins consommateur, mais cette course à une
limite : non seulement les circuits rajoutés atteindront très
rapidement leur limites, mais les autres fondeur qui font du vrai
RISC vont aussi atteindre ses performances avec des consommations
largement moindres.



Je crois comme Michel Talon que l'avantage du RISC sur le CISC est
aujourd'hui nul. Le gros des transistors d'un CPU actuel, ce sont les
mémoires caches. Le surplus de circuiterie pour traduire les
instructions CISC en micro-instruction RISC est complétement négligeable.
J'ai même ouï dire que, les instructions CISC étant plus courtes que les
RISC, leur lecture en mémoire est plus efficace que sur un processeur RISC.

Le débat RISC contre CISC est même sans doute dépassé. Aujourd'hui c'est
plus la comparaison GPU/CPU qui est en vogue.



Le problème n'est pas une problème de RISC ou bien de CISC.
Si un CISC est bien optimisé cela permet de simplifier le code, et d'en
améliorer le rendement/exécution.

Ma critique va dans le sens que l'x86 ne parait pas propre, qu'il fait
de gros progrès ce qui le rend toujours aussi populaire voire de plus en
plus, alors qu'il traine des casseroles plus grosses les unes que les
autres.
La perte d'efficacité est vraiment dommage, car on pourrait avoir des
machines plus efficace/puissante.

Mais voilà, il faudra accepter de lacher une partie de la logithèque qui
fait le succès du couple Wintel, et qui n'a pas alors beaucoup
d'incitation à faire évoluer les choses proprement
9 10 11 12 13