AMD, Zen 4'ün döngü arabelleğini devre dışı bırakma kararı aldı

 (chipsandcheese.com)
1 puan yazan GN⁺ 2024-12-02 | 1 yorum | WhatsApp'ta paylaş
  • ASRock B650 PG Lightning için yayınlanan yeni BIOS'ta Zen 4 döngü arabelleği artık bir mikro-op kaynağı olarak gözlemlenmedi; önceki BIOS'a dönüldüğünde ise yeniden etkinleşiyor
  • Bu yapı, küçük döngüleri front-end'de tekrarlı işleyerek güç tüketimini azaltmayı amaçlayan bir özellik gibi görünüyor; tek iş parçacığında 144 giriş, SMT ile 2 iş parçacığında ise iş parçacığı başına 72 giriş olduğu tahmin ediliyor
  • SPEC CPU2017'de döngü arabelleği açık/kapalı durumları arasındaki toplam puan farkı %1'in altında kaldığı için, genel performans etkisi çok küçük görünüyor
  • Döngü arabelleği kapandığında Zen 4 daha fazla mikro-op'u op cache üzerinden besliyor; op cache bant genişliği arka uç işlem kapasitesinden zaten yüksek olduğundan bunun front-end darboğazına yol açması zor
  • Devre dışı bırakılma nedeni ve gerçek güç etkisi belirsiz, ancak AMD'nin neredeyse hiç belgelemediği veya tanıtmadığı sınırlı bir özellik olduğu için çoğu kullanıcı ve geliştirici bu değişikliği fark etmeyebilir

Zen 4 döngü arabelleğinin rolü ve sınırları

  • Döngü arabelleği, CPU front-end'inde daha önce getirilmiş az sayıdaki komutu tutarak küçük döngüler tekrar çalıştırılırken bazı front-end aşamalarının kapatılmasına izin veren bir yapı
    • Güç tasarrufuna yardımcı olabilir
    • Ön taraftaki front-end sınırlamalarını aşarak performansı artırma ihtimali vardır
    • Intel, Arm ve AMD çekirdeklerinde uzun zamandır kullanılan bir tekniktir
  • Zen 4, yüksek performanslı AMD çekirdekleri içinde döngü arabelleğine sahip olduğu anlaşılan tek örnek
  • Zen 4'ün Processor Programming Reference belgesi, döngü arabelleğini op cache ve decoder ile birlikte mikro-op dispatch kaynağı olarak anıyor
  • Performans sayacı deneylerine göre kapasite şu şekilde tahmin ediliyor
    • Tek iş parçacıklı çalışmada 144 giriş
    • SMT ile 2 iş parçacığı etkin olduğunda iş parçacığı başına statik olarak bölünmüş 72 giriş
  • Döngü içinde CALL/RET varsa Zen 4 döngü arabelleği o döngüyü yakalayamıyor
  • AMD'nin Zen 4 optimizasyon kılavuzu döngü arabelleğinden söz etmiyor; yalnızca hot code region'ları op cache kapasitesi içinde tutmayı öneriyor

BIOS güncellemesinden sonra kaybolan döngü arabelleği

  • ASRock B650 PG Lightning, BIOS 3.10 sürümüne güncellendikten sonra donanımsal performans izlemede döngü arabelleğinin mikro-op dispatch etmediği görüldü
  • BIOS 1.21 sürümüne geri dönüldüğünde döngü arabelleği yeniden etkinleşiyor
  • Devre dışı bırakmanın, BIOS 1.21'deki AGESA 1.0.0.6 ile BIOS 3.10'daki AGESA 1.2.0.2a arasında gerçekleştiği anlaşılıyor
  • AMD bu değişikliği ayrı bir duyuru veya tanıtım yapmadan uyguladı
  • Hot Chips 2024'te AMD çalışanlarıyla yapılan ek görüşmelere göre döngü arabelleği esas olarak güç optimizasyonu amacı taşıyan bir özellikti

