حول سجلات القناع

تضمنت مجموعة التعليمات AVX-512 ثمانية ما يسمى سجلات القناع [1] - من k0 [2] إلى k7 . وهي مناسبة للاستخدام مع معظم عمليات ALU وتسمح لك بإجراء عمليات القناع على عناصر المتجه مع صفر أو دمج البيانات في سجل الوجهة [3] ، وبالتالي تسريع الكود ، الأمر الذي يتطلب عمليات دمج إضافية في مجموعة تعليمات AVX2 والإصدارات السابقة .

إذا لم يكن ما سبق كافياً لجعلك متابعًا لعبادة سجلات القناع ، فسوف أقتبس مقتطفًا من مقالة ويكيبيديا ، والتي آمل أن تساعدك في اكتشافها في النهاية:
يمكن لمعظم أوامر AVX-512 استخدام قناع المعامل المقابل لأحد سجلات القناع 8 (k0 - k7). إذا تم استخدام سجل القناع كقناع التشغيل ، فإن سجل k0 يتصرف بشكل مختلف عن بقية تسجيلات القناع: في هذه الحالة ، يعمل بمثابة ثابت مشفر يشير إلى أن القناع لم يتم تطبيقه مع هذه العملية. ومع ذلك ، في العمليات الحسابية والمنطقية وعند كتابة القيم لإخفاء السجلات ، يتصرف k0 مثل سجل العمل العادي. في معظم الأوامر ، تُستخدم سجلات القناع كقناع يحدد العناصر التي يجب كتابتها في سجل الإخراج. يعتمد سلوك قناع المعامل على العلم: إذا تم تعيينه ، سيتم إعادة تعيين جميع العناصر غير المحددة (وضع " صفر " ، صفر) ، إذا لم يكن كذلك ، فإن جميع العناصر غير المحددة تحتفظ بحالتها السابقة (وضع الدمج ، الدمج ). وضع الدمج له نفس تأثير تعليمات الدمج .

بشكل عام ، تعد سجلات القناع [4] ابتكارًا مهمًا ، ولكن نادرًا ما يتم تذكرها على عكس ، على سبيل المثال ، سجلات الأغراض العامة ( eax ، rsi وغيرها) أو سجلات SIMD ( xmm0 ، ymm5 ، إلخ). في عروض Intel التقديمية ، التي توضح أحجام موارد الهندسة المعمارية الدقيقة ، لا يتم ذكر تسجيلات الأقنعة:

صورة

على حد علمي ، لم يتم أيضًا نشر معلومات حول حجم ملف السجل الفعلي ( ملف السجل الفعلي ، PRF ) لسجلات القناع. الآن سنقوم بإصلاحه.
استخدمت نسخة معدلة من الأداة لقياس حجم المخزن المؤقت لإعادة ترتيب الأوامر ( ROB ) ، الذي تم إنشاؤه ووصفه بواسطة Henry Wong [5] (يشار إليه فيما بعد باسم Henry). باستخدام هذه الأداة ، قام بحساب حجم الهياكل الموثقة وغير الموثقة للتنفيذ الاستثنائي في الهياكل السابقة. إذا لم تكن قد قرأت ملاحظة هنري ، فتوقف وارجع إليها. وسوف تنتظر مقالتي.

حسنا ، اقرأ؟ للضرر ، إليك ملخص لمقالة هنري:

ROB


يتم إدراج عدد من تعليمات الصابورة بين اثنين من تعليمات القراءة مع فقد ذاكرة التخزين المؤقت [6] - سيعتمد عددها الدقيق على مورد المعالج الذي نريد قياسه. إذا لم يكن هناك عدد كبير جدًا من أوامر الصابورة ، فستتم معالجة كل من أخطاء التخزين المؤقت بالتوازي ، وبالتالي فإن تداخلات التأخير الخاصة بها وستكون إجمالي وقت التنفيذ تقريبًا [7] نفس الوقت الذي يستغرقه في حالة عدم وجود ذاكرة تخزين مؤقت واحدة.

