Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
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
11 12 13 14 15
Avatar
Miod Vallat
Ça, permets-moi d'en douter. Les instructions (avec leurs opérandes)
font 32 ou 64 bits selon les modes sur un UltraSparc (soit un mot
mémoire). Sur Alpha, c'est 64 bits. Rien ne dépasse.



Non, sur ultrasparc comme sur alpha, les instructions mesurent 32 bits.
Avatar
pehache-youplaboum
"PP" a écrit dans le message de news:
4ca6e4a9$0$689$

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.



Pourquoi se prendre le choux ? Si vraiment l'x86 traine de si grosses
casseroles que ça, ça finira par se voir un jour. En attendant il progresse
régulièrement et c'est le principal.

La perte d'efficacité est vraiment dommage, car on pourrait avoir des
machines plus efficace/puissante.



On a des machines toujours plus efficaces et toujours plus puissantes basées
sur du x86. Le jour où ça ne sera plus vrai, t'inquiète pas, d'autres
architectures prendront rapidement sa place.


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



La logithèque n'est pas le problème. Ou très peu. Recompiler les applis pour
une autre plateforme ce serait assez simple. Même Microsoft, quoi qu'on en
dise, pourrait porter relativement facilement Windows sur une autre
plateforme si vraiment ils y étaient obligés. Apple est bien passé du
PowerPC au x86 sans gros problème (après être passé du 68xxx au PowerPC).

Le problème vient beaucoup plus de tout le matériel et de tout les drivers
fournis par les tierces parties, qui ne seraient pas forcément réactifs pour
tout réécrire pour une autre architecture. Il n'y a qu'à voir tous les
problèmes de drivers non disponibles pour Windows 64 bits (ça commence à
aller mieux, visiblement, mais il fallut du temps). A la différence d'Apple,
Microsoft ne contrôle pas son environnement matériel et du coup est plus ou
moins prisonnier du x86 aujourd'hui.

Cela dit, Linux sur autre chose que le x86 aujourd'hui, ce n'est pas
forcément gagné d'avance pour les utilisateurs.

--
pehache
http://pehache.free.fr
Avatar
JKB
Le 02 Oct 2010 10:00:01 GMT,
Nicolas George <nicolas$ écrivait :
JKB , dans le message , a
écrit :
Tu n'as pas forcément le _choix_, surtout lorsque la chose doit être
_portable_.



Ben si.



Ben non. signalfd() n'est _pas_ portable.

Par ailleurs, un thread dédié, ce n'est pas forcément
optimal du point de vue du CPU.



D'où l'intérêt de signalfd.



Non, c'est une mauvaise réponse à une bonne question.

Et tu peux aussi être contraint d'utiliser des signaux par thread.



Non, on n'est jamais contraint d'utiliser des signaux par thread, c'est un
choix de design. Un choix mauvais.



Permets-moi d'en douter. Il y a des tas d'applications où tu dois
signaler proprement un thread. Que tu n'aies jamais été contraint de
le faire est autre chose. D'ailleurs, si ce n'était pas nécessaire,
explique-moi d'où vient la rustine signalfd().

Il y a d'ailleurs tout un tas de mécanismes dans POSIX 2001 pour
faire ça.



Ça prouve quoi ? gets aussi est POSIX.



Que signalfd() ne sert à rien sauf à écrire des choses non
portables.

Quant à signalfd, c'est une hérésie linuxienne qui devrait tomber
dans les oubliettes de l'histoire informatique !



Ce sont les signaux qui devraient tomber dans les oubliettes de l'histoire
d'Unix. Le principe d'Unix, c'est : tout est fichier.



Et un fichier est asynchrone peut-être ?

Là encore, tu ne retiens que ce que tu veux bien retenir. J'ai pris
un _exemple_, mais tu ne dois pas savoir ce que c'est. La plupart
des ALU des processeurs 32 bits tournent sur plus de 32 bits (réels
ou émulés). Pour le i386, le bus d'adresse interne est de 48 bits,
ce qui permet de sortir le fameux PAE. Les calculs internes
d'adresses se font sur 48 bits même si le bus externe s'arrête à 4
Go de mémoire adressable. Toute la circuiterie est là



