YBoy360 a écrit 715 commentaires

Ou Asciidoc + diagram. C'est étrange que tu sois le seul à mentionner reveal.js…

avec reveal.js, et un git, tu tues tout. LO, PowerPoint, OO.

Finalement, le meilleur WYSIWYG c'est sans contestation Intellij version communautaire.

Avec autant de mésaventure il devrait monter sa chaîne Youtube.

De la vrai graine d'Influenceur dans ce journal (tristesse, émotion, chagrin, avec un soupçon d'authenticité "La perte d'un espoir")…

Juste un petit point : dans certaines boites, comme Amazon, les présentations sont interdites. Trop de temps perdu à la faire, à perdre du temps de l'auditoire, pour transmettre plus la forme que du fond. C'est discutable, il y a du pour. Nous, nous avons des templates avec LO, et strictement aucun problème de mise en forme, par contre personne ne doit consacrer plus de 20 minutes à faire sa présentation à partir du moment où on ouvre l'OTT.

ASP.NET contre du C++, et de moins en moins de Java.
OOXML contre ODF.

Bref, un débat sans doute déjà perdu pour LO. Quand je pense OO, je pense MS. LO, c'est Collabora, RH : un journal qui dénonce indirectement Collabora se prend +22, super l'ambiance ici. Je ne dirai rien, mais cela fera du bruit dans Landerneau!

Le LibreOffice killer, avec 95 % du code venant de MS, en ASP.NET… Je suis de l'ancienne génération, mon cerveau considère ça comme un cheval de Troie. Je préfère encore LibreOffice, même si techniquement c'est sans doute très intéressant.

C'est un exploitant. Ils se sont mis à concevoir des centrales nucléaires, en Angleterre, pour concurrencer AREVA, l'industriel.

Ils ont hypothéqués toutes chances de l'industrie française en brouillant les cartes "Le nucléaire en France, c'est nous", face à l'industrie Coréenne unifiée, sur tous les marché du globe.

Les luttes entre des politiciens incompétents, de l'ENA ou d'HEC, ont ruiné cette industrie (mais pas que) en France, alors que le nucléaire est un investissement majeur ici depuis plus de 50 ans. Je crois qu'EDF est l'entreprise du CAC 40 ayant historiquement le plus perdu de valeur. Faire Henri 4 ou Louis Legrand ne rend pas apte à faire autre chose que de la finance.

Oui, il y a des pubs, et Noël est une fête païenne inventée par Coka-Colala..

Cela dit, fabriquer sa machine 8-bit aujourd'hui, surtout si on a des enfants et qu'on a commencé sur un Commodore PET, y a rien qui peut espérer égaler ça en terme de découverte et de bons moments. C'est comme réapprendre l'alphabet alors qu'on ne fait que regarder des films en VR. Ce genre de produit me fait plus vibrer que n'importe quelle serveur, console de jeux, téléphone portable…

J'ai beau apprécier Rust, même utiliser des logiciels Rust car c'est plus sécure, le reconnaitre, ça n'est pas tout à fait pour les mêmes usages. Il y a quand même des développeurs qui arrivent à faire des applications fluides en Java, sur serveurs, desktops ou téléphones, codées très rapidement, qui gèrent parfaitement beaucoup de dépendances, sans aucun problème.

Comme on est plus vendredi, il serait bon de passer à autre chose.

Concernant l'étalage d'expérience, j'ai connu presque pire. Ce que l'on constate en général, c'est que tout dépend de l'encadrement des projets, et des compétences techniques de la hiérarchie. L'idéal est que le chef de projet soit aussi l'intégrateur car en Java, c'est le poste clé (idem en C++). Il faut faire preuve de prudence, bien choisir les dépendances est ce qui demande de l'expérience.

Combiens d'idées "géniales" ou projets miraculeux doivent finir à la benne avant d'avoir de l'expérience? Je ne sais pas, mais je ne pense pas que la réponse à cette question soit propre à un langage particulier. Pour développer en C/C++/Java/Python/Kotlin/Groovy, 4 stagiaires sur 5 fait du code inutilisable en production après l'école. Peut-être que d'autres langages offrent un cadre plus restrictif, donc permettrait de changer ce ratio, mais je n'y crois pas trop, ou alors, le prix à payer ne serait pas négligeable.