SPEC CPU2017'de görülen küçük performans farkı

  • SPEC CPU2017 tamsayı ve kayan nokta test paketlerinin toplam puanı, döngü arabelleği açık/kapalı arasında %1'den az fark gösterdi
  • SMT performans artışı da döngü arabelleğinin devre dışı bırakılmasından etkilenmiyor
  • Performans etkisinin küçük olmasının nedeni, Zen 4'ün op cache'inin zaten arka uçtaki rename/allocate aşamasının tüketebileceğinden daha fazla bant genişliği sunması
  • Döngü arabelleği açık olsa bile performans sayaçlarında mikro-op'ların yalnızca küçük bir kısmının döngü arabelleğinden beslendiği görülüyor
  • Tek tek benchmark'larda da büyük bir kayıp doğrulanmadı
    • 523.xalanbmk testinde döngü arabelleği komut akışının anlamlı ama küçük bir kısmını üstlendi, ancak puan yeni BIOS'ta 9.48, eski BIOS'ta 9.44 ile hata payı içinde kaldı
    • 544.nab testinde mikro-op'ların neredeyse dörtte biri döngü arabelleğinden beslendi, ancak döngü arabelleğinin kapalı olduğu yeni BIOS'ta puan 11.7 ile önceki 11.5'in %1.7 üzerine çıktı
    • Bu artış çalıştırmadan çalıştırmaya değişen varyans olabilir
  • Yeni BIOS'un performans sayaçlarında op cache, döngü arabelleğinin payını devralıyor ve komut akışının daha büyük bölümünü işliyor
  • 507.cactuBSSN testinde op cache kapsaması bir miktar düşüyor ve decoder'ın toplam mikro-op'ların yaklaşık dörtte birini beslediği bir desen görülüyor
    • Performans sayaçları %100 doğru ölçümden ziyade genel eğilimleri gösteren araçlardır
    • Front-end dispatch, yanlış tahmin edilen dallanmaların ardından yanlış getirilen komutlardan da etkilenebilen spekülatif bir olaydır

Güç tasarrufu ihtimali ve front-end etkinliği

  • Döngü arabelleğinin ana amacı performans artışı değil, op cache dahil front-end'in önemli bir bölümünü fırsat buldukça kapatmak
  • Zen 4'ün performans izleme özelliklerinde, olay sayacının eşik değeri aşılmış çevrimleri sayabilen bir count mask bulunuyor
    • Eşik 1 olarak ayarlandığında her mikro-op kaynağının gerçekten mikro-op beslediği çevrim sayısı tahmin edilebiliyor
    • Böylece döngü arabelleği etkinken front-end'in ne kadar sık kapatılabildiği anlaşılabiliyor
  • SPEC CPU2017'de her kaynağın etkin olma sıklığı, o kaynağın sağladığı mikro-op oranıyla genel olarak iyi örtüşüyor
  • Bazı iş yüklerinde front-end'in hiçbir şey beslemediği çevrimler de oldukça fazla
    • 502.gcc ve 520.omnetpp, arka uç bellek gecikmesine ciddi biçimde bağlı
    • Out-of-order yürütme motoru gecikmeyi gizleyecek kadar komutu uçuşta tutamadığında, front-end arka uca daha fazla gönderemiyor ve boşta kalıyor
  • Kayan nokta test paketinde 544.nab ve 508.namd, oldukça fazla çekirdek çevriminde döngü arabelleğini kullanıyor
    • 508.namd, ortalama 3.64 IPC ile yüksek IPC'li bir iş yükü ve front-end throughput talebi yüksek
    • Döngü arabelleğine uygun olduğu için op cache'i kapatıp güç tasarrufu sağlama fırsatı sunuyor
  • Döngü arabelleği kapandığında op cache daha fazla çevrim boyunca çekirdeği besliyor
    • 523.xalanbmk testinde döngü arabelleği olmadan op cache'in çekirdek çevrimlerinin ilave %12'sinde aktif olması gerekiyor
    • 548.exchange2, ortalama 4.31 IPC ile yüksek IPC'li bir iş yükü, ancak döngü arabelleği açıkken bile neredeyse hiç kullanılmıyor ve op cache çekirdek çevrimlerinin %85'inden fazlasında aktif kalıyor
    • 508.namd testinde op cache etkinlik oranı, döngü arabelleği açıkken %56.67'den kapalıyken %75.1'e çıkıyor
  • 144 girişlik döngü arabelleği, komut akışının büyük kısmını tutmak için küçük kalıyor
    • Program ancak çalışma süresinin önemli bölümünü küçük döngülerde geçiriyor ve arka uç throughput'u ya da gecikmesiyle sınırlanmıyorsa belirgin bir etki gösterebilir