On s'en fout : les registres généraux font 32 bits, pour manipuler des
données plus grosses, il faut jongler.



Ton propos, c'est que c'est au programmeur de jongler. Je prétends
que c'est faux, c'est à l'OS de le faire et ça doit être
transparent. Merci de prouver une fois de plus que tu fais une
pirouette pour retomber sur tes pieds dès que tu es à cours
d'argument.

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
JKB , dans le message , a
écrit :
Ben non. signalfd() n'est _pas_ portable.



Donc thread dédié pour l'émuler.

Non, c'est une mauvaise réponse à une bonne question.



Affirmation gratuite.

D'ailleurs, si ce n'était pas nécessaire,
explique-moi d'où vient la rustine signalfd().



Ça a été conçu pour les utilisations historiques des threads, qui n'ont rien
à voir avec les signaux.

Et un fichier est asynchrone peut-être ?



Non, justement, c'est bien le but.

Ton propos, c'est que c'est au programmeur de jongler. Je prétends
que c'est faux, c'est à l'OS de le faire et ça doit être
transparent.



L'OS ne peut pas rendre l'arithmétique sur plus que la taille des registres
généraux efficace.
Avatar
Stephane CARPENTIER
pehache-youplaboum a écrit:

"PP" a écrit dans le message de news:
4ca655a0$0$690$
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.



La réponse est quelques lignes plus haut.



En gros, tu considères que tous les programmeurs qui ne savent pas bi en
programmer en multic?ur sont des cons ?
Avatar
PP
Le 02/10/2010 11:06, Tonton Th a écrit :
On 10/01/2010 11:41 PM, PP wrote:
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 ...



Il ne manque plus que des vrais Linux, quoi.



Si t'en mets, je pense que tu peux tous les mettre !
Tout est question de liberté du code pour certaines distributions

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 !



Tu aurais un lien vers la fiche technique de ce CPU ?



Non précisément, mais sur le site blogarm.net par exemple ils en ont
beaucoup parlé avec de nombreux liens.
Avatar
PP
Le 02/10/2010 11:38, pehache-youplaboum a écrit :

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.



Tu es désappointé par le fait qu'Intel fasse beaucoup d'efforts de
développement sur les x86 ??



Je suis désappointé par le fait qu'on pourrait avoir des machines
peut-être encore plus puissante et meilleur marché, et surtout avoir des
machines plus petite, silencieuse, etc. si on ne se coltinait pas la
technologie x86, ou plutôt son héritage rustinique de 30 ans !
Heureusement qu'Intel fait des progrès, sinon, les concurrents auraient
depuis de nombreuses années pris la relève.

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 ...



La logithèque Linux accessible sur les netbooks, ce n'est pas
franchement nouveau...



Netbooks autres que x86, bien sûr !

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 !



Mais qu'est-ce que tu racontes ???

OpenMP est une spécification décrivant des directives et des appels de
routines pour faire de la programmation parallèle en C ou en Fortran.
Rien à voir avec Microsoft, et ces spécifications sont publiques.



je parle de certaines fonctions des processeurs Intel ou x86, qui sont
peu voire non décrite (d'après un truc que j'ai lu il y a quelques jours
sur le net). Je trouve cela vachement interessant le concept !!
Soit c'est faux, soit c'est vrai et c'est plus grave, car qui utilise
alors ces fonctions/instructions ?
Je ne parle pas de compilation, je parle des processeurs eux-même !
Avatar
JKB
Le Sat, 2 Oct 2010 10:15:41 +0000 (UTC),
Miod Vallat écrivait :
Ça, permets-moi d'en douter. Les instructions (avec leurs opérandes)
font 32 ou 64 bits selon les modes sur un UltraSparc (soit un mot
mémoire). Sur Alpha, c'est 64 bits. Rien ne dépasse.



Non, sur ultrasparc comme sur alpha, les instructions mesurent 32 bits.



Sur alpha, j'avais un doute. Le reste, c'est le l'abus de langage
parce que pour moi, une opération de chargement immédiat tient sur
deux fois 32 bits.

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
JKB
Le 02 Oct 2010 10:31:20 GMT,
Nicolas George <nicolas$ écrivait :
JKB , dans le message , a
écrit :
Ben non. signalfd() n'est _pas_ portable.



