Discussion:Logiciel de Base

De Ensiwiki.

Je viens de regarder la page Software Optimization, et notamment le programme qui compte le | nombre de cycles d'un bout de code. Il me semble bien que ce code fait pas du tout ce qu'il faut. Si je comprends bien, il regarde la valeur du RTSC (Read time stamp counter) pour définir le nombre d'instructions qui se sont écoulés. Le problème c'est que l'incrémentation de ce compteur est la meme quelque soit la fréquence du processeur (ou plutot est la meme que le processeur soit en idle - fréquence faible - ou en pleine charge). Autrement dit, si le processeur n'est pas en pleine charge pendant que l'on mesure la performance de notre algo, on se retrouve avec un nombre de cycle qui ne signifie pas grand-chose. Quelqu'un confirme ? --Lepersb 28 janvier 2009 à 19:07 (UTC)

Je ne vois pas en quoi ce ne serait pas la bonne chose à faire. Le nombre de cycles (je suppose que c'était cycle et pas instruction que tu voulais dire) est la bonne mesure au contraire, puisqu'elle ne varie pas d'une fréquence à l'autre ; si tu as une fréquence plus faible, les ticks s'incrémenteront plus lentement mais le compte devrait être le même (problèmes de sérialisation mis à part), c'est donc la seule mesure fiable du temps processeur, et par ailleurs, cela permet d'avoir des stats concernant l'architecture et pas un modèle précis ; le clock freq change d'un modèle à l'autre mais l'architecture ne change pas le comportement vis à vis du code à mesurer devrait être le même.

Update : Bon, ça fait longtemps que j'ai plus fait ça, mais effectivement, les procos récents Core & co (moi, jme suis arrêté avec le Pentium 4 de jouer avec ces choses là :D) ont un RDTSC constant^1, et ya pas moyen d'avoir une mesure du nombre de cycles apparemment ; bon bah dans ce cas-là, on dirait bien que faut faire les mesures à fréquence maximale, m'enfin c'est pas non plus un gros gros problème, à mon avis, et je ne connais pas de meilleure méthode. Btw, je me demande pourquoi ils ont changé ça, d'après Intel, "it's architectural behavior moving forward", quel bullshit...

Update : Quoi qu'il en soit, c'est intéressant de voir qu'il y a d'autres élèves ici qui sont au courant de ce genre de choses, même si à mon avis c'est poussé de dire que le programme ne fait pas ce qu'il faut ; toutes les mesures sont à effectuer dans un cadre, l'interprétation que l'on en fait après dépend, mais je fais confiance à l'auteur du site en question pour ça.

^1 : IA-32 Software Developer Manual Vol 3B § 18.11

--Len 28 janvier 2009 à 19:41 (UTC)

Effectivement, le "problème" n'est là que sur les processeurs avec la techno SpeedStep (ou équivalent AMD ?) où l'incrémentation du RDTSC n'est pas corrélée à la fréquence courante du processeur. (Cf. une vieille new d'x86-secret. Apparemment il faut utiliser un "CPU_CLK_UNHALTED.CORE" (ou "CPU_CLK_UNHALTED.TOTAL_CYCLES") pour avoir des mesures correctes. (Mais j'avoue avoir un peu la flemme de me pencher dans les doc pour vérifier que ça fait bien ce qu'il faut...)

Quant à la raison du TSC invariable(d'après la news), c'est à priori suite à la demande de Microsoft... P't'être qu'ils avaient des vieilles routines ASM qui avaient besoin de ça pour fonctionner correctement... --Lepersb 29 janvier 2009 à 20:57 (UTC)

Bon, comme tout ça m'intrigue, je viens de parcourir la doc Intel et j'ai aussi lu le code des trucs fournis dans le testp.zip d'Agner Fog, et comme je m'en doutais, il est largement au courant de tout ça, en fait... suffit de lire le readme (shame...) où il dit que si on utilise un proco pour lequel le TSC ne donne pas de valeurs potables, il faut lire le core cycle counter, qui est un PMC, et ça c'est à la charge de PMCTest (qui est inclus dans le zip), mais il précise aussi que pour pouvoir setup les PMC, il faut avoir des privilèges systèmes sur le proco. Bref, je suppose que ça conclut l'affaire. EDIT : Bouh, ça me déprime de voir que mes connaissances en procos & ASM ont si mal vieillies. :( M'enfin je suppose que c'est inévitable puisque je ne m'y intéresse plus tellement... --Len 29 janvier 2009 à 22:36 (UTC)

Effectivement, ça m'apprendra à m'être jeté dans le code dans lire la FAQ... Le gars fournit même un driver pour utiliser le PCM... (Shame effectivement...) --Lepersb 30 janvier 2009 à 10:26 (UTC)

J'en avais déjà un peu discuté avec M. Moy, mais voici un lien intéressant sur la syntaxe GAS et ses bizarreries. Il serait peut-être intéressant de réfléchir à faire les TP en syntaxe intel plutôt qu'en syntaxe GAS ? (Sachant qu'il suffit de rajouter une instruction en tête de .s pour compiler de l'asm "intel" avec gcc.)

(Ca préparerait un peu au projet C en plus... La logique dest,src est celle qui est utilisée dans la plupart des fonctions de base du C (strcpy, etc.). Ca habituerait peut-être un peu les gens à l'avance ?) --Lepersb 29 janvier 2009 à 21:08 (UTC)

Franchement, je crois pas que ça fera quelque chose, mais je tiens à dire que moi aussi je conchie la syntaxe AT&T, ne serait-ce que parce que je pense que l'ASM devrait être écrit dans le dialecte du fabricant, ne serait-ce que pour des raisons évidentes de doc... Le reste, m'en fiche, les arguments dans un sens ou l'autre, c'est juste du sucre, c'est pas comme si c'était pas un merdier fou l'ASM x86 de toute façon... un peu plus, un peu moins. --Len 29 janvier 2009 à 23:06 (UTC)

Je ne pense pas que ce soit très important vu les objectifs du cours, mais effectivement, passer en syntaxe intel, pourquoi pas. Pour l'instant, je n'ai pas encore soulevé la question avec l'équipe pédagogique, parce que ça prendrait un certain temps (ré-écriture des exemples, de certaines parties du poly, ... et synchronisation avec les gens du système). Bref, j'ai bien noté la remarque, mais pas le temps de m'y plonger pour l'instant. --Moy 2 février 2009 à 12:27 (UTC)

Effectivement, on est d'accord que l'asm x86 c'est un merdier total. C'est d'ailleurs dommage qu'on ne voit que les instructions de base en cours (qui n'ont aucun intérêt, je connais pas grand monde qui s'amuse à optimiser du code avec ça) et pas les instructions avancées (SSE & co) qui elles, par contre, sont pas mal utilisées dans les routines critiques (codecs notamment... Je m'étais amusé à regarder les sources de x264 un jour et quelques passages sont assez monstrueux). --Lepersb 30 janvier 2009 à 10:26 (UTC)

Moui, enfin, Log de Base, c'est pas « comment guruter l'assembleur en 42 heures », et à mon avis, il est bien plus important de comprendre les concepts derrière l'optimisation de tous les jours ; le jeu d'instructions, ça s'apprend quand on en a besoin, et c'est franchement assez spécifique à certaines applications. En plus, la plupart des gens n'ont jamais vraiment codé quoi que ce soit, s'ils se mettaient à optimiser, ce serait la fin du monde. Mais clairement, si on devait nous enseigner un truc sur l'optimisation bas niveau, je pencherai pour les questions d'optimisation générale (problèmes liés au cache, aux prédictions, notions de profiling, etc.). Après, il est aussi clair que mon point de vue est celui du compiler designer, pas celui du programmeur assembleur. Mais là je crois que l'on s'éloigne du sujet. :) --Len 30 janvier 2009 à 10:52 (UTC)

Mon idée c'était pas de devenir un guru asm avec ce cours, mais plutôt de mentionner l'intérêt de l'asm pendant le cours (limité, mais existant quand même). Disons qu'un mini TP de comparaison code C normal / mini routine ASM pourrait être intéressant. (En tout cas plus qu'une recherche dichotomique où tout le monde se galère à faire des movl/cmp.)

• Pile le sujet du TP télécom 2008, et du futur TP Ensimag ;-). Mais ça reste un algo de tri basique, donc, la conclusion reste que GCC code mieux que nous sur ce cas ... --Moy 2 février 2009 à 10:56 (UTC)

Il y a moyen de coder des trucs très simples en SSE4 et de voir une augmentation des perfs x10 (voire bien plus) par rapport à un code classique. (J'ai pas d'idée d'algo comme ça, mais par exemple un truc tout simple avec SSE5 serait de faire calculer 1/sqrt en C et via l'instruction SSE5. M'est avis qu'on a facilement un gain de 1000... Et les normalisations de vecteur, c'est un truc qui se fait quand même super souvent..)

Bon, après les gens s'en foutront peut-être, mais c'est à mon avis plus concret que de dire "vous voyez l'asm ça existe, c'est joli, mais le compilo il fait ça 100 fois mieux que toi et plus vite" (à tel point que j'ai fait tous les TP de 1A avec un gcc -S (<- option pour générer le .s ? A vérifier...) en repassant derrière pour faire un code plus "lisible"...) --Lepersb 30 janvier 2009 à 12:29 (UTC)

Attention, le but du cours n'est pas tellement de "connaitre l'assembleur", mais beaucoup plus de "comprendre ce qu'il se passe". Il faut voir le cours de logiciel de base comme un complément à l'archi, et une préparation au système et à la compilation. Les trucs indispensables, c'est au moins:

• Notion de registre
• Comprendre ce que c'est que la mémoire, ce que c'est qu'une adresse
• Avoir des notions de représentation de données (par exemple, le fait qu'un même registre peut contenir un entier, un flottant ou un pointeur)
• Comprendre la mécanique des appels de fonctions, la pile

Et en fait, y'a pas tellement la place pour plus que ça dans le cours (18h de TD, avec des séances machines, c'est très court). Et pour ça, bah, faut connaitre mov, push, pop, call, ret, ...

Je suis d'accord qu'il y aurait pleins de choses intéressantes à faire, mais ce cours de 1A n'est vraiment pas le lieu pour ça. Faut garder en tête que même après un cours comme ça, la proportion d'étudiants qui n'ont pas compris la différence entre une liste et un tableau reste importante :-(. --Moy 2 février 2009 à 10:56 (UTC)

Désassembleur

J'ai une petite remarque, je pense qu'il serait intéressant si on parlait aussi de l'existence de désassembleurs qui transforment un binaire en assembleur (c'est la méthode qu'utilisent d'ailleurs les petits malins pour cracker des logiciels, mais restons dans un cadre pédagogique et surtout légal :) ). Par exemple :

• objdump pour Linux.
• ollydbg pour Windows.

L'idée peut vous paraitre pas très interessante, mais en tout cas j'ai découvert par pur hasard que le passage du binaire à l'assembleur était réalisable, et j'étais bien étonné, car on nous l'a jamais signalé (à l'école)... Donc je me suis dit que ce serai bien si les autres le sachent aussi. Cordialement.--Mohamed

J'ai ajouté un paragraphe sur objdump -d en séance 3, mais ça sera pour l'année prochaine ! --Moy 8 avril 2009 à 08:28 (UTC)

Il y a une myriade d'autres choses importantes à savoir aussi (p.ex. je pense surtout à la mémoire, qu'elle virtuelle, isolée pour chaque processus, etc.). Après, pourquoi celle-là ? pourquoi pas. :p Après, faut voir ce qui recoupe les cours de systèmes en 2A aussi, je ne sais pas trop. --Len 8 avril 2009 à 08:34 (UTC)

Je connais pas les détails du cours de système, mais la notion de mémoire virtuelle est effectivement abordée. En logiciel de base 1A, on triche, et on fait semblant de programmer sur machine nue, sans MMU, sans processus concurrents. Je fais en général une remarque pour éveiller la curiosité des étudiants sur le fait qu'on leur a menti sur ce point (typiquement, deux gdb en parallèle sur la même machine donnent des résultats différents pour « (gdb) p $eax » ou « (gdb) p *une-adresse »). Mais tenter une moitié d'explication là dessus, pour la majorité des étudiants, c'est faire s'écrouler la compréhension du cours de logiciel de base et le cours d'archi pour ceux qui le suivent, je préfère attendre la 2A pour que les étudiants voient ça « comme il faut ».