Dlteam-list

dlteam-list@iro.umontreal.ca

315 discussions

Instrumenting V8 to Measure the Efficacy of Dynamic Optimizations on Production Code
by Erick Lavoie 24 Mar '13

24 Mar '13

Il y a des insights vraiment intéressants sur le comportement de V8 dans ce travail et la qualité du travail est vraiment impressionnante pour ce qui semble être un travail de session pour un cours. De plus, la documentation sur la définition initiale du projet, le suivi et le rapport final sont vraiment intéressants. On pourrait s'en inspirer pour nos propres projets. Erick *Instrumenting V8 to Measure the Efficacy of Dynamic Optimizations on Production Code* 4.1 Optimization has limited benefit [...] 4.2 Many optimizations diminish performance [...] 4.3Reasons for Performance Tables3 <http://www.mrcaps.com/proj/OptimizationEfficacy/site/#x1-140023>and4 <http://www.mrcaps.com/proj/OptimizationEfficacy/site/#x1-140034>summarize the interesting counters for BenchM and Gmail respectively. In general, the trend is towards more deoptimizations, stack interrupts, and compiled code as optimizations get more aggressive. Ignoring the case where optimizations don't occur, program counter to source code looks-ups also occur more often and stubs are utilized less often as optimization becomes more aggressive. The trend is towards performing notably more operations in the compiler as the amount of optimization increases. In particular, we measured the impact of increasing deoptimization. By isolating time taken for deoptimization from the profiler results, we find that foralways_opton BenchM the time required to execute deoptimization increases from 0 to7333±107profiler ticks as compared to a total of24726±193execution ticks --- a very significant component of runtime. In4.2 <http://www.mrcaps.com/proj/OptimizationEfficacy/site/#x1-130004.2>we saw that the compile-time overhead for applications like Gmail is higher than for the V8 benchmark. The question arises of which portions of the compilation process contribute to this overall overhead. We break down compilation time into its multiple phases by analyzing the contents of the profile and attributing a point in the trace to one of nine portions of the codebase. Five of these phases (Assembler, Lithium, Hydrogen, AST, and Parser) correspond to the portions in Figure1 <http://www.mrcaps.com/proj/OptimizationEfficacy/site/#x1-40011>, and three (LowLevel, Shared, and Tracing) are work that is shared between multiple parts of the compiler. Figure5 <http://www.mrcaps.com/proj/OptimizationEfficacy/site/#x1-140045>illustrates the breakdown for the three summary configurations used previously. An overall conclusion for Gmail is that much of this compilation time does not come from time spent in the optimizer. Rather, it comes from work that must be done in any case, even with the optimizing compiler turned off entirely. Of all the time allocation, the parser is the largest contributor. Though initially surprising, this is sensible in light of the much larger size of the Gmail source: based on internal counters, the parser handles over 14 times as much code in Gmail than in BenchM. While compilation overhead for BenchM does increase significantly as a result of time spent in the optimization path, the total overhead is small compared to the decrease in JavaScript execution time it produces. These results also support the running observation that the opportunity for optimization is limited in real-world applications. http://www.mrcaps.com/proj/OptimizationEfficacy/site/

1 0

Do you want critique, or a hug? how to gain valuable criticism on your design
by Erick Lavoie 24 Mar '13

24 Mar '13

Trouvé en faisant une revue de littérature. Guidelines: 1. Be quiet 2. Write it all down 3. Extract more details 4. Reserve time for conflict, and realize that you don't have to agree. 5. Don't ask for critique if you only want validation. If you want a hug, just ask. http://www.ac4d.com/2012/04/30/do-you-want-critique-or-a-hug/ Slides summary: There are 2 sides to critique: giving & receiving. The right intent (on both sides) is to try to understand the decisions made so far and their impact toward meeting goals and objectives. Critique is a skill. It takes practice to improve. There are basic rules that should be followed to help ensure good critique. Mutually understood and agreed upon goals are critical both when asking for and giving critique. Critique can be done both internally and with clients. Use up to 6 people for about 1 hour. Be prepared to deal with difficult people. You will encounter them. Critique can be incorporated into the design process both as an activity and as part of other activities. http://www.slideshare.net/adamconnor/discussing-design-the-art-of-critique Erick

1 0

Dave Mandelin
by Marc Feeley 22 Mar '13

22 Mar '13

