كيف يمكنني الحصول على عدد دورات وحدة المعالجة المركزية في Win32؟

Question

في Win32، هل هناك أي طريقة للحصول على عدد دورات وحدة المعالجة المركزية الفريدة أو شيء مشابه يكون موحدًا لعمليات/لغات/أنظمة متعددة/إلخ.

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

ومع ذلك، لا يزيد GetTickCount لكل مكالمة، لذلك لا يمكن الاعتماد عليه.هل هناك رقم أفضل حتى أتلقى المكالمات بالترتيب الصحيح عند الفرز؟

---

يحرر:شكرا ل @ جريج وهذا ما وضعني على المسار الصحيح للوصول إلى QueryPerformanceCounter، وهو ما أدى المهمة.

Answer 1

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

Answer 2

ها هي مقالة مثيرة للاهتمام! يقول عدم استخدام RDTSC، ولكن لاستخدامه بدلاً من ذلك الاستعلام عن أداء العداد.

خاتمة:

استخدام القديم العادي timeGetTime() للقيام بالتوقيت لا يمكن الاعتماد عليه على العديد من أنظمة التشغيل المستندة إلى Windows لأن تفريغ مؤقت النظام يمكن أن يصل إلى 10-15 ميلي ثانية ، وهذا يعني ذلك timeGetTime() دقيقة فقط إلى 10-15 ميلي ثانية.لاحظ أن الحبيبات العالية تحدث على أنظمة التشغيل المستندة إلى NT مثل Windows NT و 2000 و XP.يميل Windows 95 و 98 إلى الحصول على تفاصيل أفضل بكثير ، حوالي 1-5 مللي ثانية.

ومع ذلك، إذا اتصلت timeBeginPeriod(1) في بداية البرنامج (و timeEndPeriod(1) في نهايةالمطاف)، timeGetTime() عادة ما تصبح دقيقة إلى 1-2 ميلي ثانية ، وسوف توفر لك معلومات توقيت دقيقة للغاية.

Sleep() يتصرف بالمثل؛طول الوقت Sleep() في الواقع ينام يسير جنبا إلى جنب مع التفاصيل timeGetTime(), ، لذلك بعد الاتصال timeBeginPeriod(1) مرة واحدة، Sleep(1) سوف ينام بالفعل لمدة 1-2 ميلي ثانية ،Sleep(2) ل 2-3 ، وهلم جرا (بدلاً من النوم بزيادات تصل إلى 10-15 مللي ثانية).

لتوقيت الدقة العليا (دقة millisecond الفرعية) ، من المحتمل أن ترغب في تجنب استخدام RDTSC ذئية التجميع لأنه من الصعب المعايرة;بدلاً من ذلك، استخدم QueryPerformanceFrequency و QueryPerformanceCounter, ، وهي دقيقة إلى أقل من 10 ميكروثانية (0.00001 ثانية).

لتوقيت بسيط ، يعمل كل من TimegetTime و QueryperFormanceCounter بشكل جيد ، ومن الواضح أن QueryperFormanceCounter أكثر دقة.ومع ذلك ، إذا كنت بحاجة إلى القيام بأي نوع من "التوقف الموقت" (مثل تلك اللازمة للحد من الإطار) ، فيجب أن تكون حذراً في الجلوس في حلقة استدعاء queryperformancecounter ، في انتظار الوصول إلى قيمة معينة ؛هذا سوف يأكل ما يصل إلى 100 ٪ من المعالج الخاص بك.بدلاً من ذلك ، ضع في اعتبارك مخططًا هجينًا ، حيث تسمي Sleep (1) (لا تنسى timebeginperiod (1) أولاً!) كلما احتجت إلى تمرير أكثر من 1 مللي ثانية من الوقت ، ثم أدخل فقط QueryperformanceCounter انتهى من آخر <1/1000 من ثانية من التأخير الذي تحتاجه.سيمنحك هذا تأخيرات دقيقة للغاية (دقيقة إلى 10 ميكروثانية) ، مع الحد الأدنى من استخدام وحدة المعالجة المركزية.انظر الرمز أعلاه.

Answer 3

يقوم System.Diagnostics.Stopwatch.GetTimestamp() بإرجاع عدد دورات وحدة المعالجة المركزية منذ أصل زمني (ربما عند بدء تشغيل الكمبيوتر، لكنني لست متأكدًا) ولم أره مطلقًا لم يزد بين مكالمتين.

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

Answer 4

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

استخدم وقت النظام، وإذا كنت تتعامل مع خلاصات من أنظمة متعددة، فاستخدم مصدر وقت NTP.يمكنك الحصول على قراءات زمنية موثوقة ومتسقة بهذه الطريقة؛إذا كانت النفقات العامة أكثر من اللازم بالنسبة لأغراضك، فاستخدم HPET لحساب الوقت المنقضي منذ آخر قراءة زمنية موثوقة معروفة أفضل من استخدام HPET وحده.

Answer 5

استخدم GetTickCount وأضف عدادًا آخر أثناء دمج ملفات السجل.لن يمنحك تسلسلًا مثاليًا بين ملفات السجل المختلفة، ولكنه سيحتفظ على الأقل بجميع السجلات من كل ملف بالترتيب الصحيح.