AMD ने Zen 4 का loop buffer निष्क्रिय करने का फैसला किया

 (chipsandcheese.com)
1 पॉइंट द्वारा GN⁺ 2024-12-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ASRock B650 PG Lightning के नए BIOS में Zen 4 का loop buffer अब micro-op source के रूप में दिखाई नहीं दिया, और पुराने BIOS पर लौटने पर यह फिर से सक्रिय हो गया
  • यह संरचना छोटे loops को frontend में बार-बार प्रोसेस करके power कम करने वाली सुविधा लगती है, और इसका अनुमानित आकार single-thread में 144 entries, जबकि SMT 2-thread पर प्रति thread 72 entries है
  • SPEC CPU2017 में loop buffer enabled/disabled के बीच कुल स्कोर का अंतर 1% से कम रहा, इसलिए सामान्य performance पर इसका असर बहुत छोटा दिखता है
  • loop buffer बंद होने पर Zen 4 अधिक micro-ops को op cache से supply करता है, और op cache bandwidth backend throughput से पर्याप्त अधिक होने के कारण frontend bottleneck बनने की संभावना कम है
  • इसे निष्क्रिय करने का कारण और वास्तविक power impact स्पष्ट नहीं है, लेकिन AMD ने इस सीमित feature को लगभग न तो document किया और न प्रचारित किया, इसलिए अधिकतर users और developers के लिए इस बदलाव को महसूस करना कठिन होगा

Zen 4 loop buffer की भूमिका और सीमाएँ

  • loop buffer CPU frontend में पहले से fetch किए गए थोड़े से instructions को रखता है, ताकि छोटे loops को बार-बार चलाते समय frontend के कुछ चरणों को बंद किया जा सके
    • इससे power saving में मदद मिल सकती है
    • frontend की सीमाओं को bypass करके performance सुधारने की भी कुछ संभावना होती है
    • यह तकनीक Intel, Arm और AMD cores में लंबे समय से इस्तेमाल होती रही है
  • Zen 4 को high-performance AMD cores में loop buffer वाले एकमात्र उदाहरण के रूप में पहचाना गया है
  • Zen 4 की Processor Programming Reference में loop buffer को op cache और decoder के साथ micro-op dispatch source के रूप में बताया गया है
  • performance counter experiments के आधार पर इसकी क्षमता का अनुमान इस प्रकार है
    • single-thread execution में 144 entries
    • SMT 2-thread सक्रिय होने पर प्रति thread 72 entries का static विभाजन
  • अगर loop के भीतर CALL/RET हो, तो Zen 4 loop buffer उस loop को capture नहीं कर पाता
  • AMD की Zen 4 optimization guide loop buffer का उल्लेख नहीं करती और केवल यही सलाह देती है कि hot code region को op cache capacity के भीतर रखा जाए

BIOS update के बाद गायब हुआ loop buffer

  • ASRock B650 PG Lightning को BIOS 3.10 पर update करने के बाद hardware performance monitoring में दिखा कि loop buffer micro-op dispatch नहीं कर रहा
  • BIOS 1.21 पर वापस जाने पर loop buffer फिर सक्रिय हो गया
  • यह निष्क्रियता संभवतः BIOS 1.21 के AGESA 1.0.0.6 और BIOS 3.10 के AGESA 1.2.0.2a के बीच हुई
  • AMD ने यह बदलाव किसी अलग घोषणा या प्रचार के बिना लागू किया
  • Hot Chips 2024 में AMD कर्मचारियों के साथ हुई अतिरिक्त चर्चा के अनुसार loop buffer मुख्य रूप से power optimization के लिए था