Je comprends bien ce que tu veux dire, mais changer la fréquence, ça se voit, surtout sur un CPU fanless. Tu peux mesurer la consommation, la fréquence des bus, avec des outils externes. Je fais une réponse globale à tout tes messages, en gros pour moi, tu confonds benchs GPU et CPU, je dis pas que tu as complètement tords, je m'explique :

Certains drivers de GPU propriétaires ont des profiles en fonction de l'application que tu utilises, tu peux vraiment changer le comportement du pipeline et les performances pour 3 raisons (et demi) :

• Les instructions exécutées par le pipeline ne sont pas accessibles à l'utilisateur final (on peut compiler dans un language intermédiaire, mais tu ne peux pas débugger ou tracer les compteurs HW associés aux unités), sur les cartes ayant de la RAM dédiée. L'utilisateur code des shaders, qui sont traduits par un compilateur dont on a pas les sources, il est possible de procéder à de nombreuses optimisations, pas générique, qui fournissent un résultat correcte. ÇA c'est de la triche.

• Le GPU dispose de très nombreuses unité de calcul, idem, on a pas accès aux détails de ce qu'il se passe, hors l'implémentation des transistors et la localité des unités de calcul, font que tu as une énorme marge de manœuvre en terme de fréquence des unités et de désactivation d'unités.

• Le switch de contexte sont bien moins nombreux, donc ça permet d'avoir un contexte qui soit bien plus complexe et qui porte plus d'info de customisation entre les applications.

• Enfin, la demie raison, c'est qu'avec les anciennes API, avant DX10 et Vulkan, les drivers étaient de grosses machines à état, le potentiel d'optimisation était énorme…

Maintenant pour les bench CPU, le contexte est totalement différent, même si tu n'as pas accès aux sources de l'OS et du compilateur, tu as accès aux instructions, aux compteurs HW et tu peux analyser et tracer très facilement ce que tu veux.

Alors bien sûr, tu peux faire plein de micro-optimisations, comme (je vais te donner des idées) :

• Changer la taille des pages ;
• Changer l'affinité d'une thread avec un core ;
• éviter l'éviction du cache de certaines données/instructions (je sais pas si c'est possible) ;
• Même faire du prefetch

Tu peux faire tout cela, en effet, l'OS peut aussi changer le CAS de la mémoire directement, ou la fréquence du CPU…

Mais on peut aussi faire cela sous Linux! Alors que sur un Bench GPU, avec un driver propriétaire, tu ne peux rien faire.

Je veux bien admettre qu'Apple joue à ce petit jeux, mais je crois que personne ne se prive de le faire, et il n'y a pas grand chose de magique dans les benchs CPU, contrairement aux benchs GPU.

T'es gentil et tu relis l'extrait que tu cites au lieu de choisir des bouts de phrase qui t'arranges.
Si t'es pas capable de comprendre ce qu'on te répond, abstiens-toi.

Ooops, non je comprends pas ce qu'est l'overclocking, ni comment on configure son bios, je n'ai jamais joué à des jeux vidéo, jamais modifier du code sur des benchs face à du NVidia/Intel (en fait si, mais toi jamais apparemment)…

En gros c'est le seul argument que t'as (j'en aurais bien d'autres), parce que le reste de ta diatribe, c'est uniquement rabaisser les autres.

Je vais prendre le temps de répondre intégralement à ton précédent message :

Pourtant ça reste aussi une possibilité pour gonfler les chiffres. Les benchs peuvent très bien subir un traitement prioritaire par l'OS, faisant fi des limites de frequence/tension, de consommation, d'enveloppe thermique, de gestion de la mémoire ou de gouverneur qui s'appliqueraient normalement pour conserver un usage et une durée de vie acceptable sur le long terme.

Vas-y que j'étale ma confiture… Comme tu dis, ça permet de gonfler les chiffres, mais de pas de beaucoups, sauf sur 2 références appréciées des gamers. Mais même pour ces références, les gains ne sont pas si important.

C'est déjà hyper facile de fausser des résultats sur des PC en les boostant avec différents paramètres d'overclocking.

Non, sur les CPU modernes, ce n'est pas simple, tu prends les derniers AMD, Ryzen 3?00 (encore plus avec les 3?50 X), tu ne peux quasiment pas changer les paramètres du FSB, ni de façon importante les fréquences du CPU.

