Rの進行状況を追跡する

私たちがこれに気づいているかどうかは関係ありませんが、あなたが待つ必要があるとき、私たちは心配し、焦りで燃えます。 これは特に盲目の期待の場合に当てはまります。 どれだけ苦しむ必要があるかわからないとき。 1980年代にステータスインジケーターの発明者と考えられていたBrad Allan Myersが、待機中に進行状況を追跡できることで、ユーザーのアプリケーションとの対話が大幅に改善されることがわかりました（Myers、1985）。









Simeon87 [ GPL ]による典型的なステータスインジケータ、ウィキメディアコモンズ



私はバイオインフォマティクスの研究のためにRをプログラムするので、私のコードは通常一般向けではありませんが、ユーザー、つまり同僚や研究者が可能な限り幸せであることは依然として重要です。 しかし、Rの進行状況を追跡するのは簡単な作業ではありません。 この記事では、私自身の（ pbmcapply ）を含むいくつかの可能なソリューションを紹介します。

画面出力

Rの進行状況を追跡する最も簡単な方法は、現在完了している作業の割合を定期的に表示することです。デフォルトでは、画面上に表示するか、ディスク上の何らかのログファイルに書き込みます。 これがおそらく最もエレガントな解決方法ではないと言うのは意味がありませんが、多くの人はまだそれを使用しています。

Pbapply

最善の（そして単純な）ソリューションは、pbapplyパッケージを有効にすることです 。 あなたが彼のページの情報を信じているなら、パッケージは非常に人気があります-9万ダウンロード。 使い方は簡単です。 applyを呼び出すたびに 、そのpbapplyバージョンを呼び出します。 例：

#  ,      nums <- 1:10 #  sapply,       sqrt <- sapply(nums, sqrt) #        pbapply sqrt <- pbsapply(nums, sqrt)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

番号が処理されている間、定期的に更新されるステータスインジケータが表示されます。









pbapplyによって生成されたステータスインジケーター。 ユーザーは、さらに多くの時間が必要であり、インジケータの形で現在の状態を確認できます。



pbapplyは素晴らしいツールであり、私は頻繁に使用していますが、最近まで、applyの並列バージョン-mcapply-の進行状況を表示することはできませんでした。 9月に、著者pbapplyは、単純なネットワーク（雪の種類-ワークステーションの単純なネットワーク-ワークステーションの単純なネットワーク）とマルチコア分岐のクラスターのサポートを追加しました。 ただし、このアプローチでは、要素をパーツに分離し、 mcapplyをそれらに一貫して適用します。 このアプローチの欠点の1つは、要素の数がコアの数を大きく超える場合、 mcapplyを何度も呼び出す必要があることです。 Unix / Linuxのfork（）関数に基づくMcapply呼び出しは非常に高価です。多くの子プロセスへのforkには時間がかかり、多くのメモリを消費します。









pbapplyは多くの子プロセスを生成し、pbmcapplyは可能な限りそれらを再利用することに注意してください。 4つのコアがpbapply / pbmcapplyに割り当てられます。 Rコードはここからダウンロードできます 。

Pbmcapply

Pbmcapplyは、この問題に対する私自身の解決策です。 CRANパッケージから入手でき、簡単に使用できます。

 #  pbmcapply install.packages("pbmcapply")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

名前が示すように、 pbapplyパッケージに触発されました。 pbapplyとは異なり、私のソリューションにはmcapplyの呼び出しが多く含まれていません。 Pbmcapplyは、代わりにfutureパッケージを使用します 。









Pbmcapplyスキーマ。 FutureCall（）は別のプロセスで実行され、指定された数の子に分岐します。 子プロセスは、progressMonitorを通じて進捗状況に関する情報を定期的に送信します。 progressMonitorがデータを受信するとすぐに、状態を標準出力デバイスに出力します。



コンピュータサイエンスでは、futureは、後で値を含むオブジェクトを示します。 これにより、プログラムは将来のようなコードを実行し、出力を待たずに次のステップに進むことができます。 pbmcapplyでは、mcapplyは将来配置できます。 Futureは定期的にそのステータスに関する情報をメインプログラムに提供し、メインプログラムはステータスインジケータを表示します。



pbmcapplyではリソースコストが最小限で非線形であるため、要素の数がプロセッサコアの数を大きく超えると、パフォーマンスが大幅に向上します。 実例として、Rではシングルスレッドとマルチスレッドの適用関数が使用されます。pbmcapplyを使用しても、監視プロセスの開始に時間がかかるため、パフォーマンスが低下することは明らかです。









pbapplyとpbmcapplyのパフォーマンス比較。 Rコードはここからダウンロードできます 。 左のパネルは、各パッケージを呼び出すときのリソースのコストを示しています。 右側のパネルには、各通話の時間が表示されます。



すべてに価格があります。 インタラクティブな状態追跡の便利さを楽しんで、覚えておいてください、これはプログラムを少し遅くします。

おわりに

いつものように、普遍的な解決策はありません。 主な優先順位がパフォーマンスである場合（たとえば、クラスターでプログラムを実行する場合）、進行状況を追跡する最善の方法はおそらくprintです。 ただし、余分な数秒で何も解決しない場合は、私のソリューション（ pbmcapply ）またはpbapplyを使用してプログラムをより便利にしてください。

参照資料

マイヤーズ、BA（1985）。 コンピューターとヒューマンのインターフェイスの完了率の進捗インジケーターの重要性。 ACM SIGCHI Bulletin（Vol。16、No. 4、pp。11-17）で。 ACM