Windows：スリープ（0.5）

おそらく多くの人が知っているように、 スリープ状態にしたいミリ秒数は、WinAPIのSleep関数に渡されます。 したがって、要求できる最小値は1ミリ秒間スリープ状態になります。 しかし、さらに睡眠を減らしたい場合はどうでしょうか？ 写真でこれを行う方法に興味がある人は、猫の下で歓迎します。



まず、Windowsは（他の非リアルタイムシステムと同様に）スレッド（スレッドと呼ばれることもある）が要求された時間に正確にスリープすることを保証しないことを思い出します。 Vista以降、OSのロジックは単純です。 実行のためにスレッドに割り当てられた一定の時間があります（はい、はい、2000 / XPの間に誰もが聞いたのと同じ20ミリ秒であり、それでもサーバーの軸でそれを聞きます） また、Windowsは、このクォンタムが期限切れになった後にのみ、スレッドを再スケジュール（一部のスレッドを停止、他のスレッドを開始）します。 つまり OSのクォンタムが20ミリ秒（XPのデフォルトはそのような値など）である場合、 スリープ（1）を要求したとしても、最悪の場合、同じ20ミリ秒後に制御が返されます。 この時間単位 、特にtimeBeginPeriod / timeEndPeriodを管理するためのマルチメディア機能があります。



第二に、このような正確さが必要な理由を簡単に説明します。 Microsoftは、このような精度が必要なのはマルチメディアアプリケーションだけだと言います。 たとえば、blackjetを使用して新しいWinAMPを作成します。ここでは、新しいオーディオデータを時間通りにシステムに送信することが非常に重要です。 私のニーズは別の分野にありました。 H264ストリームデコンプレッサーがありました。 そして彼はffmpeg'eにいた。 そして、彼は同期インターフェース（Frame * decompressor.Decompress（Frame * compressedFrame））を持っていました。 そして、プロセッサのIntelチップで解凍を行うまで、すべてが順調でした。 ちなみに、ネイティブIntel Media SDKではなく、DXVA2インターフェイスを使用して作業する必要があった理由を覚えていません。 そして、それは非同期です。 だから私はこのように働かなければなりませんでした：

• データをビデオメモリにコピーする
• フレームがリラックスする時間を持つように、スリープ状態にします
• 解凍が完了したかどうかを確認し、完了している場合は、ビデオメモリから拡張フレームを取得します

問題は2番目の段落にありました。 GPUViewを信じている場合、フレームには50〜200マイクロ秒で解凍する時間がありました。 Sleep（1）を設定すると、コアi5で最大1000 * 4 *（コア）= 4000フレーム/秒を解凍できます。 通常のfpsが25に等しいと考えると、これは同時に40 * 4 = 160のビデオストリームのみを解凍します。 そして目標は200を引き出すことでした。実際には2つのオプションがありました。ハードウェアコンプレッサーを使用して非同期操作のためにすべてをやり直すか、スリープ時間を短縮するかです。

最初の測定

現在の実行時のクォンタムを概算するために、簡単なプログラムを作成します。

