“Kesalahan tipikal - tanpa memilah-milah segalanya dalam satu baris”: sebuah wawancara dengan Andrey Akinshin tentang pembandingan

Tahun lalu, Andrei Akinshin (Dreamwalker) buku "Pro .NET Benchmarking" diterbitkan : karya terperinci tentang pembandingan, berguna untuk pengembang .NET dan spesialis TI di bidang lain.

Ketika beberapa bulan tersisa sebelum rilis, kami mengadakan konferensi DotNext 2019 Piter, di mana dalam siaran online kami bertanya kepada Andrei tentang buku itu dan umumnya tentang benchmarking. Tampaknya sejak itu wawancara ini seharusnya menjadi usang: di sana mereka berbicara tentang buku di masa mendatang, dan sekarang sudah enam bulan. Tetapi selama enam bulan terakhir, umat manusia belum memutuskan sebaliknya untuk mengambil persentil ke-99 - jadi bagi semua orang yang dapat menggunakan tolok ukur, jawaban Andrei masih memiliki banyak hal yang relevan dan menarik.

Dia akan tampiltentang masa depan DotNext dengan topik "Mari kita bicara tentang analisis kinerja" - yaitu, bukan tentang menulis tolok ukur, tetapi tentang menganalisis nilai-nilai yang mereka kumpulkan. Saat ini, Andrey sedang mempelajari ratusan artikel tentang statistik matematika untuk memberi tahu Anda tentang metode yang paling cocok untuk analisis kinerja dalam kehidupan nyata. Dalam buku itu, perhatian juga diberikan untuk analisis tersebut, dan dalam sebuah wawancara, Andrey hanya menjelaskan pentingnya hal itu. Oleh karena itu, untuk mengantisipasi laporan baru, kami membuka video wawancara untuk semua orang, dan kami membuat transkrip teks khusus untuk Habr: sekarang tidak hanya dapat dilihat, tetapi juga dibaca.

Hal utama tentang buku itu

- Kami menyambut lagi pemirsa siaran DotNext. Kali ini Andrey Akinshin bersama kami.

- Halo semuanya!

- Sekarang berita utama yang terkait dengan Anda adalah buku yang diumumkan, yang akan dirilis pada bulan September ...

- Jika semuanya berjalan dengan baik, itu akan dirilis pada akhir Juni.

Di sini Anda perlu memahami cara kerja tenggat waktu. Ada yang paling ekstrem, yang tidak bisa dilanggar dalam hal apa pun. Di Amazon, buku ini sekarang memiliki tanggal rilis sekitar 23 Agustus. Dan jika Anda membalik tanggal ini, semua jenis hukuman akan hilang, Amazon tidak akan senang. Dan jika buku itu keluar lebih awal - baik, bagus.

Oleh karena itu, saya sangat berharap bahwa jika tidak ada masalah di mana pun, akan mungkin untuk dibaca pada bulan Juni. Jadi, akhir Agustus adalah batas waktu. Anda juga bekerja di IT, sehingga Anda mengerti bagaimana hal-hal ini bekerja.

- Sebagian besar penonton mungkin sudah mendengar tentang buku itu. Tetapi bagi mereka yang tidak tahu, mari mulai dengan cerita tentangnya.

- Buku ini disebut "Pro .NET Benchmarking . " Dia berasal dari seri Apress - seri yang sama dengan buku Conrad Coconut 's Pro .NET Memory Management baru-baru ini dirilis . Dan ada buku Sasha Goldstein "Pro .NET Performance" yang diterbitkan - Anda mungkin pernah mendengar tentang ini, dimainkan dari waktu ke waktu di DotNext. Dan dalam seri yang sama datang buku saya. Ini tentang bagaimana melakukan pembandingan dari awal hingga akhir.

Saya mencoba membahas berbagai aspek, mulai dari statistik, ada bab tersendiri tentangnya. Dan itu bukan cara kita diajarkan di universitas, saya tidak punya satu contoh pun tentang "bola yang dimasukkan ke dalam kotak". Fokus pada apa yang bisa berguna selama benchmark: metrik, deviasi standar, kesalahan standar, segala macam interval kepercayaan dan bagaimana menafsirkannya. Artinya, kita berbicara tentang yang berikut: jika BenchmarkDotNet bersyarat memberi Anda jutaan angka yang berbeda, apa yang harus saya lakukan dengan mereka? Rekomendasi praktis diberikan tentang cara menafsirkan data ini dan menarik kesimpulan.