ومع ذلك ، إذا تجاوز عدد فرق الصابورة عتبة حرجة معينة ، فسيتم استنفاد المورد المقابل تمامًا وسيتوقف وضع الفرق في ROB قبل إصدار الأمر الثاني مع عدم وجود ذاكرة تخزين مؤقت. في هذه الحالة ، ستكون المعالجة المتوازية مستحيلة وسيضاعف إجمالي الوقت تقريبًا وقت إحدى هذه العمليات ، والذي سينعكس في الرسم البياني على أنه قفزة حادة.

أخيرًا ، يتم كتابة الاختبار بحيث تستخدم الفرق وحدة واحدة بالضبط من المورد الذي يتم فحصه - في هذه الحالة ، تشير ذروة الذروة على الرسم البياني إلى إجمالي حجمها. لذلك ، تستخدم الأوامر القياسية للأغراض العامة ، كقاعدة عامة ، سجلاً ماديًا واحدًا من سجلات PRF للأغراض العامة وبالتالي فهي مثالية لقياس حجم مورد معين.

حجم ملف التسجيل المادي لسجلات القناع


في هذا الاختبار ، سننفذ الأوامر التي تكتب القيمة لإخفاء التسجيلات لمعرفة حجم PRF لهذه السجلات.

لنبدأ بسلسلة من الفرق kaddd k1 ، k2 ، k3 (يظهر 16 فريق صابورة):

mov    rcx,QWORD PTR [rcx]  ;    -
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
kaddd  k1,k2,k3
mov    rdx,QWORD PTR [rdx]  ;    -
lfence                      ;      ,    
                            ;   
;     16 

يستهلك كل أمر kaddd تسجيل قناع مادي واحد. إذا كان عدد أوامر الصابورة أقل من أو يساوي عدد سجلات القناع ، فستتم معالجة أخطاء التخزين المؤقت في الوضع المتوازي ، وإلا - في الوضع التسلسلي. لذلك ، عند التبديل من الوضع المتوازي إلى الوضع التسلسلي ، يجب أن نرى قفزة حادة على الرسم البياني ، مما يشير إلى زيادة في وقت التنفيذ.

هذا هو بالضبط ما نلاحظه:

صورة

دعونا نلقي نظرة فاحصة على الارتفاع:

صورة

كما نرى الآن ، فإن القفزة ليست حادة للغاية : مع عدد أوامر الصابورة من 130 إلى 134 ، تأخذ سرعة التنفيذ قيمًا متوسطة بين المستويات الدنيا والقصوى. يصف هنري هذا السلوك بأنه غير كامل؛ لقد لاحظت ذلك في العديد من هذه الاختبارات ، وإن لم يكن في جميع. والحقيقة هي أن تنفيذ الأجهزة لا يسمح دائمًا بالاستنفاد الكامل للمورد لأنه يقترب من الحد [8] - في بعض الحالات ينجح ذلك ، وفي حالات أخرى لا يوجد سوى عدد قليل من الفرق المفقودة إلى الحد الأقصى النظري.
في هذا الصدد ، نحن مهتمون بنقطة الصعود قبل الأخيرة ، حيث لا تزال السرعة أعلى من الوضع البطيء. تشير هذه النقطة إلى عدد وحدات الموارد المتاحة لنا ، مما يعني أن هناك على الأقل العديد من السجلات المادية. كما ترون ، في هذه الحالة يبلغ حوالي 134.

وبالتالي ، لدى SKX 134 تسجيلًا ماديًا قادرًا على تخزين قيم المضاربة (التي يتم الحصول عليها بالتنفيذ الاستباقي) لسجلات القناع. يقترح هنري استخدام 8 أخرى لتخزين الحالة المعمارية الحالية لثمانية سجلات قناع ، لذلك يمكن تقدير الكمية الكاملة من PRF عند 142. وهذا أصغر قليلاً من حجم الملفات للسجلات العامة (180) وسجلات SIMD (168) ، ولكن لا يزال كثيرًا جدًا (انظر جدول أحجام الموارد للتنفيذ غير العادي لمنصات أخرى).

