مواد پر جائیں

AVX

آرکیٹیکچر کا حوالہFeex

AVX، Advanced Vector Extensions، YMM رجسٹرز اور VEX-encoded ہدایات کے ساتھ ایک ویکٹر پروگرامنگ ماڈل کا اضافہ کرتا ہے، بشمول 256-bit فلوٹنگ پوائنٹ آپریشنز۔ پروسیسر کی سپورٹ اور آپریٹنگ سسٹم کے اسٹیٹ مینجمنٹ دونوں کی ضرورت ہوتی ہے۔

آپ کے لیے جاننا کیا ضروری ہے

AVX، Advanced Vector Extensions، YMM رجسٹرز اور VEX-encoded ہدایات کے ساتھ ایک ویکٹر پروگرامنگ ماڈل کا اضافہ کرتا ہے، بشمول 256-bit فلوٹنگ پوائنٹ آپریشنز۔ پروسیسر کی سپورٹ اور آپریٹنگ سسٹم کے اسٹیٹ مینجمنٹ دونوں کی ضرورت ہوتی ہے۔

یہ کیسے کام کرتا ہے

AVX ویکٹر رجسٹرز کو 256 بٹس تک بڑھاتا ہے، جس میں ہر YMM رجسٹر کے نچلے 128 بٹس اس کے XMM رجسٹر کے ساتھ اوورلیپ ہوتے ہیں۔ بہت سی ہدایات تین اوپیرانڈ کی شکل استعمال کرتی ہیں، جس سے آؤٹ پٹ کو ان پٹس سے مختلف ہونے کی اجازت ملتی ہے۔ ایک 256-bit ویکٹر سنگل پریسیشن کی 8 یا ڈبل پریسیشن کی 4 فلوٹنگ پوائنٹ ویلیوز رکھ سکتا ہے، لیکن ہدایات اپنے اوپیرانڈ کی اقسام اور رویے میں مختلف ہوتی ہیں۔

یہ کہاں مفید ہے

ایک عددی لوپ ایک ویکٹر ہدایت کے ساتھ کئی آزاد فلوٹنگ پوائنٹ اقدار کو شامل کر سکتا ہے۔ کمپائلر یا لائبریری کو وہ کوڈ تیار کرنا چاہیے اور لوڈز، الائنمنٹ، ٹیلز اور انحصارات کو درست طریقے سے ترتیب دینا چاہیے۔ AVX خود بخود کسی بھی پروگرام کو کورز میں متوازی نہیں بناتا ہے، اور 256 بٹس پر انٹیجر آپریشنز کے لیے AVX2 کو فرض کرنے کے بجائے متعلقہ ایکسٹینشن کی جانچ کی ضرورت ہوتی ہے۔

سپورٹ اور فعالی کی جانچ کیسے کریں

CPUID.01H:ECX AVX بٹ 28، XSAVE بٹ 26 اور OSXSAVE بٹ 27 کو چیک کریں۔ صرف OSXSAVE کی تصدیق کے بعد ہی سافٹ ویئر ECX=0 کے ساتھ XGETBV کا استعمال کر سکتا ہے اور تصدیق کر سکتا ہے کہ XCR0 بٹس 1 اور 2 XMM اور YMM اسٹیٹ کو فعال کرتے ہیں۔ شناخت کے تجربے کے طور پر AVX پر عمل درآمد کرنے کے بجائے ایک برقرار رکھے گئے رن ٹائم ڈسپیچر کا استعمال کریں۔

پروگرام میں مناسب عمل درآمد ہونا چاہیے اور رن ٹائم پر اسے منتخب بھی کرنا چاہیے۔ ہارڈ ویئر کا تعین، OS کی فعال کردہ رجسٹر اسٹیٹ اور بائنری کی مرتب کردہ بیس لائن الگ الگ جانچ ہیں۔ ایک ورچوئل مشین جان بوجھ کر اپنے میزبان کے مقابلے میں کم خصوصیات ظاہر کر سکتی ہے، اور ایک کنٹینر میزبان CPU میں ہدایات کا اضافہ نہیں کرتا ہے۔

یہ خصوصیت کیا ثابت نہیں کرتی

صرف AVX سپورٹ کا مطلب AVX2، FMA، F16C، AVX-VNNI یا AVX-512 نہیں ہے۔ ویکٹر کی چوڑائی یہ نہیں بتاتی کہ ایک ہدایت کتنے سائیکل لیتی ہے۔ ایک ورچوئل مشین فزیکل ہوسٹ کے مقابلے میں ہدایات کا ایک چھوٹا سیٹ ظاہر کر سکتی ہے۔

عملی طور پر مطابقت اور کارکردگی

نمائندہ ڈیٹا کے ساتھ مکمل ورک لوڈ کی پیمائش کریں۔ وسیع تر ویکٹرز میموری ٹریفک، ہم وقت سازی یا تبدیلی کے اخراجات کو تبدیل کیے بغیر ہدایات کی تعداد کو کم کر سکتے ہیں۔ ہدایت کی تاخیر، تھرو پٹ اور پاور کا رویہ مخصوص مائیکرو آرکیٹیکچر اور آپریٹنگ حالات پر منحصر ہوتا ہے۔