Ada bab, misalnya, tentang tolok ukur terikat-CPU dan tentang tolok ukur terikat-memori. Ada banyak studi kasus yang berbeda dengan contoh-contoh bagaimana Anda dapat menulis tolok ukur untuk 3-4 baris dan pada saat yang sama menembak diri sendiri karena efek mikroarsitektur dari prosesor Intel modern.

Dan ada bab tentang analisis kinerja dan pengujian kinerja. Benchmarking baik sebagai eksperimen terpisah, tetapi banyak orang ingin menempatkan tolok ukur pada CI, menggerakkannya sepanjang waktu di beberapa server (idealnya sama), mengumpulkan data, misalnya, untuk mengetahui penurunan kinerja. Oleh karena itu, ada bab tentang cara bekerja dengan data tersebut dan menulis berbagai jenis tes kinerja (ada banyak yang berbeda). Apa, misalnya, perbedaan antara tes untuk memulai dingin, untuk mulai panas, bagaimana memproses grafik, bagaimana memproses seluruh array data.

Di salah satu DotNext terakhir saya berbicaratentang analisis kinerja, ia berbicara tentang berbagai metode mencari anomali kinerja. Degradasi bukan satu-satunya masalah yang mungkin timbul. Misalnya, ada distribusi multimoda saat benchmark bekerja selama satu detik atau sepuluh. Dalam produk besar (terutama multi-threaded), case seperti itu pasti akan, dan biasanya mereka menyembunyikan masalahnya. Bahkan jika ini bukan tentang tes kinerja yang berjalan pada mesin yang sesuai, tetapi tes yang biasa, iblis tahu bagaimana "gemetar" dan memberikan banyak perbedaan, maka jika Anda mengumpulkan dan menganalisis semua data ini, Anda dapat menemukan banyak tes dengan masalah seperti itu.

Secara umum, ada berbagai tugas yang sangat menarik dalam pembandingan, dan saya mengaturnya dengan hati-hati di rak. Tetapi saya mencoba untuk melakukannya sepraktis mungkin, sehingga itu bukan hanya teori, tetapi beberapa pengetahuan yang dapat saya ambil dan gunakan pada produk saya dalam produksi.

Selisih pembandingan

- Saya ingat frasa yang saya baca di suatu tempat bahwa untuk setiap hasil benchmark di Internet Anda dapat menemukan interpretasi yang salah dari hasil ini. Seberapa besar Anda setuju dengan frasa ini?

- Sangat setuju. Ada banyak pembicaraan tentang tolok ukur yang valid dan tidak valid, tetapi jika Anda melihat dari pandangan mata, maka jika Anda entah bagaimana mengukur sesuatu, mengumpulkan setidaknya beberapa metrik kinerja dan menampilkannya dalam file atau konsol, maka ini adalah patokan dengan tertentu Dari sudut pandang, itu valid: sesuatu mengukur dan menampilkan beberapa angka. Pertanyaan utamanya adalah bagaimana Anda menginterpretasikan angka-angka ini dan apa yang akan Anda lakukan selanjutnya.

Salah satu kesalahan pertama dari orang yang tenggelam dalam topik benchmark adalah bahwa mereka akan melakukan benchmark semuanya tanpa bertanya pada diri sendiri pertanyaan "mengapa." Ya, kami membuat tolok ukur, mengukur - lalu apa? Sangat penting untuk menentukan untuk tujuan apa kita melakukan benchmarking.

Misalnya, jika kita ingin membuat beban kerja yang stabil, yang dengannya kita dapat mengevaluasi kinerja kasus-kasus tertentu dan mendeteksi penurunan kinerja - ini adalah satu kasus. Kasus lain: kami memiliki dua perpustakaan yang melakukan hal yang sama, dan kami untuk kinerja dan kami ingin memilih yang tercepat - bagaimana Anda membandingkan ini?

Dari sudut pandang interpretasi, siapa pun yang mengarah pada keputusan bisnis yang tepat dapat dianggap baik. Itu belum tentu benar, tetapi jika Anda berhasil, itu bagus.