Les gains sont marginaux (prouve moi l'inverse, sans utiliser de solutions WaterCooling ou autres), même en ayant un système instable avec WaterCooling. Encore plus pour les hauts de gamme.

C'est déjà hyper facile de fausser des résultats sur des PC en les boostant avec différents paramètres d'overclocking. Ça peut même souvent arriver de manière involontaire sans faire attention, voire à l'insu de l'acheteur avec les réglages d'usine (Ya plein de cas récents de fabricants de carte-mère pour x86 qui activent par défaut une option d'OC ou qui augmente les tensions, les fréquences ou les durées de turbo au delà des specs).

Et ça n'apporte que peu de performances. Prouve moi les gains. S'ils arrivent à 20 % je te pais un soda.

C'est tout le problème de cet environnement fermé. On ne peut rien infirmer ou affirmer avec certitudes.

Parce que les BIOS, ou les firmware de ta carte mère, ils sont ouverts ?? Les firmwares des CPU font tous ça et tu n'as pas accès à ces couches logiciels, sur du Intel, comme de l'ARM. Le throttle, le boost de fréquence pour un bench mono-threadé, ou changer d'autres paramètre associé à un process, c'est ce que font de base tous les utilisateurs un peu averti (gamers bas du front)! Pas besoin de faire son propre CPU pour jouer sur ces paramètres.

Mon point de vue, c'est que si les CPU d'Apple supporte bien l'O/C, tant mieux pour eux. C'est pas les premiers à le faire, donc, ton bel argument n'a aucune valeur.

Pas de ma faute si tes clients sont des gros pigeons.

Pfff, déjà, arrête de prendre les gens de haut en te prenant pour le Saint-Père, c'est très malsain. Ta vérité n'est pas universelle.

Mais justement ça c'est de l'optimisation ! Ça ne permet absolument pas d'affirmer que tel CPU est équivalent à tel autre de la concurrence comme vous le faites !
Sachant qu'en plus iOS/OSX ça tourne sur un nombre restreint de machines bien définies, l'optimisation y est logiquement plus présente.

Et ? Tu crois vraiment que sur la plupart des benchs CPU l'OS à un impacte ? Le fait de maîtriser sa plateforme ne va pas multiplier les perfo comme les petits pains…

Pourtant ça reste aussi une possibilité pour gonfler les chiffres. Les benchs peuvent très bien subir un traitement prioritaire par l'OS, faisant fi des limites de frequence/tension, de consommation, d'enveloppe thermique, de gestion de la mémoire ou de gouverneur qui s'appliqueraient normalement pour conserver un usage et une durée de vie acceptable sur le long terme.
C'est déjà hyper facile de fausser des résultats sur des PC en les boostant avec différents paramètres d'overclocking. Ça peut même souvent arriver de manière involontaire sans faire attention, voire à l'insu de l'acheteur avec les réglages d'usine (Ya plein de cas récents de fabricants de carte-mère pour x86 qui activent par défaut une option d'OC ou qui augmente les tensions, les fréquences ou les durées de turbo au delà des specs).
C'est tout le problème de cet environnement fermé. On ne peut rien infirmer ou affirmer avec certitudes.

Elle est bonne celle là, "l'Overclocking", c'est donc le seul argument que tu as pour que l'OS optimise le bench … C'est énorme.

Tout cet échange pour en arrivé là. Les bras m'en tombe…

Je monte sur mes grands chevaux parce que vous brisez les noix à systématiquement prendre en argument des comparatifs foireux sur ces iBidules pour dire que ARM devient plus performant. Des comparatifs ARM vs x86 vs Tartempion existent déjà pour d'autres gammes d'utilisation et ces tests sont bien plus fiables.

T'es vraiment obtus, ce n'est pas foireux de comparer différentes plateforme pour connaître la plus rapide et d'en déduire les performances du CPU. On ne te demande pas une analyse exhaustive de l'impacte de chaque instruction. Si la même application, compilée par le même développeur s'exécute aussi vite sur ARM MacOSX que sur un i5 Windows 10, et que les résultat sont ceux attendu, alors l'ARM d'Apple est aussi rapide. Sinon tu suggères que Windows pénalise l'i5. Bien sûr que l'on aimerait tester ça sous Linux, mais ce n'est pas la question.