عملی تصدیقی چیک لسٹ

  1. پروسیسر یا پلیٹ فارم کا اصل ماڈل اور شامل ایپلی کیشن، OS اور رن ٹائم کے ورژنز ریکارڈ کریں۔ اصل خرابی یا ضرورت کے الفاظ کو جوں کا توں محفوظ رکھیں۔
  2. اس مخصوص ماڈل کے لیے مینوفیکچرر کے حوالے کو چیک کریں، پھر اس ماحول میں مؤثر صلاحیت اور فعال حالت کا معائنہ کریں جہاں پروگرام چلتا ہے۔
  3. منتخب کردہ بائنری یا بیک اینڈ کی ہر ضرورت کا موازنہ کریں۔ ملتے جلتے نام کی خصوصیت، عرفیت یا وسیع ٹیکنالوجی لیبل کافی نہیں ہے۔
  4. تصدیق کریں کہ ایپلی کیشن نے مطلوبہ عمل درآمد کا انتخاب کیا ہے۔ اس کی دستاویزی تشخیص اور معاون متبادل کا استعمال کریں جب ضروریات پوری نہ ہوں۔
  5. ایک وقت میں ایک معاون تبدیلی کریں اور وہی ورک لوڈ دہرائیں۔ اصل کنفیگریشن اور بحالی کا راستہ دستیاب رکھیں۔

اگر خصوصیت درج ہے لیکن سافٹ ویئر اسے استعمال نہیں کر سکتا

فیل ہونے والے اصل جزو سے شروعات کریں۔ ہارڈ ویئر ڈیٹا بیس ریکارڈ شدہ صلاحیت کو بیان کرتا ہے؛ آپریٹنگ سسٹم یا ہائپروائزر ایک مختلف مؤثر ماحول فراہم کر سکتا ہے۔ ایک غیر قانونی ہدایت کی خرابی (illegal-instruction error) میں بھی اصل خرابی پیدا کرنے والی ہدایت اور بائنری بلڈ کی تحقیقات کی ضرورت ہوتی ہے، کیونکہ کرپشن یا ایک غیر متعلقہ غیر معاون ہدایت ایسی ہی علامت پیدا کر سکتی ہے۔

مخصوص پلیٹ فارم کے لیے معاونت یافتہ ایپلی کیشن، ڈرائیور یا رن ٹائم ورژن انسٹال کریں، اور اگر ضرورت ہو تو وینڈر کا دستاویزی بنیادی یا فال بیک بلڈ استعمال کریں۔ سافٹ ویئر اپ ڈیٹ ایسی ہدایت تیار نہیں کر سکتا جس کی پروسیسر میں کمی ہو۔ فرم ویئر اور سیکیورٹی پالیسی کی تبدیلیوں کو عام اصلاحی طریقے کے بجائے سسٹم مینوفیکچرر کے طریقہ کار اور بحالی کے منصوبے پر عمل کرنا چاہیے۔

اس وضاحت کے ذرائع اور دائرہ کار

Intel 64 and IA-32 Architectures Software Developer's Manual · Linux kernel: user space میں XSTATE خصوصیات کا استعمال

یہ حوالہ جات آرکیٹیکچرل رویے اور سافٹ ویئر کی ضروریات کو قائم کرتے ہیں۔ وہ لنک شدہ ہارڈ ویئر ماڈل کے صفحے پر ہر خصوصیت کی قدر کی آزادانہ طور پر تصدیق نہیں کرتے ہیں۔ ماڈل کی سپورٹ کے لیے، اس صفحے کے مینوفیکچرر کے ثبوت استعمال کریں اور مؤثر سسٹم کنفیگریشن چیک کریں۔ یہ مضمون بینچ مارک، سرٹیفیکیشن یا آزادانہ جائزے کی تاریخ فراہم نہیں کرتا ہے۔

ذرائع اور توثیق

ادارتی ملکیت: Feex۔ آزادانہ جائزے کی کوئی تاریخ ریکارڈ نہیں کی گئی ہے۔ ہم تحقیق کیسے کرتے ہیں.

  • Intel 64 and IA-32 Architectures Software Developer's Manual · جلد 1 اور 2 نامزد انسٹرکشن فیملیز اور CPUID کی وضاحت کرتی ہیں؛ جلد 3 اسٹیٹ، پیجنگ، VMX اور پروٹیکشن کنٹرولز کی وضاحت کرتی ہے۔ آرکیٹیکچر کی دستاویزات کسی خاص ماڈل کے لیے سپورٹ کا تعین نہیں کرتیں۔
  • Linux kernel: user space میں XSTATE خصوصیات کا استعمال · OS کے زیر انتظام ویکٹر اسٹیٹ، ڈائنامک طور پر فعال ٹائل اسٹیٹ، سگنل اسٹیک کی ضروریات اور AMX اجازت کا بہاؤ۔ Linux کا مخصوص رویہ کسی دوسرے OS کے بارے میں کوئی وعدہ نہیں ہے۔

کیا یہ مضمون مفید تھا؟

ہاں یا نہیں کافی ہے۔ اگر آپ چاہیں تو کوئی وجہ منتخب کریں، یا ایک مختصر نوٹ شامل کریں۔

کیا یہ مضمون مفید تھا؟