"Une erreur typique - comparer sans réfléchir tout de suite": une entrevue avec Andrey Akinshin sur l'analyse comparative

L'année dernière, Andrei Akinshin (Dreamwalker), le livre «Pro ​​.NET Benchmarking» a été publié : un travail détaillé sur le benchmarking, utile à la fois aux développeurs .NET et aux informaticiens dans d'autres domaines.

Lorsqu'il restait quelques mois avant sa sortie, nous avons organisé la conférence DotNext 2019 Piter, où lors de la diffusion en ligne, nous avons interrogé Andrei sur le livre et généralement sur l'analyse comparative. Il semblerait que depuis lors, cette interview soit devenue obsolète: là, on parle du livre au futur, et maintenant ça fait déjà six mois. Mais au cours des six derniers mois, l'humanité n'a pas décidé autrement de prendre le 99e centile - donc pour tous ceux qui peuvent utiliser l'analyse comparative, les réponses d'Andrei ont encore beaucoup de réponses pertinentes et intéressantes.

Il jouerasur l'avenir de DotNext avec le sujet «Parlons de l'analyse des performances» - c'est-à-dire non pas de la rédaction de benchmarks, mais de l'analyse des valeurs qu'ils ont collectées. À l'heure actuelle, Andrey étudie des centaines d'articles sur les statistiques mathématiques pour vous parler des méthodes les mieux adaptées à l'analyse des performances dans la vie réelle. Dans le livre, une attention est également accordée à une telle analyse, et dans une interview, Andrey vient d'expliquer son importance. Par conséquent, en prévision d'un nouveau rapport, nous avons ouvert une vidéo d'entrevue pour tout le monde, et nous avons fait une transcription textuelle spécifiquement pour Habr: maintenant, elle peut non seulement être consultée, mais aussi lue.

L'essentiel du livre

- Nous souhaitons à nouveau la bienvenue aux téléspectateurs de l'émission DotNext. Cette fois, Andrey Akinshin est avec nous.

- Bonjour à tous!

- Maintenant, la principale nouvelle qui vous concerne est l'annonce du livre, qui sortira d'ici septembre ...

- Si tout se passe bien, il sortira fin juin.

Ici, vous devez comprendre le fonctionnement des délais. Il existe les plus extrêmes, qui ne peuvent en aucun cas être violées. Sur Amazon, la date de sortie du livre est d'environ le 23 août. Et si vous retournez cette date, toutes sortes de sanctions iront, Amazon sera mécontent. Et si le livre sort plus tôt - eh bien, c'est bien.

Par conséquent, j'espère vraiment que s'il n'y a aucun problème nulle part, il sera possible de lire en juin. Et donc, la fin août est la date limite. Vous travaillez également en informatique, vous comprenez donc comment ces choses fonctionnent.

- La plupart du public a probablement déjà entendu parler du livre. Mais pour ceux qui ne le savent pas, commençons par une histoire à son sujet.

- Le livre s'appelle "Pro .NET Benchmarking" . Elle fait partie de la série Apress - la même que celle dans laquelle le livre Pro .NET Memory Management de Conrad Coconut a récemment été publié . Et il y a eu le livre de Sasha Goldstein «Pro ​​.NET Performance» publié - vous en avez probablement entendu parler, il est joué de temps en temps sur DotNext. Et dans la même série vient mon livre. Il s'agit de savoir comment effectuer une analyse comparative du début à la fin.

J'ai essayé de couvrir une variété d'aspects, à partir des statistiques, il y a un chapitre séparé à ce sujet. Et ce n'est pas la façon dont on nous a enseigné à l'université, je n'ai pas un seul exemple de "balles qui sont mises dans des boîtes". Concentrez-vous sur ce qui peut être utile lors de l'analyse comparative: mesures, écart-type, erreurs standard, toutes sortes d'intervalles de confiance et comment les interpréter. Autrement dit, nous parlons de ce qui suit: si le BenchmarkDotNet conditionnel vous a donné un million de numéros différents, que dois-je faire avec eux? Des recommandations pratiques sont données sur la façon d'interpréter ces données et d'en tirer des conclusions.