Quand tu optimises un système, tu compares bien les variations sans changer d'autres paramètres hard ou soft, non ? sinon c'est pas possible de mesurer l'impact individuel de chaque changement. Ici c'est la même chose : tu peux pas comparer les perfs brutes de différents CPU/GPU si tu changes d'autres paramètres en même temps.

T'apprends rien à personne, oui, il faut procéder avec méthode, on fait de la dichotomie pour faire de l'optimisation, en analysant ce qui se passe dans le CPU, le GPU, et en ne changeant qu'un paramètre à la fois, merci. Je vois pas à quoi répond ce genre de remarque. Dans la plupart des benchmark que j'ai dû optimiser, sans changer l'OS, on était en compétition avec d'autres plateformes et le prix des stations dépendait des perfos, il n'y a rien d'académique là dedans. Et le client lui, comme tout le monde à part toi, déduit du benchmark les perfo du CPU.

À part les ingénieurs d'Apple, personne ne peut donc évaluer ce que leurs processeurs ont réellement dans le ventre face à la concurrence puisque l'environnement est clos et possède ses propres optimisations qui faussent toute mesure absolue. L'entreprise jouait déjà sur cet obscurantisme avec ses iPhone et iPad.

Justement, le but est de mesurer les perfo, pas les méthodes pour y parvenir. Si les applications utilisent des hack d'Apple tant pis si tu comprends pas ce qui se passe. Mais comme dit plus haut, il n'y a rien de magique. Surtout, ce que je ne comprends pas dans cette remarque, c'est qu'au pire, Apple ne fait qu'exploiter son CPU, à te lire, on a l'impression qu'il "accélère" les choses en trichant, ça n'a AUCUN sens…

Du calme… Pas la peine de monter sur tes grands chevaux, je dis juste que l'archi x86 est moins efficace, relis mon premier message.

On verra les benchs de l'A14X (ou je sais pas quoi), par rapport à l'Intel.

Pour ta preuve "scientifique", on optimise pas de la même façon CATIA, Oracle et du HPTC avec du MPI. Tu te bases sur un binaire certifié dans un cas, sur une plateforme donnée, de l'autre tu peux customiser ce que tu veux. Les clients de DS ou d'Oracle n'ont pas accès aux sources. Il compare un tout, en customisant qq paramêtres. Le calcul scientifique, c'est différent.

La différence est que les tests sur Windows sont généralement intra ISA. Quand on compare deux ISA, on utilise un OS commun avec des builds reproductibles, càd un Linux ou BSD.
De plus Microsoft ne vend pas de matériel x86 donc y a pas de risque que leur OS trafique ces résultats.
Les binaires de bench n'ont qu'une valeur indicative intrinsèque. Un testeur sérieux utilisera une palette d'applications réelles qui lui permettra de constater si tel ou tel soft favorise tel ou tel matériel.

Ha bon? pour avoir travaillé 7 ans dans l'optimisation CPU, je peux te dire que personne ne s'empêche de faire des bench entre différents OS, sur différentes ISA …

La différence est que les tests sur Windows sont généralement intra ISA. Quand on compare deux ISA, on utilise un OS commun avec des builds reproductibles, càd un Linux ou BSD.

ça n'a pas toujours été le cas, en plus d'ARM, Windows a supporté l'Itanium et autres.

Vous avez fumé la moquette les gars. Regardez les specs et les perfs d'un i7, i9, R7 ou R9 desktop de cette année. Regardez aussi ce qui est sorti récemment en laptop. Aucune chance que cette puce faites pour les contraintes d'une tablette leur arrive à la cheville. C'est comme comparer une console de salon avec un PC gaming.

Regarde les évolutions en performance en 2 ans dans le monde ARM. ils sont peut-être loin concernant l'arithmétique flottante, mais à part application gourmande en FLOP on peut prédire l'année prochaine un CPU au niveau d'un i5, voir i7.

Merci pour le fou-rire. Désolé mais c'est bien la preuve que tu ne sais vraiment pas de quoi tu parles et que t'as même pas la curiosité de chercher. Petit indice : OpenPower.

Je voulais dire RISC, l'architecture RISC, pas forcément RISC-V ou OpenPower. En 2000, que ce soit les SPARC, les powers ou les MIPS, c'était ça les Workstations. Il n'y a qu'IBM qui perdure :

