Journal : utilité du i386
Posté par seginus () le 13 janvier 2007
0
Voilà, j'ai découvert récemment archlinux qui me plaît beaucoup, mais je ne vais pas rentrer en détail sur ce point ici.Cette distribution est optimisé pour les processeurs 686. Certains diront que ce n'est pas bien parce que c'est rejeter des architectures (mais non je ne pense pas au débianiste).
J'ai installé Linux sur beaucoup d'ordi, dont des plus tout jeunes. Et bien je n'ai jamais utilisé d'architecture inférieur au i686.
Et c'est la que je me pose une question : pourquoi une distribution comme ubuntu ne compile-t-elle pas sa distribution en 686 vu que de toute façon, elle ne tournera pas (ou difficilement) sur un 386 vu que les carte-mère gérant de tel processeurs ne géraient déjà pas une grande quantité de mémoire (en edo en plus, ne pensais même pas rajouter une barrette de 256).
De plus je pense que celui qui va installer linux sur une telle machine va plutôt s'orienter vers une debian ou une slackware.
Voilà, c'est juste une question que je me posais et que je pose donc tout haut. Quelqu'un a-t-il une raison à cela ?
> Lire le journal (57 commentaires, moyenne: 3,3).
Vous avez demandé le commentaire #794131.
Run by 
Cette page a été générée par Templeet en 0.1122s (dont 0.0108 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
[+] Qu'est-ce que ca change?
Quelles ont été les évolutions depuis i386?
Pas grand chose qui permette de dire que compiler en i686 est plus rapide que i386.
Est qu'est-ce que le i686? En fait, si je regarde le man de gcc,
http://www.hmug.org/man/1/gcc.php
i686 = Intel PentiumPro CPU
Tu en as vu beaucoup des Pentium pro? Pas moi.
Après, tu vas devoir choisir entre AMD K6 ou K7, Intel P4 ou Core Duo, etc... hum. Pourquoi alors privilégier des vieuw Pentium Pro?
Bref, le jour où on me montrera que compiler pour i686 est plus rapide que i386 sur un Intel Core 2 Duo et un AMD K7, peut-être que je compilerai moi-même en i686, mais pour le moment, ben... non, à part compiler pour toutes les architectures, le i386 reste le plus universel.
[^]Re: Qu'est-ce que ca change?
Peut-être parce qu'entre i386 et i686, il y a tout un tas de nouvelles instructions, qui sont dispos sur tout les processeurs ci-après, je pense donc que ça a de fortes chances d'optimiser au moins certaines applications.
Je pense qu'utiliser ses instructions permettent de gagner aussi bien sur un core 2 que sur un AMD K7. Que le gain ne soit pas forcément le même entre les deux c'est quasi-forcé, mais je pense qu'il y a un gain. Sauf qu'à remplacer les nouvelles instructions par des blocs d'instructions équivalentes et dispos sur i386 permettent de gagner sur l'un des deux processeurs(se dont je doute tout de même, ce serait illogiques, mais pourquoi pas après tout...).
[^]Re: Qu'est-ce que ca change?
bah moi sur mon intel core2 duo, c'est en x86_64 :p (et oui j'ai dû repackager des backports donc j'ai effectivement recompilé).
bon après, l'utilisation du x86_64 met en avant les limitations des logiciels avec java en dépendance (oui je pense à la compil' de OOo qui segfaulte à 98% de la compil') ou firefox dont le greffon java segfaulte méchamment (et vivement que gnash soit encore un peu plus abouti).
[^]Re: Qu'est-ce que ca change?
Je doute qu'actuellement (en 4.1) , GCC soit vraiment capable de profiter de ces différences de jeux d'instructions. GCC est réputé pour être un bon compilateur très généraliste (beaucoup d'architectures supportées) au détriment des optimisations pour chacun d'entre eux. De plus, depuis le i386, les instructions qui sont apparues correspondent à des besoins très particuliers surtout pour le calcul multimedia. A côté de ça, les instructions existantes très utilisées ont été optimisées au maximum ce qui fait que le même code s'exécute plus vite.
Bref, je doute que GCC puisse facilement tirer parti de ces nouvelles instructions (même si l'après-4.1 devrait améliorer les choses mais sans vraiment utiliser ces instructions). Après, si on veut des optimisations Intel, il suffit d'utiliser le compilateur d'Intel qui ne compile pour les x86 !
[^]Re: Qu'est-ce que ca change?
Et n'utiliser le compilateur intel que pour les intels, pas pour les AMD ;-)
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
[^]Re: Qu'est-ce que ca change?
Et quand on n'est pas trop exigeant sur la sémantique des calculs sur les nombres flottants.
http://david.monniaux.free.fr/dotclear/index.php/2006/03/17/(...)
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
[^]Re: Qu'est-ce que ca change?
Bin oui, mais quand on parle de compiler toute une édition en i686, on parle de compiler aussi les applications multimedias. Le but n'est pas non plus d'optimiser bash ;).
Et justement, une édition comme Ubuntu étant à destination du grand publique, elle doit donc être tournée multi-media.
Après, on est d'accord, le gain est sans doute faible. La question est: est-il négligeable? Mais ce que l'auteur du journal disait, c'était que de toute façon, Ubuntu sur un Pentium n'est pas forcément génial, donc autant sauter le pas.
Sinon, je suis d'accord, c'est surtout les instructions existantes qui sont optimisées. Parce qu'il faut bien que 4 jours avant la sortie du proc, les benchs en mettent au maximum plein la vue. Et puis bon, tout le monde n'a pas la chance d'utiliser Gentoo.
[^]Re: Qu'est-ce que ca change?
Les applications multimédia (couche bas-niveau) il n'y en pas pas des milliers et les applications scientifique non plus. Par exemple, pour la bibliothèque fftw on trouve trois versions spécialisé sur debian : p4fftwgel2, k6fftwgel2k et k7fftwgel2. Avec l'une de ces versions, j'ai vu un code tourner 5 fois plus vite. Cependant, ce cas de figure est rare. Il suffit donc d'avoir quelques bibliothèques optimisés et cela suffit. Je ne sais pas ce que vous faisez de votre machine mais mon expérience personnel montre que globalement un PC aujourd'hui ne fait rien (sauf ponctuellement). Il n'y a donc pas intérêt à complexifier les distributions pour des programmes comme bash.
Je me souviens un bench il y a quelques années qui comparait la gentoo à la debian compilé pour 386. Globalement la debian allait plus vite que la gentoo (sauf quelques bench) ce qui m'avait pas mal surpris mais pas déplu ;-)
Il vaut voir qu'a chaque fois qu'on change les paramètres de compilation, les bogues ne sont pas toujours reproductibles. C'est bien de compiler avec plusieurs compilateurs et plusieurs jeux de paramètres mais il faut encore pouvoir ensuite maitriser son Bogue Tracking System et arriver à en faire quelque chose.
[^]Re: Qu'est-ce que ca change?
Un journal qui traite du fameux bench:
http://linuxfr.org/2003/08/13/13629.html
[^]Re: Qu'est-ce que ca change?
De plus, depuis le i386, les instructions qui sont apparues correspondent à des besoins très particuliers surtout pour le calcul multimedia.
Il n'y a pas que le jeu d'instruction qui compte m'ai aussi leur performance et l'ordonancement.
Sur certaines familles il peut etre plus interresant de faire des additions avec l'instruction X alors qu'avec une autre famille il faut mieux utiliser l'instruction Y.
D'ailleurs gcc propose ce choix : compiler avec un jeu d'instruction donné en optimisant pour une archi.
[^]Re: Qu'est-ce que ca change?
C"est perninent en effet, mais l' architecture P6 (pentium pro, I686), est quasi-universelle en desktop/laptop/serveur.
Pourquoi dans l' architecture PC (X86) devraient on ce contenter du i386 ?
La Mandriva ( mandrake ) en i586 a donné une premiére impulsion. Qui irait installer une "ce que vous voulez" sur un pentium 75 ?
Gael tu as eu une trés bonne idée la dessus
Les seules distributions utilisable pour ce type de machines sont dédiées . Et je suis optimiste.
Maintenant, il faut être clair : on ne passe pas son temps a traiter des données en 64 ou 128 bit. Le I386 est encore nettement suffisant pour beaucoup d ' application.
Il y a un juste compromis a trouver.....
L'erreur est humaine, mais un véritable désastre nécessite un ordinateur.
[^]Re: Qu'est-ce que ca change?
Par expérience, pour avoir déjà recompiler des distributions complètes sur PowerPC et sur ix86, je confirme qu'optimiser la compilation pour le processeur cible apporte un gain de performance non négligeable.
Si tu pense qu'un i386 est équivalent à un Core 2 Duo, libre à toi. le ridicule ne tue pas !
Il serait temps qu'aujourd'hui les distribs "grands public" soit optimisé pour les CPUs récent et exploite leurs nouvelles instructions, en particulier les instructions vectorielles MMX et SSE*. Utiliser l'auto-vectorization de GCC ne coute rien et rapporte beaucoup !
Et demain, avec la généralisation des architectures multi core, l'auto-parallelisation du code est là aussi une fonctionnalité de GCC a activer, qui ne coute rien et rapporte beaucoup.
[^]Re: Qu'est-ce que ca change?
Je ne connais pas grand chose à l'optimisation, mes notions d'assembleur sont vraiment légères, et je ne suis pas programmeur, mais il me semble que les jeux d'instructions mmx, sse, etc., par exemple, sont largement orientées pour certains types d'applications.
Ma question est donc: est-il pertinent d'y avoir recours pour tout type d'applications, ou justement de ne s'en servir que là où ils sont réellement efficaces?
Ca prendrait un temps fou et nécessiterait des connaissances techniques bien au-delà des miennes, mais un test à faire:
- prendre une debian (on n'est pas vendredi, mais en Chine les trolls, c'est tous les jours :D) standard, avec les paquets 586 ou 686 quand ils sont dispos
- recompiler intégralement tous les paquets de la debian ci-dessus, pour une utilisation bureautique/loisirs/ce-que-vous-faites-de-votre-ordi
et faire une série de tests pour voir si on sent vraiment une différence
(je précise que je ne m'intéresse pas aux benchs genre "on voit bien que A prend 3ms et B 7ms pour faire blablabla", parce que moi, entre 3ms et 7ms, j'ai besoin d'être vachement concentré pour espérer sentir la différence sur une opération ponctuelle)
Bon! Personne ne va le faire (certainement pas moi d'abord!)! Donc, on n'a aucune information objective pour démontrer qui a raison et qui a tord!
A VOS TROLLS! :D
[^]Re: Qu'est-ce que ca change?
Le plus simple, c'est encore de prendre une gentoo... Elle est faite pour être recompilée ;-)
D'ailleurs, c'est un débat qui a déjà eu lieu maintes et maintes fois à propos de cette distrib' : gagne-t-on vraiment beaucoup en recompilant tout ? Je n'ai jamais eu de véritable réponse...
En tout cas pour ma part, le temps perdu à recompiler le compense pas le temps gagné à l'exécution !
[^]Re: Qu'est-ce que ca change?
Oui mais non!
Les patchs et les configurations entre une debian et une gentoo n'ont rien à voir !
Faut comparer une debian avec une debian ou une gentoo avec une gentoo, sinon ca voudra rien dire...
[^]Re: Qu'est-ce que ca change?
Ce test a déjà été fait, et alors, chose incroyable, Debian i386 se revèle plus rapide que gentoo en moyenne. Amusant ;-)
http://linuxfr.org/2003/08/13/13629.html
[^]Re: Qu'est-ce que ca change?
...Et après, mon commentaire initial sur le sujet (comme quoi compiler en i686 c'est pas mieux que compiler en i386, donc pas d'interet spécialement de diffuser du i686) se fait moinsser, pas mal... Faudra m'expliquer pourquoi, il me semble que je n'avais pas si tord que ça...
Mais bon, passons!
[^]Re: Qu'est-ce que ca change?
Utiliser l'auto-vectorization de GCC ne coute rien et rapporte beaucoup
J'aimerais bien voir des bench pour confirmer ça (perso j'y crois pas -- lui non plus: http://gcc.gnu.org/ml/gcc/2007-01/msg00288.html )
[^]Re: Qu'est-ce que ca change?
Euh, il me semblait que PPC était justement hyper sensible aux optimisations. Du genre, une bête compilation linéaire du code pouvait être bien moins performante qu'une réorganisation équivalente de celui-ci, mais exploitant les spécificités(sans même parler des instructions).
Côté x86, j'ai l'impression que la multiplication des architectures pousse ce travail de réorganisation du code au niveau du processeur plutôt qu'au niveau du compilo, ce qui est bien dommage car cela joue sur le coût du processeur et sur sa consommation.
Quelqu'un peut confirmer?
[^]Re: Qu'est-ce que ca change?
Euh, il me semblait que PPC était justement hyper sensible aux optimisations.
Comme toutes machines RISC, ou chaque instruction fait qu'une chose et c'est au compilo de se debrouiller pour les mettres quand il faut en tenant compte des specificité de la machine.
[^]Re: Qu'est-ce que ca change?
Des preuves, je veux des preuves!
J'arrete pas d'entendre les gens dire "c'est plus rapide", "c'est plus lent", jamais sans benchs
Ah si : j'ai vu quelques benchs, tous donnaient un gain de perfs négligeable, voir négatif, alors bon... J'ai plus les URLs sous la main, zut, mais voila, j'en garde le souvenir que compiler avec GCC en i386 ou autre, ca ne change pas grand chose...
Apportez des preuves SVP!
[^]Re: Qu'est-ce que ca change?
Je n'ai jamais dit ca, tu détournes mes dires pour te faire plaisir.
un Core 2 Duo va optimiser le code i386 à l'exécution, et au final le gain est nul. Depuis le i386, il n'y a pas eu de nouvelle instructions fulgurantes qui accelere autre chose que le multimédia, ce qui a changé est l'optimisation des instructions existantes.
D'ou le gain quasi nul de la compilation en autre que i386.
Maintenant, si tu peux m'apporter des preuves, en tous cas le troll de LFS ou Gentoo montre que ce n'est pas si évident que tu sembles vouloir le croire...
[^]Re: Qu'est-ce que ca change?
Maintenant, si tu peux m'apporter des preuves, en tous cas le troll de LFS ou Gentoo montre que ce n'est pas si évident que tu sembles vouloir le croire...
Ben ecoute dans un stage, on était sur des xeon HT 3Ghz.
On a fait certains test de calcul scientifique, et entre gcc et icc on obtenait plus de 20% de perfs sur certains code.
Alors ensuite en restant tout le temps sous gcc je sais pas, mais en optimisant pour l'archi lors de la compilation, sisi on peut gagner bcp !
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Qu'est-ce que ca change?
Rien a voir, donc. Ca prouve juste que icc est un meilleur compilo que gcc, ce qui n'est pas franchement nouveau et est completement orthogonal au fait de compiler pour i386/i486/i586/i686.
Cela n'empeche que pour certaines applications, passer les bons parametres a la compilation peut effectivement apporter un gain en perf non negligeable pour certaines applis, scientifiques ou multimedia entre autre, via l'utilisation du MMX, SSE, etc... Encore faut-il que le compilo reussisse a reperer les cas ou il peut s'en servir, ce qui est loin d'etre evident.
Apres on peu aussi jouer sur le scheduling et les temps de latence des instructions pour grapiller encore un peu ; mais on arrive au point ou il faudrait de toute facon recompiler les applis soi-meme, donc pas pour une distro binaire.
Plus ou moins dans le meme sujet, j'ai relu hier un article[1] sur l'Itanium et les difficultes d'optimisations avec. Pour un appel systeme L4, le compilo arrivait a 508 cycles. Apres pas mal de boulot et d'assembleur ecrit a la main, ils sont descendus a 36 cycles...
[1] http://www.usenix.org/events/usenix05/tech/general/gray/gray(...)
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: Qu'est-ce que ca change?
Rien a voir, donc. Ca prouve juste que icc est un meilleur compilo que gcc, ce qui n'est pas franchement nouveau et est completement orthogonal au fait de compiler pour i386/i486/i586/i686.
Donc on peut pas prendre les optimisation de gcc suivant l'archi comme montrant qu'on ne peut rien gagner, vu que tu dis toi meme que c'est un 'mauvais compilo' , il fait donc pe mal ces optimisations ;)
ps icc permet aussi de spécifier l'archi . Je serais curieux de savoir si la aussi on 'gagne rien' ou pas.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Qu'est-ce que ca change?
J'ai pas dit qu'il etait mauvais mais qu'il etait moins bon. Et ca ne veut pas dire que les optimisations ne sont pas valides. Il me semble meme que pour l'Itanium, a une epoque, gcc etait meilleur sur cetains aspects, et icc sur beaucoup d'autres. Pour faire une analogie avec mon boulot, ce n'est pas parce qu'une F1 (la RB2 en l'occurence) a une aerodynamique pas terrible que passer a une boite seemless shift ne peut pas nous faire gagner 2 dixiemes au tour.
Je n'ai pas dit qu'il n'y avait rien a gagner, hein. Les problemes des optimisations au-dela du 486, en gros, c'est que :
-MMX, SSE, etc... c'est pas des instructions triviales, pour que le compilo reussisse a retrouver ses petits, c'est pas gagne. C'est pas pour rien que les mecs se font de sbouts en assembleur...
-si on fait abstraction des differences de jeux d'instructions, on joue sur leur scheduling, ce qui veut dire qu'on va privilegier une arch plutot qu'une autre. C'est assez genant quand on a des differences aussi fondamentales qu'entre P3, P4 et K7 (surtout le P4). Mais quand on arrive a ce stade-la, je doute que les differences soient vraiment perceptibles pour les applis classiques ; donc j'aurais tendance a penser que effectivement ca vaut le coup pour les applis de calcul vraiment intensives, mais pour le reste...
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: Qu'est-ce que ca change?
Juste quelques exemples
Avec le bench Polyhedron
Sur un Athlon XP 1900+ (avec g95, le dernier gfortran de la FC6 ayant un bug sur ix86)
i386 == 1629s (-O2 -mtune=i386)
athlon-xp == 1551s (-O3 -march=athlon-xp -mmmx -m3dnow -msse -mfpmath=sse,387)
Sur un Opteron 285 où par défaut gcc utilise déjà mmx, sse, sse2 en 64 bits avec gfortran
x86_64 == 569s (-O2)
amd64e == 535s (-O3 -march=opteron -msse3)
Alors oui, ça vaut le coup d'optimiser sa compilation pour le processur cible.
Juste pour info, avec pgf90 6.2, le bench dure 439s... gfortran a encore de la marge pour gagner en optimisation...
Ensuite, concernant le gain sur une distrib complète avec les mêmes versions de logiciels bien sûr...
avec 500 itérations de gtkperf
Fedora Core 6 == 142s
Gentoo optimisé == 117s
Encore une fois ça vaut le coup d'optimiser une distrib à la compil !!
Sinon on peut vraiment se demander à quoi ça sert que les fondeurs se décarcasse à sortir des nouvelles fonctions à leur CPU, ou encore que les devs de GCC continue à bosser !!
Sur certains codes scientifiques faisant un usage considérables de matrices, les gains, lors de l'utilisation des instructions vectorielles et des fonctions spécifiques du CPU, peuvent être phénoménaux...
[^]Re: Qu'est-ce que ca change?
Tu aurais le bench avec le meme niveau d'optim pour les differents cas ? Parce que la, on ne sait pas si ce qui ameliore les perfs c'est le -O3 ou les autres flags. Bref, ton bench vaut 0 comme comparaison pour le sujet qui nous interesse.
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: Qu'est-ce que ca change?
Tu utilises O3 à la place de O2 lorsque tu compiles en spécifiant l'architecture...
Dans certaines grosses applications, le code généré par le compilateur peut-être plus volumineux lorsque tu optimises, et ça peut dégrader les perfs.
J'ai du mal à croire que les différences dans les résultats obtenus avec gtkperf ne soit due qu'aux flags de compil.
[^]Re: Qu'est-ce que ca change?
Les benchmarks montrent que dans une utilisation courante, il y a déjà très très peu de différences entre une distro 32 et 64 bits. Alors franchement, tout recompiler en 686..