Dan ada hal seperti itu sehingga saya bahkan memiliki latihan khusus dalam buku saya. Katakanlah ada dua algoritma, dan latihannya adalah ini: pertama Anda perlu membuat tolok ukur yang menunjukkan bahwa algoritma pertama adalah 10 kali lebih cepat dari yang kedua, dan kemudian tolok ukur yang menunjukkan sebaliknya. Anda dapat bermain dengan sumber data, dengan lingkungan, mengubah Mono menjadi .NET Core, atau berjalan di Linux dan bukannya Windows - ada sejuta opsi untuk penyesuaian. Dan kesimpulannya adalah ini: jika Anda ingin menunjukkan bahwa satu program bekerja lebih cepat daripada yang lain, kemungkinan besar ada cara untuk melakukannya.

Oleh karena itu, kembali ke pertanyaan Anda, sangat sulit untuk menarik garis antara tolok ukur yang valid dan tidak valid dan memberikan definisi yang tidak valid (yaitu, apa yang seharusnya ada sehingga kami menyadari bahwa itu buruk). Dan hal yang sama dengan perbedaan antara interpretasi "benar" dan "salah": Anda tidak dapat sepenuhnya memahami apa yang terjadi dalam tolok ukur, Anda tidak dapat sepenuhnya menjelaskan semua proses internal (yang tidak terlalu baik, akan lebih baik untuk melakukan ini, tetapi Anda dapat melewati bagian ini, jika sangat sibuk), tetapi pada saat yang sama mengerti secara umum seperti apa gambar itu. Dan jika Anda berhasil melakukannya dengan benar (di sini sekali lagi pertanyaannya adalah apa yang "benar") dan sampai pada keputusan bisnis yang tepat, maka Anda sudah selesai.

“Jika Anda hanya mengambil dan membaca buku Anda dengan serius, apakah Anda akan mulai membuat keputusan yang“ benar ”? Atau ada banyak hal di luar ruang lingkup buku yang juga memengaruhi?

- Pembandingan adalah topik yang, menurut pendapat saya, hanya dapat dikuasai dalam praktik. Ya, dalam buku ini saya memberikan banyak metodologi, rekomendasi, menggambarkan perangkap. Dalam pembandingan, ada banyak masalah sehingga jika Anda tidak mengetahuinya, maka dalam hidup Anda tidak akan pernah menebaknya. Tetapi jika Anda tahu tentang mereka, ini sama sekali tidak memberikan jaminan bahwa tolok ukur Anda akan benar. Artinya, ini adalah toolkit minimal yang membantu untuk mengarahkan orientasi seseorang di lapangan.

Anda dapat menulis tolok ukur normal dan tes kinerja hanya jika Anda secara sistematis menangani area ini. Grid saraf pada head train untuk membaca laporan kinerja - ketika Anda melihat distribusi yang diperoleh selama pengukuran kinerja, Anda melihat tabel ringkasan, misalnya, dari BenchmarkDotNet (dan tidak hanya kolom "Rata-rata", tetapi juga standar deviasi ), Anda melihat kesalahan standar, karakteristik tambahan, minimum, maksimum, pada kuantil, pada persentil ke-99.

Ketika Anda melihat semua ini sangat, sangat, sangat banyak, volume minimum tertentu diakumulasikan, memungkinkan Anda untuk melakukan investasi kinerja jauh lebih cepat dan melihat apa yang orang tanpa pengalaman (bahkan jika mereka membaca buku saya dan jutaan posting blog) tidak akan melihat karena fakta bahwa mereka tidak memiliki pengalaman. Mereka tidak akan melihat masalah atau tidak akan dapat menginterpretasikan data secara instan dan tepat.

- Tentang DotNext ini dalam sebuah wawancara dengan Dmitry Nesteruk (mezastel) kami mengatakan bahwa biasanya buku IT dengan cepat menjadi usang, tetapi jika ia menulis tentang pola desain, maka semuanya tidak berubah di sana setiap tahun. Dan bagaimana dengan pembandingan: buku ini mungkin juga sudah ketinggalan zaman untuk waktu yang sangat lama, atau apakah Anda telah menulis sesuatu yang lain dua tahun yang lalu?

- Sangat sulit untuk memberikan jawaban bersuku kata satu. Ada beberapa dasar, beberapa materi yang tidak menjadi usang. Statistik yang sama: karena persentil ke-99 dianggap dua tahun yang lalu, itu masih dianggap demikian, dan ada kecurigaan bahwa tidak ada yang akan berubah dalam dua tahun.