En passant, Dave Mandelin ne travaille plus chez Mozilla. Je me demande ce que ça veut dire pour l'équipe de VM. Marc

2 2

Félicitations
by Marc Feeley 22 Mar '13

22 Mar '13

Je tiens à féliciter Emmanuel Bengio, Alexandre St-Louis-Fortier et Nicolas De Jay qui ont tous trois reçu la bourse BRPC du CRSNG. Bravo! Marc

1 0

Rencontre de vendredi annulée
by Marc Feeley 20 Mar '13

20 Mar '13

Bonjour. Afin de nous donner plus de temps pour la préparation de l'article OOPSLA, la rencontre de groupe de ce vendredi est annulée. Marc

1 0

OOPSLA Artifacts
by Erick Lavoie 19 Mar '13

19 Mar '13

OOPSLA introduit cette année la soumission volontaire d'artéfact (VM, code, données, etc.) reliés au papier. /The high level goal of the Artifact Evaluation (AE) process is to empower others to build upon the contributions of a paper./ La limite de soumission est le 1er juin pour l'artéfact et seuls les auteurs dont l'article a été accepté en première phase sont invités à soumettre un artéfact. La soumission d'un artéfact n'influence en rien l'évaluation de l'article. L'artéfact va être évalué séparément et être inclus dans une section "source materials" de la librairie digitale de l'ACM. / / /The artifact will be evaluated in relation to the //*expectations set by the paper*//. Thus, in addition to just running the artifact, the evaluators will read the paper and may try to tweak provided inputs and create new ones, to test the limits of the system./ http://splashcon.org/2013/cfp/due-june-01-2013/665-oopsla-artifacts Je me sens tout à coup un peu moins cynique envers le processus de revue! Erick

1 0

Méthodologies d'évaluation de performance
by Erick Lavoie 19 Mar '13

19 Mar '13

Il y a eu deux présentations particulièrement intéressantes sur l'analyse de performance aujourd'hui à ASPLOS. Voici les résumés et des liens vers des version publiques des articles. Jamais deux sans trois, alors j'y ajoute également un article de 2009, que Paul m'a déjà recommandé si je me rappelle bien. Ça vaudra probablement la peine que je prépare une présentation au lab là-dessus. Erick *Why You Should Care About Quantile Regression* (ASPLOS 2013) Research has shown that correctly conducting and analysing computer performance experiments is difficult. This paper investigates what is necessary to conduct successful computer performance evaluation by attempting to repeat a prior experiment: the comparison between two schedulers. [...] we demonstrate the successful application of quantile regression, a recent development in statistics, to computer performance experiments. Quantile regression can provide more insight into the experiment than ANOVA, with the additional benefit of being applicable to data from any distribution. This property makes it especially useful in our field, since non-normally distributed data is common in computer experiments. https://uwaterloo.ca/embedded-software-group/sites/ca.embedded-software-gro… *Stabilizer: Statistically Sound Performance Evaluation* (ASPLOS 2013) [...] The standard methodology is to compare execution times before and after applying changes. Unfortunately, modern architectural features make this approach unsound. Statistically sound evaluation requires multiple samples to test whether one can or cannot (with high confidence) reject the null hypothesis that results are the same before and after. However, caches and branch predictors make performance dependent on machine-specific parameters and the exact layout of code, stack frames, and heap objects. A single binary constitutes just one sample from the space of program layouts, regardless of the number of runs. Since compiler optimizations and code changes also alter layout, it is currently impossible to distinguish the impact of an optimization from that of its layout effects. This paper presents STABILIZER, a system that enables the use of the powerful statistical techniques required for sound performance evaluation on modern architectures. STABILIZER forces executions to sample the space of memory configurations by repeatedly rerandomizing layouts of code, stack, and heap objects at runtime. STABILIZER thus makes it possible to control for layout effects. Re-randomization also ensures that layout effects follow a Gaussian distribution, enabling the use of statistical tests like ANOVA. We demonstrate STABILIZER's efficiency (< 7% median overhead) and its effectiveness by evaluating the impact of LLVM's optimizations on the SPEC CPU2006 benchmark suite. We find that, while -O2 has a significant impact relative to -O1, the performance impact of -O3 over -O2 optimizations is indistinguishable from random noise. http://people.cs.umass.edu/~charlie/stabilizer.pdf <http://people.cs.umass.edu/%7Echarlie/stabilizer.pdf> *Producing wrong data without doing anything obviously wrong* (ASPLOS 2009 This paper presents a surprising result: changing a seemingly innocuous aspect of an experimental setup can cause a systems researcher to draw wrong conclusions from an experiment. What appears to be an innocuous aspect in the experimental setup may in fact introduce a significant bias in an evaluation. This phenomenon is called measurement bias in the natural and social sciences. Our results demonstrate that measurement bias is significant and commonplace in computer system evaluation. By significant we mean that measurement bias can lead to a performance analysis that either over-states an effect or even yields an incorrect conclusion. By commonplace we mean that measurement bias occurs in all architectures that we tried (Pentium 4, Core 2, and m5 O3CPU), both compilers that we tried (gcc and Intel's C compiler), and most of the SPEC CPU2006 C programs. Thus, we cannot ignore measurement bias. Nevertheless, in a literature survey of 133 recent papers from ASPLOS, PACT, PLDI, and CGO, we determined that none of the papers with experimental results adequately consider measurement bias. Inspired by similar problems and their solutions in other sciences, we describe and demonstrate two methods, one for detecting (causal analysis) and one for avoiding (setup randomization) measurement bias. http://machine.cs.colorado.edu/klipto/mytkowicz-asplos09.pdf