لنفترض أن هذا الملف كبير بما فيه الكفاية بحيث لا يتوفر لدينا من الناحية العملية الوقت لاحتلاله بالكامل: من الصعب تخيل رمز حقيقي حيث يكتب 60٪ تقريبًا [9] من الأوامر [10] لإخفاء السجلات - أي أن الكثير منها سيكون مطلوبًا لاستنفاد هذا المورد .

هل هذه ملفات التسجيل المختلفة؟


كما لاحظت ، لقد افترضت حتى الآن بشكل افتراضي أن PRFs لتسجيل القناع هو ملف منفصل لا يتقاطع مع أنواع أخرى من ملفات التسجيل. أعتقد أن هذا مرجح جدًا استنادًا إلى مبدأ تشغيل سجلات القناع وحقيقة أنها جزء من مجال منفصل لإعادة تسمية التسجيل [11]. حجة أخرى لصالح افتراض بلدي هو حقيقة أن الحجم الملحوظ من سجلات قناع PRF لا يتطابق مع حجم ملف التسجيل للأغراض العامة أو ملف تسجيل SIMD. في الواقع ، يمكننا أخذ هذا واختباره باختبار!

هذا الاختبار مشابه للاختبار السابق ، ولكنه الآن أوامر kadddسوف يتناوب مع الأوامر التي تستخدم إما سجلات الأغراض العامة أو سجلات SIMD. إذا تم دمج سجلات القناع مع الأول أو الثاني في نفس ملف التسجيل ، فيجب أن تشير القفزة في الرسم البياني إلى حجم PRF المقابل. إذا لم يتم دمج ملفات التسجيل ، فسوف نواجه بعض الحدود الأخرى ، والتي لن تكون مساوية لحجم أي من ملفي التسجيل ، ولكنها ستكون مساوية ، على سبيل المثال ، لحجم ROB.

في الاختبار 29 ، تكون أوامر kaddd وأوامر إضافة العددية بديلاً :

mov    rcx,QWORD PTR [rcx]
add    ebx,ebx
kaddd  k1,k2,k3
add    esi,esi
kaddd  k1,k2,k3
add    ebx,ebx
kaddd  k1,k2,k3
add    esi,esi
kaddd  k1,k2,k3
add    ebx,ebx
kaddd  k1,k2,k3
add    esi,esi
kaddd  k1,k2,k3
add    ebx,ebx
kaddd  k1,k2,k3
mov    rdx,QWORD PTR [rdx]
lfence

ننظر إلى الرسم البياني:

صورة

كما ترون ، فإن عدد فرق الصابورة ، التي تمثل الذروة ، أكبر من أحجام سجلات الأغراض العامة PRF وسجلات القناع. من هذا نستنتج أن سجلات القناع ليست مدرجة في ملف التسجيل للأغراض العامة.

ثم ربما يتم تضمينها في ملف تسجيل SIMD؟ بعد كل شيء ، ترتبط سجلات القناع بأوامر SIMD أكثر من أوامر الأغراض العامة.

لمعرفة ذلك ، سنستخدم الاختبار 35 ، وهو مطابق للاختبار 29 مع الاختلاف في أن أوامر kaddd هنا تتناوب مع أوامر vxorps :

mov    rcx,QWORD PTR [rcx]
vxorps ymm0,ymm0,ymm1
kaddd  k1,k2,k3
vxorps ymm2,ymm2,ymm3
kaddd  k1,k2,k3
vxorps ymm4,ymm4,ymm5
kaddd  k1,k2,k3
vxorps ymm6,ymm6,ymm7
kaddd  k1,k2,k3
vxorps ymm0,ymm0,ymm1
kaddd  k1,k2,k3
vxorps ymm2,ymm2,ymm3
kaddd  k1,k2,k3
vxorps ymm4,ymm4,ymm5
kaddd  k1,k2,k3
mov    rdx,QWORD PTR [rdx]
lfence