Il y a un chapitre, par exemple, sur les benchmarks liés au CPU et sur les benchmarks liés à la mémoire. Il existe de nombreuses études de cas différentes avec des exemples de la façon dont vous pouvez écrire un point de référence pour 3-4 lignes et en même temps vous tirer une balle dans le pied en raison de certains effets microarchitecturaux des processeurs Intel modernes.

Et il y a un chapitre sur l'analyse des performances et les tests de performances. L'analyse comparative est bonne en tant qu'expérience distincte, mais beaucoup de gens veulent mettre des repères sur CI, les conduire tout le temps sur un serveur (idéalement le même), collecter des données, par exemple, pour détecter les dégradations de performances. Par conséquent, il existe un chapitre sur la façon de travailler avec de telles données et d'écrire différents types de tests de performances (il y en a beaucoup différents). Quelle est, par exemple, la différence entre les tests pour un démarrage à froid, pour un démarrage à chaud, comment traiter des graphiques, comment traiter des tableaux de données entiers.

À l'un des derniers DotNext j'ai parléÀ propos de l'analyse des performances, il a parlé de différentes méthodes de recherche d'anomalies de performances. La dégradation n'est pas le seul problème qui peut survenir. Par exemple, il existe des distributions multimodales lorsque l'indice de référence fonctionne pendant une seconde ou dix. Dans un grand produit (en particulier multi-thread), de tels cas le seront sûrement, et ils masquent généralement le problème. Même s'il ne s'agit pas de tests de performances exécutés sur les machines correspondantes, mais des tests habituels, le diable sait comment "trembler" et donner beaucoup de variance, alors si vous collectez et analysez toutes ces données, vous pouvez trouver beaucoup de tests avec de tels problèmes.

En général, il y a un très large éventail de tâches très intéressantes dans l'analyse comparative, et je les ai soigneusement disposées sur les étagères. Mais j'ai essayé de le faire aussi pratique que possible, afin que ce ne soit pas seulement une théorie, mais des connaissances que je pouvais prendre et utiliser sur mon produit en production.

Benchmarking subtilités

- Je me souviens de la phrase que j'ai lue quelque part: pour tout résultat de référence sur Internet, vous pouvez trouver une mauvaise interprétation de ce résultat. Dans quelle mesure êtes-vous d'accord avec cette phrase?

- Tout à fait d'accord. Il y a beaucoup de discussions sur les repères valides et invalides, mais si vous regardez à vol d'oiseau, alors si vous avez en quelque sorte mesuré quelque chose, collecté au moins quelques mesures de performance et les avez affichées dans un fichier ou une console, alors c'est un repère avec un certain Du point de vue, c'est valable: quelque chose mesure et affiche des chiffres. La principale question est de savoir comment interprétez-vous ces chiffres et que ferez-vous ensuite.

L'une des premières erreurs des personnes qui sont plongées dans le sujet de l'analyse comparative est qu'elles vont tout évaluer sans se poser la question «pourquoi». Eh bien, nous avons comparé, mesuré - et puis quoi? Il est très important de déterminer dans quel but nous effectuons l'analyse comparative.

Par exemple, si nous voulons créer une charge de travail stable, avec laquelle nous pouvons évaluer les performances de certains cas et détecter une dégradation des performances - c'est un cas. Un autre cas: nous avons deux bibliothèques qui font la même chose, et nous sommes pour la performance et nous voulons choisir la plus rapide - comment comparez-vous cela?

Du point de vue des interprétations, tout ce qui conduit à la bonne décision commerciale peut être considéré comme bon. Ce n'est pas nécessairement correct, mais si vous réussissez, c'est bien.