1 0

Compte-Rendu #2 Souper de samedi, dimanche et ASPLOS jour 1
by Erick Lavoie 18 Mar '13

18 Mar '13

Pour continuer où le compte-rendu #1 s'arrêtait, c'est-à-dire samedi après-midi, Antony m'a invité à venir souper avec lui, Steve Blackburn et d'autres participants de RESoLVE. Il m'a conseillé fortement de publier à OOPSLA le plus tôt possible et de profiter du fait que mon projet est actuellement "sexy". Avant d'aller souper nous avons pris une bière à l'hôtel. Parmis les conversations les plus intéressantes que j'ai eues, celle avec Anil Madhavapeddy était remarquable. Ce dernier était à la fois très dynamique, avec un débit tellement rapide que je devais le faire répéter de temps à autre et un enthousiasme particulièrement communicatif. Anecdote qui ne sera savoureuse que pour ceux qui ont lu le compte-rendu de POPL (pas juste comme somnifère ;-)), Anil est le superviseur de Heidi, la rousse de Cambridge, qui apparaît dans une des photos que je vous ai envoyée (dans le compte-rendu de POPL). Leur projet est particulièrement excitant, ils travaillent sur un OS micro-kernel en OCAML qui tourne sur l'infrastructure d'Amazon. L'objectif est de permettre d'établir des canaux de communication sécurisés personnels pour plusieurs /devices/ sur des réseaux différents, potentiellement avec firewalls et autres. Je pourrai vous donner plus de détails mercredi après sa présentation. Le reste du souper était intéressant, bien que comme seul étudiant parmi un groupe de "seniors" du milieu académique et industriel j'ai davantage été observateur que participant. L'objectif avoué d'Antony dans l'invitation était de discuter de leur projet de framework de VM pour langage dynamique. Dans les faits, on en a peu parlé et la conversation a dérivé sur la politique américaine et australienne, les différences culturelles entre les pays, le choix d'un Chair général pour une prochaine conférence, les aléas de l'organisation d'une revue par les pairs d'articles, etc. J'ai également su que la hache a été mis dans le projet Maxine chez Oracle et j'ai eu droit à des anecdotes internes sur la tentative ratée d'Intel de développer une VM haute-performance pour Java pour éviter de laisser une partie critique de la stack informatique dans les mains de son principal concurrent de l'époque, Sun. Steve a dit essentiellement la même chose qu'Antony sur l'idée de faire une VM haute-performance pour JavaScript (ce qui n'est certainement pas suprenant puisqu'ils travaillent ensembles) c'est-à-dire qu'avec l'effort industriel actuel derrère le langage c'est difficile d'obtenir rapidement des résultats comparablement intéressants. Je ne me rappelle plus ses termes exacts, mais il me semble qu'il ait dit qu'il n'y avait plus rien à faire avec Java non plus à ce niveau, ce qui expliquerait qu'ils sont en train de se tourner vers les langages dynamiques. Il a par la suite argumenté qu'au niveau industriel c'est toujours possible de mettre des ressources démesurées pour optimiser même le pire des langages. Pour supporter son argument, il m'a dit que certains estiment à 1 milliards $ l'argent qui a collectivement été mis sur l'optimisation de Java. Steve a envoyé une demande de financement en Australie la semaine dernière pour leur projet de VM et est en attente de réponse. Atony s'est plaint qu'il était difficile de faire passer des projets "d'infrastructure" à NSF et a même lancé à la "blague" qu'il aurait peut-être mieux fait d'aller en industrie pour faire de l'infrastructure. Il aurait peut-être eu moins de liberté sur le choix de ce qu'il aurait construit mais au moins il aurait pu le faire. Il y a eu des discussions sur la position des gros joueurs, Oracle, VMWare et de leurs projets en cours, dont je ne me rappelle plus malheureusement. Dans tous les cas, je suis ressorti avec la nette impression que Steve et Antony entretiennent des contacts étroits avec plusieurs personnes en industrie et qu'ils orientent leurs projet de recherches en fonction de ce qui s'y passe. J'ai également eu l'impression que leurs projets étaient solides techniquement mais clairement incrémentaux, ce qui a l'avantage d'être facilement transférable en industrie et plus facile à vendre pour obtenir du financement industriel mais le désavantage d'avoir une demi-vie limitée, ce qui oblige à suivre les tendances industrielles pour éviter de rater la vague ou de tomber en désuétude. Dimanche, j'ai pris la majeure partie de la journée pour travailler sur Photon, pour faire quelques optimisations et expériences supplémentaires pour l'article et j'ai peu rencontré de gens. J'ai tout de même parlé avec un allemand de l'université de Dresden. Il m'a partagé qu'un de ses collègues qui travaille avec les FPGAs a battu le record du monde pour la résolution du problème des N-Reines, c'est-à-dire qu'ils ont résolu une instance de 26x26 alors que le précédent record était 25x25, en exploitant le circuit de report de retenue qui sert normalement à accélérer les additions matérielles. Il a pas pu m'expliquer comment le problème pouvait être converti de cette façon car ce n'est pas son projet mais j'ai tout de même trouvé l'anecdote intéressante. Aujourd'hui, j'ai également passé la plus grosse partie de la journée à travailler sur Photon. J'ai été surpris de voir une session entière réservée à l'efficacité énergétique dans les centres de données. En même temps, ça fait du sens étant donné la monté de "l'informatique nuagique". Pendant le lunch, j'ai parlé avec Chen Ding <http://www.cs.rochester.edu/groups/bai/compiler>, prof à l'université de Rochester. Après mon pitch de 30s sur Photon, sa réaction fut "It seems like fun!". Il m'a même dit que l'instrumentation dynamique de Ruby pourrait peut être être fait avec une approche similaire. Il m'a ensuite partagé qu'il travaillait sur le Paraléllisme Sécuritaire en Ruby. Il avait un fort accent asiatique (chinois?) et j'ai eu de la difficulté à comprendre le détail de ses explications mais il semble avoir un intérêt marqué pour les optimisations dynamiques exploitant le paraléllisme tout en préservant la sémantique séquentielle du langage original. J'ai tâté l'eau pour voir s'il serait intéressé à appliquer ses idées à JavaScript, il semblait nettement préférer travailler avec Ruby ;-). Il connaissait Laurie de McGill et m'a suggéré de participer à CASCON, histoire de garder contact et d'être avec la gang de compilation ;-). Dans le reste de la journée, ce qui m'a marqué c'est le développement d'approche probabilistes pour le développement de certaines tâches (par opposition aux méthode déterministes). D'abord, un présentateur a suggéré l'utilisation de compteurs de performances pour obtenir de l'information suffisante pour déterminer la cause de bugs sur du logiciel déployé en production. Puisque l'approche n'est pas garantie d'obtenir des résultats ça a soulevé du scepticisme de la part d'une prof plus agée, de l'université de Virginia je crois. Ensuite, la présentation la plus intéressante fut une présentation invitée de Vikash K. Mansinghka <http://web.mit.edu/vkm/www/> dans laquelle il présentait un DSL pour l'apprentissage machine, basé sur des primitives probabilistes plutôt que déterministes (booléennes). Il argumentait avoir obtenu un facteur 100x en nombre de lignes de code et jusqu'à 1000x en vitesse d'exécution avec une implémentation sur FPGA. Le coeur de l'idée c'est qu'apprentissage machine, les fondements mathématiques offrent un parallélisme et un non-déterminisme inhérent qui n'est pas supporté efficacement par nos architectures séquentielles déterministes modernes. Pour exprimer les algorithmes, ils ont développé un langage spécifique au domaine basé sur une variante de scheme sans la mutabilité. Anecdote de métacircularité, à une question de l'auditoire sur les fondaments réellement révolutionnaires de leur approche, Vikash a argumenté que leur langage, Venture, est le premier langage offrant des primitives probabilistes capable d'implémenter son engin d'inférence dans son propre formalisme. La tendance sous-jacente semble suivre ce que David Ungar argumentait à DLS 2011, c'est à dire qu'il est temps d'abandonner le déterminisme et les garanties de correctitude pour aller chercher la prochaine vague d'amélioration majeure de performance (pour les applications qui s'y prêtent). Ma perception c'est que les méthodes probabilistes vont dans ce sens. Bon, j'arrête ici, j'ai un rapport à terminer ;). Erick

