所以我一直在研究一個復雜應用程式的源代碼（由數百名程式員撰寫）。除此之外，我還創建了一些時間檢查功能，以及合適的資料結構來測量主回圈不同部分的執行周期，并對這些測量結果進行一些分析。
這是一個有助于解釋的偽代碼：
main()
{
TimeSlicingSystem::AddTimeSlice(0);
FunctionA();
TimeSlicingSystem::AddTimeSlice(3);
FuncitonB();
TimeSlicingSystem::AddTimeSlice(6);
PrintTimeSlicingValues();
}
void FunctionA()
{
TimeSlicingSystem::AddTimeSlice(1);
//...
TimeSlicingSystem::AddTimeSlice(2);
}
FuncitonB()
{
TimeSlicingSystem::AddTimeSlice(4);
//...
TimeSlicingSystem::AddTimeSlice(5);
}
PrintTimeSlicingValues()
{
//Prints the different between each slice, and the slice before it,
//starting from slice number 1.
}
大多數測量都是非常合理的，例如為區域變數分配一個值將花費不到幾分之一微秒。大多數函式將在幾微秒內從開始到結束執行，很少達到一毫秒。
I then ran a few tests for half an hour or so, and I found some strange results that I couldn't quite understand. Certain functions will be called, and when measuring the time from the moment of calling the function (last line in 'calling' code) to the first line inside the 'called' function will take a very long time, up to a 30 milliseconds period. That's happening in a loop that would otherwise complete a full iteration in less than 8 milliseconds.
To get a picture of that, in the pseudocode I included, the time period between the slice number 0, and the slice number 1, or the time between the slice number 3, and the slice number 4 is measured. This the sort of periods I am referring to. It is the measured time between calling a function, and running the first line inside the called function.
QuestionA. Could this behavior be due to thread, or process switching by the OS? Does calling a function is a uniquely vulnerable spot to that? The OS I am working on is Windows 10.
Interestingly enough, there was never a last line in a function returning to the first line after the call in the 'calling' code problem at all ( periods from slice number 2 to 3 or from 5 to 6 in pseudocode)! And all measurements were always less than 5 microseconds.
QuestionB. Could this be, in any way, due to the time measurement method I am using? Could switching between different cores gives an allusion of slower than actually is context switching due to clock differences? (although I never found a single negative delta time so far, which seems to refute this hypothesis altogether). Again, the OS I am working on is Windows 10.
我的時間測量功能看起來是這樣的：
FORCEINLINE double Seconds()
{
Windows::LARGE_INTEGER Cycles;
Windows::QueryPerformanceCounter(&Cycles);
// add big number to make bugs apparent where return value is being passed to float
return Cycles.QuadPart * GetSecondsPerCycle() 16777216.0;
}
uj5u.com熱心網友回復：
問題A。這種行為可能是由于執行緒或作業系統的行程切換造成的嗎？
是的。執行緒切換可以在任何時候發生（例如，當設備發送一個 IRQ 導致另一個更高優先級的執行緒立即解除阻塞并搶占您的執行緒時），這可能/將導致您的執行緒出現意外的時間延遲。
呼叫函式是一個獨特的脆弱點嗎？
呼叫你自己的函式并沒有什么特別的地方，這使得它們特別容易受到攻擊。如果函式涉及內核的 API，則更有可能發生執行緒切換，并且某些事情（例如呼叫“ sleep()”）幾乎肯定會導致執行緒切換。
還有與虛擬記憶體管理的潛在互動——通常事物（例如你的可執行檔案、你的代碼、你的資料）使用“記憶體映射檔案”，第一次訪問它可能會導致作業系統從磁盤（以及你的執行緒可以被阻塞，直到它想要的代碼或資料從磁盤到達）；并且很少使用的代碼或資料也可以發送到交換空間并需要獲取。
問題 B。無論如何，這可能是由于我使用的時間測量方法嗎？
在實踐中，Windows 很可能QueryPerformanceCounter()是用一條RDTSC指令（假設 80x86 CPU/s）實作的，根本不涉及內核，而對于現代硬體來說，這很可能是單原子的。理論上，Windows 可以模擬RDTSC和/或QueryPerformanceCounter()以另一種方式實作以防止安全問題（定時側通道），正如英特爾 30 年來一直推薦的那樣，但這不太可能（現代作業系統，包括但不限于 Windows ，往往更關心性能而不是安全性）；從理論上講，您的硬體/CPU 可能太舊（大約 10 多年前）以至于 Windows 必須以QueryPerformanceCounter()不同的方式實作，或者您可能正在使用其他一些 CPU（例如 ARM 而不是 80x86）。
換一種說法; 您使用的時間測量方法不太可能（但并非不可能）導致任何計時問題。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/445026.html