مدخل إلى إعدادات المعالج (CPU) لمطوّري تطبيقات Windows: الأولويّة، والانتماء (Affinity)، ونواة الأداء/نواة الكفاءة (P-core/E-core)

أداء تطبيقات Windows لا يتحدّد بالكود وحده. حتّى نفس ملفّ .exe، قد يختلف إحساس التشغيل باختلاف الحاسوب الذي يعمل عليه.

في حاسوب ما، تكون المعالجة الدوريّة مستقرّة.
وفي حاسوب آخر، تتأخّر أحياناً.
لا مشكلة عند التشغيل بالطاقة الكهربائيّة (AC)، لكنّه بطيء بشكل غريب عند التشغيل بالبطّاريّة.
رفعتَ الأولويّة في مدير المهامّ، لكنّه لم يصبح أسرع كما كنتَ تتوقّع.
ظننتَ أنّك حصرتَه في نواة الأداء (P-core)، لكن زمن المعالجة ما زال يتذبذب.
وعلى العكس، عند محاولة رفع الأداء، تستمرّ المروحة في الدوران وتصبح التطبيقات الأخرى بطيئة.

عند بناء تطبيقات Windows، تصادف ظواهر من هذا النوع «يصعب تفسيرها بالكود وحده».

الأشياء الأربعة التي نريد النظر إليها عندئذ هي:

وفي عالم Windows الحديث، تدخل في هذا الأمر أيضاً EcoQoS وميزة Efficiency mode في مدير المهامّ.

بعبارة أخرى، بيئة تنفيذ تطبيقات Windows ليست مجرّد «هل المعالج سريع أم بطيء».

متى يُنفَّذ
أين يُنفَّذ
على أيّ نوع من الأنوية يُنفَّذ
في أيّ حالة أداء يعمل المعالج
هل يراه نظام التشغيل «يُركِّز على الأداء» أم «يكفيه توفير الطاقة»

اجتماع كلّ هذه العناصر هو ما يحدِّد الاستجابة الفعليّة وزمن المعالجة.

في هذا المقال، نرتّب العلاقة بين الأولويّة والانتماء ونواة الأداء/نواة الكفاءة وإعدادات توفير الطاقة، وهي أمور يسهل إغفالها في تطوير تطبيقات Windows.

