[débat] Gentoo / 64-bits

[-KuRGaN-]

C'est clair c'est sympa cette salle blanche mobile de Sun. Par contre, il doit faire une sacrée chaleur dedans quand même. Tiens, Sun devrait commercialisé un module pour leur blackbox, il envoit toute la chaleur dissipée par les serveurs dans une petite pièce à coté pour le sauna. Important le sauna pour tout admin qui se respecte.
_________________
Knight Gent00 Industries RiDeR !!!!

[TrizoLakai]

[titoucha]

Il ne faut pas oublier la facture d'électricité

[Scullder]

Je recadre : est-ce que quelqu'un a essayé net-www/nspluginwrapper pour faire passer les plugin 32bits sur un firefox 64bits. Qu'est ce que ça donne ?
Là je viens de recompiler mplayerplug-in en 32bits pour firefox-bin, tout en utilisant mplayer en 64bits, ça marche super bien
_________________
Linux gentoo 2.6.18-ck1-r2 #1 PREEMPT Fri Nov 17 01:37:56 CET 2006 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

[titoucha]

J'ai testé, j'arrive a avoir l'image mais pas le son.

[Jacqueline]

Je ne m'étais jamais trop posé de questions jusqu'à l'achat d'un PC avec un AMD64, les distributions en général proposant l'architecture 64 bits.. je pensais naïvement pouvoir bénéficier du gain de performances de ma nouvelle acquisition...

j'ai vite déchanté avec les histoitres de codecs, ce n''est pas vraiment génant, mais j'étais surprise de voir que les applis n'étaient pas toutes écrites pour fonctionner avec du 64 bits.. : normalement les applis écrites dans un langage dit "évolué " et donc "portable", c'est le compilateur qui se charge de faire l'adaptation au processeur utilisé et à l'OS..

Souvent j'entends dire qu'on obtient pas un gain de preformances réel avec l'AMD64 parce que les applis ne sont pas écrites pour le 64 bits.. c'est un peu décevant...

Une autre question que l'on voit souvent : d'ailleurs pour une distrib très en vogue on m'avait conseillé de mettre la version 32 bits... quelle déception.. ( c'est un peu comme la limitation de vitesse lorsqu'on possède une Porsche )..

J'essaye donc de comprendre d'où peuvent venir ces complications..

