7. Donald E. Knuth
Professor Emeritus at Stanford University
ACM Grace Murray Hopper Award
Turing Award
Author of The Art Of Computer Programming
Creator of TeX
7
8. Donald E. Knuth
Nous devrions oublier les petites
efficacités, disons environ 97% du
temps: l'optimisation prématurée
est la racine de tout mal.
Pourtant, nous ne devrions pas
laisser passer notre opportunité
dans ce 3% critique.
8
9. Donald E. Knuth
L'expérience universelle des
programmeurs qui ont utilisé des
outils de mesure a été que les
suppositions intuitives échouent.
9
41. Profileurs intégrés
Compilation en cours pendant qu’on mesure ?
Class loading en cours pendant qu’on mesure ?
Taux d’allocation d’objets par benchmark
Quelles méthodes consomment du temps CPU
41
45. Java Mission Control
GUI pour visualiser les données de JFR
Pas toujours la meilleure façon de le faire
Pourquoi ?
46.
47.
48. Flamegraphs
Nouvelle visualisation pour la sortie des profileurs
Crée par Brendan Gregg chez Netflix
Disponible sur Github
Normalement utilisée pour le CPU, mais pas que ...
68. Vérifier que le code correspond aux attentes
Vérifier qu'aucune régression n'est introduite
Valider les idées d'optimisation
Couvrir les performances fixes avec un test associé
Amadeus est le leader mondial de l'industrie du voyage.
Quand vous êtes un développeur, vous voulez:
Finir votre code
Que ça marche
Que ça marche vite!
Donc que faites-vous ?
Vous faites l'optimisation !
N'est-ce pas?
”L'optimisation prématurée est la racine de tout Mal”
This catching phrase is usually used without much context. Just like biblical citations it can lead to religious wars.
Let’s check the context around that phrase.
”L'optimisation prématurée est la racine de tout Mal”
This catching phrase is usually used without much context. Just like biblical citations it can lead to religious wars.
Let’s check the context around that phrase.
Mettons du contexte autour de cette citation. Regardons ce qui est écrit avant et après cette phrase dans le papier où elle est apparue.
Knuth is the guy who said that.
There’s some polemic about whether the quote is originally from Knuth or if he was citing Tony Hoare.
This article tries to ”prove” that it’s actually from Knuth:
https://shreevatsa.wordpress.com/2008/05/16/premature-optimization-is-the-root-of-all-evil/
A little bit of context:
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunity in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgements about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that the intuitive guesses fail.”
Page 268
Donald Knuth
Structured programming with go to statements
Computing Surveys, Vol. 6, No. 4, December 1974
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.6084&rep=rep1&type=pdf
A little bit of context:
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunity in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgements about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that the intuitive guesses fail.”
Page 268
Donald Knuth
Structured programming with go to statements
Computing Surveys, Vol. 6, No. 4, December 1974
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.6084&rep=rep1&type=pdf
Now you’re all convinced that you should be measuring the performance of your code. But wait, don’t just put timers on your unit-tests .
Now you’re all convinced that you should be measuring the performance of your code. But wait, don’t just put timers on your unit-tests .
Explain how code is initially interpreted;
Then, compiled at runtime;
Then, it runs in compiled mode.
Explain how code is initially interpreted;
Then, compiled at runtime;
Then, it runs in compiled mode.
Explain how code is initially interpreted;
Then, compiled at runtime;
Then, it runs in compiled mode.
Branch prediction
Loop unrolling
Dead code elimination
Autobox elimitation
Constant propagation
Null check elimination
Algebraic simplification
Devirtualisation
Range check elimitation
Etc.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
The thread scope matches well the concept of application server, because usually Java app servers have scope per thread.
This would be like processing 20 requests in parallel.
Benchmark scope would be a cache that all your requests are accessing. It should be guarded by synchronization mechanisms to make sure that it remains consistent.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
Write to a volatile happens-before every subsequent read of that volatile
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
Instead of using a single lock for the shared data, the shared data is segmented with each segment having its own lock. Uncontended lock acquisition is very cheap; it's the contented locks that cause scalability issues.
With a different lock for each partition, ConcurrentHashMap effectively reduces how often a lock is requested by the number of partitions. You can think of ConcurrentHashMap as made up of n separate hash tables.
Write to a volatile happens-before every subsequent read of that volatile
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
API available (even if unofficial) means that the data is hackable;
Lots of recorded events, e.g. CPU
API available (even if unofficial) means that the data is hackable;
Lots of recorded events, e.g. CPU
La vue hiérarchique conduit à cliquer sans cesse et, parfois, ça bloque la GUI
Les flamegraphs peuvent être utilisés pour n’importe quelle donnée qui se presente bien de façon hiérarchique, e.g. tout ce qui est stacktrace.
Dans un flammegraph, les fonctions seront agrégées en fonction de leur stacktrace, donc réorganisées pour regrouper autant que possible la même stacktrace.
Dans un flammegraph, les fonctions seront agrégées en fonction de leur stacktrace, donc réorganisées pour regrouper autant que possible la même stacktrace.
Jfr-flame-graph : est utilisé pour convertir le format proprietaire de JFR en input texte pour le script perl de Brendan Gregg
FlameGraph : script perl que converti le format text en fichier SVG
Les flamegraphs peuvent être utilisés pour n’importe quelle donnée qui se presente bien de façon hiérarchique, e.g. tout ce qui est stacktrace.
Jfr-flame-graph : est utilisé pour convertir le format proprietaire de JFR en input texte pour le script perl de Brendan Gregg
FlameGraph : script perl que converti le format text en fichier SVG
Les flamegraphs peuvent être utilisés pour n’importe quelle donnée qui se presente bien de façon hiérarchique, e.g. tout ce qui est stacktrace.
Jfr-flame-graph : est utilisé pour convertir le format proprietaire de JFR en input texte pour le script perl de Brendan Gregg
FlameGraph : script perl que converti le format text en fichier SVG
Les flamegraphs peuvent être utilisés pour n’importe quelle donnée qui se presente bien de façon hiérarchique, e.g. tout ce qui est stacktrace.
Nombre des fois qu’un thread a été bloque sur ce lock. La stack trace done le lock.
Nombre des fois qu’un thread a été bloque sur ce lock. La stack trace done le lock.
Nombre des fois qu’un thread a été bloque sur ce lock. La stack trace done le lock.
JMH is an open-source project that does exactly that. It’s part of the OpenJDK project and we will see how it can help you.
LMAX: Our micro-benchmarks currently take over an hour to run, though with more hardware we could run them in parallel to improve this. That's still not bad, but for comparison, our suite of ~11k acceptance tests only takes ~25mins...
Reduce noise / Isolate your benchmarks as much as possible (using cpu isolation, sched_setaffinity);
Care about a correct warmup phase / Give benchmarks enough time to run;
Don't do nanosecond per operation benchmarks in Continuous integration;
Define regression / Some variance is expected;
Define well your baseline;
Differentiate inter-version, intra-version regressions;
Make sure issues backlog is tracked and handled.