Cyberpunk 2077'de gözlemler

  • Döngü arabelleğinin devre dışı bırakılmasının oyun performansına etkisi, Cyberpunk 2077'nin dahili benchmark'ı ile incelendi
  • Tutarlılığı artırmak için Ryzen 9 7950X3D'de Core Performance Boost devre dışı bırakıldı ve tüm çekirdekler 4.2GHz ile sınırlandı
    • Hardware Configuration register MSR 0xC0010015 içindeki bit 25 ayarlandı
    • RX 6900 XT 2GHz ile sınırlandı
    • Benchmark ayarları 1080p, medium preset, upscaling kapalı
  • Oyun VCache die'a sabitlendiğinde döngü arabelleğinin devre dışı bırakılması performansı neredeyse etkilemiyor
  • non-VCache die'a sabitlendiğinde ise döngü arabelleği kapalıyken %5 performans kaybı gözlendi, ancak nedeni doğrulanamadı
    • Benchmark yaklaşık altı kez yeniden çalıştırıldı
  • Cyberpunk 2077, komut akışının ortalama yaklaşık %22'sini döngü arabelleğine bırakarak beklenenden daha döngü arabelleği dostu çıktı
    • Döngü arabelleği kapatıldıktan sonra op cache'in mikro-op besleme oranı %62'den %82'ye yükseldi
  • Bu oyun, döngü arabelleği kapalıyken ortalama 0.89 IPC, açıkken 1.02 IPC ile yüksek IPC'li bir iş yükü değil
    • Front-end bant genişliği büyük bir etken değil
    • Arka uç sınırlı ya da branch predictor gecikmesine bağlı olabilir
  • VCache die üzerinde çalışırken performans sayaçları, döngü arabelleği açıkken ortalama 1.25 IPC, kapalıyken 1.07 IPC gösteriyor
    • Yeni BIOS'ta küçük bir performans düşüşü de gözlendi
    • 155 FPS seviyesinde GPU tarafı darboğazına daha fazla yaklaşılmış olabilir

Çekirdek güç sayacı sonuçlarındaki belirsizlik

  • Döngü arabelleği kullanımının güç verimliliğini artırıp artırmadığını görmek için Zen 4'ün çekirdek güç sayacı da incelendi
  • Komut bant genişliği benchmark'ı, test bölümünde CALL/RET kullanmayacak şekilde değiştirildi
    • Çünkü CALL/RET varsa Zen 4 döngü arabelleğini kullanmıyor
  • Test tek bir çekirdeğe sabitlendi ve ortalama güç, test dizisine atlamadan önce ve sonra Core Energy Status MSR okunarak hesaplandı
  • Core Performance Boost, güç okumalarını ciddi biçimde oynattığı için kapatıldı
  • Eski BIOS'ta Core Energy Status MSR, NOP'lar op cache'ten getirilirken ortalama 6W, döngü arabelleğinden getirilirken ise çok daha düşük güç gösterdi
  • Test dizisi boyutu, op cache kapsamasını %1'in altına düşürmek için L2 kapasitesine sığan 128KB'ye çıkarıldığında bile ortalama çekirdek gücü 1.5W olarak gösterildi
    • Bu sonuç, decoder ve L2 fetch path kullanımının artması gereken durumla uyuşmuyor
  • Yeni BIOS'ta op cache testi ortalama 1.68W, decoder'ın çoğunlukla L2'den beslendiği test de neredeyse aynı güç değerini gösterdi
  • AMD'nin güç izleme özelliği gerçek ölçüm değil, güç modellemesi olabilir
    • BIOS sürümleri arasında modelleme yöntemi değişmiş veya güç modeli isabetli olmayabilir
    • 12V EPS konnektörü gibi noktalardan doğrudan ölçüm yapacak donanım olmadığı için ek doğrulama yapılamadı

