AMD Memutuskan Menonaktifkan Loop Buffer Zen 4

 (chipsandcheese.com)
1 poin oleh GN⁺ 2024-12-02 | 1 komentar | Bagikan ke WhatsApp
  • Pada BIOS baru ASRock B650 PG Lightning, loop buffer Zen 4 tidak lagi teramati sebagai sumber micro-op, dan saat dikembalikan ke BIOS lama, fitur ini aktif kembali
  • Struktur ini tampaknya merupakan fitur untuk mengurangi daya dengan memproses loop kecil berulang kali di frontend; kapasitasnya diperkirakan 144 entri untuk single thread, dan 72 entri per thread pada SMT 2 thread
  • Di SPEC CPU2017, selisih skor total antara loop buffer aktif/nonaktif kurang dari 1%, sehingga dampak pada performa umum tampaknya sangat kecil
  • Saat loop buffer dimatikan, Zen 4 memasok lebih banyak micro-op dari op cache, dan karena bandwidth op cache cukup besar dibanding throughput backend, hal ini sulit menjadi bottleneck frontend
  • Alasan penonaktifan dan dampak daya sebenarnya masih belum pasti, tetapi karena ini adalah fitur terbatas yang hampir tidak didokumentasikan atau dipromosikan AMD, sebagian besar pengguna dan developer kemungkinan sulit merasakan perubahannya

Peran dan batasan loop buffer Zen 4

  • Loop buffer adalah struktur di frontend CPU yang menyimpan sejumlah kecil instruksi yang sudah diambil, sehingga sebagian tahap frontend bisa dimatikan saat menjalankan loop kecil berulang kali
    • Dapat membantu menghemat daya
    • Juga berpotensi meningkatkan performa dengan melewati batasan frontend bagian depan
    • Ini adalah teknik yang sudah lama digunakan pada core Intel, Arm, dan AMD
  • Zen 4 dipahami sebagai satu-satunya contoh core AMD berperforma tinggi yang memiliki loop buffer
  • Processor Programming Reference untuk Zen 4 menyebut loop buffer sebagai sumber dispatch micro-op bersama op cache dan decoder
  • Berdasarkan eksperimen performance counter, kapasitasnya diperkirakan sebagai berikut
    • 144 entri saat eksekusi single thread
    • Dipartisi statis menjadi 72 entri per thread saat SMT 2 thread aktif
  • Jika ada CALL/RET di dalam loop, loop buffer Zen 4 tidak dapat menangkap loop tersebut
  • Panduan optimasi Zen 4 dari AMD tidak membahas loop buffer, dan hanya memberi saran untuk menjaga hot code region tetap berada dalam kapasitas op cache

Loop buffer yang menghilang setelah update BIOS

  • Setelah ASRock B650 PG Lightning diperbarui ke BIOS 3.10, pemantauan performa hardware menunjukkan bahwa loop buffer tidak melakukan dispatch micro-op
  • Jika dikembalikan ke BIOS 1.21, loop buffer aktif kembali
  • Penonaktifan tampaknya terjadi antara AGESA 1.0.0.6 pada BIOS 1.21 dan AGESA 1.2.0.2a pada BIOS 3.10
  • AMD menerapkan perubahan ini tanpa pengumuman atau promosi terpisah
  • Berdasarkan diskusi tambahan dengan karyawan AMD di Hot Chips 2024, loop buffer adalah fitur yang terutama ditujukan untuk optimasi daya

Perbedaan performa kecil yang terlihat di SPEC CPU2017

  • Skor total suite integer dan floating-point SPEC CPU2017 hanya berbeda kurang dari 1% antara loop buffer aktif/nonaktif
  • Peningkatan performa SMT juga tidak terdampak oleh penonaktifan loop buffer
  • Dampak performa yang kecil disebabkan op cache Zen 4 sudah menyediakan bandwidth lebih besar daripada yang dapat dikonsumsi tahap rename/allocate di backend
  • Bahkan saat loop buffer aktif, performance counter menunjukkan hanya sebagian kecil micro-op yang dipasok dari loop buffer
  • Pada benchmark individual pun tidak ditemukan penurunan besar
    • 523.xalanbmk memiliki porsi kecil namun bermakna dari instruction stream yang ditangani loop buffer, tetapi skornya 9,48 pada BIOS baru dan 9,44 pada BIOS lama, masih dalam rentang galat
    • 544.nab menerima hampir seperempat micro-op dari loop buffer, tetapi pada BIOS baru dengan loop buffer dimatikan, skornya naik 1,7% menjadi 11,7 dari sebelumnya 11,5
    • Kenaikan ini bisa jadi merupakan run-to-run variance
  • Pada performance counter BIOS baru, op cache mengambil alih porsi loop buffer dan memproses bagian instruction stream yang lebih besar
  • Pada 507.cactuBSSN, terlihat pola op cache coverage sedikit menurun dan decoder memasok sekitar seperempat dari total micro-op
    • Performance counter adalah alat untuk menunjukkan tren umum, bukan pengukuran yang 100% akurat
    • Dispatch frontend adalah event spekulatif, sehingga dapat dipengaruhi instruksi yang salah diambil setelah branch yang salah diprediksi