الرسم البياني:

صورة

في هذا الاختبار ، لوحظ نفس السلوك كما في السابق ، لذلك نستنتج أن ملفات التسجيل الخاصة بسجلات القناع وسجلات SIMD مفصولة أيضًا.

سر لم يتم حله


ومع ذلك ، في كلا الاختبارين ، تقع نهاية الذروة عند حوالي 212 أمرًا ، في حين أن حجم ROB لهذه العمارة الدقيقة هو 224. ربما هذا مجرد سلوك غير كامل لاحظناه سابقًا؟ حسنًا ، دعنا نتحقق من ذلك: قارن نتائج هذين الاختبارين مع نتائج الاختبار 4 ، حيث يتم استخدام أوامر nop فقط كأوامر الصابورة : باستثناء ROB ، يجب ألا تستهلك أي موارد أخرى. قارن الرسوم البيانية للاختبار 4 ( nop ) والاختبار 29 ( kaddd and scalar add البديل ):

صورة

في الاختبار 4تقع بداية الوضع البطيء تمامًا عند علامة 224 (صور متجهة ، بحيث يمكنك زيادتها ومشاهدتها بنفسك). اتضح أن 212 (من هذه النقطة يبدأ الوضع البطيء عند تسجيل القناع بالتناوب مع السجلات العامة أو سجلات SIMD) - هذا هو الحد من بعض الموارد الأخرى. في الواقع ، نواجه نفس التقييد حتى عندما نتبادل السجلات العامة وسجلات SIMD - قارن الاختبار 4 والاختبار 21 (يجمع بين إضافة السجلات العامة وأوامر SIMD vxorps ):

صورة

في مقالتك ، تحت بنفس العنوان ("الغموض الذي لم يتم حله") ، يصف هنري نفس التأثير ، ولكنه أكثر وضوحًا:
, AVS SSE Sandy Bridge 147 , ROB. (, , AVX- , NOP-), , SSE/AVX, , - , 147, – , .
لمزيد من التفاصيل ، أحيلك إلى مقالة هنري. نلاحظ تأثيرًا مشابهًا ، ولكن أقل وضوحًا: نتمكن على الأقل من احتلال 95 ٪ من حجم ROB ، لكننا ما زلنا لا نستنفدها تمامًا. ربما ترتبط مجموعة السجلات المشتركة الغامضة بآلية إطلاقها ، على سبيل المثال ، جدول PRRT [12] ، الذي يتتبع السجلات المتاحة للإصدار بعد اكتمال الأمر.

أخيرًا ، دعنا نتحدث عن بعض الميزات الأخرى لسجلات القناع والتحقق مما إذا كانت آليات التحسين المتاحة لسجلات الأغراض العامة وسجلات SIMD قابلة للتطبيق عليها.

استبدال نسخة


للأغراض العامة أو أوامر SIMD ، يمكن تطبيق ما يسمى إزالة الحركة . مع هذا التحسين، وسجل آلية إعادة تسمية يسمح بعدم تنفيذ الأوامر التي نسخ قيمة من سجل واحد إلى آخر، على سبيل المثال EAX وسائل التحقق ، EDX أو vmovdqu ymm1 ، ymm2 - بدلا من ذلك ، فإن وجهة السجل هو "ببساطة" [13] إعادة تعيين إلى السجل مصدر في RAT، الذي يسمح لك بالاستغناء عن ALU.

تحقق مما إذا كان استبدال النسخة قابلاً للتطبيق ، على سبيل المثال ، الأمر kmov k1 ، k2 . أولاً ، انظر إلى الرسم البياني للاختبار 28 ، حيث kmovd k1 هو فريق الصابورة ،k2 :
صورة
يبدو هذا الرسم البياني تمامًا كما في الاختبار 27 الذي تمت مناقشته سابقًا مع أوامر kaddd . لذلك ، من المنطقي أن نفترض أنه يتم ملء السجلات المادية ، ما لم نستنفد عن طريق الخطأ بعض الموارد الأخرى المستخدمة عند استبدال نسخة تتصرف بنفس الحجم ولها نفس الحجم [14].