كما أنّ الكود الوارد في هذا المقال متاح على GitHub كمجموعة نماذج كاملة قابلة للبناء والتشغيل (مكتبة C# وعرض توضيحيّ للتعامل مع الأولويّة والانتماء، وسكربتات PowerShell، واختبارات وحدة).

windows-app-cpu-priority-affinity-power - komurasoft-blog-samples (GitHub)

1. الصورة الشاملة أوّلاً

بدايةً، هذه هي الصورة الشاملة في شكل رسم بيانيّ.

flowchart LR
  A["كود التطبيق"] --> B["مجدوِل Windows"]

  P["الأولويّة<br/>متى يُرجَّح تنفيذه"] --> B
  AF["الانتماء (Affinity) / CPU Sets<br/>على أيّ معالج يُسمَح بالتنفيذ"] --> B
  Q["QoS / EcoQoS<br/>التركيز على الأداء أم على توفير الطاقة"] --> B

  B --> C["اختيار الخيط المُراد تنفيذه"]
  C --> D["اختيار المعالج المنطقيّ المُراد التنفيذ عليه"]

  PE["نواة الأداء / نواة الكفاءة (P-core / E-core)<br/>هل يميل إلى الأداء أم إلى توفير الطاقة"] --> D
  PM["وضع الطاقة / خطّة الطاقة / PPM<br/>التردّد، والتعزيز (Boost)، وCore Parking"] --> D

  D --> R["الاستجابة الفعليّة<br/>زمن المعالجة<br/>الحرارة<br/>استهلاك البطّاريّة<br/>الأثر على التطبيقات الأخرى"]

المهمّ هو أنّ هذه العناصر ليست مستقلّة عن بعضها.

رفع الأولويّة يجعل التنفيذ أرجح.
لكن إن كان المعالج نفسه مضبوطاً بميل نحو توفير الطاقة، فقد لا يصبح سريعاً بالقدر المتوقَّع.

تضييق المعالج عبر الانتماء قد يقلِّل انتقال الخيوط.
لكن إن كانت الوجهة المُضيَّقة نواة تميل إلى توفير الطاقة، أو لم تتوافق مع Core Parking أو إدارة الطاقة، فقد يصبح الأمر عكسيّاً.

التوجّه نحو نواة الأداء قد يُسرِّع المعالجة الحسابيّة.
لكن إن وُجِّه كلّ شيء نحو الجانب عالي الأداء، تزداد الحرارة وضجيج المروحة واستهلاك البطّاريّة والأثر على العمليّات الأخرى.

ضبط أداء تطبيقات Windows ليس مجرّد «البحث عن زرّ للإسراع».

أيّ معالجة تريد تسريعها.
أيّ معالجة يمكن أن تكون بطيئة.
هل تُعطَى الأولويّة لاستجابة تفاعل المستخدم.
هل تُعطَى الأولويّة لزمن إنهاء المعالجة في الخلفيّة.
إلى أيّ حدّ تُقبَل البطّاريّة والحرارة.

هذا كلّه يتحوّل إلى مسألة تصميم.

2. الأولويّة هي «متى يُرجَّح التنفيذ»

في Windows، عندما توجد عدّة خيوط قابلة للتنفيذ، يقرِّر المجدوِل «أيّ خيط يُشغَّل على المعالج بعد ذلك». وهنا يظهر أثر الأولويّة.

تُحدَّد الأولويّة عموماً على مرحلتين.

فئة أولويّة العمليّة (process priority class)
  + الأولويّة النسبيّة للخيط
  = الأولويّة الأساسيّة للخيط

في Win32 API، توجد SetPriorityClass لجانب العمليّة، وSetThreadPriority لجانب الخيط.

لرؤية أولويّة عمليّة قيد التشغيل حاليّاً عبر PowerShell، يكون الأمر مثلاً كالتالي.

Get-Process -Id $PID | Select-Object Id, ProcessName, PriorityClass

لرفع أولويّة عمليّة PowerShell الحاليّة، يكون الأمر كالتالي.

$p = Get-Process -Id $PID
$p.PriorityClass = "AboveNormal"

في C#، يمكن كتابته كالتالي.

using System.Diagnostics;

using var process = Process.GetCurrentProcess();
process.PriorityClass = ProcessPriorityClass.AboveNormal;

ما نريد الانتباه إليه هنا هو أنّ الأولويّة ليست «إعداداً يُسرِّع المعالج». ما تتعلّق به الأولويّة هو أيّ خيط يُشغَّل أوّلاً عند وجود تنافس.

ليست إعداداً يرفع تردّد المعالج.
وليست إعداداً يختار نواة الأداء.
وليست إعداداً يُسرِّع الإدخال/الإخراج.
وليست إعداداً يُزيل انتظار الأقفال أو انتظار الشبكة.

لذلك، من الطبيعيّ حدوث «رفعتُ الأولويّة لكنّه لم يصبح أسرع». فمثلاً، إن كان سبب البطء أحد هذه الأمور، فرفع الأولويّة لا يحلّ المشكلة جوهريّاً.

• انتظار إدخال/إخراج القرص
• انتظار الشبكة
• انتظار استجابة قاعدة البيانات
• تنافس الأقفال (lock)
• توقّف GC
• انسداد خيط واجهة المستخدم
• انتظار من جانب GPU أو التعريف (driver)
• فحص الملفّات بواسطة برنامج مكافحة الفيروسات
• تردّد المعالج مكبوح نحو توفير الطاقة

كما أنّ HIGH_PRIORITY_CLASS وREALTIME_PRIORITY_CLASS ليسا شيئين يُستخدَمان باستخفاف.

الخيط الذي يعمل لفترة طويلة بأولويّة عالية يصعب عليه تسليم زمن المعالج لخيوط أخرى.
وإن اقتصر ذلك على تطبيقك وحده فلا بأس، لكنّه قد يُضعِف استجابة النظام بأكمله.

الأولويّة أشبه بالدواء.

تنفع في الموقف المناسب.
لكن ليس صحيحاً أنّ زيادة الجرعة أفضل.

ما ينبغي التفكير فيه قبل رفع الأولويّة

قبل رفع الأولويّة، توجد أمور نريد التفكير فيها أوّلاً.

المهمّ في تطبيقات Windows ليس العمل دائماً بأعلى أولويّة، بل إعطاء الأولويّة للمعالجة الضروريّة، في التوقيت الضروريّ، وللنطاق الضروريّ فقط.

3. الانتماء (Affinity) هو «أيّ معالج يُسمَح بالتنفيذ عليه»

إذا كانت الأولويّة تعني «متى يُرجَّح التنفيذ»، فإنّ الانتماء يعني «على أيّ معالج يُسمَح بالتنفيذ».

في Windows، يمكن تحديد مجموعة من المعالجات المنطقيّة القابلة للتنفيذ عليها لعمليّة أو خيط معيّن.

في Win32 API، توجد SetProcessAffinityMask للعمليّة، وSetThreadAffinityMask للخيط.

لرؤية انتماء عمليّة عبر PowerShell، يكون الأمر مثلاً كالتالي.

Get-Process -Id $PID | Select-Object Id, ProcessName, ProcessorAffinity

لغرض التحقّق، إن أردتَ حصر عمليّة PowerShell الحاليّة في أوّل 4 معالجات منطقيّة، يمكن كتابته كالتالي.

$p = Get-Process -Id $PID
$p.ProcessorAffinity = [IntPtr]0xF

0xF هو 1111 بالنظام الثنائيّ.
أي أنّه يعني السماح بالمعالجات المنطقيّة من 0 إلى 3.

لكن هذا مجرّد مثال لغرض التحقّق فقط.

تضييق الانتماء قد يُحسِّن محليّة ذاكرة تخزين المعالج المؤقّت (CPU cache)، وقد يقلِّل تذبذب المعالجة الدوريّة في بعض الحالات.
لكن في المقابل، فإنّه يحبس الخيط في مكان ضيّق، بينما كان بإمكان Windows في الأصل أن يُهرِّبه إلى معالج فارغ.

يلزم الحذر خصوصاً في البيئات التالية.

• اختلاط نواة الأداء ونواة الكفاءة (P-core/E-core)
• عدم وضوح التطابق بين المعالجات المنطقيّة والأنوية الفيزيائيّة بسبب SMT/Hyper-Threading
• بنية NUMA
• تدخّل Processor Group عند تجاوز 64 معالجاً منطقيّاً
• تفعيل Core Parking
• تحكّم قويّ في الطاقة من طرف OEM أو BIOS
• التشغيل داخل بيئة افتراضيّة

الانتماء إعداد يفرض قيداً قويّاً على النظام يقول «شغِّل على هذا المعالج فقط».

القيد يمكن أن يكون أداة استقرار.
لكن الخطأ فيه يسدّ مسارات الهروب.

توجد الآن CPU Sets أيضاً

قناع الانتماء (affinity mask) التقليديّ قيد قويّ جدّاً.

في المقابل، توجد في Windows آليّة تُسمَّى CPU Sets.
CPU Sets هي واجهة برمجيّة (API) تتيح لجانب التطبيق التعبير عن رغبته في المعالج بشكل أكثر ليونة.

في شرح مايكروسوفت، تُوضَع CPU Sets في مرتبة تحديد انتماء «ناعم (soft)» متوافق مع إدارة طاقة نظام التشغيل.

هل تريد تثبيت المعالج بدقّة صارمة؟
أم تريد فقط توجيه موضع التنفيذ تقريباً بالتعاون مع إدارة الطاقة والجدولة في نظام التشغيل؟

هذا الفرق مهمّ.

بدل محاولة حلّ كلّ شيء بـ SetProcessAffinityMask التقليديّة، يلزم في تطبيقات Windows الحديثة التفكير في CPU Sets وQoS أيضاً.

4. نواة الأداء/نواة الكفاءة: قصّة «للمعالج شخصيّته أيضاً»

في المعالجات الحديثة، ليست كلّ الأنوية بالضرورة بنفس الأداء ونفس استهلاك الطاقة. النموذج الأبرز هو نواة الأداء (P-core) ونواة الكفاءة (E-core)، وباختصار، نواة الأداء تميل إلى الأداء، ونواة الكفاءة تميل إلى الكفاءة.

لكن من الخطر أن يجزم المطوِّر باستخفاف بأنّ «المعالجات 0-7 هي نواة الأداء، و8-15 هي نواة الكفاءة». قد يختلف ترتيب أرقام المعالجات باختلاف المعالج وBIOS وإصدار Windows والبرامج الثابتة (firmware) وإعدادات OEM وبيئة الافتراضيّة.

من جانب Windows، توجد في معلومات CPU Sets فكرة تُسمَّى EfficiencyClass.
وهي قيمة تُظهِر خصائص كفاءة ذلك الـ CPU Set في نظام يحمل معالجات غير متجانسة. في وثائق مايكروسوفت، يُشرَح أنّه كلّما ارتفعت هذه القيمة، كان الـ CPU Set يحمل معالجاً أسرع لكن كفاءته في الطاقة أقلّ.

إن أردتَ التعامل مع نواة الأداء/نواة الكفاءة، فمجرّد النظر إلى رقم المعالج لا يكفي. إن أردتَ التدقيق فعلاً، تلزم ملاحظات من هذا النوع.

• النظر إلى EfficiencyClass عبر CPU Sets API
• رؤية المعالج الذي نُفِّذ عليه الخيط عبر Windows Performance Recorder / Analyzer
• رؤية الاتّجاه عبر عرض المعالجات المنطقيّة في مدير المهامّ
• قياس زمن المعالجة لكلّ جهاز فعليّ
• المقارنة بين حالة التشغيل بالطاقة الكهربائيّة وحالة البطّاريّة
• المقارنة عند تغيير وضع الطاقة

نواة الأداء/نواة الكفاءة ليست مجرّد مواصفة عتاديّة، بل يتحدَّد موضع التنفيذ الفعليّ باجتماعها مع مجدوِل Windows وQoS وإعدادات توفير الطاقة.

5. إعدادات توفير الطاقة تتعلّق بـ«إلى أيّ مدى يُدار المعالج بجدّيّة»

هذه النقطة مهمّة جدّاً في الميدان.

الأولويّة هي «أيّ خيط يُشغَّل أوّلاً».
والانتماء هو «على أيّ معالج يُسمَح بالتشغيل».
ونواة الأداء/نواة الكفاءة هي «هل هذا المعالج يميل إلى الأداء أم إلى توفير الطاقة».

أمّا إعدادات توفير الطاقة فتتعلّق بـ

إلى أيّ تردّد وحالة طاقة يُدار المعالج أصلاً

بعبارة أخرى، يحدث الآتي.

رفعتَ الأولويّة.
وجّهتَ نحو نواة الأداء.
لكن إن كانت إعدادات الطاقة تميل إلى توفير الطاقة،
فقد لا يعمل المعالج بجدّيّة.

هذه قصّة تُشبه Windows إلى حدّ بعيد.

في Windows 11، يمكن اختيار وضع الطاقة من تطبيق الإعدادات عبر «النظام > الطاقة والبطّاريّة». تختلف التسمية باختلاف البيئة والإصدار، لكنّ الاتّجاه العامّ يكون هكذا تقريباً.

كما توجد في خطط الطاقة التقليديّة Power Saver وBalanced وHigh Performance.
تُعدِّل Balanced الأداء واستهلاك الطاقة حسب الطلب، بينما تميل High Performance نحو تحقيق أقصى أداء مقابل استهلاك الطاقة.

حتّى وإن كان الإعداد الذي يراه المستخدم بسيطاً، توجد خلف الكواليس إعدادات إدارة طاقة المعالج (Processor Power Management، اختصاراً PPM).

6. P-state، وC-state، والتعزيز (Boost)، وEPP

لا يعمل المعالج دائماً بأقصى تردّد، بل تمتلك المعالجات حالات لخفض استهلاك الطاقة.

P-state آليّة تُخفِّض استهلاك الطاقة بتغيير تردّد المعالج وجهده الكهربائيّ.
وC-state آليّة يوقِف فيها المعالج بعض وظائفه عند الخمول ليدخل حالة توفير طاقة أعمق.

تستخدم إدارة الطاقة في Windows هذه الآليّات لتحقيق توازن بين الأداء واستهلاك الطاقة.

لذلك يمكن أن تحدث ظاهرة «أولويّة عالية لكنّه بطيء».

يُنفَّذ الخيط بأولويّة.
لكن تردّد المعالج منخفض.
ويصعب دخول التعزيز.
وEPP يميل إلى توفير الطاقة.
والأنوية المتاحة مُقيَّدة عبر Core Parking.
ونظام التشغيل بأكمله يعمل بميل نحو توفير الطاقة أثناء التشغيل بالبطّاريّة.

في مثل هذه الحالات، لا يمكن الوصول إلى السبب بالنظر إلى الأولويّة وحدها.

خصوصاً في المعالجة الدوريّة، ومعالجة الصور، والتحكّم بأجهزة القياس، ومعالجة الفيديو، ومعالجة الصوت، والتقاط كاميرا USB، والاتّصال التسلسليّ (serial)، لا تكون المشكلة زمن المعالجة المتوسّط فقط، بل «التأخّر أحياناً».

المتوسّط سريع.
لكن مرّة واحدة فقط من كلّ 1000 مرّة يحدث تأخّر.
وتلك المرّة الواحدة تُسبِّب انسداد المخزن المؤقّت (buffer).
وتتجمّد واجهة المستخدم.
ويختلّ التوقيت مع الجهاز.

في هذه الظواهر، لا يكفي متوسّط نسبة استخدام المعالج وحده.

يلزم النظر معاً إلى توزيع زمن المعالجة، والقيمة القصوى، والقيم الشاذّة (outliers)، وحالة الطاقة، والمعالج المُنفَّذ عليه، وحمل الخلفيّة.

7. يتعلّق Core Parking بـ«عدد الأنوية القابلة للاستخدام»

توجد في Windows آليّة تُسمَّى Core Parking. وهي تحكّم يتّجه نحو إراحة المعالجات المنطقيّة غير المستخدَمة.
يُخفَض استهلاك الطاقة بتوجيه بعض الأنوية إلى حالة طاقة منخفضة عندما تكون نسبة الاستخدام منخفضة.

في وثائق مايكروسوفت، يُشرَح CPMinCores كإعداد يحدِّد الحدّ الأدنى لنسبة المعالجات المنطقيّة الواجب إبقاؤها un-parked، أي في حالة قابلة للاستخدام، في أيّ لحظة.
عند ضبط القيمة على 100%، تُعطَّل خوارزميّة Core Parking.

المشكلة التي تظهر هنا هي التركيب مع الانتماء.

قيَّدنا عبر الانتماء بـ«نريد التشغيل على مجموعة المعالجات هذه».
لكن كيفيّة معاملة تلك الأنوية من ناحية إدارة الطاقة مسألة منفصلة.

حتّى في الوثائق الموجَّهة لـ Windows Server، يُشرَح أنّه عندما يُحدَّد انتماء قويّ لخيط نشط إلى جزء من معالجات عقدة NUMA، توجد مواقف لا تتوافق مع قرار Core Parking.

هذا مرجع مفيد من ناحية الفكرة حتّى في حواسيب العميل المكتبيّة.

الانتماء يفرض قيداً على المجدوِل.
وCore Parking يتعلّق بـ«أيّ الأنوية تجعلها إدارة الطاقة قابلة للاستخدام».

التفكير في هذين الأمرين بشكل منفصل يؤدّي إلى الخطأ في تحديد السبب.

8. EcoQoS / Efficiency Mode هما آليّة لإبلاغ «يكفي أن تعمل هذه المعالجة بتوفير الطاقة»

في الماضي، كان الحديث عن ضبط أداء تطبيقات Windows يتمحور حول رفع الأولويّة أو خفضها، وتغيير الانتماء. لكن في Windows الحديث، توجد فكرة مختلفة قليلاً، وهي QoS.

QoS، أي Quality of Service (جودة الخدمة)، هي فكرة تُظهِر للخيط «إلى أيّ مدى تُركِّز هذه المعالجة على الأداء، وإلى أيّ مدى تُركِّز على توفير الطاقة».

في وثائق مايكروسوفت، يُشرَح أنّ أولويّة الجدولة تبقى المؤشِّر الرئيسيّ الذي يحدِّد أيّ خيط يُنفَّذ بعد ذلك، بينما قد تؤثِّر QoS على اختيار النواة وإدارة طاقة المعالج.

على وجه الخصوص، EcoQoS آليّة لمعاملة المعالجة التي لا يكون الأداء فيها الأهمّ بميل نحو توفير الطاقة.

في C++، يمكن مثلاً استخدام SetThreadInformation وThreadPowerThrottling لجعل الخيط الحاليّ EcoQoS.

#include <windows.h>

void EnableEcoQoSForCurrentThread()
{
    THREAD_POWER_THROTTLING_STATE powerThrottling = {};
    powerThrottling.Version = THREAD_POWER_THROTTLING_CURRENT_VERSION;
    powerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
    powerThrottling.StateMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;

    SetThreadInformation(
        GetCurrentThread(),
        ThreadPowerThrottling,
        &powerThrottling,
        sizeof(powerThrottling));
}

وعلى العكس، عند العودة إلى التركيز على الأداء، اضبط StateMask إلى 0 لنفس هدف التحكّم.

void DisableEcoQoSForCurrentThread()
{
    THREAD_POWER_THROTTLING_STATE powerThrottling = {};
    powerThrottling.Version = THREAD_POWER_THROTTLING_CURRENT_VERSION;
    powerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED;
    powerThrottling.StateMask = 0;

    SetThreadInformation(
        GetCurrentThread(),
        ThreadPowerThrottling,
        &powerThrottling,
        sizeof(powerThrottling));
}

EcoQoS ليست ميزة تعني «اجعل كلّ شيء موفِّراً للطاقة». ما يناسبها، على سبيل المثال، هذه المعالجات.

• المزامنة في الخلفيّة
• إنشاء فهارس (index) بأولويّة منخفضة
• تجميع سجلّات غير مستعجِل
• تحديث تخزين مؤقّت لا يرتبط مباشرةً بتفاعل المستخدم
• معالجة صيانة يكفي أن تنتهي لاحقاً

في المقابل، ينبغي التزام الحذر مع هذه المعالجات.

• المعالجة المرتبطة مباشرةً بتفاعل واجهة المستخدم
• التقاط الكاميرا
• معالجة الصوت
• المعالجة المرتبطة بدورة التحكّم
• معالجة الحكم في أجهزة الفحص
• معالجة التصدير التي ينتظرها المستخدم
• المعالجة التي تحتاج استجابة قريبة من الزمن الحقيقيّ

ترتبط ميزة Efficiency mode في مدير المهامّ بهذه الفكرة أيضاً.
في مدوّنة Performance Diagnostics لمايكروسوفت، يُشرَح أنّه عند تفعيل Efficiency mode، تُخفَّض الأولويّة الأساسيّة للعمليّة إلى Low، وتُضبَط QoS إلى EcoQoS.

بعبارة أخرى، Efficiency mode ليست مجرّد «أيقونة توفير طاقة»، بل آليّة تجمع بين خفض الأولويّة وEcoQoS لحماية استجابة تطبيق المقدّمة وكفاءة الطاقة.

من منظور المطوِّر، هذا أمر مهمّ جدّاً.

لأنّه يمكن تصميم إبلاغ نظام التشغيل ليس فقط بـ«أريد أن تنتهي هذه المعالجة بسرعة»،
بل أيضاً بـ«يكفي أن تعمل هذه المعالجة ضمن نطاق لا يزعج المستخدم».

9. مخطّط تدفّق القرار

بما أنّ ما سبق معقَّد، نضع هنا مخطّط تدفّق القرار عند التحقيق في أداء تطبيقات Windows أو تذبذب الدوريّة.

flowchart TD
  A["الأعراض<br/>بطيء، تذبذب دوريّ، تجمّد واجهة المستخدم، ضجيج المروحة"] --> B["سجِّل أوّلاً<br/>زمن المعالجة / القيمة القصوى / نسبة استخدام المعالج / حالة الطاقة / AC أم بطّاريّة / الحاسوب المستهدَف"]
  B --> C{"هل المعالج هو السبب الرئيسيّ؟"}

  C -- "لا / غير معروف" --> D["تحقَّق من الإدخال/الإخراج، والأقفال، وقاعدة البيانات، والشبكة، وGC، وGPU، والتعريف (driver)<br/>أزِل زمن الانتظار قبل التفكير في الأولويّة أو الانتماء"]
  C -- "نعم" --> E{"هل التنافس مع عمليّات أخرى على المعالج قويّ؟"}

  E -- "نعم" --> F["ادرس رفع الأولويّة<br/>لكن حدِّد النطاق<br/>تجنَّب الاستخدام الدائم لـ High/Realtime"]
  E -- "لا" --> G{"هل هناك تحيّز إلى معالج معيّن؟"}

  G -- "نعم" --> H["تحقَّق من الانتماء / CPU Sets<br/>هل التثبيت مبالَغ فيه<br/>هل نُظِر إلى نواة الأداء/الكفاءة أو NUMA"]
  G -- "لا" --> I{"هل التردّد أو حالة الطاقة مشتبَه بها؟"}

  I -- "نعم" --> J["تحقَّق من وضع الطاقة / خطّة الطاقة / PPM<br/>اشتبه في P-state / EPP / التعزيز / Core Parking"]
  I -- "لا" --> K{"هل معالجة الخلفيّة تزعج معالجة المقدّمة؟"}

  K -- "نعم" --> L["ادرس EcoQoS / Efficiency Mode / خفض الأولويّة<br/>أبعِد المعالجة غير المستعجِلة نحو توفير الطاقة"]
  K -- "لا" --> M["راجع الخوارزميّة، ودرجة التوازي، وتصميم الطابور، وتصميم خيط واجهة المستخدم"]

  F --> N["غيِّر بندًا واحدًا في كلّ مرّة وقِس بأسلوب A/B"]
  H --> N
  J --> N
  L --> N
  M --> N

  N --> O["انظر إلى القيمة القصوى والقيم الشاذّة والحرارة والأثر على التطبيقات الأخرى<br/>وليس المتوسّط فقط"]

المهمّ في هذا التدفّق هو عدم العبث بالإعدادات من البداية. سجِّل أوّلاً.

• هل البطء دائم
• أم بطيء أحياناً
• AC أم بطّاريّة
• ما هو وضع الطاقة
• هل أصبح Efficiency mode مفعَّلاً في مدير المهامّ
• هل نسبة استخدام المعالج مرتفعة
• هل التردّد مرتفع
• أيّ خيط يستخدم المعالج
• ما هي القيمة القصوى لزمن المعالجة
• هل يتدخّل برنامج مقيم آخر أو برنامج مكافحة فيروسات

بعد ذلك، غيِّر عنصراً واحداً في كلّ مرّة.

غيِّر الأولويّة.
غيِّر الانتماء.
غيِّر وضع الطاقة.
أضِف EcoQoS.
افصل معالجة الخلفيّة.
أضِف طابوراً (queue).
أخرِجه من خيط واجهة المستخدم.

تغيير عدّة أمور في وقت واحد يجعل من غير الممكن معرفة ما الذي أثَّر فعلاً.

10. أوامر التحقّق في الميدان

عندما يختلف سلوك تطبيق Windows باختلاف البيئة، من المفيد أوّلاً إعداد إمكانيّة أخذ الحالة.

رؤية معلومات المعالج

Get-CimInstance Win32_Processor |
  Select-Object Name, NumberOfCores, NumberOfLogicalProcessors, MaxClockSpeed

رؤية خطّة الطاقة النشطة

powercfg /getactivescheme

رؤية إعدادات إدارة طاقة المعالج

powercfg /q SCHEME_CURRENT SUB_PROCESSOR

المُخرَج طويل جدّاً، لكن يمكن التحقّق من الإعدادات المتعلّقة بالحدّ الأدنى والأقصى لحالة المعالج، وEPP، والتعزيز، وCore Parking.
تختلف العناصر الظاهرة باختلاف البيئة.

إنشاء تقرير تشخيص كفاءة الطاقة

نُفِّذ في طرفيّة (terminal) بصلاحيّات المدير.

powercfg /energy

بعد قياس لفترة زمنيّة معيّنة، يُخرَج تقرير بصيغة HTML.
وهو مدخل لرؤية التعريفات (drivers)، والأجهزة، ودقّة المؤقّت (timer resolution)، وتوفير طاقة USB، وما يعيق النوم (sleep) وغيرها.

رؤية أولويّة العمليّة المستهدَفة وانتمائها

Get-Process -Name MyApp |
  Select-Object Id, ProcessName, PriorityClass, ProcessorAffinity

رؤية حالة أداء المعالج

تختلف أسماء العدّادات (counters) المتاحة باختلاف البيئة، لكنّ عدّادات الأداء (Performance Counter) هذه مفيدة كمرجع.

Get-Counter '\Processor Information(_Total)\% Processor Performance'

Get-Counter '\Processor Information(_Total)\% Processor Utility'

للنظر بشكل جدّيّ، الأضمن هو أخذ ETW عبر Windows Performance Recorder وWindows Performance Analyzer.
يمكن تتبّع تذبذب الدوريّة، وتبديل السياق (context switch)، والمعالج المُنفَّذ عليه، وDPC/ISR، وإدخال/إخراج القرص، وتغيّرات تردّد المعالج، كلّها معاً.

11. في المعالجة شبه الآنيّة (Soft Real-Time)، يجب التفكير في كلّ شيء معاً

Windows ليس نظام تشغيل آنيّ (Real-Time OS) بالمعنى العامّ. لكن تطبيقات Windows الميدانيّة أحياناً ما تُطلَب منها خصائص قريبة من الزمن الحقيقيّ.

• التقاط صور بدوريّة ثابتة من كاميرا USB
• التبادل مع جهاز عبر الاتّصال التسلسليّ (serial)
• قراءة بيانات من جهاز قياس
• المزامنة مع PLC أو جهاز خارجيّ
• معالجة الصوت أو الفيديو
• إعادة نتيجة الفحص خلال زمن محدَّد
• تشغيل حساب ثقيل دون تجميد واجهة المستخدم

في هذا النوع من المعالجة، لا تكفي سرعة الكود وحدها.

يلزم تصميم الخيوط.
ويلزم تصميم الطابور (queue).
ويلزم التسجيل (logging).
ويلزم المهلة الزمنيّة (timeout).
ويلزم الضغط الخلفيّ (backpressure).
ويلزم تحديد ما إذا كان يُتجاهَل عند التأخّر أم يُنتظَر أم تُعاد المحاولة.

وفوق ذلك، يلزم النظر إلى الأولويّة والانتماء ونواة الأداء/الكفاءة وإعدادات توفير الطاقة.

لنفكِّر مثلاً في خيط التقاط الكاميرا.

هذا الخيط قريب من تفاعل المستخدم، وله دوريّة أيضاً.
قد لا ينبغي جعله EcoQoS.
وقد تستحقّ رفع أولويّته قليلاً.
لكن إن رُفِعت كثيراً، يظهر أثر سلبيّ على واجهة المستخدم أو المعالجات الأخرى.
وقد يستقرّ بتثبيت انتمائه.
لكن إن كانت الوجهة المُثبَّتة تميل إلى نواة الكفاءة، فقد يكون الأثر عكسيّاً.
وإن كان وضع الطاقة يميل إلى توفير الطاقة، فقد يتأخَّر فقط عند التشغيل بالبطّاريّة.

في المقابل، ماذا عن معالجة ضغط السجلّات القديمة؟

قد تكون هذه معالجة لا ينتظرها المستخدم.
في هذه الحالة، اخفض الأولويّة.
واجعلها EcoQoS.
وشغِّلها عند الخمول (idle).
وشغِّلها فقط عند التشغيل بالطاقة الكهربائيّة (AC).
هذا التصميم أكثر لطفاً بالنسبة للتطبيق ككلّ.

بدل «تسريع» كلّ المعالجات، افصل بين المعالجة التي ينبغي تسريعها والمعالجة التي ينبغي ألّا تُزعِج.

12. المبادئ الأساسيّة للتصميم

توجد ستّة مبادئ أساسيّة عند التعامل مع هذه الأمور في تطبيقات Windows.

1. لا تُثبِّت من البداية

من الأفضل عدم تثبيت الأولويّة أو الانتماء بشكل قويّ من البداية.

يقوم مجدوِل Windows بعمل جيّد جدّاً في معظم الحالات.
فرض قيود زائدة من جانب التطبيق قد يجعل الأمر أسوأ عكسيّاً.

ابنِه بشكل عاديّ أوّلاً.
قِس.
عند ظهور مشكلة، ضع فرضيّة.
غيِّر بشكل صغير.
قِس مرّة أخرى.

هذا هو الترتيب.

2. استخدم الأولويّة مؤقّتاً

اقصر الأولويّة العالية على النطاق الضروريّ فقط.

بدل جعلها عالية باستمرار، فإنّ

رفعها مباشرةً قبل المعالجة المهمّة
وإعادتها بعد الانتهاء

أكثر أماناً.

3. ادرُس الانتماء في مرحلة متأخّرة

الانتماء إعداد قويّ.

قد يكون فعّالاً عند الاشتباه بتذبذب الدوريّة أو أثر انتقال المعالج.
لكنّه ليس الإعداد الذي يُمَسّ أوّلاً.

خصوصاً إن كانت حواسيب العملاء متعدّدة الأنواع، فإنّ الجزم بأرقام معالجات محدَّدة أمر خطير.

4. لا تجزم بنواة الأداء/الكفاءة، بل راقِبها

إن أردتَ التمييز بين نواة الأداء ونواة الكفاءة، راقِب أوّلاً على الجهاز الفعليّ.

بدل الجزم برقم المعالج، انظر عبر CPU Sets وEfficiencyClass وETW والقياس الفعليّ.

5. اختبِر مع افتراض إعدادات توفير الطاقة

لا يكفي القول إنّ جهاز التطوير سريع لأنّه يعمل بالطاقة الكهربائيّة وبإعدادات أداء عالية.

في بيئة العميل، توجد عادةً حالات من هذا النوع.

• حاسوب محمول يعمل بالبطّاريّة
• Best power efficiency
• Energy saver
• أداة توفير طاقة خاصّة بـ OEM
• إعدادات طاقة مثبَّتة بسياسة الشركة
• حاسوب رفيع تنخفض أداءه بسبب الحرارة
• جهاز عمل يحتوي على كثير من البرامج المقيمة

في اختبار الأداء، نريد على الأقلّ فصل الشروط بهذا القدر.

6. ادرُس EcoQoS لمعالجة الخلفيّة

المعالجة التي لا ترتبط مباشرةً بتجربة المستخدم، من الأفضل أحياناً إعطاء الأولويّة لعدم الإزعاج بدل السعي وراء الأداء.

التطبيق الذي يُشغِّل كلّ شيء بأداء عالٍ قد يكون سريعاً.
لكنّه يُزعِج الأعمال الأخرى.
ويُشغِّل مروحة الحاسوب المحمول.
ويستهلك البطّاريّة.
والنتيجة تطبيق يصعب استخدامه.

في تطبيقات Windows، الجودة ليست السرعة وحدها، بل «حسن التعايش» أيضاً.

13. سوء فهم شائع

رفع الأولويّة يجعله أسرع

لا يصبح أسرع بالضرورة.

قد ينفع إن كان السبب تنافساً على المعالج.
لكن إن كان السبب انتظار الإدخال/الإخراج، أو انتظار الأقفال، أو انخفاض التردّد بسبب توفير الطاقة، أو التنفيذ على نواة الكفاءة، فالأولويّة وحدها لا تكفي.

التثبيت على نواة الأداء هو الصواب دائماً

ليس صواباً دائماً.

نواة الأداء عالية الأداء، لكن الحرارة واستهلاك الطاقة يزدادان أيضاً.
كما توجد احتماليّة تنافسها مع معالجة أخرى مهمّة في المقدّمة.

الأهمّ هو الفصل بين المعالجة التي ينبغي توجيهها نحو نواة الأداء والمعالجة التي تكفيها نواة الكفاءة.

إعدادات توفير الطاقة تفضيل للمستخدم ولا علاقة لها بالتطبيق

لها علاقة.

حتّى نفس التطبيق، تختلف طريقة تنفيذه باختلاف وضع الطاقة، وخطّة الطاقة، وEPP، والتعزيز، وCore Parking.

خصوصاً في الحواسيب المحمولة، يختلف السلوك بين الطاقة الكهربائيّة والبطّاريّة.

Efficiency mode تُبطئ فقط لا أكثر

ليست مجرّد إبطاء لا أكثر.

هي آليّة لحماية استجابة تطبيق المقدّمة وكفاءة الطاقة عبر خفض الأولويّة وEcoQoS.
بل تستحقّ التفكير فيها بشكل إيجابيّ لمعالجة الخلفيّة غير المستعجِلة.

السبب في عدم الاستقرار هو Windows نفسه

هذه أيضاً نظرة سطحيّة.

Windows ليس نظام تشغيل آنيّاً.
لكن مع فهم الجدولة وإدارة الطاقة وQoS والقياس والتسجيل وتصميم الخيوط، يمكن تحقيق استقرار كافٍ للاستخدام الميدانيّ.

المشكلة ليست «مستحيل لأنّه Windows»، بل عدم النظر إلى أيّ طبقة يحدث فيها ماذا.

14. صمِّم السجلّات قبل التنفيذ

هذا النوع من المشاكل قد يحدث فقط في بيئة العميل. لذا من المفيد إعداد التطبيق ليترك حدّاً أدنى من معلومات التشخيص.

على سبيل المثال، أخرِج هذه المعلومات في سجلّ التشخيص.

• إصدار التطبيق
• إصدار Windows
• اسم المعالج
• عدد المعالجات المنطقيّة
• AC أم بطّاريّة
• متوسّط زمن المعالجة وقيمته القصوى والمئينات (percentiles)
• عدد مرّات تأخّر دوريّة المعالجة
• أولويّة الخيط المستهدَف
• أولويّة العمليّة
• وجود إعداد الانتماء من عدمه
• وجود إعداد EcoQoS من عدمه
• خطّة الطاقة عند بدء التشغيل
• عدد مرّات انتهاء مهلة المعالجة المستهدَفة

عندما يُقال لدى العميل «بطيء أحياناً»، فإن لم يوجد أيّ تسجيل، يصبح الأمر لعبة تخمين. أمّا مع وجود السجلّات، فيمكن وضع فرضيّات.

بطيء فقط عند البطّاريّة
بطيء فقط على حاسوب معيّن
بطيء فقط مباشرةً بعد بدء التشغيل
بطيء بعد 30 دقيقة
بطيء فقط أثناء تشغيل تطبيق آخر
ظهور قيم شاذّة بدوريّة ثابتة

إذا ظهرت هذه الفروق، يسهل الفصل بين كون السبب الأولويّة، أو الانتماء، أو إعدادات الطاقة، أو الحرارة، أو انتظاراً آخر.

15. منظور Komura Soft

في تطوير تطبيقات Windows، لا تكفي النظريّة الأنيقة وحدها.

يجب أن يعمل على حاسوب العميل.
ويجب أن يعمل على الجهاز الميدانيّ.
ويجب أن يتعايش مع أجهزة طرفيّة قديمة.
ويجب أن يعمل في بيئة تحتوي برنامج مكافحة فيروسات وطابعة وسياسة داخليّة للشركة.
ويجب ألّا ينهار حتّى مع إعدادات توفير الطاقة في الحاسوب المحمول.
ويجب أن يُحقِّق الأداء المطلوب فعليّاً حيث يلزم الأداء.
ويجب ألّا يُزعِج المستخدم في المعالجة غير المستعجِلة.

لتحقيق ذلك، من الأفضل عدم النظر إلى Windows كمجرّد «نظام تشغيل صندوق أسود».

يفكِّر Windows في كيفيّة تشغيل الخيوط.
ويفكِّر في أيّ معالج يُشغَّل عليه.
ويوازن بين الطاقة والأداء.
ويتعامل مع أنوية غير متجانسة كنواة الأداء ونواة الكفاءة.
ويحاول التمييز بين تطبيق المقدّمة ومعالجة الخلفيّة.

على المطوِّر ألّا يُقاوم ذلك، بل أن يُبلِّغ عن نيّته حيث يلزم الأمر.

هذه المعالجة تُبقي المستخدم منتظِراً.
وهذه المعالجة يمكن أن تكون بطيئة قليلاً.
وهذه المعالجة تهمّ فيها الدوريّة.
وهذه المعالجة يكفي أن تعمل بهدوء في الخلفيّة.
وهذه المعالجة يجب ألّا تُزعِج معالجة أخرى.

يُترجَم هذا التصميم إلى فهم الأولويّة والانتماء وQoS وإعدادات توفير الطاقة.

16. الخلاصة

أداء تطبيقات Windows لا يتحدّد بالكود وحده.

حتّى مع رفع الأولويّة، إن كان الانتماء يميل نحو نواة الكفاءة، فقد لا يعمل كما هو متوقَّع.
وحتّى مع التوجّه نحو نواة الأداء، إن كان وضع الطاقة يميل إلى توفير الطاقة، فقد لا يُحقِّق المعالج أقصى أداء.
وفرض انتماء قويّ دون التفكير في CPU Sets أو QoS قد يسدّ مسارات هروب إدارة طاقة Windows ومجدوِله.
وتوجيه كلّ شيء نحو الأداء العالي يزيد الحرارة وضجيج المروحة واستهلاك البطّاريّة والأثر على التطبيقات الأخرى.

في تطوير تطبيقات Windows، يلزم التصميم ليشمل ليس فقط السرعة، بل الاستجابة والاستقرار واستهلاك الطاقة والحرارة والتعايش مع العمليّات الأخرى أيضاً.

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

الأولويّة
الانتماء (Affinity)
نواة الأداء / نواة الكفاءة (P-core / E-core)
إعدادات توفير الطاقة

وفي Windows الحديث، يُضاف إلى ذلك EcoQoS وEfficiency mode.

توجد أمور كثيرة تستحقّ القلق.

لكن ليس من الضروريّ إبقاء القلق قلقاً محضاً.

حوِّل القلق إلى قياس.
وحوِّله إلى سجلّات.
وحوِّله إلى تصميم.
وحوِّله إلى شروط اختبار.

عندئذ، لن يكون Windows بيئة تنفيذ متقلّبة، بل منصّة ميدانيّة تستحقّ المراقبة الجادّة.

Windows ليس نظام تشغيل آنيّاً.
ومع ذلك، بفهم بيئة التنفيذ وتصميمها، يمكن بناء تطبيق يمكن الاعتماد عليه ميدانيّاً بشكل كافٍ.

وتلك الصعوبة بالذات هي ما يجعل تطوير تطبيقات Windows ممتعاً.

المراجع

• هذا رابط مجموعة الأكواد النموذجيّة لهذا المقال (C# / PowerShell / اختبارات وحدة) - komurasoft-blog-samples (GitHub)
• Scheduling Priorities - Microsoft Learn
• SetProcessAffinityMask function - Microsoft Learn
• SetThreadAffinityMask function - Microsoft Learn
• CPU Sets - Microsoft Learn
• SYSTEM_CPU_SET_INFORMATION structure - Microsoft Learn
• Change the power mode for your Windows PC - Microsoft Support
• Power Policy Settings - Microsoft Learn
• P-states and C-States - Microsoft Learn
• Processor power management options - Microsoft Learn
• CPMinCores - Microsoft Learn
• Quality of Service - Microsoft Learn
• SetThreadInformation function - Microsoft Learn
• Reduce Process Interference with Task Manager Efficiency Mode - Microsoft DevBlogs

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

كيف تُضبَط أولويّة المعالج (CPU)؟

تُحدَّد الأولويّة على مرحلتين: فئة أولويّة العمليّة (process priority class) والأولويّة النسبيّة للخيط. في Win32 API توجد SetPriorityClass لجانب العمليّة وSetThreadPriority لجانب الخيط. في PowerShell يمكن ضبط الخاصّيّة PriorityClass للكائن المُستلَم عبر Get-Process إلى قيمة مثل "AboveNormal"، وفي C# يُسنَد ProcessPriorityClass.AboveNormal إلى PriorityClass الخاصّة بـ Process.GetCurrentProcess(). لكن ينبغي تجنّب الاستخدام الدائم لـ HIGH_PRIORITY_CLASS أو REALTIME_PRIORITY_CLASS لأنّه يُضعِف استجابة النظام بأكمله.

لماذا لا يُصبح التطبيق أسرع بعد رفع الأولويّة؟

لأنّ الأولويّة إعداد يحدِّد «أيّ خيط يُشغَّل أوّلاً عند وجود تنافس»، وليست إعداداً يُسرِّع المعالج. إن كان سبب البطء انتظار إدخال/إخراج القرص، أو انتظار الشبكة، أو تنافس الأقفال (lock)، أو توقّف GC، أو انسداد خيط واجهة المستخدم، أو فحص برنامج مكافحة الفيروسات، أو انخفاض تردّد المعالج بسبب إعدادات توفير الطاقة، فإنّ رفع الأولويّة لا يحلّ المشكلة جوهريّاً. المهمّ أوّلاً هو تسجيل توزيع زمن المعالجة، وحالة الطاقة، والمعالج الفعليّ الذي نُفِّذَت عليه العمليّة، لعزل السبب.

ماذا يحدث عند ضبط EcoQoS عبر SetThreadInformation؟

عند تحديد ThreadPowerThrottling وTHREAD_POWER_THROTTLING_EXECUTION_SPEED في SetThreadInformation، يمكن إبلاغ نظام التشغيل بمعاملة ذلك الخيط كـ EcoQoS (جودة خدمة (QoS) تميل إلى توفير الطاقة). بما أنّ QoS قد يؤثِّر على اختيار النواة وإدارة طاقة المعالج، يمكن إبعاد معالجات مثل المزامنة في الخلفيّة أو تجميع السجلّات غير المستعجِل إلى الجانب الموفِّر للطاقة دون إزعاج التطبيق في المقدّمة. في المقابل، ينبغي التزام الحذر مع المعالجات المرتبطة مباشرةً بتفاعل واجهة المستخدم، والتقاط الكاميرا، والمعالجات المتعلّقة بدورة التحكّم. يمكن العودة إلى التركيز على الأداء بضبط StateMask إلى 0.

ما هو CPMinCores في powercfg؟

CPMinCores إعداد طاقة متعلّق بميزة Core Parking في Windows، ويحدِّد الحدّ الأدنى لنسبة المعالجات المنطقيّة (logical processors) الواجب إبقاؤها un-parked (في حالة قابلة للاستخدام) في أيّ لحظة. عند ضبط القيمة على 100%، تُعطَّل خوارزميّة Core Parking. يمكن التحقّق من الإعداد الحاليّ بتنفيذ powercfg /q SCHEME_CURRENT SUB_PROCESSOR بصلاحيّات المدير، وعند تضييق المعالجات عبر الانتماء (Affinity) قد لا يتوافق ذلك مع قرار Core Parking في بعض المواقف، لذا يلزم النظر إلى الاثنين معاً.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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