SPEC CPU2017 में दिखा छोटा performance अंतर

  • SPEC CPU2017 integer और floating-point suite के कुल स्कोर में loop buffer enabled/disabled के बीच 1% से कम का अंतर रहा
  • SMT performance gain पर भी loop buffer निष्क्रिय होने का असर नहीं पड़ा
  • performance impact छोटा रहने का कारण यह है कि Zen 4 का op cache पहले से ही backend के rename/allocate चरण की खपत से अधिक bandwidth देता है
  • loop buffer चालू होने पर भी performance counters में micro-ops का केवल छोटा हिस्सा ही loop buffer से आता दिखा
  • अलग-अलग benchmarks में भी कोई बड़ा नुकसान नहीं दिखा
    • 523.xalanbmk में instruction stream का अर्थपूर्ण छोटा हिस्सा loop buffer संभाल रहा था, लेकिन स्कोर नए BIOS में 9.48 और पुराने BIOS में 9.44 रहा, जो error range के भीतर है
    • 544.nab में लगभग एक-चौथाई micro-ops loop buffer से आए, लेकिन loop buffer बंद वाले नए BIOS में स्कोर 11.7 रहा, जो पुराने 11.5 से 1.7% अधिक है
    • यह बढ़त run-to-run variance भी हो सकती है
  • नए BIOS के performance counters में op cache, loop buffer की हिस्सेदारी लेकर instruction stream का बड़ा भाग संभालता दिखा
  • 507.cactuBSSN में op cache coverage कुछ कम हुई और decoder द्वारा कुल micro-ops के लगभग एक-चौथाई supply करने का पैटर्न दिखा
    • performance counters 100% सटीक measurement से अधिक समग्र रुझान दिखाने वाले tools हैं
    • frontend dispatch speculative event है, इसलिए mispredicted branch के बाद गलत fetch हुए instructions से भी प्रभावित हो सकता है

power saving की संभावना और frontend activity

  • loop buffer का मुख्य उद्देश्य performance बढ़ाना नहीं, बल्कि op cache सहित frontend के बड़े हिस्से को अवसर मिलने पर बंद करना है
  • Zen 4 की performance monitoring सुविधा में count mask है, जिससे उन cycles को गिना जा सकता है जिनमें event count threshold से ऊपर जाता है
    • threshold को 1 रखने पर यह अनुमान लगाया जा सकता है कि हर micro-op source ने वास्तव में कितने cycles में micro-ops supply किए
    • इससे यह आकलन किया जा सकता है कि loop buffer सक्रिय होने पर frontend को कितनी बार बंद किया जा सकता है
  • SPEC CPU2017 में हर source की सक्रियता का अनुपात, उस source द्वारा भेजे गए micro-ops के अनुपात से मोटे तौर पर मेल खाता है
  • कुछ workloads में frontend के कुछ भी supply न करने वाले cycles भी काफी अधिक थे
    • 502.gcc और 520.omnetpp backend memory latency से काफी बंधे हुए थे
    • जब out-of-order execution engine latency छिपाने लायक पर्याप्त instructions को in-flight नहीं रख पाता, तब frontend backend को और नहीं भेज पाता और idle हो जाता है
  • floating-point suite में 544.nab और 508.namd ने काफी core cycles तक loop buffer का उपयोग किया
    • 508.namd औसतन 3.64 IPC वाला high IPC workload है, इसलिए frontend throughput की मांग अधिक है
    • यह loop buffer friendly है, इसलिए op cache को बंद करके power बचाने का मौका मिलता है
  • loop buffer बंद होने पर op cache अधिक cycles तक core को supply करता है
    • 523.xalanbmk में loop buffer के बिना op cache को अतिरिक्त 12% core cycles तक सक्रिय रहना पड़ा
    • 548.exchange2 औसतन 4.31 IPC वाला high IPC workload है, लेकिन loop buffer चालू होने पर भी इसका लगभग उपयोग नहीं करता, और op cache 85% से अधिक core cycles में सक्रिय रहता है
    • 508.namd में op cache active ratio, loop buffer सक्रिय होने पर 56.67% से बढ़कर निष्क्रिय होने पर 75.1% हो गया
  • 144-entry loop buffer instruction stream के बड़े हिस्से को समेटने के लिए छोटा है
    • इसका स्पष्ट प्रभाव शायद तभी दिखे जब program काफी समय छोटे loops में बिताए और backend throughput या latency से बंधा न हो