Potensi penghematan daya dan aktivitas frontend

  • Tujuan utama loop buffer bukan meningkatkan performa, melainkan secara oportunistis mematikan sebagian besar frontend, termasuk op cache
  • Fitur pemantauan performa Zen 4 memiliki count mask yang dapat menghitung siklus saat jumlah event melewati ambang tertentu
    • Jika ambang diatur ke 1, jumlah siklus ketika setiap sumber micro-op benar-benar memasok micro-op dapat diperkirakan
    • Dengan ini, dapat diperkirakan seberapa sering frontend bisa dimatikan saat loop buffer aktif
  • Di SPEC CPU2017, frekuensi aktif masing-masing sumber secara umum sesuai dengan rasio micro-op yang dikirimkan sumber tersebut
  • Pada sebagian workload, ada juga cukup banyak siklus ketika frontend tidak memasok apa pun
    • 502.gcc dan 520.omnetpp sangat dibatasi backend memory latency
    • Jika out-of-order execution engine tidak dapat mempertahankan cukup banyak instruksi dalam keadaan in-flight untuk menyembunyikan latency, frontend tidak dapat mengirim lebih banyak ke backend dan menjadi idle
  • Pada suite floating-point, 544.nab dan 508.namd menggunakan loop buffer selama cukup banyak core cycle
    • 508.namd adalah workload high IPC dengan rata-rata 3,64 IPC, sehingga kebutuhan throughput frontend besar
    • Karena ramah terhadap loop buffer, ada peluang mematikan op cache dan menghemat daya
  • Saat loop buffer dimatikan, op cache memasok core selama lebih banyak cycle
    • Pada 523.xalanbmk, tanpa loop buffer, op cache harus aktif selama tambahan 12% dari core cycle
    • 548.exchange2 adalah workload high IPC dengan rata-rata 4,31 IPC, tetapi hampir tidak memakai loop buffer meski fitur itu aktif, dan op cache aktif lebih dari 85% core cycle
    • Pada 508.namd, rasio aktif op cache meningkat dari 56,67% saat loop buffer aktif menjadi 75,1% saat nonaktif
  • Loop buffer 144 entri terlalu kecil untuk menampung banyak bagian instruction stream
    • Efek yang jelas kemungkinan hanya muncul ketika program menghabiskan porsi waktu eksekusi yang besar di loop kecil, dan tidak dibatasi throughput atau latency backend

Pengamatan di Cyberpunk 2077

  • Dampak penonaktifan loop buffer terhadap performa game diperiksa menggunakan benchmark bawaan Cyberpunk 2077
  • Untuk meningkatkan konsistensi, Core Performance Boost dinonaktifkan pada Ryzen 9 7950X3D dan semua core dibatasi ke 4,2GHz
    • Bit 25 pada Hardware Configuration register MSR 0xC0010015 diatur
    • RX 6900 XT dibatasi ke 2GHz
    • Pengaturan benchmark adalah 1080p, preset medium, tanpa upscaling
  • Saat game dipasang pada VCache die, penonaktifan loop buffer hampir tidak berdampak pada performa
  • Saat dipasang pada non-VCache die, penurunan performa 5% teramati ketika loop buffer dinonaktifkan, tetapi penyebabnya belum dikonfirmasi
    • Benchmark dijalankan ulang sekitar enam kali
  • Cyberpunk 2077 rata-rata menggunakan loop buffer untuk sekitar 22% dari instruction stream, lebih ramah terhadap loop buffer daripada perkiraan
    • Setelah loop buffer dinonaktifkan, rasio pasokan micro-op dari op cache meningkat dari 62% menjadi 82%
  • Game ini bukan workload high IPC, dengan rata-rata 0,89 IPC saat loop buffer nonaktif dan 1,02 IPC saat aktif
    • Bandwidth frontend bukan pertimbangan besar
    • Kemungkinan terikat backend atau branch predictor delay
  • Saat dijalankan pada VCache die, performance counter menunjukkan rata-rata 1,25 IPC saat loop buffer aktif dan 1,07 IPC saat nonaktif
    • Penurunan performa kecil juga teramati pada BIOS baru
    • Pada level sekitar 155 FPS, kemungkinan sudah lebih dekat ke bottleneck sisi GPU