نجد تأكيدًا إضافيًا على موقع الويب uops.info: يشير إلى أن جميع متغيرات أمر نسخ kmov بين سجلات القناع تحتل عملية واحدة صغيرة يتم تنفيذها على المنفذ p0 . إذا كانت هناك نسخة بديلة ، فلن نلاحظ أي نشاط على الموانئ.
من هذا استنتج أن أوامر النسخ التي تستخدم سجلات القناع [15] لم يتم استبدالها.

التعابير الإدمان


أفضل طريقة لإلغاء تسجيل الأغراض العامة في بنية x86 هي استخدام لغة OR حصرية (xor): xor reg ، reg . يعتمد عملها على حقيقة أن مقارنة أي قيمة مع نفسها باستخدام هذه العملية تؤدي إلى صفر. هذا الأمر أقصر (يأخذ أقل بايت) من eax mov الأكثر وضوحًا ، 0 ، وأسرع أيضًا ، لأن المعالج يدرك أنه لغة إعادة تعيين وينفذ إعادة التسمية اللازمة للسجلات [16] ، مما يلغي الحاجة إلى ALU وتحميل المنفذ.

علاوة على ذلك ، هذا المصطلح يزيل تبعيات البيانات: عادة ما تكون نتيجة الأمر xor reg1 ، reg2يعتمد ذلك على القيم الموجودة في تسجيلات reg1 و reg2 ، ولكن في الحالة الخاصة عندما تحتوي reg1 و reg2 على نفس القيمة ، لا يوجد اعتماد ، نظرًا لأن أي قيم إدخال سيكون الناتج صفرًا. تعترف جميع معالجات x86 الحديثة بهذه الحالة الخاصة [17]. وينطبق الشيء نفسه على إصدارات xor idiom التي تستخدم سجلات SIMD ، وهي عمليات vpxor على الأعداد الصحيحة وعمليات vxorps و vxorpd على الأعداد الحقيقية.
هنا، قارئ غريبة قد نسأل: هل هذا عمل لغة مماثلة مع المتغيرات من قيادة kxor ؟ على سبيل المثال ، هل يعتبر الأمر kxorb k1 و k1 و k1 [18] إعادة تعيين لغة؟
في الواقع ، هذان سؤالان مختلفان ، لأن تأثير استخدام لغة إعادة التعيين يتكون من مكونين:

  • تنفيذ بدون تأخير يتجاوز وحدة التنفيذ ( إلغاء التنفيذ )
  • القضاء على التبعية

سنتعامل مع كل سؤال على حدة.

تنفيذ الاستبدال


لذا ، هل يمكن استبدال الأوامر باستخدام xor ، على سبيل المثال kxorb k1 ، k1 ، k1 ، بإعادة تعيين السجلات دون وضعها في وحدة التنفيذ؟

لا.

لست مضطرًا حتى إلى القيام بأي شيء بنفسي لإثبات ذلك: كل المعلومات موجودة على موقع uops.info على الويب ، حيث أجروا مثل هذا الاختبار وأظهروا أن هذا الأمر يتم تنفيذه بتأخير دورة ساعة واحدة ويأخذ عملية دقيقة واحدة على المنفذ p0 . ويترتب على ذلك أن مصطلحات xor لإعادة ضبط التسجيلات لا تعمل.

القضاء على التبعية


لكن ماذا لو كانت إعادة ضبط التعابير باستخدام kxor لا تزال تقضي على تبعيات البيانات ، حتى إذا كانت تتطلب وضعًا في وحدة التنفيذ؟