Cyberpunk 2077 में अवलोकन

  • Cyberpunk 2077 के built-in benchmark से देखा गया कि loop buffer निष्क्रिय होने का game performance पर क्या असर पड़ता है
  • consistency बढ़ाने के लिए Ryzen 9 7950X3D में Core Performance Boost को बंद किया गया और सभी cores को 4.2GHz तक सीमित किया गया
    • Hardware Configuration register MSR 0xC0010015 का bit 25 सेट किया गया
    • RX 6900 XT को 2GHz तक सीमित किया गया
    • benchmark settings थीं 1080p, medium preset, बिना upscaling
  • जब game को VCache die पर pin किया गया, तब loop buffer निष्क्रिय होने का performance पर लगभग कोई असर नहीं पड़ा
  • non-VCache die पर pin करने पर loop buffer निष्क्रिय होने से 5% performance loss देखा गया, लेकिन कारण की पुष्टि नहीं हो सकी
    • benchmark लगभग छह बार फिर चलाया गया
  • Cyberpunk 2077 में औसतन instruction stream का लगभग 22% हिस्सा loop buffer संभाल रहा था, इसलिए यह अपेक्षा से अधिक loop-buffer-friendly निकला
    • loop buffer निष्क्रिय होने के बाद op cache की micro-op supply share 62% से बढ़कर 82% हो गई
  • यह game loop buffer निष्क्रिय होने पर औसतन 0.89 IPC और सक्रिय होने पर 1.02 IPC दिखाता है, इसलिए यह high IPC workload नहीं है
    • frontend bandwidth कोई बड़ा मुद्दा नहीं है
    • संभव है कि यह backend-bound हो या branch predictor delay से सीमित हो
  • VCache die पर चलाने पर performance counters ने loop buffer सक्रिय होने पर औसतन 1.25 IPC और निष्क्रिय होने पर 1.07 IPC दिखाया
    • नए BIOS पर हल्की performance गिरावट भी देखी गई
    • संभव है कि लगभग 155 FPS के स्तर पर यह GPU bottleneck के अधिक करीब आ गया हो

core power counter परिणामों की अनिश्चितता

  • यह जाँचने के लिए कि loop buffer execution power efficiency सुधारता है या नहीं, Zen 4 के core power counter भी देखे गए
  • instruction bandwidth benchmark को इस तरह बदला गया कि test section में CALL/RET का उपयोग न हो
    • क्योंकि CALL/RET होने पर Zen 4 loop buffer का उपयोग नहीं करता
  • test को एक core पर pin किया गया, और test array पर jump करने से पहले और बाद में Core Energy Status MSR पढ़कर average power निकाली गई
  • Core Performance Boost को बंद किया गया क्योंकि power readings में बहुत उतार-चढ़ाव था
  • पुराने BIOS में Core Energy Status MSR ने op cache से NOP fetch करते समय औसतन 6W और loop buffer से fetch करते समय इससे काफी कम power दिखाई
  • test array का आकार बढ़ाकर 128KB किया गया, जो L2 capacity में आता है, और op cache coverage को 1% से कम कर दिया गया, फिर भी average core power 1.5W दिखी
    • यह उस स्थिति से मेल नहीं खाता जहाँ decoder और L2 fetch path का उपयोग अधिक होना चाहिए
  • नए BIOS में op cache test ने औसतन 1.68W दिखाया, और L2 से मुख्यतः decoder supply वाला test भी लगभग उतनी ही power दिखाता है
  • AMD की power monitoring सुविधा वास्तविक measurement के बजाय power modeling हो सकती है
    • BIOS versions के बीच modeling तरीका बदला हो सकता है या power model सही न हो
    • 12V EPS connector आदि से direct measurement करने वाला hardware न होने के कारण अतिरिक्त verification नहीं किया गया