Ketidakpastian hasil core power counter

  • Untuk memastikan apakah eksekusi melalui loop buffer meningkatkan efisiensi daya, core power counter Zen 4 juga diperiksa
  • Benchmark instruction bandwidth dimodifikasi agar tidak menggunakan CALL/RET di bagian pengujian
    • Karena jika ada CALL/RET, Zen 4 tidak menggunakan loop buffer
  • Pengujian dipasang pada satu core, lalu Core Energy Status MSR sebelum dan sesudah melompat ke array pengujian dibaca untuk menghitung daya rata-rata
  • Core Performance Boost dinonaktifkan karena pembacaan daya sangat berfluktuasi
  • Pada BIOS lama, Core Energy Status MSR menunjukkan rata-rata 6W saat mengambil NOP dari op cache, dan daya jauh lebih rendah saat mengambilnya dari loop buffer
  • Bahkan ketika ukuran array pengujian diperbesar hingga 128KB yang masuk kapasitas L2 untuk menurunkan op cache coverage di bawah 1%, average core power tetap ditampilkan 1,5W
    • Ini tidak sesuai dengan kondisi yang seharusnya meningkatkan penggunaan decoder dan L2 fetch path
  • Pada BIOS baru, pengujian op cache menunjukkan rata-rata 1,68W, dan pengujian yang terutama memasok decoder dari L2 juga menunjukkan daya yang hampir sama
  • Fitur pemantauan daya AMD bisa jadi merupakan pemodelan daya, bukan pengukuran nyata
    • Ada kemungkinan metode pemodelan berubah antarversi BIOS, atau model dayanya tidak akurat
    • Karena tidak ada hardware untuk mengukur langsung dari konektor 12V EPS dan sejenisnya, verifikasi tambahan tidak dilakukan

Alasan penonaktifan dan sudut pandang developer

  • Alasan AMD menonaktifkan loop buffer Zen 4 tidak diketahui
  • Fitur CPU terkadang dinonaktifkan karena bug hardware
    • LSD, loop buffer Intel Skylake, pernah dinonaktifkan karena bug terkait partial register access pada loop pendek ketika dua thread SMT aktif
  • Zen 4 adalah upaya pertama AMD memasukkan loop buffer ke CPU berperforma tinggi, dan validasi fitur pada implementasi pertama memang sulit
  • Ada kemungkinan AMD menemukan bug internal yang tidak terlihat dari luar dan mematikan loop buffer sebagai langkah pencegahan
  • Dampak performanya tampaknya hampir tidak ada atau sangat kecil karena bandwidth op cache sudah cukup
  • Dampak dayanya tidak diketahui, tetapi bisa saja kecil dan sulit diukur
  • AMD hampir tidak mendokumentasikan atau mengiklankan loop buffer selain satu baris di Processor Programming Reference
    • Ini kontras dengan cara Intel sering mendokumentasikan loop buffer miliknya dan merekomendasikan developer memanfaatkannya lewat panduan optimasi
  • Loop buffer Zen 4 adalah fitur terbatas yang tidak semanfaat op cache karena kapasitasnya rendah dan adanya batasan CALL/RET
  • Jika ingin mengoptimalkan dengan mempertimbangkan loop buffer Zen 4 pada BIOS lama, kondisi berikut dapat dipertimbangkan
    • Menjaga loop di bawah 144 micro-ops
    • Jika dua thread berbagi satu core fisik, pertimbangkan sekitar separuh kapasitas tersebut
    • Untuk fungsi yang dipanggil di dalam loop kecil, pertimbangkan inline agar menghindari CALL/RET
  • Meski optimasi seperti ini dilakukan, kemungkinan besar imbalannya hampir tidak ada

Bacaan terkait