هنا لن يساعدنا uops.info. يحتوي الأمر kxor على تأخير لدورة ساعة واحدة ويتم تنفيذه على منفذ واحد ( p0 ) ، وبالتالي هناك حالة مثيرة للاهتمام (؟) يتم فيها تنفيذ سلسلة أوامر kxor بنفس السرعة ، بغض النظر عما إذا كانت هناك تبعيات بينها أم لا: عرض النطاق الترددي القدرة 1 القيادة / الدورة تعطي نفس الأداء انخفاض الأداء / دورة 1!

لا شيء ، لا يزال لدينا بعض الحيل في المخزون. سيساعدنا الاختبار التالي في الإجابة على هذا السؤال. تضمين kxorفي سلسلة من الأوامر ، حيث يعتمد كل أمر لاحق على الأمر السابق ، ويجب أن يكون إجمالي وقت التنفيذ لهذه السلسلة كبيرًا بما يكفي لتشكيل اختناق. إذا لم يلغي الأمر kxor التبعية ، فسيكون إجمالي وقت تنفيذ السلسلة مساوياً لمجموع تأخيرات الأوامر المكونة لها. إذا اختفى الاعتماد ، تنقسم السلسلة إلى تسلسل أقصر ، وتتداخل تأخيراتها ، ومن ثم ستكون سرعة تنفيذها محدودة ببعض القيمة الحدية للإنتاجية (المرتبطة ، على سبيل المثال ، بالمنافسة على المنافذ ). يمكن إظهار ذلك بوضوح باستخدام المخطط ، لكنني لست قويًا في ذلك.

كل هذه التجارب يمكن العثور عليها في المؤشر uarch مقاعد البدلاءولكن النقاط الرئيسية التي سأعطيها أدناه.

أولاً ، قم بقياس وقت النسخ القياسي من السجل العام والعكس صحيح:

kmovb k0, eax
kmovb eax, k0
;   127 

يتم تنفيذ زوج من هذه الأوامر [19] في 4 مقاييس. من غير المعروف بالضبط كم من الوقت يمر على كل منهما: مقياسان أو مقياس واحد ، و 3 مقاييس على الآخر [20]؟ ومع ذلك ، بالنسبة لمهمتنا ، هذا غير ذي صلة ، لأننا مهتمون بالوقت الإجمالي للنسخ ذهابًا وإيابًا. من الجدير بالذكر أن عرض النطاق الترددي لهذا التسلسل هو دورة ساعة واحدة ، وهي أسرع 4 مرات من التأخير ، حيث يتم تنفيذ كل أمر على المنفذ الخاص به ( p5 و p0 ، على التوالي). هذا يعني أنه يمكننا فصل تأثير التأخير عن تأثير عرض النطاق الترددي.

بعد ذلك ، في سلسلتنا ، نقوم بتضمين الأمر kxor ، والذي يضمن ألا يؤدي إلى إعادة تعيين الحالة:

kmovb k0, eax
kxorb k0, k0, k1
kmovb eax, k0
;   127 

نظرًا لأننا نعرف أن kxorb لديه تأخير لدورة ساعة واحدة ، يجب أن يزيد إجمالي وقت التنفيذ إلى 5 دورات - وهذا هو ما يظهره الاختبار (يتم عرض نتائج أول اختبارين):

**   avx512 :  AVX512 **
                                       
mov  GP  kreg                    4.00         1.25
mov  GP  kreg   + 
kxorb                              5.00         1.57

وأخيرًا ، الاختبار الرئيسي:
kmovb k0, eax
kxorb k0, k0, k0
kmovb eax, k0
;   127 

هذه المرة نستخدم الأمر kxorb مع إعادة تعيين الحالة: kxorb k0 ، k0 ، k0 . إذا اختفى الاعتماد على القيمة في السجل k0 ، فهذا يعني أن الأمر kmovb eax، k0 لم يعد يعتمد على الأمر kmovb k0 السابق ، الأمر eax وأن السلسلة قد انهارت وأن وقت التنفيذ الإجمالي يجب أن ينخفض.

لفة الطبل ...

حصلنا على نفس الإجراءات 5.0 - كما في المثال السابق:

**   avx512 :  AVX512 **
                                     