Power9

Phoronix

J'hésite à te coller l'étiquette "je travaille chez ESI Group sur des clusters Intel" ou "je travaille chez Intel tout court" …

Sinon ça sert à rien de prendre Apple en exemple, les biais de ces comparatifs sur ce genre de matériel ultra fermé ont déjà été débattus ultérieurement. Tant qu'on pourra pas y faire tourner un autre OS pour isoler le hard du soft, ça n'est que mélanger des choux et des carottes.

Apple va lancer l'année prochaine des iMac basés sur l'ISA d'ARM, donc il s'agit bien de desktop. Ils utilises Gcc, llvm, Webkit … Qu'est-ce qui empêche de comparer ça à un Raspberry PI, ou à un x86 ?

En quoi un benchmark sous Windows, ou avec n'importe quel binaire est-il plus ouvert ?

Aujourd'hui, tu as les performances d'un "Desktop" x86 (i7, i9), dans un boîtier de Nuc. Intel ne peut rien y faire de par la nature de leur ISA. Elle est la moins efficace de toutes. Le surcoût est au minimum de 30 % de transistor supplémentaire pour les étapes fetch/decode par rapport à de l'ARM.

Que va tu dires lorsque Microsoft va lancer des processeurs ARM, lorsque Google va faire de même, tu crois qu'ils vont se cantonner aux smartphones et tablettes ?

Un petit test du dernier CPU Microsoft : Surface Pro X review, TheVerge. C'est juste leur 1er CPU maison.

De plus, il me semble que le jeu d'instruction RISC-V est utilisé par IBM pour leurs stations de travail…

Après avoir supprimer les logs, ça ne change rien sur FF.

Un point rigolo, Konqueror (basé sur Webkit) est super rapide avec ce test..

Si tu cliques sur "Generate 50" plusieurs fois, que ce passe t-il ?

Si ça fonctionne bien, quelle est ta plateforme, quelle carte graphique utilises-tu ?

merci pour le lien.

Si tu cliques plusieurs fois sur "Generate 50", ça rame sur FF, c'est toujours fluide sous Chrome / Chromium.

Le code n'est clairement pas optimisé pour un grand nombre de carrés, c'est volontaire. Le but est de tester les performance de l'approche "brute force" : il n'y a pas d'arbres, pas de partitionnement de l'espace ou autres.

Une des raisons de la lenteur de FF pourrait-être l'affiche des logs de la page, même si la console de développement n'est pas affichée.

J'aimais bien Firefox et Thunderbird, mais je n'apprécie vraiment pas les dernières décision de la MoFo.

Ce que je n'apprécie pas concernant la MoFo :

• le quasi abandon de Thunderbird, malgré les moyen dont ils disposent, pour moi c'est un pièce crutiale du libre, il semble vivre sa vie comme un vilain petit canard au sein de la fondation ;
• Le rejet de toutes techno venant de Google (Dart VM, PNaCL, …), OK, c'est Google, mais moi j'aimais bien, et il eut fallu des avis constructifs sur le sujet ;
• Leur moteur était plus difficile à maintenir que Webkit (avis personnel), qui doit son origine à KTHML, le moteur de rendu HTML de KDE, qui était un moteur très compacte, adapté aux mobiles. Si Apple puis Google base leur navigateur dessus, ce n'est pas par hasard.

J'apprécie particulièrement Webkit, c'est un fait. En partie, car les développeurs sont les mêmes que pour KHTML. Ils essayent de rendre leur moteur maintenable, c'est encore un avis personnel, mais personne parle du code de FF vs le code de Webkit. Certes, ce n'est pas à la porté du premier venu, mais si toute l'industrie choisi ce moteur, c'est sans doute pour ce genre de raison.

Concernant les performances brutes, sous Linux, par rapport à FF, désolé, sur ma machine, la page suivante est catastrophique sur FF (d/l les 2 fichiers, puis ouvrir le fichier HTML, c'est un bête canvas, avec du picking) :

client-area-tests

P-e que ça fonctionne bien sur FF sous Windows, super …

Même si j'utilise et adore Kotlin (hors d'Android), Groovy a largement plus de légitimité pour avoir la primeur sur ces fonctionnalités.

Gradle est un très mauvais exemple de comment faire du Groovy, je pense que ça le dessert plus qu'autre chose. Mais bon, ça lui permet d'avoir une certaine présence.