निष्क्रिय करने का कारण और developer का दृष्टिकोण

  • AMD ने Zen 4 loop buffer को क्यों निष्क्रिय किया, यह ज्ञात नहीं है
  • CPU features कभी-कभी hardware bugs के कारण बंद किए जाते हैं
    • Intel Skylake के loop buffer LSD को SMT के दो threads सक्रिय होने वाले short loops में partial register access से जुड़े bug के कारण निष्क्रिय किया गया था
  • Zen 4, AMD का high-performance CPU में loop buffer जोड़ने का पहला प्रयास था, और पहली implementation को validate करना कठिन होता है
  • संभव है AMD ने अंदरूनी तौर पर कोई ऐसा bug पाया हो जो बाहर दिखाई नहीं देता, और एहतियात के तौर पर loop buffer बंद कर दिया हो
  • performance impact लगभग न के बराबर या बहुत छोटा लगता है, क्योंकि op cache bandwidth पर्याप्त है
  • power impact अज्ञात है, लेकिन यह छोटा और मापना कठिन हो सकता है
  • AMD ने Processor Programming Reference की एक पंक्ति के अलावा loop buffer को लगभग न document किया न advertise किया
    • यह Intel के उस तरीके के विपरीत है जिसमें वह अपने loop buffer को अक्सर document करता है और optimization guides में developers को उसका उपयोग करने की सलाह देता है
  • Zen 4 loop buffer अपनी कम capacity और CALL/RET सीमा के कारण op cache जितना उपयोगी नहीं, बल्कि एक सीमित feature है
  • अगर कोई पुराने BIOS पर Zen 4 loop buffer को ध्यान में रखकर optimize करना चाहे, तो ये शर्तें ध्यान में रखी जा सकती हैं
    • loop को 144 micro-ops से कम रखें
    • यदि दो threads एक physical core साझा करते हों, तो उसका लगभग आधा मानें
    • छोटे loop के भीतर बुलाए जाने वाले functions के लिए CALL/RET से बचने हेतु inline पर विचार करें
  • फिर भी ऐसे optimization का लाभ अधिकांश मामलों में शायद नहीं मिलेगा

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-12-02
Hacker News की राय

  • ऐसा अनुमान लग रहा है कि शायद इस फीचर को किसी अप्रकाशित hardware vulnerability को रोकने की कोशिश में disable किया गया हो

    • लेख में भी कुल मिलाकर कुछ ऐसा ही अनुमान है: Zen 4 AMD की high-performance CPU में loop buffer डालने की पहली कोशिश है, और पहली implementation को validate करना हमेशा मुश्किल होता है
      यह कल्पना करना अनुचित नहीं कि AMD के भीतर कोई ऐसा bug मिला जिसे पहले किसी ने नहीं देखा था, और जरूरत से ज्यादा सावधानी बरतते हुए loop buffer बंद कर दिया गया। core lifecycle के इस पड़ाव पर AMD द्वारा Zen 4 frontend को छेड़ने की कोई और वजह आसानी से समझ नहीं आती
    • असल में शायद और भी चीजें disable हुई हों। आंकड़े काफी चौंकाने वाले हैं: Cyberpunk 2077 को VCache die पर चलाते समय loop buffer on हो तो performance counter average IPC 1.25 दिखाता है, off हो तो 1.07, फिर भी नए BIOS में थोड़ी performance गिरावट है
      निजी तौर पर इसमें microcode mitigation जैसी गंध आती है, लेकिन जाहिर है CVE का इंतजार करना होगा
    • चुपचाप disable करना भी बड़ा जोखिम है। क्योंकि यह संकेत देता है कि उन्हें समस्या की गंभीरता पता थी, और उन्होंने इसे patch करने लायक गंभीर माना
      vulnerability सार्वजनिक न हो तो प्रभावित पक्षों के पास pure paranoia के अलावा response शुरू करने का कोई तरीका नहीं होता। vulnerability disclosure अंतिम जिम्मेदारी end user पर डालने का तरीका भी है। जैसे, update नहीं किया तो शिकायत मत करो। disclosure से product liability बनती हो, ऐसा कम ही होता है, और Meltdown या Spectre में भी मुझे ऐसा liability issue याद नहीं। इसलिए मैं यह निष्कर्ष नहीं निकालूंगा कि AMD जानबूझकर इसे छिपा रहा है
    • लगता है यही सही जवाब है, लेकिन इससे ज्यादा नहीं कह सकता :(

  • लेख से ऐसा लगता है कि loop buffer से न performance benefit है, न power benefit
    अगर ऐसा है तो यह वह classic case हो सकता है जहां “engineering team ने महीनों लगाकर चमकदार नया feature बनाया, लेकिन असल में कोई फायदा नहीं था, फिर भी किसी ने face-saving के लिए उसे release कर दिया।” software teams में भी मैंने देखा है कि legacy bloat हटाकर performance बढ़ाने के नाम पर codebase rewrite करने की बात हुई, और अंत में code lines बढ़ गईं और performance खराब हो गई। दोनों ही मामलों में इसे release नहीं करना चाहिए था

    • फिर भी release करने की वजह यह है कि इसे firmware update से बंद किया जा सकता था, और design के बीच में physical hardware layout को बड़े पैमाने पर बदलने से शायद और खराब असर पड़ता
    • अगर core में शामिल हो जाने के बाद एहसास हुआ कि इससे खास मदद नहीं मिल रही, तो इसे हटाना अपने-आप में साफ जोखिम था
    • लेख में भी कहा गया कि overall power usage मापना मुश्किल था, इसलिए यह निष्कर्ष नहीं निकाला जा सकता कि इस feature का कोई असर नहीं है—और सच कहें तो ऐसा करना भी नहीं चाहिए
      यह मानना मुश्किल है कि AMD engineering team इतनी principle-less होगी कि बेकार hardware feature पर area और power खर्च होने दे; यहां मैं इस संभावना को ज्यादा वजन दूंगा कि Chips 'n Cheese उसका असर माप नहीं पाया
    • मैं एक काफी मशहूर hardware company में काम करता हूं, और software side पर कुछ narrow use cases या targeted benchmarks के अलावा पर्याप्त benefit साबित न होने पर भी कुछ करने की जिद चल रही है
      यह बहुत frustrating है, लेकिन कोई भी पहले से research करने में समय नहीं लगाना चाहता। नया project push करना upper management को खुश करने और कम सवाल झेलने का आसान तरीका है
    • एक और संभावना यह भी है कि power benchmark सही हो। buffer ने power बचाई थी, लेकिन बाद में microcode level पर सामान्य path को और power-efficient बनाने वाली बेहतर optimization मिल गई, जिससे buffer उल्टा power खाने वाला component बन गया

  • लेख का सबसे दिलचस्प paragraph यह हिस्सा है: Zen 4 के loop buffer को देखने का सबसे अच्छा नजरिया यह है कि यह AMD में engineers के पास कुछ आजमाने की spare capacity होने का संकेत है
    इस बार शायद नतीजा नहीं निकला, लेकिन engineers को low-risk और low-impact features के साथ experiment करने देना confidence बनाने का अच्छा तरीका है। उम्मीद है आगे ऐसा confidence और देखने को मिलेगा

  • “अजीब बात है कि non-VCache die पर pin करने पर loop buffer disable करने से gaming performance 5% गिरती है। वजह नहीं पता” वाला हिस्सा—अगर ज्यादा fine-grained power measurements हों तो शायद समझा जा सके कि यह thermal/power budget से जुड़ा है या नहीं
    यह feature power बचाने के इरादे से बना लगता है

    • यहां पर्याप्त details नहीं हैं। Ryzen chip का second CCD, non-X3D chips में भी first CCD से कम binning quality वाला होता है, और हर chip में अलग होता है
      मेरी non-X3D chip में CCD0 के ज्यादातर cores 5.6~5.75GHz तक जाते हैं, लेकिन CCD1 cores 5.4~5.5GHz पर रुक जाते हैं। Zen 4 के V-Cache chips में clock penalty बड़ी है, लेकिन cache उससे ज्यादा compensate कर देता है। देखना होगा कि क्या उसी chip के CCD1 पर feature on और off दोनों states test की गईं, और क्या security fixes जैसे दूसरे बदलावों को अलग करने की कोशिश की गई; लेख खुद इसका जवाब “नहीं” मानता है। सही तरीके से करने के लिए feature-enabled BIOS में सिर्फ यही feature बंद करने का तरीका ढूंढ़कर उसी chip पर दोनों sides test करनी होंगी, और तब भी दूसरी branch conditions की वजह से results सटीक न हों। full performance profile हो तो accuracy बढ़ेगी, लेकिन शायद यह काम AMD engineers ही कर सकते हैं
    • कहा गया कि test की गई दो UEFI versions के बीच कहीं इसे disable किया गया। उनमें दूसरे changes भी शामिल रहे होंगे, इसलिए measurement strict A/B test नहीं है

  • असल फर्क डालने के लिए यह बहुत छोटा था, और लगता है कि सिर्फ बहुत specific situations में ही मायने रखता था। इसे बड़ा बनाते तो benefit की तुलना में implementation cost बहुत ज्यादा होती
    फिर भी कुछ workloads में थोड़ी regression होगी, लेकिन AMD ने release के बाद छोटी performance improvements भी की हैं। Zen 4 में इसे बस BIOS option बना देना चाहिए था। ऐसा नहीं किया गया लगता है, जो bug या security issue की संभावना की ओर इशारा करता है

    • ज्यादातर users को पता भी नहीं चलेगा, लेकिन frontend को complex बनाने वाले feature को चुपचाप disable करना ऐसा लगता है मानो hardware bug disclosure से बचते या उसे delay करते हुए mitigation पहले ही deploy करने के लिए यह chicken bit खींचा गया हो। धत्त तेरे vendors, कब सीखेंगे

  • किस्से के तौर पर, 1979 के 68000 और 1982 के 68010 के बीच मौजूद कुछ ही फर्कों में से एक “loop mode” था, यानी 6-byte loop buffer का जोड़

    • इससे कहीं ज्यादा अहम बात MMU support को ठीक करना था। असल 68000 page fault से recover करने के लिए जरूरी कुछ state खो देता था, और workaround बदसूरत व महंगा था
      तरीका यह था कि दो CPU को एक cycle के अंतर से चलाया जाए और दूसरे CPU में recoverable interrupt inject किया जाए। फिर भी, अगर आपको MMU वाला, 32-bit instruction set और 24-bit address bus वाला CPU चाहिए था, तो लगता है यह उस समय के विकल्पों से सस्ता था। वाकई काफ़ी कठिन दौर रहा होगा
    • दिलचस्प है। छोटे loop buffer के मामले में मुझे GreenArrays forth core काफी पसंद है
      एक 18-bit word में 4 instructions फिट होते हैं, और एक opcode loop counter घटाने के बाद word की शुरुआत पर वापस चला जाता है। ऐसे में यह काफी तेज चल सकता है
    • 68010 का loop buffer लगभग बेकार था। वजह यह थी कि वह सिर्फ 6 bytes ही नहीं, बल्कि केवल दो instructions भी रखता था
      उनमें से एक loop instruction (DBcc) होना जरूरी था, इसलिए loop body एक ही instruction की होनी पड़ती थी। असल में जो चीज़ तेज हो सकती थी, वह लगभग सिर्फ unoptimized memcpy जैसी चीज़ थी

  • Cortex-A15 में यह core design feature है, यह दिलचस्प है। सोचता हूं कि दूसरे chips में इसके असर के आंकड़े हैं या नहीं
    console जैसे लंबी design life वाले devices में तो कम-से-कम इसे optimization target के रूप में इस्तेमाल किया जा सकता है

    • मुझे भी जिज्ञासा है। मेरा अनुमान है कि किसी भी RISC architecture में loop buffer से मिलने वाला फायदा अपेक्षाकृत छोटा होगा
      क्योंकि RISC का मुद्दा ही यह है कि instruction fetch और decode कहीं आसान, या लगभग मामूली, हो जाता है

  • मेरे पास 7950X3D है, जिसे मैंने Skylake 6700K से upgrade किया था। लगता है मैं अनजाने में ऐसे chips जिनमें hardware loop buffer software से disable किया गया हो की ओर खिंचता हूं

    • अगर कभी नई machine खरीदने वाले हो, तो पहले से बता देना। ताकि हम उससे बच सकें!

  • लेख दिलचस्प है, लेकिन मुझे नहीं पता कि loop buffer die पर कितनी जगह लेता है
    अगर भविष्य के chips में इसे हटा दिया जाए, तो सोचता हूं क्या उस जगह को बड़े L2 cache जैसी किसी ज्यादा उपयोगी चीज़ में लगाया जा सकता है

    • मेरी राय में ज्यादातर modern chips में floor area से ज्यादा wiring constraints बड़ी समस्या हैं। features तो बहुत सारे बनाए जा सकते हैं, लेकिन उन तक power और normalized signals पहुंचाना सचमुच बहुत मुश्किल काम है
    • मेरी समझ में यह frontend की काफी छोटी optimization है। शुरुआत से ही entries ज्यादा नहीं हैं—144—इसलिए बचने वाली जगह शायद मामूली होगी
      सिद्धांत रूप में loop buffer tight loops में power बचा सकता है या performance बढ़ा सकता है। व्यवहार में लगता है कि यह दोनों में से कुछ नहीं कर पा रहा, और AMD ने Zen 5 में इसे पूरी तरह हटा दिया
    • diagram देखने पर लगता है कि loop buffer वही storage space इस्तेमाल करता है जो वैसे भी मौजूद micro-op queue के लिए होता है
      अगर यह सही है, तो बात समझ में आती है, और area cost बस अतिरिक्त control logic जितनी है। सबसे महंगा हिस्सा शायद शुरुआत में loop detect करना होगा, लेकिन queue size की तुलना में वह भी काफी छोटा होगा
    • लिखा है कि प्रति core 144 micro-op entries हैं। यह नहीं पता कि कितने bytes हैं, लेकिन आजकल L2 cache प्रति core करीब 1MB होता है, इसलिए अगर मान भी लें कि loop buffer die space ज्यादातर storage है, तब भी कोई noticeable फर्क नहीं पड़ेगा

  • “power” section का analysis ऐसा लगता है जैसे उसे प्रति सेकंड execute हुई instructions की संख्या से divide नहीं किया गया
    इस loop buffer का फायदा देखने के लिए लगभग पक्का है कि प्रति सेकंड energy, यानी power (watts), नहीं बल्कि energy per instruction देखनी चाहिए

    • हर instruction में लगने वाले clock cycles अलग होते हैं, और Zen 4 से Zen 5 जैसी architecture generations के बीच भी बदलते हैं। इसलिए जब तक workload बिल्कुल वही instructions per cycle न बनाए, यह practically संभव नहीं है; और multithreading व task processing की वजह से यह असंभव है
      order और RAM contents तक सब कुछ बदल सकते हैं। enabled और disabled cases को सैकड़ों बार चलाकर कुछ हद तक अलग किया जा सकता है, लेकिन इसमें बहुत समय लगेगा और फिर भी 100% accurate नहीं होगा। सिर्फ feature बंद करने से भी code किसी अलग branch पर जा सकता है और सारी layout बदल सकती है। मैं इस specific issue को नहीं जानता, लेकिन ऐसे cases देखे हैं जहां feature बंद करने पर load integer unit से FPU या GPU पर shift हो गया, या 5 instructions गायब होने के बदले 2 instructions जुड़ गए