Ngomong-ngomong, pada saat yang sama saya perhatikan: Saya percaya bahwa tolok ukur harus menjadi disiplin yang terpisah. Untuk beberapa alasan, secara historis, tidak ada yang memperhatikan pengukuran sistematis. Apa yang ada di sana? Dia mengambilnya, memulai timer, mematikan timer, melihat berapa banyak yang telah berlalu. Dan dalam buku itu, menurut perkiraan awal, ternyata lebih dari 600 halaman, dan semua orang bertanya kepada saya, "Apa yang bisa ditulis di 600 halaman?"

Dan saya percaya bahwa ini harus menjadi disiplin ilmu, bidang ilmu komputer yang terpisah. Dan ini adalah arah "bahasa-agnostik", di mana peralatan umum tetap benar dan tidak berubah: inilah yang telah dicapai umat manusia secara keseluruhan. Ini berlaku untuk setiap runtime, bahasa, ekosistem. Tetapi ini hanya satu bagian dari jawabannya.

Dan bagian lainnya sudah terikat dengan fitur runtime, ke fitur .NET. Saat ini (kami memiliki banyak tentang hal ini dalam buku ini), kami memiliki .NET Framework, ada .NET Core, dan ada Mono. Pengukuran kinerja dapat bervariasi pada runtime yang berbeda atau bahkan pada dua versi yang berdekatan dari runtime yang sama. Jika Anda menggunakan .NET Core 2.2 dan .NET Core 3.0 yang akan datang, beberapa beban kerja berbeda seperti siang dan malam. Mereka membuat optimasi yang keren sehingga skenario paling sederhana dipercepat 10 kali, 50 kali.

Jelas bahwa jika Anda beralih ke Core versi baru, seluruh program tidak akan mulai bekerja 50 kali lebih cepat, tetapi setiap potongan kecil, yang paling sering jatuh ke dalam tolok ukur sintetis, mungkin di-overclock.

Dan apa yang berubah, perubahan terutama dalam kaitannya dengan semua versi ini, optimasi baru muncul. Misalnya, jitting berjenjang akan muncul di .NET Core 3.0 . Yaitu, runtime pertama dapat dengan cepat menghasilkan satu implementasi asli sederhana (dan tidak terlalu efektif) untuk metode dengan kode. Dan kemudian, ketika pemberitahuan runtime yang Anda panggil metode ini berkali-kali, itu akan menghabiskan sedikit lebih banyak waktu di latar belakang dan membuat kembali kode yang lebih produktif. Ini kira-kira fakta bahwa di Jawa di HotSpot sudah ada bertahun-tahun, di dunia .NET akan muncul dalam rilis yang disertakan secara default tahun ini di paruh kedua tahun ini (catatan editor: kami mengingatkan Anda, wawancara dilakukan pada 2019) .

Dan untuk BenchmarkDotNet, merupakan tantangan untuk menangani kasus seperti itu secara normal. Di dunia Jawa, Alexey Shipilev dalam JMH- nyaSaya belajar cara menanganinya sejak lama, tetapi kita masih harus melakukannya. Mengenai hal ini juga, saya berkomunikasi dengan orang-orang yang melihat runtime. Artinya, saya akan membutuhkan pena khusus, API dari mereka untuk menangani semuanya dengan benar.

Hal-hal ini berubah. Segera kita akan memiliki semua runtime bersatu, akan ada satu. NET 5. Saya berasumsi bahwa itu akan diubah namanya entah bagaimana berbeda, bahwa ini adalah nama perantara. Mungkin tidak akan menjadi 5, tetapi 6, karena kami sudah memiliki versi .NET Core 5.0.

- Ya, seperti yang kita tahu dari Windows, bukan masalah bagi Microsoft untuk melewati angka dalam versi.

- Iya. Sudah pada saat DNXada kerangka kerja target dengan .NET Core kelima, sekarang "5.0" telah banyak digunakan di mana, ada banyak posting lama. Jadi saya tidak tahu, mereka sekarang akan membuat yang kelima setelah versi ketiga, tetapi saya akan melewatkan tidak hanya empat, tetapi lima juga, dan akan membuat yang keenam segera. Dan dengan mempertimbangkan fakta bahwa mereka sekarang ingin membuat, menurut pendapat saya, versi aneh stabil LTS, dan bahkan yang tidak sangat stabil, akan mungkin untuk segera tujuh.