Devre dışı bırakılma nedeni ve geliştirici bakışı

  • AMD'nin Zen 4 döngü arabelleğini neden devre dışı bıraktığı bilinmiyor
  • CPU özellikleri bazen donanım hataları nedeniyle kapatılabiliyor
    • Intel Skylake'in döngü arabelleği olan LSD, SMT'nin iki iş parçacığının etkin olduğu kısa döngülerde partial register access ile ilgili bir hata nedeniyle devre dışı bırakılmıştı
  • Zen 4, AMD'nin yüksek performanslı CPU'lara döngü arabelleği koyduğu ilk deneme ve ilk uygulamaların doğrulanması zordur
  • AMD'nin, dışarıdan görünmeyen bir hatayı içeride tespit edip önlem olarak döngü arabelleğini kapatmış olması mümkün
  • Performans etkisi, op cache bant genişliği yeterli olduğu için neredeyse yok ya da çok küçük görünüyor
  • Güç etkisi bilinmiyor, ancak küçük ve ölçülmesi zor olabilir
  • AMD, döngü arabelleğini Processor Programming Reference içindeki tek satır dışında neredeyse hiç belgelemiyor veya tanıtmıyor
    • Bu durum, Intel'in kendi loop buffer'ını sıkça belgelemesi ve geliştiricilerin bundan yararlanmasını optimizasyon kılavuzlarında önermesiyle tezat oluşturuyor
  • Zen 4 döngü arabelleği, düşük kapasitesi ve CALL/RET kısıtı nedeniyle op cache kadar kullanışlı olmayan sınırlı bir özellik
  • Eski BIOS'larda Zen 4 döngü arabelleğini dikkate alarak optimizasyon yapılacaksa şu koşullar göz önünde bulundurulabilir
    • Döngüler 144 micro-ops'tan küçük tutulmalı
    • Fiziksel çekirdeği iki iş parçacığı paylaşıyorsa bunun yarısı dikkate alınmalı
    • Küçük döngü içinde çağrılan fonksiyonlar için CALL/RET'ten kaçınmak amacıyla inline değerlendirilmelidir
  • Ancak bu tür optimizasyonların çoğu durumda bir karşılığı olmayacaktır

İlgili okumalar