Et il y a une telle chose que j'ai même des exercices spéciaux dans mon livre. Disons qu'il y a deux algorithmes, et l'exercice est le suivant: vous devez d'abord faire un benchmark qui montre que le premier algorithme est 10 fois plus rapide que le second, puis un benchmark qui montre le contraire. Vous pouvez jouer avec les données source, avec l'environnement, changer Mono en .NET Core ou exécuter sur Linux au lieu de Windows - il existe un million d'options de personnalisation. Et la conclusion est la suivante: si vous tentez de montrer qu'un programme fonctionne plus rapidement qu'un autre, il y a très probablement un moyen de le faire.

Par conséquent, pour revenir à votre question, il est très difficile de tracer une ligne entre les repères valides et invalides et de donner une définition de invalide (c'est-à-dire ce qui devrait être là pour que nous reconnaissions qu'il est mauvais). Et la même chose avec la distinction entre l'interprétation «correcte» et «incorrecte»: vous ne pouvez pas comprendre pleinement ce qui se passe dans le benchmark, vous ne pouvez pas expliquer pleinement tous les processus internes (ce qui n'est pas très bon, il vaudrait mieux le faire, mais vous pouvez sauter cette partie, si très occupé), mais en même temps, comprenez en général à quoi ressemble l'image. Et si vous avez réussi à bien faire (ici encore la question est de savoir ce qui est «bien») et à prendre la bonne décision commerciale, alors vous êtes bien fait.

«Si vous prenez et lisez votre livre de façon réfléchie, commencerez-vous à prendre les« bonnes »décisions? Ou y a-t-il beaucoup de choses en dehors de la portée du livre qui influencent également?

- L'analyse comparative est un sujet qui, à mon avis, ne peut être maîtrisé qu'en pratique. Oui, dans le livre, je donne beaucoup de méthodologies, de recommandations, décris les pièges. Dans le benchmarking, il y a beaucoup de tels problèmes que si vous ne les connaissez pas, alors dans la vie vous ne les devinerez jamais. Mais si vous les connaissez, cela ne donne absolument aucune garantie que vos repères seront corrects. Autrement dit, il s'agit d'une telle boîte à outils minimale qui aide à s'orienter en quelque sorte dans le domaine.

Vous ne pouvez écrire des tests de performance et des tests de performance normaux que si vous traitez systématiquement ce domaine. La grille neuronale dans la tête s'entraîne à lire les rapports de performances - lorsque vous regardez les distributions obtenues lors des mesures de performances, vous consultez les tableaux récapitulatifs, par exemple, de BenchmarkDotNet (et pas seulement la colonne «Moyenne», mais aussi l'écart type ), vous examinez les erreurs types, les caractéristiques supplémentaires, au minimum, au maximum, sur un quantile, sur le 99e centile.

Lorsque vous regardez tout cela très, très, beaucoup, un certain volume minimum est accumulé, vous permettant d'effectuer des investissements de performance beaucoup plus rapidement et de voir ce que les gens sans expérience (même s'ils lisent mon livre et un million de billets de blog) ne verront pas en raison du fait qu'ils n'ont aucune expérience. Ils ne verront aucun problème ou ne pourront pas interpréter instantanément et correctement les données.

- Sur ce DotNext dans une interview avec Dmitry Nesteruk (mezastel), nous avons dit que généralement les livres informatiques deviennent rapidement obsolètes, mais s'il écrit sur les modèles de conception, alors tout n'y change pas chaque année. Et qu'en est-il de l'analyse comparative: ce livre peut également ne pas être obsolète depuis très longtemps, ou auriez-vous écrit autre chose il y a deux ans?

- Il est très difficile de donner une réponse monosyllabique. Il y a une base, du matériel qui ne devient pas obsolète. Les mêmes statistiques: comme le 99e centile était envisagé il y a deux ans, il l'est toujours, et l'on soupçonne que rien ne changera dans deux ans.