Nah, ini sakit kepala mereka. Tetapi penting bahwa Anda perlu memantau perkembangan runtimes, dan inilah bagian .NET-spesifik yang menjadi usang - tidak secepat itu usang, tetapi secara diam-diam.

Saya sudah berpikir untuk membuat edisi kedua buku di mana semua ini diperbarui. Prosesor Intel juga tidak diam, mereka berkembang, muncul optimisasi baru, yang juga perlu ditangani dengan cara yang licik. Skylake menyajikan banyak kejutan yang tidak menyenangkan, di BenchmarkDotNet yang sama banyak pekerjaan yang dilakukan untuk menyiasati optimasi yang rumit dan mendapatkan hasil yang stabil.

Interaksi dengan BenchmarkDotNet dan Rider

- Jelas bahwa bekerja di perpustakaan BenchmarkDotNet telah memberi Anda banyak pengalaman, jadi masuk akal jika Anda menulis buku tentang topik pembandingan. Dan di sini muncul pertanyaan: apakah buku itu terkait dengan BenchmarkDotNet, atau apakah itu "alat-agnostik"?

- Saya mencoba membuat alat-agnostiknya. Tentang BenchmarkDotNet, saya memiliki satu bagian kecil, dan saya juga menggunakannya sebagai contoh dalam studi kasus saya: ketika saya perlu menunjukkan beberapa efek mikroarsitektur kecil, saya mengatakan "di sini kita akan menulis patokan menggunakan BenchmarkDotNet". Agar tidak memasukkan sejuta strapping di setiap tolok ukur dalam buku, tidak ada tempat untuk menulis secara terpisah logika pemanasan. Kami sudah memiliki solusi siap pakai yang melakukan seluruh patokan rutin untuk kami, dan kami tidak akan membicarakan metodologi lagi (kami membicarakannya di awal), tetapi membicarakan tentang efek pada level CPU.

Berikut adalah dua kasus penggunaan, dan saya mencoba melakukan sisanya sebagai abstrak dari BenchmarkDotNet. Bahwa buku itu bermanfaat tidak hanya untuk pengembang .NET, tetapi juga, misalnya, untuk pengembang Java. Karena semua mekanisme umum dengan mudah dipindahkan ke platform lain, yaitu .NET dan BenchmarkDotNet digunakan sebagai alat untuk menggambarkan konsep tersebut.

- Dan ke arah lain pengaruhnya? Apa, dalam proses mengerjakan buku itu, apakah Anda akhirnya mengerti apa yang perlu Anda lakukan di BenchmarkDotNet seperti ini?

- Ya, saya menulis segala macam keripik kecil terutama untuk mereka agar ada di buku. Misalnya, deteksi dingin distribusi multimoda, yang sudah saya bicarakan.

Dalam cara yang baik, ketika Anda menganalisis hasil benchmark, Anda harus selalu melihat distribusinya, buka gambarnya, pelajari apa yang terjadi di sana. Namun dalam praktiknya, tidak ada yang melakukannya. Karena jika saya menjalankan, dengan syarat, 50 benchmark pada beberapa jenis basis kode, dan saya mengubah basis kode ini 10 kali sehari, dan setiap kali saya me-restart set lengkap, maka bahkan saya pasti tidak akan menonton 50 grafik, saya harus melakukannya malas Dan ini, pada umumnya, tidak masuk akal, ini bukan tugas manusia, ini adalah tugas penyetelan.

BenchmarkDotNet memiliki algoritma keren yang secara otomatis menentukan bahwa distribusinya multimodal dan memperingatkan pengguna: “Bung! Lihat grafiknya! Semuanya buruk di sini! Di sinilah nilai rata-rata muncul di kolom, jangan melihatnya! Itu tidak sesuai dengan apa pun, lihat bagan! "

Dan ini dicetak hanya dalam kasus-kasus ketika benar-benar penting untuk tidak mengalihkan perhatian seseorang dalam grafik dengan sia-sia. Di sana, sebuah pendekatan yang didasarkan pada apa yang disebut nilai-nilai m dari Brendan Gregg, adalah seorang insinyur kinerja terkemuka di Netflix.