1 komentar

 
GN⁺ 2024-12-02
Pendapat Hacker News

  • Muncul dugaan apakah fitur ini dinonaktifkan sebagai upaya mencegah kerentanan perangkat keras yang belum diungkap

    • Artikel itu juga kurang lebih berspekulasi ke arah yang sama: Zen 4 adalah upaya pertama AMD memasukkan loop buffer ke CPU berperforma tinggi, dan memverifikasi implementasi pertama selalu sulit
      Tidak berlebihan membayangkan AMD menemukan bug yang tidak pernah ditemui siapa pun di internal, lalu mematikan loop buffer sebagai langkah ekstra hati-hati. Sulit membayangkan alasan lain AMD menyentuh frontend Zen 4 pada tahap siklus hidup core seperti sekarang
    • Bisa jadi yang dinonaktifkan sebenarnya lebih banyak. Angkanya cukup mengejutkan: di Cyberpunk 2077 saat berjalan pada die VCache, performance counter menunjukkan rata-rata IPC 1.25 saat loop buffer aktif dan 1.07 saat dimatikan, tetapi BIOS baru tetap menunjukkan sedikit penurunan performa
      Secara pribadi ini terasa seperti mitigasi mikrokode, tapi tentu saja kita harus menunggu CVE
    • Menonaktifkannya diam-diam juga merupakan risiko besar. Karena itu menandakan mereka tahu tingkat keparahan masalahnya dan menilai masalah itu cukup serius untuk ditambal
      Jika kerentanannya tidak diungkap, pihak yang terdampak tidak punya cara memulai respons selain paranoia murni. Pengungkapan kerentanan juga merupakan cara mengalihkan tanggung jawab ke pengguna akhir. Semacam, kalau Anda tidak memperbarui maka jangan mengeluh. Jarang sekali pengungkapan berujung pada tanggung jawab produk, dan saya juga tidak ingat ada isu tanggung jawab seperti itu pada Meltdown atau Spectre. Jadi saya tidak akan langsung menyimpulkan AMD sengaja menyembunyikannya
    • Sepertinya itu jawaban yang benar, tapi saya tidak bisa bilang lebih banyak :(

  • Artikel ini terkesan menyiratkan bahwa loop buffer tidak memberi keuntungan performa maupun daya
    Kalau begitu, mungkin ini kasus klasik “tim engineering menghabiskan berbulan-bulan membuat fitur baru yang keren, tapi ternyata tidak memberi manfaat nyata, lalu tetap dirilis demi menjaga muka seseorang”. Di tim software pun saya pernah melihat upaya menulis ulang codebase dengan alasan menghapus beban legacy dan meningkatkan performa, tetapi setelah selesai jumlah baris kode malah bertambah dan performanya memburuk. Dalam kedua kasus itu, seharusnya tidak dirilis

    • Alasan tetap dirilis kemungkinan karena bisa dimatikan lewat pembaruan firmware, dan perubahan besar pada tata letak fisik perangkat keras di tengah desain kemungkinan akan menimbulkan dampak yang lebih buruk
    • Jika setelah sudah masuk ke core baru disadari bahwa fitur itu tidak banyak membantu, menghapusnya sendiri jelas berisiko
    • Artikel itu juga mengatakan konsumsi daya sulit diukur secara menyeluruh, jadi tidak bisa disimpulkan fitur ini sama sekali tidak berdampak, dan memang seharusnya tidak demikian
      Sulit membayangkan tim engineering AMD begitu tanpa prinsip sampai membiarkan area dan daya dipakai untuk fitur perangkat keras yang sama sekali tidak bernilai, jadi saya cenderung menganggap kemungkinan Chips 'n Cheese tidak berhasil mengukur dampaknya lebih besar
    • Saya bekerja di perusahaan perangkat keras yang cukup terkenal, dan di sisi software ada obsesi untuk melakukan sesuatu, bahkan jika manfaatnya belum benar-benar terbukti kecuali pada beberapa kasus penggunaan sempit atau benchmark yang ditargetkan
      Sangat menjengkelkan, tapi tidak ada yang mau meluangkan waktu untuk riset pendahuluan. Mendorong proyek baru lebih mudah menyenangkan atasan dan memicu lebih sedikit pertanyaan
    • Ada kemungkinan lain bahwa benchmark daya itu memang akurat. Buffer itu mungkin dulu menghemat daya, tetapi kemudian pada level mikrokode ditemukan optimasi yang lebih baik sehingga jalur umum justru menjadi lebih hemat daya, dan buffer malah berubah menjadi perangkat yang boros daya

  • Bagian paling menarik dari artikel ini adalah paragraf berikut: cara terbaik melihat loop buffer Zen 4 adalah sebagai tanda bahwa AMD punya kapasitas cadangan bagi para engineer untuk mencoba sesuatu
    Mungkin kali ini tidak membuahkan hasil, tetapi membiarkan engineer bereksperimen dengan fitur berisiko rendah dan berdampak rendah adalah cara yang baik untuk membangun kepercayaan diri. Saya berharap kita akan melihat lebih banyak kepercayaan diri seperti itu ke depannya

  • Bagian “Anehnya, jika dipatok ke die non-VCache, menonaktifkan loop buffer menurunkan performa game 5%. Saya tidak tahu alasannya” membuat saya berpikir, kalau ada pengukuran daya yang lebih rinci, mungkin bisa dinilai apakah ini terkait anggaran termal/daya
    Fitur ini juga terlihat seperti dirancang untuk menghemat daya

    • Di sini detailnya tidak cukup. CCD kedua pada chip Ryzen memang kualitas binning-nya lebih rendah daripada yang pertama, bahkan pada chip non-X3D, dan setiap chip berbeda-beda
      Pada chip non-X3D saya, sebagian besar core di CCD0 bisa mencapai 5.6~5.75GHz, tetapi core di CCD1 berhenti di 5.4~5.5GHz. Chip V-Cache Zen 4 memang punya penalti clock yang besar, tetapi cache menutupinya lebih dari cukup. Kita perlu melihat apakah mereka menguji kondisi fitur aktif dan nonaktif pada CCD1 di chip yang sama, serta apakah mereka mencoba memisahkan perubahan lain seperti perbaikan keamanan, dan artikel itu sendiri mengakui “tidak”. Untuk melakukannya dengan benar, mereka harus menemukan cara mematikan hanya fitur ini pada BIOS yang fitur tersebut aktif, lalu menguji kedua kondisi pada chip yang sama, dan bahkan begitu hasilnya masih bisa tidak akurat karena kondisi percabangan lain. Profil performa penuh akan meningkatkan akurasi, tetapi mungkin hanya engineer AMD yang bisa melakukannya
    • Dikatakan bahwa fitur ini dinonaktifkan di suatu titik di antara dua versi UEFI yang diuji. Karena pasti ada perubahan lain juga, pengukuran ini bukan uji A/B yang ketat

  • Tampaknya dampaknya terlalu kecil untuk menghasilkan perbedaan nyata, dan hanya bermakna dalam situasi yang sangat spesifik. Kalau diperbesar, biaya implementasinya mungkin terlalu tinggi dibanding manfaatnya
    Meski begitu, akan ada sedikit regresi pada sebagian workload, tetapi AMD juga sudah membuat peningkatan performa kecil setelah peluncuran. Di Zen 4, ini seharusnya dijadikan opsi BIOS. Fakta bahwa tampaknya tidak demikian mengisyaratkan kemungkinan adanya bug atau masalah keamanan

    • Bahwa mereka diam-diam menonaktifkan fitur yang memperumit frontend tetapi sebagian besar pengguna tidak akan menyadarinya, terasa seperti mereka menarik chicken bit ini untuk menghindari atau menunda pengungkapan bug perangkat keras sambil tetap lebih dulu mendistribusikan mitigasinya. Vendor sialan, kapan mereka akan belajar

  • Secara anekdotal, salah satu dari sedikit perbedaan antara 68000 tahun 1979 dan 68010 tahun 1982 adalah penambahan “loop mode”, yaitu buffer loop 6-byte

    • Yang jauh lebih penting adalah perbaikan pada dukungan MMU. Awalnya 68000 kehilangan sebagian status yang diperlukan untuk pemulihan dari page fault, dan jalan memutarnya jelek serta mahal.
      Caranya adalah menjalankan dua CPU dengan selisih satu siklus dan menyuntikkan interupsi yang bisa dipulihkan ke CPU kedua. Meski begitu, jika menginginkan CPU dengan MMU serta set instruksi 32-bit dan bus alamat 24-bit, tampaknya itu masih lebih murah daripada alternatif saat itu. Pasti masa yang benar-benar liar
    • Menarik. Untuk buffer loop kecil, saya cukup menyukai core forth GreenArrays
      Satu word 18-bit memuat 4 instruksi, dan satu opcode mengurangi penghitung loop lalu kembali ke awal word. Dalam kasus seperti itu, eksekusinya bisa jauh lebih cepat
    • Buffer loop pada 68010 hampir tidak berguna. Bukan cuma karena ukurannya hanya 6 byte, tetapi juga karena hanya bisa menampung dua instruksi
      Salah satunya harus berupa instruksi loop (DBcc), jadi isi loop harus berupa satu instruksi saja. Praktis, hampir satu-satunya hal yang benar-benar bisa dipercepat hanyalah memcpy yang tidak dioptimalkan

  • Menarik bahwa ini merupakan fitur desain inti pada Cortex-A15. Saya penasaran apakah ada angka dampaknya pada chip lain
    Pada perangkat dengan umur desain yang lebih panjang seperti konsol, sepertinya ini setidaknya bisa dijadikan target optimasi

    • Saya juga penasaran. Saya menduga pada arsitektur RISC mana pun, keuntungan dari buffer loop akan relatif kecil
      Karena inti dari RISC adalah pengambilan dan dekode instruksi jauh lebih mudah atau nyaris sepele

  • Saya punya 7950X3D, hasil upgrade dari Skylake 6700K. Sepertinya tanpa sadar saya tertarik pada chip dengan buffer loop hardware yang dinonaktifkan lewat software

    • Kalau suatu hari nanti Anda mau beli mesin baru, tolong beri tahu sebelumnya. Biar kami bisa menghindarinya!

  • Tulisan yang menarik, tetapi saya tidak tahu berapa banyak area di die yang dipakai buffer loop
    Jika dihapus dari chip mendatang, saya penasaran apakah ruang itu bisa dipakai untuk hal yang lebih berguna seperti cache L2 yang lebih besar

    • Menurut saya, kebanyakan chip modern lebih dibatasi oleh kendala pengkabelan daripada luas area. Anda bisa membuat sangat banyak fitur, tetapi benar-benar menyiksa untuk menyalurkan daya dan sinyal yang sudah dinormalisasi ke semuanya
    • Setahu saya, ini optimasi yang cukup kecil di frontend. Jumlah entri dari awal memang tidak banyak, hanya 144, jadi penghematan areanya mungkin sangat kecil
      Secara teori, buffer loop bisa menghemat daya atau meningkatkan performa pada loop yang ketat. Dalam praktiknya, tampaknya tidak berhasil melakukan keduanya, dan AMD menghapusnya sepenuhnya di Zen 5
    • Dari diagramnya, tampaknya buffer loop memakai ruang penyimpanan yang sama dengan queue mikro-operasi yang memang sudah ada
      Jika benar, itu masuk akal, dan biaya areanya mungkin hanya berupa logika kontrol tambahan. Bagian yang paling mahal kemungkinan adalah mendeteksi loop sejak awal, tetapi itu pun tampaknya cukup kecil dibanding ukuran queue
    • Disebutkan 144 entri mikro-operasi per core. Saya tidak tahu berapa byte itu, tetapi cache L2 modern sekitar 1MB per core, jadi bahkan jika diasumsikan sebagian besar ruang die buffer loop adalah penyimpanan, kemungkinan tidak akan ada perbedaan yang mencolok

  • Analisis pada bagian “daya” tampaknya tidak dibagi dengan jumlah instruksi yang dieksekusi per detik
    Untuk melihat keuntungan buffer loop ini, hampir pasti yang perlu dilihat adalah energi per instruksi, bukan energi per detik, yaitu daya (watt)

    • Jumlah siklus clock per instruksi berbeda-beda, dan itu juga berubah antar generasi arsitektur seperti dari Zen 4 ke Zen 5. Jadi hal itu tidak benar-benar layak dilakukan kecuali beban kerja menghasilkan jumlah instruksi per siklus yang persis sama, yang mustahil karena multithreading dan pemrosesan pekerjaan
      Bahkan urutan dan isi RAM saja bisa mengubah segalanya. Menjalankan kondisi aktif dan nonaktif ratusan kali mungkin bisa memisahkan pengaruhnya sampai taraf tertentu, tetapi itu akan memakan waktu luar biasa lama dan tetap tidak 100% akurat. Hanya dengan mematikan fitur saja, kode bisa melewati cabang yang berbeda sehingga seluruh penjadwalan berubah. Saya tidak tahu masalah spesifik ini secara mendetail, tetapi saya pernah melihat kasus saat mematikan fitur justru memindahkan beban dari unit integer ke FPU atau GPU, atau 5 instruksi hilang tetapi digantikan 2 instruksi tambahan