Donc thread dédié pour l'émuler.



Ce qui je le répète peut être idiot lorsque le signal s'adresse à un
thread spécifique, ou lorsque le signal doit récupérer une clef au
sens de la pthread. Il y a des tas d'applications où tu ne peux pas
faire comme ça et qui n'ont pas été codées par des pieds.

Non, c'est une mauvaise réponse à une bonne question.



Affirmation gratuite.



Prouve-le.

D'ailleurs, si ce n'était pas nécessaire,
explique-moi d'où vient la rustine signalfd().



Ça a été conçu pour les utilisations historiques des threads, qui n'ont rien
à voir avec les signaux.



Et le rapport avec la choucroute ? Je ne sais pas si tu rends bien
compte de ce que tu écris ou si tu as le début d'une expérience de
programmation multithreadée. Ton fameux signalfd() est idiot. Je
prétends que c'est une mauvaise réponse à une bonne question parce
que c'est le pire truc qu'on puisse faire. Tu remplaces la gestion
des signaux asynchrones par un truc synchrone pour ne pas être
obligé de rendre tes gestionnaires de signaux thread safe (parce que
le fond du problème est là). En effet, tu ne peux utiliser dans un
gestionnaire de signal un mutex que tu utilises ailleurs dans le
cours du programe sans protéger quelque peu ce mutex pour éviter que
le gestionnaire de signal ne soit appelé depuis un bloc où le mutex
est déjà verrouillé.

Donc tu remplaces ce code fastidieux à écrire par un autre code
synchrone. Au passage, tu remplaces le système d'interruptions par
un système de polling. Ce n'est plus du tout équivalent. Par
ailleurs, tu es aussi obligé d'utiliser des attentes actives. En
terme d'efficacité, c'est une catastrophe.

Au passage, depuis la dernière fois où tu m'as parlé de signalfd()
qui semble être ton grand truc, j'ai fait quelques tests pour voir
l'efficacité de la chose. Si le code est plus simple (forcément, il
n'y a plus d'appels asynchrones à gérer), le truc n'est vraiment pas
efficace.

Et un fichier est asynchrone peut-être ?



Non, justement, c'est bien le but.



En rajoutant un truc qui n'est supporté que par Linux ? Je rigole.

Ton propos, c'est que c'est au programmeur de jongler. Je prétends
que c'est faux, c'est à l'OS de le faire et ça doit être
transparent.



L'OS ne peut pas rendre l'arithmétique sur plus que la taille des registres
généraux efficace.



Ce n'est pas le débat. Réponds à la question. Tu prétends qu'il faut
faire des opérations complexes sources de bugs. Je te réponds que
c'est faux. Que vient faire dans le débat l'efficacité des calculs ?
Que viennent faire là-dedans les tailels des registres généraux ?
Surtout que rien ne dit que les registres d'adresses ne sont pas
plus long et que l'ALU n'est pas capable de calculer sur la longueur
des registres d'adresses. C'est d'ailleurs la moindre des choses
lorsqu'on essaye d'implanter dans un CISC des modes d'adressage
comme les adressages autoincrémentés ou décrémentés ou des
adressages à offset.

JKB

PS: je ne te répondrai qu'à partir du moment où tu resteras dans le
débat sans biaiser comme à ton habitude.

--
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
JKB
Le Sat, 02 Oct 2010 12:41:54 +0200,
Stephane CARPENTIER écrivait :
pehache-youplaboum a écrit:

"PP" a écrit dans le message de news:
4ca655a0$0$690$
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.



La réponse est quelques lignes plus haut.



En gros, tu considères que tous les programmeurs qui ne savent pas bien
programmer en multic?ur sont des cons ?



Pour lui, je ne sais pas. Tout ce que je peux dire, c'est qu'il
existe des tas d'excellents programmeurs qui sont incapables de
programmer quelque chose d'efficace dès qu'il s'agit de
programmation multithreadée. Cela n'en fait pas des cons pour
autant.

De la même façon, on peut être un très bon développeur sans savoir
écrire un bout de noyau d'OS. C'est exactement le même problème.

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
11 12 13 14 15