Tetapi pendekatannya tidak cukup bagi saya karena dia menggunakan histogram yang dibangun secara khusus berdasarkan distribusi. Artinya, histogram dimasukkan ke input, n nilai dianggap dan secara ajaib ditentukan oleh itu, kami memiliki distribusi multimodal atau tidak. Dan bagaimana cara membangun histogram, Brendan Gregg tidak menulis! Saya harus menciptakan semacam sepeda sendiri, yang ternyata bekerja dengan baik. Algoritma ini dirangkum dalam sebuah buku.

Ada beberapa kisah semacam itu. Langsung menulis buku butuh dua setengah tahun. Secara umum, saya telah mengumpulkan konten selama lima tahun, dan dua setengah tahun sejak saya menandatangani perjanjian dengan penerbit. Selama dua setengah tahun ini, berkat buku itu, perpustakaan telah dipompa dalam banyak hal, banyak hal telah muncul di sana.

- Sulit untuk dibayangkan, tetapi selain buku dan BenchmarkDotNet, dalam hidup Anda juga ada pekerjaan pada Rider - dan di sana Anda mungkin juga akan melakukan benchmark. Bisakah Anda membicarakan ini? Anda punya di Twitter foto-foto macbook di freezer dan di sebelah pemanas , memeriksa bagaimana hal itu mempengaruhi kinerja - apakah itu untuk bekerja, atau untuk sebuah buku, atau keduanya sekaligus?

- Sebaliknya, semuanya. Di pengendaraKami menggunakan BenchmarkDotNet untuk investasi kinerja individual. Yaitu, ketika Anda perlu mencari cara terbaik untuk menulis kode dalam beberapa bagian kinerja kritis, atau Anda perlu mempelajari bagaimana kami berbeda dalam perilaku sepotong kode di bawah Mono di Linux dan di bawah .NET Framework pada Windows. Kami mengambil BenchmarkDotNet, mendesain percobaan, mengumpulkan hasil, menarik kesimpulan, membuat keputusan bisnis, cara menulis kode sehingga bekerja dengan cepat di mana-mana. Dan kemudian tolok ukur ini dibuang.

Artinya, kami tidak memiliki tolok ukur dasar sistematis di BenchmarkDotNet yang akan berjalan pada CI. Tetapi sebaliknya, kami memiliki banyak bidang kinerja lainnya. Misalnya, alat internal yang mengumpulkan angka dari semua tes dan mencari anomali kinerja yang berbeda di dalamnya, distribusi multimoda yang sama, tes dengan beberapa standar deviasi besar, dan mengumpulkan semuanya menjadi satu dasbor.

Pendekatan lain yang telah kami kerjakan untuk waktu yang sangat lama tetapi belum dilakukan adalah tes kinerja yang andal. Artinya, kami ingin membuat pendekatan di mana tidak mungkin untuk membekukan penurunan kinerja di cabang utama.

Dan tolok ukur klasik tidak terlalu cocok, karena sangat intensif sumber daya. Hal ini diperlukan untuk melakukan banyak iterasi untuk mendapatkan statistik normal dan entah bagaimana bekerja dengannya. Dan ketika Anda memiliki ratusan atau ribuan tes kinerja, jika Anda menjalankan setiap tes 30 kali, seperti yang diharapkan, dan ini untuk setiap makan siang setiap orang - tidak ada zat besi yang cukup.

Oleh karena itu, di satu sisi, saya ingin melakukan sesedikit mungkin iterasi (idealnya satu, tetapi satu per satu sangat sulit untuk mengatakan apakah Anda mengalami degradasi). Hal terburuk yang dapat terjadi adalah false positive, ketika Anda tidak melakukan kesalahan, tetapi sistem berbicara tentang penurunan kinerja dan tidak memungkinkan Anda untuk membekukan brunch in master. Jika ini terjadi, mereka akan melempari saya dengan batu, dan tidak ada yang akan menggunakan sistem ini.

Oleh karena itu, secara kondisional, jika setelah satu iterasi ada kecurigaan perfdegradasi, tetapi tidak ada kepercayaan 100%, perlu dilakukan iterasi kedua. Setelah yang kedua, Anda dapat memutuskan bahwa semuanya baik-baik saja dengan kami, hanya kebetulan bahwa sesuatu terjadi. Anda dapat mengatakan bahwa sekarang kami yakin akan penurunan kinerja dan melarang pawai. Dan Anda dapat mengatakan: "Tidak, dua iterasi masih tidak cukup, kita harus pergi ke yang ketiga." Baik dan sebagainya.