void test() { std::cout << "Starting test" << std::endl; std::int64_t total = 0; for (unsigned i = 0; i < 5; ++i) { auto t1 = std::chrono::high_resolution_clock::now(); ::Sleep(1); auto t2 = std::chrono::high_resolution_clock::now(); auto elapsedMicrosec = std::chrono::duration_cast<std::chrono::microseconds>(t2 - t1).count(); total += elapsedMicrosec; std::cout << i << ": Elapsed " << elapsedMicrosec << std::endl; } std::cout << "Finished. average time:" << (total / 5) << std::endl; } int main() { test(); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すぐに、たとえばMSVS 2012がある場合、std :: chrono :: high_resolution_clockを使用するつもりはないことを警告します。 とにかく、何かの継続時間を測定する最も確実な方法は、パフォーマンスカウンターを使用することです。 コードを少し書き直して、正しい時間を測定していることを確認します。 最初に、クラスヘルパーを記述します。 _{私は現在MSVS2015でテストを行いましたが、そこではhigh_resolution_clockの実装はパフォーマンスカウンターを通じて既に正しいです。 私はこのステップをやっている、突然誰かが古いコンパイラでテストを繰り返したい}

額の問題を解決しようとしています

プログラムを少し書き直します。 そして、明白なものを使用してみてください：







つまり ご覧のとおり、移動中のゲインはありません。 this_thread :: sleep_forをよく見てください 。 そして、一般的にthis_thread :: sleep_until 、つまり スリープとは異なり、彼は、例えば、時計の影響も受けません。 最良の代替案を見つけてみましょう。

できるスリップ

MSDNとstackoverflowを検索すると、唯一の代替手段として待機可能なタイマーに導かれます。 さて、別のヘルパークラスを作成しましょう。





そして、新しいテストを追加します：

 int main() { test("Sleep(1)", [] { ::Sleep(1); }); test("sleep_for(microseconds(500))", [] { std::this_thread::sleep_for(std::chrono::microseconds(500)); }); WaitableTimer timer; test("WaitableTimer", [&timer] { timer.SetAndWait(5000); }); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何が変わったのか見てみましょう。





ご覧のとおり、外出先でのサービスオペレーションでは、何も変わっていません。 デフォルトでは、その上でのフローランタイムクォンタムは通常巨大です。 XPとWindows 7を搭載した仮想マシンは探しませんが、XPでもまったく同様の状況になる可能性が高いと言えますが、Windows 7ではデフォルトの1ミリ秒のタイムスライスのようです。 つまり 新しいテストでは、Windows 8.1での以前のテストと同じインジケーターが提供されます。





何が見えますか？ 新しいスリップができたのは事実です！ つまり Windows 8.1では、すでに問題を解決しています。 何が起こったのですか？ これは、ウィンドウ8.1ではタイムクォンタムがわずか500マイクロ秒であったために発生しました。 はい、はい、スレッドは500マイクロ秒で実行されます（私のシステムでは、デフォルトで解像度は500.8マイクロ秒に設定され、正確に500マイクロ秒を設定することができたXP / Win7とは異なり、より低く設定されていません）新しい実行で実行します。



結論1 ： 睡眠（0.5）を必要とするが、十分ではない、正しいスリップ。 これには常に待機可能タイマーを使用します。



結論2 ：Win 8.1 / Win 10のみで記述し、他のOSで実行しないことが保証されている場合、Waitable Timerの使用を停止できます。

状況への依存またはシステムタイマーの精度を上げる方法を削除します

マルチメディア関数timeBeginPeriodについては既に述べました。 ドキュメントには、この機能を使用して、タイマーの精度を設定できることが記載されています。 見てみましょう。 もう一度、プログラムを変更します。





伝統的に、私たちのプログラムの典型的な発見。







結果から見える興味深い事実を分析しましょう。

1. Windows 8.1では、何も変更されていません。 timeBeginPeriodは十分に賢い、つまり N個のアプリケーションが異なる値でシステムタイマーの解像度を要求した場合、この解像度は低下しません。 Windows 7では、タイマーの解像度が既に1ミリ秒であるため、変更も認識されません。
   
   
   
   
2. サーバーOSでは、 timeBeginPeriod（1）は予期しない方法で動作しました。システムタイマーの解像度を可能な限り高い値に設定しました。 つまり そのようなOSでは、フォームの回避策が明らかに縫い付けられています：
   
   
   
   

    void timeBeginPerion(UINT uPeriod) { if (uPeriod == 1) { setMaxTimerResolution(); return; } ... }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   これは、Windows Server 2003 R2ではこれまで発生していなかったことに注意してください。 これは2008サーバーの革新です。
   
   
   
   
3. サーバーOSでは、 Sleep（1）も予期しない方法で動作しました。 つまり スリープ（1）は 、 サーバーOSでは2008サーバーから 「 1ミリ秒の一時停止 」ではなく「 できる限り最小の一時停止 」として解釈されます 。 ^{この場合、この記述が正しくない場合があります。}

結論を続けましょう。



結論3 ：Win Server 2008/2012/2016でのみ記述し、他のOSで実行しないことが保証されている場合、気にする必要はまったくありません。timeBeginPeriod（1）とそれに続くSleep（1）が必要なすべてを行います。



結論4 ：私たちの目的のためのtimeBeginPeriodは、サーバー軸に対してのみ有効です。 ただし、Waitableタイマーと共有すると、Win Server 2008/2012/2016およびWindows 8.1 / Windows 10でのタスクがカバーされます。

一度にすべてが必要な場合はどうなりますか？

Windows XP / Windows Vista / Windows 7 / Windows Server 2003でスリープ（0.5）が必要な場合の対処方法を考えてみましょう。



ネイティブAPIのみが助けになります-ntdll.dllを介してユーザー空間からアクセスできる、文書化されていないAPIです。 興味深いNtQueryTimerResolution / NtSetTimerResolution関数があります。











観察と結論を出すことは残っています。



観察：

1. Win8では、プログラムの最初の起動後、システムタイマーの解像度が大きな値にリセットされました。 つまり 結論2は、私たちが間違っていました。
   
   
   
   
2. 手動インストール後、平均スリップは約500マイクロ秒ですが、WaitableTimerケースの実際のスリップの広がりが増加しました。
   
   
   
   
3. サーバーOSでは、 timeBeginPeriodの場合と比較して、 Sleep（1）は非常に予期せず動作を停止しました（ this_thread :: sleep_forなど ）。 つまり スリープ（1）は正常に機能し始めました。つまり、「 1ミリ秒間一時停止します」。

最終的な結論

• 結論1に変更はありませんでした。 睡眠（0.5）が必要ですが、十分ではないため、正しいスリップが必要です。 これには常に待機可能タイマーを使用します。
  
  
  
  
• 結論2 ：Windowsのシステムタイマーの解像度は、Windowsの種類、Windowsのバージョン、現在実行中のプロセス、前に実行できるプロセスによって異なります。 つまり 何も主張も保証もできません！ 保証が必要な場合は、必要な精度を常に要求/設定する必要があります。 1ミリ秒未満の値の場合、ネイティブAPIを使用する必要があります。 値が大きい場合は、 timeBeginPeriodを使用することをお勧めします。
  
  
  
  
• 結論3 ：可能であれば、作業中のWin 10だけでなく、主要な顧客から指示されたコードでもテストすることをお勧めします。 サーバーOSはデスクトップとは大きく異なる可能性があることに注意してください