Hier j'ai un peu plongé dans la donc de référence de l'AMD64 ( 5 tomes de 4 à 500 pages...) ( je connaissais un peu le domaine des microprocs : les anciens : 8080 et 6502...... 6800 et 6502, qui sont aux nouveaux processeurs ce qu'une village est à une grande ville... avec les problèmes de circulation, d'embouteillage et de parkings.et de transports en commun... L'impression de la doc coutetait plus cehr que le procéseur lui même

En découvrant grub aussi.. ( mais l'étude du processus de boot est toujours intéressante ) j'avais découvert dans stage 1 une ligne qui indique à l'assembleur de générer du code 'mode réel" les instructions en assembleur d'un vieux 8080... grande découverte : on peut faire marcher un porcesseur 32 ou 64 bits , comme un bon vieux 8 bits, parce que le BIOS.. est resté une vieillerie.qui manipule des octets...

La lecture de la doc de l'AMD64 explique donc assez clairement avec des tableaux, les divers modes normalisés de fonctionement des processeurs.. et des Os qui doivent être adaptés en conséquence.. Le mode réel, le Legacy etc.. le mode 64 bits etc...

Avec une particularité de l'AMD de pouvoir manipuler des instructions et données sur 128 bits pour les calculs en nombre flottant.. qui doit apporter un gain de temps considérable pour le calcul scientifique..

ùmais en utilisation classique .. encore un tableau sur les instructions machines à travers les acages qui peuvent aller de 1 octet , jusqu'à 16, le gain dude performances du 64 bits me parait évident.. rien qu'au niveau de l'adressage..


Cette fois j'ai compris comment mon AMD64 pouvait accepter une distibution avec une architecture 32 bits.. mais c'est tout de même frustrant..

Je ne trouve pas que mon AMD va très vite, mais je n'ai pas assez de ram justement.. ' 512 Mo est vraiment trop juste. si j'oublie de refermer des applications consommatrices de mémoire, c'est très très lent... je suis obligée de passer à 1 Go, cette fois j'en ai la preuve.. j'espère aussi que gentoo participera à alléger le système; mais aussi les applis.. qui sont sytématiquement compilées pour les deux WM : KDE et Gnome.. je doute que ceratines distribs puissent fonctionner sur un ancien PC...

En poursuivant ma lecture, il me semble avoir compris cette chose :

Le 64 bits permet de gérer la mémoire avec des instructions plus larges.. et donc minimiser le nombre de cycles de lecture mémoire ( enfin ce n'est pas la mémoire ram, mais le cache qu'on tlit ) et on gagne plusieurs cycles machine pour décoder une instruction. et l' adresse.. La pagination mémoire est presque devnue inutile..

Je me souviens du premier calculateur auquel je me suis trouvée confrontée fin des années 70 , avec des blocs mémoires de 4 K ( et des mots de 20 bits par contre ), et toujours en service ! . on organisait le programme ( en assembleur c'était du temps réel ) dans les différents blocs :les données Ici, l'application là ; l'OS (très short ) dans un autre bloc, et diverses fonctions dans le dernier ...

Je me trompe peut être ;, mais c'est bien un peu ce qui est fait dans Linux ainsi que dans d'autres OS ) Il faut donner une allocation mémoire aux différentes applications ( que la mémoire soit paginée ou non. ) . et certaines zones sont interchangeables recevant un coup telle application, une autre fois, une autre.. selon les besoins du moment .. et le noyau demeurant en place..

( je n'avais pas ce problème sur mes antiquités l'ensemble du programme étant chargé en mémoire..parce que les disques ce n'était pas adapté au milieu industriel plein de poussière ) Il n'y avait donc pas d'allocation dynamique de la mémoire ( est-ce bien le mot juste ?)

Avec l'AMD 64 ( en simplifiant ) la mémoire est adressée de manière continue ( ou presque selon sa capacité ) et non par pages, mais il faut tout de même gérer l'allocation mémoire des zones de programmes.. on a plus de liberté, mais avec une mémoire paginée, il ne viendrait à l'idée de personne de placer un bout de programme à cheval sur deux pages mémoire.. on ne va pas lire deux pages de mémoire pour les mettre dans le cache du processeur pour éxécueter le programme alors qu'on peut le faire en une seule opération si le programme est localisé dans la même page de la RAM..

J'en conclus pour l'instant qu'un OS 32 bits était plus "ficelé" à la pagination de la mémoire héritée du 16 bits, qu'un OS 64 bits...

Pour l'instant , c'est de l'extrapolation gratuite, si je me trompe certains me le diront, mais j'essaye de comprendre les difficultés de ce passage au 64 bits pour certaines applications . On peut imaginer que certaines applis sont écrites en tenant compte de cette contrainte de pagination que gère l'OS 32 bits et d'autres non et elles doivent être réécrites.. ( parce que normalement , le compilateur gère l'adaptation du binaire au jeu d'instructions du processeur pour lequel on compile l'application ).

Enfin dans un autre document d'AMD : conseils aux dévelopeurs (de compilateurs surtout ) expliquait que pour optimiser l'utilisation de leur processeur et tirer partie de son architecture intime, il était préférable d'utiliser telle suite d'instructions machine que telle autre ( pour une meilleure utilisation des registres et des pointeurs.) ca c'est pour ceux qui créent les compilateurs..

Mais ils donnent un autre exemple , avec du java, il me semble , et là , c'est plus à l'attention de ceux qui écrivent les applications.. Ce qui signifie que les langages évolués ne sont pas si portables qu'on veut bien le dire.. tout diu moins pour tirer partie des performances du processeur 64 bits ...

j'imagine aussi qu'il y a des incompatibilités, lorsqu'on utilise des rpm qui n'ont pas été précompilés pour le 64 bits..et donc c'est une vraie liberté de compiler son linux à partir des sources, même si c'est plus long et plus compliqué..

Bien sur on peut toujours recompiler à partir des sources. d'un paquetage, mais ça m'a toujours paru délicat de le faire de manière isolée..

C'est l'exemple donné au dessus sur la façon de compiler les codecs ( zut en postant , je ne le vois plus pour le citer ) qui m'a interpelée... et aussi tout le mystère des flags.; (je connais leur utilisation dans l'assembleur, mais ça n'a pas ce coté magique et presque impénétrable dans la compilation.. c'est pour celà que j'aimais bien l'assembleur ! sur des processeurs simples, c'est plus facile, ( je me suis bien amusée sur le 6502 de mon Apple II en assembleur pendant que les copains faisaient des progs en basic sur leur commodore 64 ) mais sur des processeurs récents, il me semble inenvisageable d'écrire un programme en assembleur .. tellement l'architecture du processeur est complexe.. il doit y avoir un bon millier de lignes à écrire rien que pour initialiser correctement le processeur.. mais ça m'ennuye de perdre cette maîtrise.. de la même façon que ça m'ennuye d'utiliser linux sans comprendre comment ça marche..

Si je voulais m'attaquer à cette tâches ôur le processeur, , lorsque j'aurais fini de comprendre comment il marche, il ne sera plus fabriqué.. LOL !

L'architecture du Pc , un peu viellote , amène aussi beaucoup de complexité.. parfois je rève d'un sun avec un Sparc .. la doc du Sparc c'est 500 pages , pas 2500 ) et pour faire la même chose. ! Est ce que je dis une bétise, si Intel et AMD ont été obligés de faire des prouesses d'imagination pour rendre le PC performant à cause de cette architecture étriquée du PC. et tout ça pour assurer la compatibilité de Windows 3.1, puis W95, W98 sur cet engin... .

Sun en ayant d'emblée opté pour le 64 bits, me parait plus simple... tout est en harmonie 64 bits : le hard (proc, bus, mémoire) l'os et les applications.. je me demande combien de temps encore cette architecture de PC va résister.. ca oblige à des processeurs qui coutente cher et à les faire fonctionner à la limite..

Enfin dans la doc d'AMD que je me suis contentée de survoler , avec 2500 pages il faut se contenter de lire la table des matières et l'intro de quelques paragraphes particuliers ) il me semble avoir lu qu'on [b]pouvait le commuter de 64 à 32 bits pour éxécuter une tâche particulière en 32 bits.. [/b] Ca reste encore très mystérieux. pour moi.. mais je me dis que tout doit pouvoir fonctionner même si certaines applis n'ont pas été écrites pour ça : j'avoue en avoir douté, regrettant presque mon choix d'un Athlon 64 ).

j'imagine aussi que cette commutation convient pour une tache courte, mais que pendant ce temps à cause du threading où l'on mélange deux applis pendant les cycles d'une même instruction machine.. on ne peut pas mélanger les deux modes de fonctionnement.. appli courte, ce n'est pas le cas d'un codec pour regarder un film..

Ce sujet dépasse largement mes compétences , mais ça permet d'aborder la compilation de Gentoo en ayant une représentation moins mystérieuse du problème.. et une grosse envie de me débarraser des paquetages précompilés.. souvent les personnes qui ne ne connaissent pas bien le sujet réduisent la compilation à un coté "puriste" qui'ls trouvent un peu ridicule.. s'il n'y avait que cet argument, ce serait moins motivant..

D'autres m'ont soulagée, de mes appréhensions sur les flags en me disant que je devais prendre ceux qui étaient proposés.. OUFF ! je me voyais mal choisir moi même tous ces flags... mais utiliser ça bêtement m'aurait fort ennuyée..

Puis j'ai capté la notion des "ebuilds" pour réduire les temps de compilation.. je suppose que là aussi il faut choisir la bonne version ..

Dans le cas où l'ebuild n'existerait pas en 64 bits, je suppose que pour ne pas avoir à recompiler chaque fois un gros truc, on peut le faire une fois, le garder dans un coin et et le réutilsier ensuite ?

J'abandonne l'idée de tout comprendre dans les moindres détails, mau niveau du processeur, mais j'ai besoin d'un minimum de repères avant de faire quelque chose.. je dois avoir l'esprit trop terre à terre.. je ne suis pas de la génération des jeux vidéos.; et je n'ai jamais rien compris à l'informatique tant que je n'ai pas pu faire un lien avec ce qui se passait dans le hard , ma première formation.. même s'il me faut faire des impasses.... mais ça donne de bonnes notions pour comprendre l'interet de caches, des pipes et de l'hyperthreading dans les processeurs .. le dual core aussi.;

Intel a fait un diaporama , très bien , pour expliquer ça de façon très simple.. avec des boules de couleur.. je ne concois pas qu'on puisse aborder Linux sans avoir cette représentation mentale ... la notion de pipe existe aussi sous une autre forme au niveau de l'OS ...

Le bouquin de Casteyde ,sur linux je l'ai déjà lu plusieurs fois,.. chaque fois on capte plus de choses après avoir ferraillé un peu avec linux.. je vais le relire encore , c'est sur ! mais il y a des pans entiers que je ne connais pas pour n'avoir installé que des distribs friendly et wondowsiennes qui n'incitent guère à jouer de la console..

Jacqueline.

[titoucha]

@Jacqueline encore un petit effort avec la doc et tu passes développeuse

[truc]

Jacqueline (maman? c'est toi? Naaa... )

[Jacqueline]

Je serais morte avant d'avoir fini de lire la doc de l'Athlon et mon processeur aussi..

mais avant de plonger plus à fond dans Linux;... cette mise à jour au niveau des microprocesseurs.. était un peu nécessaire.;
l

- L hyperthreading , j'ai découvert ça dans la notice de ma CM il y a quelques mois.. mais j'imagine que ça a des conséquences sur la compil du kernel..

Je m'étais posé la question avant d'acheter sur l'interêt du Dual Core ( veinard ) pas beaucoup de réponses éclairées là où tu sais .

Dans le doute je n'ai pas trop forcé sur le modèle d'Athlon ... si jamais ça valait la peine de passer à un Dual Core ( j'ai choisi le socket en conséquence )

et je n'ai vu ce diaporama d'Intel que ces dernières semaines..

Je suppose aussi qu 'il doit bien trainer des flags ou alors c'est compris dans le modèle de processeur déclaré en tête de la compil , que l'OS doit gerérer tout ça de manière différente.. en plus comme ça a l'air configurable dans le BIOS, il ne faudrait pas avoir oublié de le configurer.. l'inconvénient de la distrib prémachée, c'est qu'on ne se pose pas ces questions avant de l'installer..

Récemment je suis tombée sur un sirete sur les processeurs qui expliquait les pipe.. dans le processeur.; je vois bien physiquement ce que c'est parce qu 'en 7_ j'avais fait uns tage hard chez le constructeur d'un premier calculo avec des instructions microprogramées ( avec comme formateur l'ingé qui avait pondu la machine ) et on pouvait dérouler l"'instruction en pas à pas, miroinstruction par micro instruction. a cette époque où l'on ne jetait pas les cartes ni les processeurs, on les dépannait ..

Sur ce site je lisais une remarque qui expliquait que le code devait être écrit en conséquences... poiur éviter qu'une instruction forme un bouchon à l'entrée du tuyau..si la suivante attend le résultat de la précédente. donc j'imagine que c'est encore un flag qui traine pour le compilateur.. amis chapeau bas.. personne n'urait osé le faire dans les années 80 ..

En tant qu'ancienne "hardeuse" (lol !) et avec le souci du temps qui est l'ennemi numéro 1 dans le temps réel je suis admirative devant ces techniques... que ce soit AMD ou Intel, qui n'existaient pas.. ( le tout premier calculo que j'ai vu il n'ya vait que des 7400 à l'intérieur.. ( quatre portes NAND dans un chip ) ... le second micropgrommé avec un jeu d'instructions plus élaboré ... et plus light. le suivant avec un scheduleur hard qui simplifiat l'OS de manière significative, mais heureusement qu'ils ont sorti les mémoires entrelacées ( ~ dual channel ) pour gagner du temps. de traitement.. les besoins avaient été un peu sous-estimes..

je suis contrainte de racheter 512 Mo de RAM, ça devrait faire du dual channel j'en comprend les avantages au niveau temps de réponsede la RAM, mais je pense que j'ai intéret à choisir le même modèle de la même marque..

Là je ne sais pas , si c'est pris en compte au niveau de l'insdtalll ou au niveau hard seulement... ( au rebbot ) mais c'est tellement flagrant que je devrais le voir assez rapidement.. Conclure de cette expérience que l'Arthlon64 n'apporte rien au niveau performances, par rapprt à un céleron.. je n'oserais pas le faire... mêmei pour l'instant je n'en ai pas vu les avantages.. opn pouvait estimer qu'avec un proc plus performant la place occupée en mémoire serait plus vite déblayée... grosse erreur !

Hier soir avec plein de trucs ouverts.. le temps de réponse au clic était très long,donc tu recliques et ça t'ouvre une appli en double..ou en triple et ça rame ( ou RAM) encore plus malgré la conf matérielle et logicielle en 64 bits... j'ai voulu faire l'essai car je n'avais jamais ramé comme ça avec la suse 9.2 et un vieux céleron, et 1 Go de ram ) jamais eu besoin de la swap.. mais à force de nous rajouter des trucs dans les distribs.. il ya plein de paquetages que je ne veux pas mais qui y sont d'office, en partie .. ( pourquoi on m'oblige à installer un bout de mono, un bout d'appamor, un bout de zen... , alors que je n'avais rien sélectionné ... à ce niveau ??? c'est pour vendre leur camelotte ? )


Je déduis aussi de ces lectures que l'installeur sur CD ou les liveCD sont compilés en mode Legacy pour s'installer sur n'importe quel PC..lorsque le choix n'est pas proposé.. par contre je n'ai pas vu dans la notice où et comment se faisait la commutation du mode legacy au mode 64 bits...

Après l'essai de ces live CD, tu te dis super mon processeur est reconnu. et bien géré.. lol !

[Jacqueline]

bonsoit truc !

Casteyde c'est la : http://casteyde.christian.free.fr/system/linux/guide/index.html


Intel : la vidéo c'est la ! en anglais et ça va un peu vite ...

http://www.intel.com/personal/desktop/dualcore/demo/popup/demo.htm


Le cours plus détaillé sur les"pipe" je le recherche et je le mets à la suite.. dans ce message lorsque je l'aurais retrouvé..


Là : http://www.geea.org/IMG/pdf/Cours_II.pdfhttp://www.geea.org/IMG/pdf/Cours_II.pdf

A comparer avec les pocesseurs RISC. : dont l'objectif est de traiter une instruction plus simple en un seul cycle machine..


Je l'avais lu juste avant la vidéo Intel , ça aide un peu..

Mais le mélange de tous ces techniques a quelque chose d'hallucinant.. au point qu'il y a une fonction debug dans le processeur pour que ses concepteurs s' y'retrouvent dans les tests.. Un Os qui gère ça , c'est pas mal non plus.. si je comprend bien qu'il est plus simple de gérer la vidéo ou une compil sur un dual core pendant qu'on fait autre chose sur l'autre coeur, ( deux procs bien séparés physiquement ) même s'ils sont dans le même boitier, je sens beaucoup moins l'hyper threading sur un monocore..

Le 64 bits , c'est plus évident sur les rares synoptiques d'AMD , niveau adressage et instructions, mais on peu regretter qu'il soit à l'étroit dans une architecture PC... un peu dépassée... et doive fonctionner en 32 bits au nom de cette compatibilité.... qu'on traine comme un boulet !

[titoucha]

@Jacqueline, pour moi le troisième lien est mort.

Très instructives tes recherches.

[Temet]

C'est pas un changement de forum qui va changer Jacqueline!

[nemo13]

[Jacqueline]

MDR ...Ttemet

Nemo .: on me charrie avec la longueur des posts..

Pour remplacer ce lien mort ( en le lisant une dernière fois avant de le coller j'ai pas révé )

Pour une approche simple du problème avant de regarder la vidéo d'Intel

http://fr.wikipedia.org/wiki/Pipeline_%28informatique%29


Les bouquins ..pour répondre à truc : il y en a des supers sur bien des sujets de l'informatique. ( j'aime bien traîner dans les librairies ) mais tu en as vite pour 200 euros..

[dapsaille]

Bonsoir jacqueline .....


nom de diou de sgreugneugneu .... mais heuu tu sors d'ou ??


Sérieusement je suis épatté par la pertinence de tes recherches et réflexions ...
on sens que tu aimes ca et ca fait plaisir de voire une représentante de la gente féminine tenir la dragée haute à la bande de velus que nous sommes (qui as parlé de machisme)

[Jacqueline]

Bonsoir dapsaille,

Merci pour cet accueil sympa

[Scullder]

[Jacqueline]

La doc j'ai tout d'abord trouvé ça : sur le site d' AMD ( 5 tomes de 500 pages mais c'est la référence et les tableaux expliquent bien les divers modes.., l'adressage mémoire, la longueur des instructions + données dans chaque mode ) je n'ai pas pu les coller , c'est du PDF...

http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html


Ce matin pur hasard en fouinant un peu dans Portage : j'ai trouvé deux assembleurs (dans dev-utilities et dev-language)

nasm http://www.tortall.net/projects/yasm/manual/html/nasm-directives.html#nasm-directive-bits-top

Là c'est clair !

[Mickael]

@modos : À quand le prochain sujet ?
_________________
À LIRE : COMMENT POSTER ET OBTENIR DE L'AIDE ?
Qui suis-je ? Bon j'ai relu, comme d'habitude, je suis bon a rien le vendredi
Qui suis-je ? Je ne serai jamais modo

[dapsaille]

Oui ...

un autre sujet .. un autre sujet

Libérez Jacqueline

[kwenspc]

une autre sujet: suis pour aussi!

(on va ptet finir par les réveiller les modos ^^)
_________________
membre officieux du SAV Ati GEntoo

[Scullder]

Pour le navigateur et ses plugins, j'ai écrit ça hier :
http://scullder.blog.free.fr/index.php?2006/12/06/42-firefox-sous-linux-x86_64

La nouvelle version de nspluginwrapper fonctionne mieux
_________________
Linux gentoo 2.6.18-ck1-r2 #1 PREEMPT Fri Nov 17 01:37:56 CET 2006 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

[truc]

youhou, ouais un nouveau un nouveau! taktaktak, un nouveau...


Bref, on peut peut-être les aider à choisir le nouveux sujet , la boite à idée se trouve toujours ici: https://forums.gentoo.org/viewtopic-t-429957.html

Mais c'est vrai que le choix est difficile, il faudrait trouver sans doute de nouvelles idées...
remarque, j'aimerai bien voir ce que ceux là peuvent donner:

[-KuRGaN-]

Allez moi j'en ai un beau là, vu que je suis en train me prendre la tête avec une Debian et que j'ai la rage:

APT vs Portage

Un jour un Kuku à dit:

Un apt c'est un peu comme un portage sans le net !!!!!!!!
_________________
Knight Gent00 Industries RiDeR !!!!

[Mickael]