1 yorum

 
GN⁺ 2024-12-02
Hacker News yorumları

  • Bu özelliğin kamuya açıklanmamış bir donanım açığını engelleme girişimi olarak devre dışı bırakılmış olabileceği yönünde spekülasyonlar var

    • Yazıda da genel olarak benzer bir tahmin yapılıyor: Zen 4, AMD'nin yüksek performanslı CPU'lara loop buffer koymaya yönelik ilk denemesi ve ilk uygulamanın doğrulanması her zaman zordur.
      AMD içinde kimsenin karşılaşmadığı bir hata bulunmuş ve aşırı temkinli davranarak loop buffer kapatılmış olabilir; bunu hayal etmek çok da zorlama değil. Çekirdek yaşam döngüsünün bu aşamasında AMD'nin Zen 4 front-end'ine dokunması için başka bir neden pek akla gelmiyor
    • Gerçekte daha fazlası da devre dışı bırakılmış olabilir. Rakamlar epey şaşırtıcı: Cyberpunk 2077'yi VCache die üzerinde çalıştırırken loop buffer açık olduğunda performans sayaçları ortalama IPC'yi 1,25, kapalı olduğunda 1,07 gösteriyor; buna rağmen yeni BIOS'ta hafif bir performans düşüşü var.
      Kişisel olarak bu bana mikrokod azaltımı kokusu veriyor, ama elbette CVE'yi beklemek gerek
    • Sessizce devre dışı bırakmak da büyük risk. Çünkü sorunun ciddiyetini bildiklerinin ve yama yapılacak kadar ciddi olduğuna karar verdiklerinin sinyalini verir.
      Açık açıklanmazsa etkilenen tarafların saf paranoya dışında harekete geçmeye başlamasının bir yolu yok. Açık açıklaması, sorumluluğu son kullanıcıya aktarmanın bir yolu da olabilir. Güncellemediysen şikâyet etme tarzında. Açıklamanın ürün sorumluluğuna yol açması nadirdir; Meltdown veya Spectre'da da böyle bir sorumluluk meselesi olduğunu hatırlamıyorum. Bu yüzden AMD'nin bunu bilerek sakladığını kesin söylemem
    • Doğru cevap gibi görünüyor, ama daha fazlasını söyleyemem :(

  • Yazı, loop buffer'ın ne performans ne de güç tüketimi açısından kazanç sağladığını ima ediyor gibi.
    Öyleyse bu, “mühendis ekibi aylarca parlak yeni bir özellik yaptı ama pratikte kazancı olmadı, yine de biri itibarını korumak için bunu piyasaya sürdü” şeklindeki klasik durum olabilir. Yazılım ekiplerinde de eski hantallığı ortadan kaldırıp performansı artıracağız diye kod tabanını yeniden yazmaya kalkışıldığını, iş bitince satır sayısının arttığını ve performansın kötüleştiğini gördüm. İki durumda da yayınlanmaması gerekirdi

    • Yine de yayınlanmasının nedeni, bunun firmware güncellemesi ile kapatılabilmesi ve tasarımın ortasında fiziksel donanım yerleşimini büyük ölçüde değiştirmenin muhtemelen daha kötü etkiler doğuracak olması
    • Çekirdeğe zaten girdikten sonra pek faydası olmadığını fark ettilerse, onu kaldırmanın kendisi bariz bir risktir
    • Yazıda da güç kullanımını genel olarak ölçmenin zor olduğu söylenmiş; dolayısıyla bu özelliğin hiçbir etkisi olmadığı sonucuna varılamaz, hatta varılmamalı.
      AMD mühendislik ekibinin hiçbir değeri olmayan bir donanım özelliği için alan ve güç harcanmasına izin verecek kadar ilkesiz olduğunu düşünmek zor; burada Chips 'n Cheese'in etkiyi ölçememiş olma ihtimaline daha fazla ağırlık vermek isterim
    • Oldukça tanınmış bir donanım şirketinde çalışıyorum; yazılım tarafı, bazı dar kullanım örnekleri veya hedeflenmiş benchmark'lar dışında yeterince kanıtlanmamış olsa bile bir şeyler yapmaya takıntılı durumda.
      Çok sinir bozucu, ama kimse ön araştırma yapmak için zaman ayırmak istemiyor. Yeni bir projeyi ileri itmek, üst yönetimi memnun etmeyi ve daha az soru almayı kolaylaştırıyor
    • Güç benchmark'larının doğru olduğu başka bir olasılık da var. Buffer güç tasarrufu sağlamış olabilir, ama daha sonra mikrokod düzeyinde genel yolun daha az güç tüketmesini sağlayan daha iyi bir optimizasyon bulunmuş ve buffer tersine güç tüketen bir aygıta dönüşmüş olabilir

  • Yazıdaki en ilginç paragraf şu: Zen 4'ün loop buffer'ına bakmanın en iyi yolu, AMD'de mühendislerin bir şeyler denemek için boş kapasitesi olduğuna dair bir işaret olarak görmek.
    Bu kez sonuç alınmamış olabilir, ama mühendislerin düşük riskli ve düşük etkili özelliklerle deney yapmasına izin vermek özgüven inşa etmenin iyi bir yolu. Gelecekte bu özgüveni daha çok görmeyi umuyorum

  • “İlginç biçimde non-VCache die'a sabitlendiğinde, loop buffer devre dışı bırakılınca oyun performansı %5 düşüyor. Nedenini bilmiyorum” kısmı için, daha ayrıntılı güç ölçümleri olsaydı bunun ısı/güç bütçesi ile ilgili olup olmadığı anlaşılabilirdi diye düşünüyorum.
    Bu özellik güç tasarrufu amaçlıymış gibi de görünüyor

    • Burada yeterince ayrıntı yok. Ryzen çiplerde ikinci CCD, non-X3D çiplerde bile birinciden daha düşük binning kalitesine sahip ve bu çipten çipe değişiyor.
      Benim non-X3D çipimde CCD0 çekirdeklerinin çoğu 5,6~5,75GHz'e çıkıyor, CCD1 çekirdekleri ise 5,4~5,5GHz'te kalıyor. Zen 4'ün V-Cache çiplerinde saat hızı cezası büyük, ama önbellek bunun fazlasını telafi ediyor. Aynı çipin CCD1'inde özellik açık ve kapalı hâllerinin ikisinin de test edilip edilmediğini, güvenlik düzeltmesi gibi başka değişiklikleri ayırmaya çalışıp çalışmadıklarını görmek gerek; yazı ise kendi kendine “hayır” diye kabul ediyor. Doğru yapmak için özelliğin açık olduğu BIOS'ta yalnızca bu özelliği kapatmanın bir yolunu bulup aynı çipte iki tarafı da test etmek gerekir; yine de farklı dallanma koşulları nedeniyle sonuçlar tam doğru olmayabilir. Tam performans profili olursa doğruluk artar, ama bunu muhtemelen yalnızca AMD mühendisleri yapabilir
    • Test edilen iki UEFI sürümü arasında bir noktada devre dışı bırakıldığı söylenmiş. Başka değişiklikler de içeriyordur; dolayısıyla ölçüm sıkı bir A/B testi değil

  • Gerçek bir fark yaratmak için fazla küçüktü ve yalnızca çok belirli durumlarda anlamlıydı gibi görünüyor. Daha büyük yapılsaydı, sağladığı kazanca kıyasla uygulama maliyeti muhtemelen fazla yüksek olurdu.
    Buna rağmen bazı iş yüklerinde küçük gerilemeler olacaktır, ama AMD çıkıştan sonra küçük performans iyileştirmeleri de yaptı. Zen 4'te bunu sadece BIOS seçeneği hâline getirmeliydiler. Bunu yapmamış gibi görünmeleri, hata veya güvenlik sorunu ihtimaline işaret ediyor

    • Çoğu kullanıcının fark etmeyeceği ama front-end'i karmaşıklaştıran bir özelliğin sessizce devre dışı bırakılması, donanım hatasını açıklamaktan kaçınırken ya da bunu geciktirirken azaltımı şimdiden dağıtmak için bu chicken bit'i çektikleri izlenimini veriyor. Lanet olası tedarikçiler, ne zaman öğrenecekler

  • Anekdot olarak, 1979’daki 68000 ile 1982’deki 68010 arasındaki az sayıdaki farklardan biri “loop mode”, yani 6 baytlık bir döngü tamponunun eklenmesiydi

    • Çok daha önemli olan, MMU desteğinin düzeltilmesiydi. Orijinal 68000, sayfa hatasından kurtulmak için gereken bazı durum bilgisini kaybediyordu ve geçici çözüm çirkin ve pahalıydı
      İki CPU’yu bir döngü kaydırarak çalıştırıp ikinci CPU’ya kurtarılabilir bir kesme enjekte etme yöntemiydi. Yine de MMU’su olan, 32 bit komut setine ve 24 bit adres veri yoluna sahip bir CPU istiyorsanız, o dönemdeki alternatiflerden daha ucuzmuş gibi görünüyor. Gerçekten zorlu zamanlar olmalı
    • İlginç. Küçük döngü tamponu konusunda GreenArrays forth çekirdeğini epey beğeniyorum
      18 bitlik bir sözcüğe 4 komut sığıyor ve bir işlem kodu döngü sayacını azalttıktan sonra sözcüğün başına dönüyor. Bu durumda oldukça daha hızlı çalışabiliyor
    • 68010’un döngü tamponu neredeyse işe yaramazdı. Çünkü yalnızca 6 bayt değildi, sadece iki komut da tutabiliyordu
      Bunlardan birinin döngü komutu (DBcc) olması gerektiğinden döngü gövdesi tek bir komut olmak zorundaydı. Pratikte hızlanabilecek şeyler neredeyse yalnızca optimize edilmemiş memcpy idi

  • Cortex-A15’te bunun temel bir tasarım özelliği olması ilginç. Diğer çiplerde etkisine dair sayılar var mı merak ediyorum
    Konsollar gibi tasarım ömrü daha uzun cihazlarda en azından optimizasyon hedefi olarak da kullanılabilir gibi görünüyor

    • Ben de merak ediyorum. Herhangi bir RISC mimarisinde döngü tamponundan elde edilen kazancın görece küçük olacağını tahmin ederim
      Çünkü RISC’in özü, komut getirme ve çözümlemenin çok daha kolay ya da neredeyse önemsiz olmasıdır

  • Bende 7950X3D var; Skylake 6700K’dan yükseltmiştim. Görünüşe göre bilinçsizce donanım döngü tamponu yazılımla devre dışı bırakılmış çiplere çekiliyorum

    • Bir gün yeni makine alacaksan önceden haber versen iyi olur. Biz de kaçınabilelim!

  • İlginç bir yazı, ama döngü tamponunun kalıpta ne kadar yer kapladığını bilmiyorum
    Gelecekteki çiplerden kaldırılırsa, o alanın daha büyük L2 önbellek gibi daha faydalı bir şeye ayrılıp ayrılamayacağını merak ediyorum

    • Bence modern çiplerin çoğunda taban alanından çok kablolama kısıtları daha belirleyici. Çok fazla işlev yapılabiliyor, ama bunlara hem güç hem de normalize edilmiş sinyaller sağlamak gerçekten eziyet
    • Anladığım kadarıyla ön uçta oldukça küçük bir optimizasyon. Zaten çok fazla öğe yok; 144 tane olduğundan tasarruf edilen alan muhtemelen önemsizdir
      Teoride döngü tamponu, sıkı döngülerde güç tasarrufu sağlayabilir veya performansı artırabilir. Pratikte ikisini de yapamıyor gibi görünüyor ve AMD bunu Zen 5’te tamamen kaldırdı
    • Diyagrama bakılırsa döngü tamponu, zaten var olan mikro işlem kuyruğuyla aynı depolama alanını kullanıyor gibi
      Eğer doğruysa bu mantıklı; alan maliyeti de ek kontrol mantığı kadar olur. En pahalı kısım başta döngüyü tespit etmek gibi görünüyor, ama kuyruk boyutuna kıyasla oldukça küçük olmalı
    • Çekirdek başına 144 mikro işlem öğesi deniyor. Kaç bayt olduğunu bilmiyorum, ama günümüzde L2 önbellek çekirdek başına yaklaşık 1 MB olduğundan, döngü tamponu kalıp alanının çoğunun depolama olduğunu varsaysak bile gözle görülür bir fark yaratmaz

  • “Güç” bölümündeki analiz, saniye başına çalıştırılan komut sayısına bölünmemiş gibi görünüyor
    Bu döngü tamponunun faydasını görmek için saniye başına enerjiye, yani güç (watt) değerine değil, neredeyse kesinlikle komut başına enerjiye bakmak gerekir

    • Her komutun aldığı saat döngüsü sayısı farklıdır; Zen 4’ten Zen 5’e gibi mimari nesiller arasında da değişir. Bu yüzden iş yükü tam olarak aynı döngü başına komut sayısını üretmediği sürece uygulanabilir değil; çok iş parçacıklılık ve iş işleme nedeniyle bu da imkânsız
      Sıra ve RAM içeriği bile her şeyi değiştirebilir. Açık ve kapalı hâlleri yüzlerce kez çalıştırarak bir ölçüde ayrıştırabilirsiniz, ama çok zaman alır ve yine de %100 doğru olmaz. Sırf bir özelliği kapatmak bile kodun başka bir dala girmesine ve tüm yerleşimin değişmesine yol açabilir. Bu sorunu özel olarak bilmiyorum, ama bir özelliği kapatınca yükün tamsayı biriminden FPU’ya veya GPU’ya kaydığı ya da 5 komutun kaybolması yerine 2 komutun eklendiği örnekler gördüm