Soit dit en passant, en même temps, je note: je crois que l'analyse comparative devrait être une discipline distincte. Pour une raison quelconque, historiquement, personne n'a accordé l'attention voulue aux mesures systématiques. Eh bien, qu'y a-t-il? Il l'a pris, a démarré le chronomètre, éteint le chronomètre, regardé combien de temps s'était écoulé. Et dans le livre, selon les estimations préliminaires, il s'est avéré plus de 600 pages, et tout le monde me demande: "Qu'est-ce qui pourrait être écrit sur 600 pages?"

Et je crois que cela devrait être une discipline, un domaine distinct de l'informatique. Et c'est une telle direction «agnostique du langage», où l'équipement général reste correct et ne change pas: c'est ce que l'humanité dans son ensemble a atteint. Cela s'applique à tous les temps d'exécution, langues et écosystèmes. Mais ce n'est qu'une partie de la réponse.

Et l'autre partie est déjà liée aux fonctionnalités du runtime, aux fonctionnalités de .NET. À l'heure actuelle (nous en avons beaucoup à ce sujet dans le livre), nous avons le .NET Framework, il y a le .NET Core et il y a Mono. Les mesures de performances peuvent varier sur différents temps d'exécution ou même sur deux versions adjacentes du même temps d'exécution. Si vous prenez .NET Core 2.2 et le prochain .NET Core 3.0, certaines charges de travail diffèrent comme le jour et la nuit. Ils font des optimisations tellement cool que les scénarios les plus simples sont simplement accélérés 10 fois, 50 fois.

Il est clair que si vous passez à la nouvelle version de Core, l'ensemble du programme ne commencera pas à fonctionner 50 fois plus vite, mais les petites pièces individuelles, qui tombent le plus souvent dans des repères synthétiques, pourraient bien être overclockées.