mov  GP  kreg                   4.00         1.25
mov  GP  kreg   + 
kxorb                             5.00         1.57
mov  GP  kreg   + 
kxorb                             5.00         1.57

الاستنتاج الأولي هو: لا يعترف المعالج بالتعريفات المعاد ضبطها إذا تم تطبيقها على سجلات القناع.

في الختام ، سنجري اختبارًا آخر للتأكد من صحة منطقنا: نستبدل الأمر kxor بالأمر kmov ، الذي ، كما تعلم ، دائمًا ما يزيل التبعيات:

kmovb k0, eax
kmovb k0, ecx
kmovb eax, k0
;   127 

يتم عرض الإجابة النهائية أدناه. الاختبار الأخير أسرع بكثير - فقط دورتان للساعة ، والاختناق هو المنفذ p5 ( يتم تنفيذ كل من أوامر kmov k و r32 على هذا المنفذ فقط):

**   avx512 :  AVX512 **
                                       
mov  GP  kreg                   4.00            1.25
mov  GP  kreg   + 
kxorb                             5.00            1.57
mov  GP  kreg   + 
kxorb                             5.00            1.57
mov  GP  kreg   + 
mov  GP                                  2.00            0.63

اتضح أن افتراضنا صحيح.

نتائج التشغيل


يمكنك إعادة إنتاج جميع النتائج المقدمة في هذه المقالة بنفسك عن طريق تشغيل الملف القابل للتنفيذ بحجم robsize على Linux أو Windows (ضمن WSL). كما أنها متوفرة في المستودع ، وكذلك النصوص لجمعها ورسمها.

الموجودات


  • توجد سجلات قناع بنية SKX في ملف تسجيل مادي منفصل ؛ تم تصميم 134 منهم لتخزين قيم المضاربة ، إجمالي عدد سجلات القناع هو 142
  • هذا الرقم مشابه لأحجام ملفات التسجيل من الأنواع الأخرى ، وكذلك المخزن المؤقت ROB ، وهو كبير بما يكفي لعدم مواجهة انخفاض في الأداء عند العمل مع تسجيلات القناع
  • لا يتم استبدال أوامر النسخ بسجلات القناع
  • [21]

  1. k- kregs – -. , k – «» (m) «» (f).
  2. ( AVX-512 ), k0 – , , , . : k0 – , , , k, SIMD-, (, AVX-512). SIMD- k0 , .
  3. , -, 0, , . , , , , - - .
  4. « », kreg – ( k0, k1 ..), – «kreg» « » ( ).
  5. H. Wong, Measuring Reorder Buffer Capacity, May, 2013. [Online]. (. , « », 2013. -.) : blog.stuffedcow.net/2013/05/measuring-rob-capacity
  6. 100 300 . , - 2 50 100 , – 2,5 (, 2 5 ). TLB-/ .
  7. «» . , , . . , 29 104, , – , 200. , ( ) – , - ( ), .
  8. , , , (register alias table, RAT), . RAT , , , , . RAT , , .
  9. 60% 134 224, .. PRF ROB. , ROB 224 , , , [10] 60% , ROB. , - , 60% , ROB, .
  10. , , . , (, SIMD- ), . [2]
  11. , . , 2 2 SIMD- ( ), 4 .
  12. Physical Register Reclaim Table ( ) Post Retirement Reclaim Table ( ).
  13. – , « », .. , , . , . : , .
  14. , ( 7) , PRF ROB.
  15. , , , . , ( , , , – ).
  16. RAT , RAT , , .
  17. xor, , sub reg,reg sbb reg, reg. , reg 0 -1 ( ) . , reg, – , . .
  18. , : kxorb k1, k1, k1 , kxorb k1, k2, k2.
  19. , ,

    ./uarch-bench.sh --test-name=avx512/*. 

  20. uops.info kmov r32, k, kmov k, 32 <= 3. , 4 . 1 , , 3 .
  21. , xor, , , -, , . , : , .

All Articles