1 0

Article de RESoLVE sur Arxiv?
by Erick Lavoie 17 Mar '13

17 Mar '13

Comme j'ai reçu des opinions contradictoires de différentes personnes, j'aimerais savoir c'est quoi la position de notre lab sur la diffusion de nos résultats. Je pense mettre l'article soumis à RESoLVE sur Arxiv avec la mention qu'il n'a été publié dans aucune conférence. De cette façon, même si quelqu'un publiait des idées similaires je pourrais prétendre à la publication préliminaire. Même là, étant donné les résultats de performance actuels, je ne pense pas que le risque de plagiat direct est vraiment problématique. D'un autre côté, ça pourrait donner l'idée à d'autres d'essayer d'obtenir des meilleurs résultats, ce qui en soi serait vraiment cool car ça validerait tout le projet. Cependant, étant donné la dynamique du milieu académique, on aimerait quand même obtenir le crédit pour le travail initial... Finalement, il semblerait que la politique de certaines communautés d'utiliser la revue doublement anonyme et l'exigence de non-publication préliminaire pourrait être problématique, car à moins que le travail soit substantiellement étendu, la soumission pourrait être refusée. Donc j'aimerais savoir ce que vous en pensez. De mon côté, je croirais que ce serait mieux de diffuser les résultats et de mettre l'article sur Arxiv. Erick