Et ce qui change, change principalement par rapport à toutes ces versions, de nouvelles optimisations apparaissent. Par exemple, le jitting à plusieurs niveaux apparaîtra dans .NET Core 3.0 . C'est-à-dire que le runtime peut d'abord générer rapidement une implémentation native simple (et peu efficace) pour la méthode par code. Et puis, lorsque le runtime remarque que vous appelez cette méthode plusieurs fois, il passera un peu plus de temps en arrière-plan et régénérera un code plus productif. Il s'agit du fait qu'il y a eu de nombreuses années en Java dans HotSpot, dans le monde .NET, il apparaîtra dans la version incluse par défaut cette année au deuxième semestre (ndlr: nous vous rappelons, l'interview a été réalisée en 2019) .

Et pour BenchmarkDotNet, il est difficile de gérer de tels cas normalement. Dans le monde Java, Alexey Shipilev dans son JMHJ'ai appris à le gérer il y a longtemps, mais nous devons encore le faire. A ce sujet aussi, je communique avec les gars qui ont vu le runtime. Autrement dit, j'aurai besoin de stylos spéciaux, d'API de leur part pour gérer correctement tout.

Ces choses changent. Bientôt, nous aurons tous les runtimes unis, il y aura un .NET 5. Je suppose qu'il sera renommé d'une autre manière, qu'il s'agit d'un nom intermédiaire. Peut-être que ce ne sera pas 5, mais 6, car nous avions déjà une version de .NET Core 5.0.

- Eh bien, comme nous le savons depuis Windows, ce n'est pas un problème pour Microsoft d'ignorer le numéro dans la version.

- Oui. Déjà à l'époque de DNXil y avait des frameworks cibles avec le cinquième .NET Core, maintenant "5.0" a déjà été beaucoup utilisé où, il y a beaucoup d'anciens articles. Donc je ne sais pas, ils vont en quelque sorte faire le cinquième après la troisième version, mais j'aurais manqué non seulement les quatre, mais aussi les cinq, et j'aurais fait le sixième tout de suite. Et compte tenu du fait qu'ils veulent désormais rendre, à mon avis, les versions impaires stables LTS, et les paires pas très stables, il serait possible d'en faire sept immédiatement.

Eh bien, c'est leur mal de tête. Mais il est important que vous deviez surveiller le développement des runtimes, et c'est cette partie spécifique à .NET qui devient obsolète - pas si rapidement qu'elle est obsolète, mais silencieusement.

Je pense déjà à faire la deuxième édition d'un livre où tout cela est mis à jour. Les processeurs Intel ne s'arrêtent pas non plus, ils se développent, de nouvelles optimisations apparaissent, qui doivent également être traitées de manière astucieuse. Skylake a présenté beaucoup de surprises désagréables, dans le même BenchmarkDotNet, beaucoup de travail a été fait pour contourner ses optimisations délicates et obtenir des résultats stables.

Interaction avec BenchmarkDotNet et Rider

- Il est clair que travailler sur la bibliothèque BenchmarkDotNet vous a donné beaucoup d'expérience, il est donc logique que ce soit vous qui ayez écrit le livre sur le thème de l'analyse comparative. Et ici, la question se pose: le livre est-il en quelque sorte lié à BenchmarkDotNet, ou est-il «agnostique»?

- J'ai essayé de la rendre agnostique aux outils. À propos de BenchmarkDotNet, j'ai une petite section, et je l'utilise également comme exemples dans mes études de cas: quand j'ai besoin de montrer un petit effet microarchitectural, je dis "ici, nous allons écrire un benchmark en utilisant BenchmarkDotNet". Pour ne pas mettre un million de strappings dans chaque benchmark du livre, nulle part pour écrire séparément la logique d'échauffement. Nous avons déjà une solution toute faite qui fait toute la routine de référence pour nous, et nous ne parlerons plus de la méthodologie (nous en avons parlé au début), mais des effets au niveau du CPU.

Voici deux cas d'utilisation, et j'ai essayé de faire le reste aussi abstrait que possible de BenchmarkDotNet. Que le livre était utile non seulement aux développeurs .NET, mais aussi, par exemple, aux développeurs Java. Parce que toutes les mécaniques courantes sont facilement portées sur n'importe quelle autre plate-forme, c'est-à-dire que .NET et BenchmarkDotNet sont utilisés comme outil pour illustrer le concept.

- Et dans l'autre sens était l'influence? Qu'est-ce qui, au cours du travail sur le livre, avez-vous finalement compris ce que vous devez faire dans BenchmarkDotNet comme ça?

- Oui, j'ai écrit toutes sortes de petites puces spécialement pour qu'elles soient dans le livre. Par exemple, la détection cool de distributions multimodales, dont j'ai déjà parlé.

Dans le bon sens, lorsque vous analysez les résultats du benchmark, vous devez toujours regarder la distribution, ouvrir l'image, étudier ce qui s'y est passé. Mais en pratique, personne ne le fait. Parce que si je lance, conditionnellement, 50 benchmarks sur une sorte de base de code, et je change cette base de code 10 fois par jour, et chaque fois que je redémarre l'ensemble complet, alors même je ne regarderai certainement pas 50 graphiques, je dois le faire paresseusement. Et cela, dans l'ensemble, n'a pas de sens, ce n'est pas une tâche humaine, c'est une tâche de réglage.

BenchmarkDotNet possède un algorithme sympa qui détermine automatiquement que la distribution est multimodale et avertit l'utilisateur: «Mec! Regarde le tableau! Tout va mal ici! C'est là que la valeur moyenne est apparue dans la colonne, ne la regardez pas! Cela ne correspond à rien, regardez le tableau! »

Et cela n'est imprimé que dans les cas où il est vraiment important de ne pas distraire une personne dans les graphiques en vain. Là, une approche basée sur les soi-disant valeurs m de Brendan Gregg, est un ingénieur de performance de premier plan chez Netflix.

Mais son approche ne m'a pas suffi car il utilise des histogrammes spécialement construits basés sur la distribution. Autrement dit, un histogramme est appliqué à l'entrée, la valeur n est prise en compte et elle est déterminée par magie, nous avons une distribution multimodale ou non. Et comment construire des histogrammes, Brendan Gregg n'a pas écrit! J'ai dû inventer une sorte de mon propre vélo, qui fonctionnait étonnamment bien. Cet algorithme est résumé dans un livre.

Il y avait pas mal d'histoires de ce genre. L'écriture directe d'un livre m'a pris deux ans et demi. En général, je collecte du contenu depuis cinq ans et deux ans et demi à partir du moment où j'ai conclu un accord avec la maison d'édition. Depuis deux ans et demi, grâce au livre, la bibliothèque a été pompée à bien des égards, beaucoup de choses y sont apparues.

- C'est difficile à imaginer, mais en plus du livre et de BenchmarkDotNet, dans votre vie, il y a aussi du travail sur Rider - et là, vous aurez probablement aussi un benchmark. Pouvez-vous en parler? Vous aviez sur Twitter des photos d'un macbook dans le congélateur et à côté du radiateur , vérifiant comment cela affectait les performances - était-ce pour le travail, ou pour un livre, ou les deux à la fois?

- Plutôt, tous ensemble. En cavalierNous utilisons BenchmarkDotNet pour des investissements de performance individuels. C'est-à-dire, lorsque vous devez trouver la meilleure façon d'écrire du code dans une partie critique des performances, ou vous devez étudier comment nous différons dans le comportement d'un morceau de code sous Mono sur Linux et sous .NET Framework sur Windows. Nous prenons BenchmarkDotNet, concevons une expérience, collectons des résultats, tirons des conclusions, prenons des décisions commerciales, comment écrire du code pour qu'il fonctionne rapidement partout. Et puis cette référence est jetée.

Autrement dit, nous n'avons pas de repères systématiques sur BenchmarkDotNet qui fonctionneraient sur CI. Mais à la place, nous avons de nombreux autres domaines de travail de performance. Par exemple, un outil interne qui recueille les nombres de tous les tests et recherche différentes anomalies de performances, les mêmes distributions multimodales, teste avec un grand écart-type et recueille le tout dans un tableau de bord.

Une autre approche sur laquelle nous travaillons depuis très longtemps mais que nous n'avons pas fait est les tests de performances fiables. Autrement dit, nous voulons faire une approche dans laquelle il est impossible de geler la dégradation des performances dans la branche principale.

Et les benchmarks classiques ne sont pas très adaptés, car ils sont très gourmands en ressources. Il est nécessaire de faire beaucoup d'itérations afin d'obtenir des statistiques normales et de travailler en quelque sorte avec. Et lorsque vous avez des centaines ou des milliers de tests de performances, si vous exécutez chaque test 30 fois, comme prévu, et c'est pour chaque brunch de chaque personne - aucun fer ne suffit.

Par conséquent, d'une part, je veux faire le moins d'itérations possible (idéalement une, mais une à la fois, il est très difficile de dire si vous avez une dégradation). La pire chose qui puisse arriver est un faux positif, quand vous n'avez rien fait de mal, mais le système parle de dégradation des performances et ne vous permet pas de figer le brunch en master. Si cela se produit, ils me jetteront des pierres et personne n'utilisera ce système.

Par conséquent, conditionnellement, si après une itération il y a un soupçon de dégradation, mais qu'il n'y a pas de confiance à 100%, cela vaut la peine de faire la deuxième itération. Après le second, vous pouvez décider que tout va bien pour nous, juste par hasard que quelque chose s'est passé. Vous pouvez dire que maintenant nous sommes sûrs de la dégradation des performances et interdisons la marche. Et vous pouvez dire: "Non, deux itérations ne suffisent toujours pas, nous devons passer à la troisième." Eh bien et ainsi de suite.

Et sur un petit nombre d'itérations (une, deux, trois), les tests standard ne fonctionnent pas du tout. Voici mon test de Mann-Whitney préféré.commence à bien fonctionner lorsque vous avez au moins cinq itérations. Mais nous n'atteignons le cinquième que lorsque tout est complètement mauvais. En conséquence, il est nécessaire de développer un tel ensemble d'heuristiques qui ne donneront jamais de faux positifs, mais en même temps, il détectera les dégradations lorsqu'elles existent, avec le nombre minimum d'itérations possible. Et maintenant, c'est une tâche plutôt difficile pour un mélange d'ingénierie programmeur et de formules mathématiques. Nous n'avons pas encore fini, mais nous y allons.

Et sur le macbook dans le réfrigérateur - c'est aussi tout pour le travail. Maintenant, l'un des mini-projets que je fais beaucoup est l'étude des modèles d'étranglement thermique. La situation est la suivante: lorsque le benchmark lié au CPU charge très fortement le matériel, la température du CPU augmente et lorsqu'il atteint une certaine valeur seuil, le processeur ou le système d'exploitation Intel dit: «Ay-yy-yy! Nous surchauffons! » - et pendant un certain temps réduit la fréquence. Et puis, par exemple, 2 à 3 itérations sont obtenues, au cours desquelles la dégradation des performances est censée être visible. Et nous sommes comme: «Oh, oh, oh, oh! Tout est mauvais! Nous ne tiendrons pas ce brunch. » Mais en fait, nous avons juste un agent de performance surchauffé.

Il existe différentes manières de gérer cela. Nous avons notre propre salle de serveurs avec nos propres stands, nous essayons d'y fournir un refroidissement suffisant pour que cette limitation thermique ne se produise pas. Mais cela ne réussit pas toujours non plus. Autrement dit, nous ne pouvons pas geler complètement les agents, ils ne seront pas beaucoup de cela, mais en quelque sorte nous devons nous battre.

Une autre option consiste, par exemple, à désactiver le turbo boost afin que le processeur ne dépasse jamais la fréquence de base. En conséquence, cela réduit la probabilité de surchauffe, le processeur n'est déjà pas si chaud. Et deuxièmement, nous obtenons une fréquence plus stable (dans un turbo boost, elle tremble souvent beaucoup, et avec un turbo boost désactivé à la fréquence de base, cela va très droit et vous obtenez un résultat beaucoup plus stable).

Et les modèles d'étranglement thermique sont très différents: d'une part, beaucoup dépend du processeur et de la configuration de tout le fer, et d'autre part, du système d'exploitation. Par exemple, prenez un Mac: nous avons beaucoup de tests Mac, car il y a beaucoup d'utilisateurs et ils ne veulent pas que Rider ralentisse. Et il existe un modèle d'étranglement thermique très agressif.

Sur les nouveaux processeurs Intel récemment annoncés, il y a des blagues encore plus complexes. Si votre température descend en dessous d'une certaine valeur seuil, comme 50 degrés, alors la fréquence peut sauter encore plus haut que la fréquence maximale sur un turbo boost régulier. Autrement dit, ils font quelque chose comme l'overclocking dynamique "un peu" à basse température. Le même effet. Nos agents sont toujours d'anciens processeurs conditionnels, n'ont pas encore été mis à niveau, mais les geeks qui aiment s'acheter les dernières nouveautés peuvent marcher dessus.

Avenir

"Je dois vous interrompre, car le temps presse." Mais pour ceux qui sont intrigués: allez-vous écrire un article de blog sur ce matériel?

- Oui, pendant que je collectionne du matériel, tout y est très intéressant, un modèle très complexe de limitation thermique. Il existe, par exemple, Power Throttling sur Windows, qui vous permet d'économiser la batterie et bien plus encore. Pendant que je collecte des données, je combinerai tout cela soit dans un article de blog, soit même dans un article scientifique, ou cela tombera dans la deuxième édition du livre.

, . — , , .

— DotNext 2020 Piter -. , , , . -, , . -, . — .

Source: https://habr.com/ru/post/undefined/