C'était quelqu'un de vraiment accessible, on a beaucoup échangé lors de mon mentoring (je n'ai pas le temps matériel de contribuer à Mageia). Il était partout, je pense à lui, à son fils et à sa famille.

J'aimerai ne pas avoir lu cette triste nouvelle. J'enterre aussi mon père demain. Mon moral est dans mes chaussettes.

Ils ont encore de quoi tenir suffisamment longtemps pour se retourner. Je me méfie toujours de ceux qui annoncent la mort des grandes entreprises tôt comme ça. Intel serait déjà mort, Microsoft aussi, Apple aussi, AMD pareil, Facebook n'en parlons pas,…

C'est un peu différent dans le cas d'Intel pour 3 raisons :

• Faire un processeur est extrêmement capitalistique, contrairement à ce que fait MS ou Facebook, un nouveau processus de fabrication coûte des milliards pour la mise en oeuvre, ne pas être à niveau aujourd'hui c'est l'être encore moins demain ;

• Le conseil d'administration a nommé l'ancien DAF (Directeur Administratif et Financier) comme dirigeant. En général, ça fonctionne pas pour les boites hi-tech (loin de moi l'idée de dire qu'ils sont des incapables, mais je n'ai pas d'exemple de financier ayant réussi dans l'industrie) ;

• Le DAF en question a suggéré de fabriquer des puces par TSMC, ça c'est la preuve qu'ils sont vraiment dans une passe inquiétante car le jeu d'instruction Intel implique une surconsommation de l'ordre de 30 % par rapport au jeu d'instruction ARM (désolé, pas de liens, je parle bien du jeu d'instruction, pas de l'architecture, car l'unité de décodage pour passer du CISC au RISC consomme 30 % de transitor d'un core sur le die), à processus de fabrication équivalent, ils seront derrière ARM, il tenait avant grâce à leurs supers usines.

Enfin, concernant l'out-of-order, la prédiction de branchement, autres, ce n'est pas une spécificité d'Intel, ARM s'est mis à le faire il y a déjà un certain temps, chez Intel, les Atoms n'en dispose pas, le compilateur ne peut pas prévoir tout statiquement et les gains associés sont quand même important, alors je doute que ça disparaisse.

tes pupilles se protègent p-e plus en voyant un écran blanc qu'un écran tout bleu. Mais bon, le wifi c'est pas bon, la 5G, n'en parlons pas, et il parait que se droguer c'est mal.

C'est vrai que c'est moins flashy que l'écran bleu d'un PDP-1 OS.

Je connais bien Javadoc, et je sais bien qu'il s'agit de la documentation d'une API.. c'est même ce que je dis dans mon 1er message. Normalement si il s'agit d'une API, c'est vrai que le code est trivial par nature. De plus les IDE proposent d'afficher le Javadoc au survole de la méthode…

Asciidoctor permet déjà de mettre des extraits de code à partir d'un numéro de commit et un numéro de ligne. On pourrait appliquer ce principe pour commenter une API.

Avantages : i18n, documentation API composite, enrichie aux extraits de code des tests venant des sources pour montrer l'usage de l'API, documentation structurée.

Si on a pas besoin de tout ça, juste d'une documentation de l'API, c'est difficile de faire mieux que les Javadoc like, je te l'accorde.

Je suis bien au courant. Quasiment tous les projets java utilisent ce principe. Cela dit, avec asciidoctor par exemple, on devrait pouvoir externaliser cette documentation. Ça fait sens si on veut la traduire et même documenter à partir des tests, des exemples de code tiré du git, présent dans d'autres fichiers.

Je veux bien documenter une classe, au dessus du code de celle-ci, car ça ne gêne pas la lecture du code. Par contre documenter toutes les méthodes est une perte de temps, surtout lorsque ça paraît triviale. La doc inline qui explique un passage complexe est bien sûr primordial.

Trop commenter le code nuit à sa lisibilité. En plus le bleu sur nos écrans c'est mauvais pour les yeux.

C'est vraiment important de commenter 1 pauvre ligne de code aussi triviale ? Alors oui, javadoc et tout, mais avec d'autres IDE, on accède au code très rapidement et on préfère le lire directement plutôt que de se coltiner la doc de chaque méthode.