1 0

RESoLVE: Compte-Rendu
by Erick Lavoie 16 Mar '13

16 Mar '13

J'ai donné la présentation ce matin à l'atelier RESoLVE, après une présentation de Michael Petullo, dans laquelle il a expliqué comment son équipe a simplifié la construction d'un nouvel OS, Ethos, dans l'objectif d'explorer l'espace de design de l'API d'un OS pour faciliter la construction d'applications sécuritaires par design. Leur démarche est analogue à la mienne au sens ou leur design réutilise autant que possible des outils existants pour implémenter les services majeurs de l'OS pour focuser leur efforts sur le design de l'API, alors que je réutilise autant que possible les éléments existants du langage pour implémenter les fonctionalités que nous ne sommes pas intéressé à instrumenter. L'atelier compte une dizaine de participants dont 2 organisateurs, le reste étant des présentateurs et une ou deux personnes ne présentant pas. Malheureusement VEE (Virtual Execution Environment) semble avoir attiré tous les autres participants à la conférence de la journée alors notre audience est limitée. Pour ma présentation, j'ai mis l'emphase sur le contexte d'application du système (i.e. l'instrumentation dynamique pour la sécurité, la compréhension de programmes, le design d'optimizations, etc.) et une vision de haut-niveau de l'architecture du système et j'ai complètement omis l'explication des optimizations réalisées. Cela fut un bon choix car plusieurs personnes dans l'audience viennent du monde de l'OS et ont peu d'expérience avec JavaScript. Les gens ont vraiment apprécié le diagramme d'architecture explicitant l'interaction entre les composants à différentes couches du système et ont confirmé que cette représentation semble "nouvelle". J'ai également eu des questions de base sur le modèle d'exécution des VMs pour JavaScript (Utilisation de Bytecode?, usage de JIT, etc.), sur la définition de métacircularité et sur la façon dont l'évaluation en performance a été réalisée. Cependant, personne n'a critiqué les résultats actuels au sens d'invalider l'utilité du système car il serait trop lent. Alex Garthwaite, maintenant à CloudPhysics après avoir travaillé chez VMWare, m'a demandé si on avait essayé de rouler Photon par dessus lui-même pour déterminer son propre comportement en performance ;-). J'ai partagé l'idée de Paul Khuong de faire une analyse asymptotique de performance sur un nombre arbitrairement grand de MetaVM stackée les unes par dessus les autres et j'ai eu quelques sourires. Après Paul et un gars à ma présentation chez Mozilla c'est la troisième personne qui suggère l'idée!. Je lui ai dit qu'on a fait quelquechose d'équivalent avec le nouveau système de Bruno. J'ai l'impression que d'instrumenter Photon avec lui-même ferait un cas d'utilisation vraiment intéressant et convaincant pour l'article de OOPSLA, spécialement si on obtenait de l'information utile pour comprendre son comportement en performance. En passant, je pense que le sandboxing de Photon lui permet de s'appliquer à lui-même alors que le prototype de Bruno ne pourrait probablement s'instrumenter lui-même, à ce que j'en comprends. Le plus enthousiaste à la présentation fut Antony Hosking de Purdue University, un des deux organisateurs de l'atelier. Il m'a dit qu'il allait définitivement prendre le temps de lire en détails l'article soumis pour comprendre le détail de l'implémentation et des optimisations réalisées. Son intérêt provient de son effort actuel, pendant sa sabbatique, pour implémenter un framework de création de VM qui résout les problèmes principaux derrière l'implémentation de VMs, soit la gestion mémoire, le scheduling de thread, la génération de code, la gestion de dépendances à l'exécution (et un 5e que je ne me rappelle pas). À terme, l'objectif est de battre CPython (et PyPy!) en performance et de montrer que Java peut être implémenté efficacement. Pour l'instant il ne pense pas implémenter JavaScript étant donné que l'effort industriel placé dans son optimisation rend plus difficile l'obtention de résultats de performance comparablement intéressants. Il ne semblait pas fermé à l'idée de le faire éventuellement mais sa réaction première était négative. Il était particulièrement intéressé à connaître les fonctionnalités dont j'aurais besoin de la part de la VM hôte sous-jacente pour optimiser les opérations de la MetaVM. Je lui ai partagé les efforts de Maxime dans la création d'une nouvelle VM JIT traçante pour JavaScript et l'opportunité qu'on aurait à travailler ensemble (Maxime et moi) pour faire le design des couches de façon à ce qu'elles interagissent de manière positive. Il était intéressé à ton travail, Maxime, alors je vais vous mettre en contact dans un email séparé. Après avoir appris que je commençais mon PhD il a confirmé que le problème de recherche que j'ai mentionné, soit "Comment réifier les éléments opaques de la sémantique de JavaScript pour permettre l'instrumentation dynamique à haut-niveau tout en minimisant son coût en performance?" semble prometteur et excitant. On a passé une partie du dîner à discuter de ses efforts actuels (non-reliés à mon projet) dans la formalisation d'un GC concurrent temps réel avec aucune pause pour les mutateurs (de ce que j'en ai compris). L'objectif est d'avoir à la fois une définition de l'algorithme qui se raffine à du C efficace et qui est également tractable pour être traduite à une logique formelle à partie de laquelle des preuves vont pouvoir être faites. La grosse limitation actuelle au niveau des formalismes existants est l'impossibilité d'exprimer la composition parallèle des opérations, reliée au comportement des caches modernes. Son principal collaborateur actuel est Steve Blackburn, que je suspecte avoir été un des reviewers de mon article de OOPSLA l'an dernier. C'était d'ailleurs l'un des meilleurs reviews en terme de qualité. Il était assis à la même table que moi au dîner mais je n'ai pas eu l'occasion de lui parler encore. Antony te connaît Marc, mais je n'ai pas trop compris dans quel contexte vous vous êtes connus. Ses explications furent brèves et je n'ai pas tenté de le faire répéter. Je viens d'entendre que son article le plus cité est celui à propos de Remembered Sets dans un contexte de GC. Benjamin je t'invite à Googler son nom pour voir si ça devrait apparaître dans ta section related work de mémoire de maîtrise. Ça va être ça pour aujourd'hui, je vous tiens au courant du reste de la conférence plus tard! Erick

1 0

Aller à la page :

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Dlteam-list