Dan pada sejumlah kecil iterasi (satu, dua, tiga), tes standar tidak berfungsi sama sekali. Ini tes Mann-Whitney favorit saya.mulai bekerja dengan baik ketika Anda memiliki setidaknya lima iterasi. Tapi kita mencapai yang kelima hanya ketika semuanya benar-benar buruk. Oleh karena itu, perlu dikembangkan seperangkat heuristik yang tidak akan pernah memberikan false positive, tetapi pada saat yang sama ia akan mendeteksi degradasi ketika mereka ada, dengan jumlah iterasi minimum yang mungkin. Dan sekarang ini adalah tugas yang agak sulit untuk campuran teknik programmer dan formula matematika. Kami belum selesai, tetapi kami akan melakukan ini.

Dan tentang macbook di lemari es - ini juga semua untuk bekerja. Sekarang salah satu proyek mini yang saya lakukan cukup banyak adalah studi tentang model pelambatan termal. Situasinya adalah sebagai berikut: ketika benchmark terikat CPU memuat perangkat keras sangat, suhu CPU naik, dan ketika mencapai nilai ambang tertentu, prosesor Intel atau sistem operasi mengatakan: "Ay-yy-yy! Kami terlalu panas! " - dan untuk beberapa periode mengurangi frekuensi. Dan kemudian, misalnya, 2-3 iterasi diperoleh, di mana penurunan kinerja seharusnya terlihat. Dan kita seperti: “Oh, oh, oh, oh! Semuanya buruk! Kami tidak akan menahan brunch ini. " Namun faktanya, kami hanya memiliki agen kinerja yang terlalu panas.

Ada berbagai cara untuk mengatasi ini. Kami memiliki ruang server sendiri dengan dudukan kami sendiri, kami berusaha menyediakan pendinginan yang cukup di sana sehingga pelambatan termal ini tidak terjadi. Tetapi ini juga tidak selalu berhasil. Artinya, kita tidak bisa sepenuhnya membekukan agen, mereka tidak akan banyak dari ini, tapi entah bagaimana kita perlu berjuang.

Pilihan lain adalah, misalnya, mematikan turbo boost sehingga prosesor tidak pernah melampaui frekuensi dasar. Ini, karenanya, mengurangi kemungkinan overheating, prosesor sudah tidak begitu panas. Dan kedua, kami mendapatkan frekuensi yang lebih stabil (dalam turbo boost sering bergetar cukup banyak, dan dengan boost turbo off pada frekuensi dasar, ia berjalan sangat lurus dan Anda mendapatkan hasil yang jauh lebih stabil).

Dan model pelambatan termal sangat berbeda: pertama, banyak tergantung pada prosesor dan pada konfigurasi semua setrika, dan kedua, pada sistem operasi. Misalnya, ambil Mac: kami memiliki banyak tes Mac, karena ada banyak pengguna dan mereka tidak ingin Rider melambat. Dan ada model pelambatan termal yang sangat agresif.

Pada prosesor Intel baru yang baru-baru ini diumumkan, ada lelucon yang lebih kompleks. Jika suhu Anda turun di bawah nilai ambang tertentu, seperti 50 derajat, maka frekuensinya bisa melonjak bahkan lebih tinggi dari frekuensi maksimum pada dorongan turbo biasa. Artinya, mereka melakukan sesuatu seperti overclocking dinamis "sedikit" pada suhu rendah. Efek yang sama. Agen kami masih merupakan pemroses lama bersyarat, belum ditingkatkan, tetapi Geeks yang suka membeli sendiri semua terbaru dapat menginjak ini.

Masa depan

"Aku harus memotongmu, karena waktu hampir habis." Tetapi bagi mereka yang tertarik: apakah Anda akan menulis posting blog tentang materi ini?

- Ya, saat saya mengumpulkan materi, semuanya sangat menarik di sana, model pelambatan termal yang sangat kompleks. Misalnya, ada Throttling Daya di Windows, yang memungkinkan Anda menghemat daya baterai dan banyak lagi. Sementara saya mengumpulkan data, dan kemudian saya akan menggabungkan semuanya baik dalam posting blog, atau bahkan dalam artikel ilmiah, atau itu akan jatuh ke dalam edisi kedua buku.

, . — , , .

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

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