2016/01/03
パイプラインの処理を途中で打ち切る方法
PowerShellのパイプライン処理
まず、PowerShellのパイプライン処理について軽くおさらいします。
例えば、@、A、Bをそれぞれ何らかのコマンドとしたとき、
@|A|B
というパイプラインがあったら、処理の流れは、
@begin→Abegin→Bbegin→(@process→Aprocess→Bprocess→)×n→@end→Aend→Bend
の順に実行されます。(processブロックで「1入力に対し1出力する」場合以外は必ずしもこうならないですが)
さて、AかBのprocessブロック実行中に、何らかの条件を満たした時、パイプラインのprocessの後続処理を打ち切りたい場合はどうすれば良いでしょうか。
まずはbreakを使った駄目な例
ネットでよく見かける以下のようなコード、すなわち「パイプラインはbreakで処理を打ち切ることができる」というのは実は正しくないのです。
function Select-WhileTest { [CmdletBinding()] param ( [parameter(ValueFromPipeline=$true)] [psobject[]]$InputObject, [parameter(Position=0)] [scriptblock]$Predicate ) process { if(!(&$Predicate)) { break } $InputObject } }
このコードはv2までではそもそも正しく動作しませんが、v3以降では条件によっては正しく動作しているように見えるのが、誤解の元なのかと思います。(というか私も誤解してました。)
例えば、
$result = "初期値" $result = &{end{foreach($i in (1..5)){$i}}} | Select-WhileTest {$_ -lt 3} Write-Host "`$resultは $result です。"
のようにすると、
$resultは 1 2 です。
のように、想定した通りの結果が得られます。このように、上流のスクリプトブロックのendブロック内にforeachなどループブロックが存在し、そのループブロック内で下流に値を出力している場合はうまくいきます。(ちなみに、スクリプトブロック直下に記述するのとendブロック内に記述するのは等価。)
しかし、上流にループブロックがない場合、例えば
$result = "初期値" $result = 1..5 | Select-WhileTest {$_ -lt 3} Write-Host "`$resultは $result です。"
とすると、コンソールに1と2が改行区切りで表示されますが、ホストに表示されるだけで$resultには値は格納されません。そしてスクリプト化して実行した場合は、Write-Hostが実行されることすらなく、スクリプトが終了してしまいます。
breakだとなぜうまくいかないのか
結局どういうことかというと、パイプライン下流のbreakは、パイプラインを打ち切る処理をするのではなく、単に一つ上流のブロックをbreakする処理に過ぎないのです。
パイプライン上流にループブロックがある場合は、そのループブロックをbreakしますが、それ以外の場合はスクリプトのbegin, process, endのいずれかのブロックがbreakされてしまい、結果としてスクリプトが終了してしまうわけですね。
そして、このSelect-WhileTest関数だと大丈夫ですが、processブロックの中にループブロックを記述し、その中でbreakを書くのは当然ダメです。単にそのループを抜けるだけなので、上流の出力は止まってくれません。
breakではなくcontinueを使う場合も基本は同じ結果です。しかもcontinueは所詮、その名の通り継続処理なので、上流に以下のような無限リストがあると無限ループに陥ってしまいます。
&{begin{$i = 0} process{while($true){$i++; $i}}}|Select-WhileTest {$_ -lt 3}
breakの代わりに、
throw (New-Object System.Management.Automation.PipelineStoppedException)
を実行する方法も見かけますが、これはループブロックがあっても強制的にスクリプトが終了するので余計ダメです。try...catchでエラートラップすればスクリプトの終了は回避できますが、「パイプラインが正常終了せずエラーを出した」扱いであることには代わりないので、やはり出力を変数に格納することができません。
ダミーループを用いる、取りあえずの解決策
前述のbreakを使った方法の問題点のうち、上流にループブロックがないとスクリプトが終了してしまい、出力を変数に代入することもできない問題は、とりあえず解決する方法があります。
以下のように、呼び出す時にパイプライン全体をダミーのループブロックでラップすれば良いのです。
$result = "初期値" $result = do{ 1..5 | Select-WhileTest {$_ -lt 3} }until($true) Write-Host "`$resultは $result です。"
このようにしておけば、breakはパイプラインの外側のdo...untilを抜ける効果になるので、スクリプトが終了する心配も、値を出力しない問題も起こりません。
元々、パイプライン上流にループブロックが存在する場合でも、単にdoループ内の処理が1回走るだけなので、特に問題は起きません。1回だけ処理を実行するダミーループなら、for($i=0; $i -lt 1; $i++){}とかでも良いです。
ただ…この記述を美しいと思う人は多分いないですね。事情を知らないと意味不明ですし。そして、breakを記述する側の関数には、前述の通りのループブロック内では値を出力できないという制限は残ったままになります。
やはりbreakでパイプラインを打ち切るのは、本来想定された動作かと言われるとかなり微妙なところだと思います。(v3で一応動くようになったとはいえ)
この方法についての参考記事:Cancelling a Pipeline - Dreaming in PowerShell - PowerShell.com ? PowerShell Scripts, Tips, Forums, and Resources (ただしv2準拠の内容であることに注意)
ところで、Select-Object -Firstは…
さて、話は変わって、PowerShell 3.0からはSelect-Object -First の処理が変わったことについては、ご存知の方も多いかと思います。
具体的には、v2までは単にパイプライン処理をすべて終了してから、最初のn件を抽出する処理であったn件のパイプライン出力がされた後は、入力をすべてフィルタし出力に流さなくなる動作であったところが、v3からはn件のパイプライン出力がされた時点で、パイプラインの処理を打ち切るようになりました。(1/5修正)
つまり、
$result = 1..5| &{process{Write-Host "Process:$_"; $_}}| Select-Object -First 2 Write-Host "`$resultは $result です。"
というスクリプトは、v2までは
Process:1 Process:2 Process:3 Process:4 Process:5 $resultは 1 2 です。
のようにパイプライン出力は指示通り2件であるものの、上流の処理は結局、全部実行されてしまっています。
一方v3以降では、
Process:1 Process:2 $resultは 1 2 です。
のように、きちんと上流の処理を打ち切ってくれています。
つまり、ここまで述べてきたパイプライン処理の打ち切りは、実はv3以降のSelect-Object -Firstでは実現できているということです。これと同じことを我々も自作関数の中でやりたいわけです。
ではSelect-Object -Firstは具体的にどういう処理をしているかというと、StopUpstreamCommandsExceptionという例外をthrowすることでパイプライン処理の打ち切りを実現しています。この例外はまさに名前の通り、パイプライン上流の処理を中止するための例外です。この例外を自作関数でthrowしてやればうまくいきそうです。
しかし、この例外は非publicな例外クラスであることから、New-Objectコマンドレットなどでインスタンス化することはできません。リフレクションを駆使する必要がでてきます。
参考:PowerShell 3.0からはじめるTakeWhile - めらんこーど地階
(1/5追記)参考2:パイプラインの処理を途中で打ち切る方法のPowerShell版 - tech.guitarrapc.cóm(Add-TypeでC#経由でリフレクションしてます。)
頑張ればできなくはないですが、もっと楽な方法はないものか…と思ってあきらめかけたところ、いい方法を思いついたので紹介します。
Select-Object -Firstを利用する方法
Select-Object -Firstでできることが我々には(簡単には)できない。ならばどうするか。Select-Object -Firstを使えばいいじゃない。という発想です。
function Select-While { [CmdletBinding()] param ( [parameter(ValueFromPipeline=$true)] [psobject[]]$InputObject, [parameter(Position=0)] [scriptblock]$Predicate ) begin { $steppablePipeline = {Select-Object -First 1}.GetSteppablePipeline() $steppablePipeline.Begin($true) } process { if(!(&$Predicate)) { $steppablePipeline.Process($InputObject) } $InputObject } end { $steppablePipeline.End() } }
scriptblockにはGetSteppablePipelineというメソッドが存在し、このメソッドによりSteppablePipelineオブジェクトが取得できます。これは何かというと、要は「スクリプトブロック内のbegin, process, endを個別に実行する」ための機能です。
参考:PowerShell: ◆パイプライン入力・パラメータ入力対応のGridView出力関数を作る(私自身も以前この記事で知りました。)
{Select-Object -First 1}というスクリプトブロックは、1回目に実行するprocessブロック内でStopUpstreamCommandsExceptionを出してくれます。
よって、自作関数のprocessブロック内のパイプライン処理を打ち切りたい箇所で、SteppablePipelineオブジェクトのProcessメソッドを使うことで、{Select-Object -First 1}のprocessブロックの処理を呼び出してやればいいわけです。
このようにして作成したSelect-While関数を以下のように実行してみると、
# 上流にループあり $result1 = &{end{foreach($i in (1..5)){$i}}} | Select-WhileTest {$_ -lt 2} Write-Host "`$result1は $result1 です。" # 上流にループなし $result2 = 1..5 | Select-While {$_ -lt 3} Write-Host "`$result2は $result2 です。" # 上流に無限リスト $result3 = &{begin{$i = 0} process{while($true){$i++; $i}}} | Select-While {$_ -lt 4} Write-Host "`$result3は $result3 です。"
結果は
$result1は 1 です。 $result2は 1 2 です。 $result3は 1 2 3 です。
となり、少なくとも今まで述べてきた諸問題はすべて解消していることが分かると思います。
このSelect-While関数は、スクリプトブロックで指定した条件を満たさなくなったときに、パイプライン処理を打ち切ってくれるものですが、この「Steppable Select -First 方式」を使えば他の自作関数でも、割と気楽に呼べるんじゃないかなと思います。ループブロック内で呼び出すことももちろん可能です。
ただし問題点はある
これはSelect-Object -FirstというかStopUpstreamCommandsExceptionあるいはPowerShellのパイプライン機構の仕様に由来する問題であると思われるので、どうにもならないことではあるんですが、一点だけ注意事項があります。
$result = 1..5| &{ begin { Write-Host "Begin" } process { Write-Host "Process:$_" $_ } end { Write-Host "End" } }| Select-While {$_ -lt 2} Write-Host "`$resultは $result です。"
これの結果は
Begin Process:1 Process:2 $resultは 1 です。
となり、なんとendブロックが実行されていません。Select-While {$_ -lt 2} の代わりに Select-Object -Firstを使っても、同様にendは実行されません。
つまり、StopUpstreamCommandsExceptionというのはパイプライン処理を打ち切って、そこまでの出力値を正しくパイプライン出力として出してくれますが、やってくれるのはそこまでで、最後のendブロック処理はしてくれません。
これは十分注意が必要な点で、自作関数内でbeginブロックで確保したリソースをprocessブロックで利用して、endブロックで解放する…という、いかにも書いてしまいそうなパターンは、実はNGなんですね。何も上のようにマニアックなことをしなくても、単に下流でSelect-Object -Firstを使うだけでアウトです。
じゃあ、リソースの取り回しはどうするのが良いの、って話もありますが、それはまたの機会にしましょう。
(1/5追記)あえとすさんの記事が参考になります。:パイプライン処理の後始末をしよう - 鷲ノ巣 ただ、この方法ではパイプライン下流でthrowされた場合はトラップできないぽいですね。コマンドレットクラスの場合はIDisposable実装で良さそうです。
ここからは私見ですが、StopUpstreamCommandsExceptionが後付けかつ非パブリックなところとか、パイプラインを合法的に脱出するステートメントが今に至るまで用意されていないところとか、パイプラインを何とかして途中で打ち切っても、endは実行されないところとかを見ていると、そもそもPowerShellではパイプライン処理の中断というのは、あまり想定してない操作なのかなぁ、という気がしてきています。
上記のような裏技を使って回避するのも一案ではあるとは思いますが、そもそも「パイプライン処理の中断はイレギュラー」と考えて、そういう処理は避けて、必要に応じて別のアプローチを取ることも考えた方がいいのかもしれません。
2014/12/11
PowerShellでMMLシーケンサーを作ってみた(その1)
MMLとは
この記事はPowerShell Advent Calendar 2014の11日目の記事です。
突然ですが、MMLってご存知ですか? MMLとはMusic Macro Languageの略で、その名の通り音楽演奏データを記述するための言語です。BASICのPLAY文で使うあれです。MIDIファイルに変換するコンパイラもありましたよね。
たとえば、「ねこふんじゃった」の最初の部分をMMLで書くとこんな感じです。MMLはいろんな記法があるのですが、よくあるのはこういうのです。
e-d-<g-4>g-rg-4e-d-<g-4>g-rg-4e-d-<g-4>g-4<e-4>g-4<d-4>frf4 e-d-<d-4>frf4e-d-<d-4>frf4e-d-<d-4>f4<e-4>f4<g-4>g-rg-4
ドの音をc、レの音をd、のように以下シの音をbまでアルファベット音階で割り当てます。半音上げる(シャープ)場合は音名のあとに+、半音下げる(フラット)場合は-を付与します。音の長さは4分音符なら4、8分音符なら8と書きます。付点は数字のあとに.を付けます。数字省略時は8分音符と解釈するのが普通のようです。オクターブを上げる場合は>、下げる場合は<と書きます(コンパイラによっては逆の解釈をする)。休符はrです。
本物のMMLでは、音色の指定だとかトラックの割り当てだとか、もっとたくさん命令があるんですが、基本はだいたいこんなもんです。
PowerShellで音を鳴らすには
PowerShellで音を鳴らすには、.NETのSystem.Console.Beepメソッドを使うのが一番手っ取り早いです。ビープ音ですね。比較的古いWindowsではハードウェアのビープスピーカーから、比較的新しいWindowsではサウンドデバイス上で鳴ります。今回のMMLシーケンサーも結局はBeepメソッドです。
そしてぎたぱそ先生がずっと以前に書いておられます。なので今回のはまあ、MMLシーケンサー部分を除けば二番煎じなんですけどもね。(そしてSmallBasicLibraryを使えば実はMML演奏もできるので、車輪の再発明でもあるんですが)
ちなみにwavやmp3なんかを鳴らすには、Windows Media PlayerをCOM経由で実行する方法や.NET(WPF)のSystem.Windows.Media.MediaPlayerクラスを使う方法などがあります。
音程の決め方
Beepメソッドでは第1引数にビープ音の周波数をHzで、第2引数に再生時間をミリ秒で指定します。つまりは音程(音の高さ)はHzで指定する必要があります。ここでドの音は何ヘルツで、みたいな対応表をどこかから探してきてそのデータを使ってもいいんですが、今回はせっかくなので、PowerShellで計算して求めてみます。
まず、ある音程の一つ上のオクターブの音程の間の周波数比は、1:2です。
ピアノ等の鍵盤楽器が近くにあれば、それを見てもらえば分かると思いますが、1オクターブには12の音程が含まれています。1オクターブの周波数比を12個均等に分割します(この周波数の決め方を平均律といいます)。つまり、隣り合う音程の周波数比は、1:12√2となるわけです。
さて、音程の周波数比はこれでわかりました。あとは基準となる音の周波数が分かれば、全ての音の周波数が計算できるわけです。時代や地域、演奏する楽器等によって微妙に違ってきますが、現代日本においては普通は、A(ラ)=440Hzが基準周波数です。
あとは単純にかけ算して周波数を求めて連想配列に入れておくだけです。コードにすればこんな感じですね。
$baseFrequency = 440.0 $pitches = @{ "c" = $baseFrequency * [math]::Pow(2, 3/12) "d" = $baseFrequency * [math]::Pow(2, 5/12) ... }
あと、+で半音上がる場合は[math]::Pow(2, 1/12)をかけ、-で半音下がる場合は割ればいいだけです。(別に$pitchesテーブルで最初から定義してもいいかもですが)
音価の決め方
音価というのは音の長さです。Beepメソッドの第2引数にはミリ秒で実際の時間を指定する必要があるので、これも計算で求めてやります。
4分音符というのは、1小節(全音符)を4分割、つまり1/4した音価を持ちます。同様に8分音符は1/8ですね。付点がつくと音価は1.5倍になります。
ではたとえば4分音符の具体的な音価はどうやって定めるのでしょうか。それを決めるのがテンポと拍子です。
テンポは1分間(つまり60000ミリ秒)の拍数(BPM、Bit Per Minuteともいう)で定義されます。今回作るシーケンサーは4/4拍子、すなわち1拍=4分音符とする4拍子固定とするので、1分間に4分音符がBPM回含まれることになります。
つまり、4分音符の音価=60000ミリ秒/BPMの値、全音符の音価=60000*4ミリ秒/BPMの値 となるわけです。
具体的なコードは…略します。単なるかけ算と割り算だけなんで。
MMLのパース
えっと時間がなくなってきたので、駆け足で説明します。
MMLのパースとは、要するに最初の例のようなMML(テキストデータ)から、実際に演奏する音程と音価の組み合わせのデータとして組み立てる作業になります。
今回のシーケンサーでは、繰り返し記号等はサポートしないので、単にMMLを一文字ずつ読み込んで、音名(cなど)を見つけたら、その後の文字を読んで、+があれば半音上げるなどして周波数を求め、その後に数字があればn分音符とみなし、先ほどの計算式から実際の音価を求めてやる。というのを全部の音でくり返すだけです。
この処理をやっているのがConvertFrom-MMLという関数です。MMLテキストを入力してやると、周波数(Frequency)や発音時間(Duration)などをプロパティとして含んだpscustomobject(Noteオブジェクト)を出力します。(Noteとは音符のことです)
MMLの演奏
パースしたMMLを実際に演奏するのがInvoke-Beep関数です。入力は、ConvertFrom-MMLで生成したNoteオブジェクトです。実際の処理は至って単純で、 [System.Console]::Beep($note.Frequency, $note.Duration)するだけです(えー)。あ、あと休符の時はDuration分だけSleepを入れてやっています。
MMLの>と<の意味を逆転する-Reverseスイッチ、BPMを指定する-Bpmパラメータ(デフォルト120)なんかも用意してます。
実際にはMMLから直接演奏できるように、Invoke-Mmlというラッパー関数を用意しています。
冒頭のねこふんじゃったのMMLを再生するにはこんな感じにします。
$s=@" e-d-<g-4>g-rg-4e-d-<g-4>g-rg-4e-d-<g-4>g-4<e-4>g-4<d-4>frf4 e-d-<d-4>frf4e-d-<d-4>frf4e-d-<d-4>f4<e-4>f4<g-4>g-rg-4 "@ Invoke-Mml $s
コード
function ConvertFrom-MML { [CmdletBinding()] param( [parameter(ValueFromPipeline=$true)][string[]]$mml, [int]$bpm = 120, [switch]$reverse = $false ) begin { $baseFrequency = 440.0 $scaleRatio = [math]::Pow(2, 1/12) $baseDuration = 60000 * 4 / $bpm $pitches = @{ "c" = $baseFrequency * [math]::Pow(2, 3/12) "d" = $baseFrequency * [math]::Pow(2, 5/12) "e" = $baseFrequency * [math]::Pow(2, 7/12) "f" = $baseFrequency * [math]::Pow(2, 8/12) "g" = $baseFrequency * [math]::Pow(2, 10/12) "a" = $baseFrequency * [math]::Pow(2, 12/12) "b" = $baseFrequency * [math]::Pow(2, 14/12) "r" = -1 } $currentOctave = 0 } process { $chars = [string[]]$mml.ToCharArray() 0..($chars.Length - 1)|%{ if($null -ne $pitches[$chars[$_]]) { $frequency = $pitches[$chars[$_]] $suffix = "" $denominator = "" $dot = $false if($_ -lt $chars.Length-1) { switch($chars[($_ + 1)..($chars.Length - 1)]) { {$pitches.Contains($_)} {break} "+" {$frequency *= $scaleRatio; $suffix += $_} "-" {$frequency /= $scaleRatio; $suffix += $_} {$_ -match "\d"} {$denominator += $_} "." {$dot = $true} } } $frequency *= [math]::Pow(2, $currentOctave) $denominator = [int]$denominator if($denominator -eq 0){$denominator = 8} $multiplier = 1 / $denominator if($dot){$multiplier *= 1.5} $duration = $baseDuration * $multiplier if($frequency -le 0){$on = $false}else{$on = $true} [pscustomobject]@{ Frequency = [int]$frequency Duration = $duration Note = "$($chars[$_])$suffix$denominator$(if($dot){"."})" Octave = $currentOctave Pitch = $chars[$_] Suffix = $suffix Denominator = "$denominator$(if($dot){"."})" On = $on } } elseif($chars[$_] -eq ">") { if($reverse) { $currentOctave-- } else { $currentOctave++ } } elseif($chars[$_] -eq "<") { if($reverse) { $currentOctave++ } else { $currentOctave-- } } } } } function Invoke-Beep { [CmdletBinding()] param([parameter(ValueFromPipeline = $true)][psobject[]]$note) process { if($note.On) { [System.Console]::Beep($note.Frequency, $note.Duration) } else { Start-Sleep -Milliseconds $note.Duration } } } function Invoke-Mml { [CmdletBinding()] param( [string]$mml, [int]$bpm, [switch]$reverse ) ConvertFrom-Mml @PSBoundParameters|Invoke-Beep }
おわりに
今回はMMLをパースしてBeepを演奏するスクリプトをPowerShellで作ってみました。これをシーケンサーというのはおこがましいと思いますが、まあたまにはこういう柔らかいネタもいいんじゃないでしょうか。ドレミの音がどうやって決められてるのかというのも、もしかして話のネタくらいにはなるかも。
そしてこれ、シーケンサーといいつつ、入力機能がないですよね。それについては次回やります。
PowerShellアドベントカレンダー2014はまだまだ残席ございます。ぜひ、あなたのPowerShell話を聞かせて下さい。
2014/04/20
集計プロパティの簡易指定
Select-Object、Format-Table、Sort-Objectなど、-Propertyパラメータを持つコマンドレットには、プロパティ名を指定する以外にも「集計プロパティ」という連想配列を指定することができます。
集計プロパティを利用すると、オブジェクトが持っていないプロパティを動的に作成し、その値を表示することができるようになります。
たとえば、dir (Get-ChildItem)の出力するファイルリストに、テキストファイルとして開いた場合の1行目の記述(Textプロパティとする)も合わせて表示したい場合は以下のようにします。
dir | select Name, Extension, @{Name="Text"; Expression={$_|gc|select -First 1}}
出力は以下のようになります。
Name Extension Text ---- --------- ---- test1.ps1 .ps1 param([Parameter(ValueFro... test2.ps1 .ps1 $x=1231 test3.ps1 .ps1 Start-Transcript test4.ps1 .ps1 Get-Content .\gacha_log.t...
ここで、@{Name="Text"; Expression={$_|gc|select -First 1}}と指定している部分が集計プロパティです。連想配列のキーとしてプロパティ名を表すNameと、スクリプトブロックを指定するExpressionを含めます。なお、キー名のNameはN、ExpressionはEと省略表記できるので、
dir | select Name, Extension, @{N="Text"; E={$_|gc|select -First 1}}
と書くこともできます。
ここまではヘルプにも載っていることなのでご存知の方も多いと思います。ただ、連想配列を指定してごにょごにょ、というのは(特にインタラクティブ実行時には)正直だるいです。そこでもっと楽な書き方はないものかと思って何気なく、
dir | select Name, Extension, {$_|gc|select -First 1}
とプロパティとしてスクリプトブロックをそのまま書いたら、普通に通りました。これ、知ってました? 私は知らなかったです。しかしv2環境で実行しても動いたので前からあったんですね。なぜヘルプに載ってないのか…。それともどこかに載ってるんでしょうか…。
ただしこの方法だと、集計プロパティでプロパティ名(Nameキー)を指定しない場合と同様、以下のようにプロパティ名がスクリプトブロックの定義そのままになります。
Name Extension $_|gc|select -First 1 ---- --------- --------------------- test1.ps1 .ps1 param([Parameter(ValueFro...
そのため、コマンドの出力を変数に入れて利用する場合などはこの方法は不適です。ですがインタラクティブ実行時で、結果表示の見た目よりも効率を重視する場合なら、この方法はお勧めです。
2011/12/25
バックグラウンドジョブを使った並列処理 [PS Advent Calendar '11]
はじめに
PowerShell Advent Calendar 2011の25日目最終日の記事、そしてこれが私の記事では4回目となります。今回もバックグラウンドジョブについての話題です。今回はバックグラウンドジョブを使って並列処理をやってみようという試みです。
これまでの記事は以下になります。
13日目:バックグラウンドジョブとの通信
19日目:PowerShell 3.0で追加されるバックグラウンドジョブ関係の新機能
ところでつい2日前、WMF3 CTP2 Windows PowerShell Workflow.pdfというpdfファイルが公開されました。これは19日目に書いたPS workflowについての詳しい説明(英語)です。構文だけでなくPSスクリプトとの違いやWFとの関係などが詳しく書かれています。ぜひ目を通しておくことをお勧めします。23日目のAhfさんの記事と併せて読むと理解が深まると思いますよ!
並列処理スクリプト
C#をご存知の方なら、PowerShellのバックグラウンドジョブ機能はC#4.0から使えるTaskオブジェクトとちょっと似てるかなーと思われるかもしれません。ではC#4.0でコレクションに対して並列処理でループを回すParallel.For()やParallel.Invoke()みたいなことはPowerShellでできないのか、という疑問が出てくるかと思います。
前回述べたようにPowerShell 3.0ならworkflowを使えば並列処理が可能で、for -parallelステートメントやparallelブロックでParallel.For()やParallel.Invoke()みたいなことが可能になります。しかしPowerShell 3.0がリリースされるのはまだ先ですし制限事項も多いので、なんとかPowerShell 2.0で、しかもworkflowのような制限なしで、並列処理のスクリプトは書けないものかと考えてみました。
function ParallelForEach-Object { [CmdletBinding()] param( [Parameter(Mandatory=$true,Position=1)][scriptblock]$process, [scriptblock]$begin={}, [scriptblock]$end={}, [Parameter(ValueFromPipeline=$true)][psobject]$inputObject ) begin { &$begin $jobs=@() } process { $jobs|Receive-Job while(@($jobs|?{$_.State -eq "Running"}).Length -ge 5) { $jobs|Receive-Job start-sleep -Milliseconds 100 } $jobs += Start-Job $process -argumentList $inputObject } end { while(@($jobs |?{$_.State -eq "Running"}).Length -gt 0) { $jobs|Receive-Job start-sleep -Milliseconds 100 } $jobs|Receive-Job $jobs|remove-job &$end } } $watch=new-object System.Diagnostics.Stopwatch "ForEach-Object 開始" $watch.Start() 1..10|ForEach-Object { "start: " + $_ Start-Sleep -sec 5 "end: " + $_ } $watch.Stop() "ForEach-Objectの場合:" + $watch.Elapsed.TotalSeconds + " sec" $watch.Reset() "ParallelForEach-Object 開始" $watch.Start() 1..10|ParallelForEach-Object { "start: " + $args[0] Start-Sleep -sec 5 "end: " + $args[0] } $watch.Stop() "ParallelForEach-Objectの場合:" + $watch.Elapsed.TotalSeconds + " sec"
ParallelForEach-Object関数はパイプラインから渡されたコレクションの各要素について、並列にスクリプトブロックを実行させるものです。同等の処理をForEach-Objectを使って同期的に逐次処理した場合とかかる時間を比較しています。10個の要素があり、各要素につき5秒かかる処理なので、逐次的に処理すると当然50秒以上かかりますが、ParallelForEach-Object関数を使って並列処理させると環境にもよりますが20秒以内に完了します。
この関数では渡されたコレクション1要素に対し1つのジョブを割り当て、同時に5ジョブまで(呼び出し元を含めて同時稼働が6プロセスまで)を並列実行するようにしています。
ただこれはあくまでなんちゃって並列処理なので、並列化することで本当に処理が高速になるかどうかは環境次第かと思います。一応、うちのCore2Duo (2コアCPU)な環境だと、足し算を3万回ほどする処理を10回行う場合、逐次処理とこの関数を使った並列処理では54秒が39秒に短縮され、有意な実行時間差が出ました。
またジョブを開始するのに新しくプロセスを起動させるので、1ループあたりの実行時間がプロセス起動にかかる時間より短ければ、この関数による並列化で処理時間の短縮は見込めません。
処理の対象が複数のリモートPCである場合などは割と有効なのかなと思います。たとえば複数サーバーから別々のファイルを同時にダウンロードするときなど。
ここではParallel.For()やParallel.ForEach()相当の関数を書きましたが、Parallel.Invoke()のような関数も書けるかと思います。スクリプトブロックの配列をStart-Jobで順に走らせ、Wait-Job, Receive-Jobする感じですね。
あとここではやりませんでしたが、Start-Jobの代わりにInvoke-Commandを使い複数のリモートPCに処理を振り分ければ、なんちゃって分散処理もできるのかなあと思いました。
おわりに
実はこのスクリプトを書いたのはPS Workflowの調査前のことで、Workflowで同様のことが可能になることを知って少々愕然としたのですが、それなりに面白いスクリプトかと思ったので公開することにしました。ともあれ、これからのマルチコア、メニーコアの時代、非同期処理や並列処理はますます重要になるかと思います。管理スクリプトにおいてもこれらの概念を意識しないわけにはいかなくなるでしょう。全4回にわたってPowerShellのバックグラウンド機能を解説してきましたが、これらがあなたの非同期&並列スクリプトライフ(?)の一助になれば幸いです。
さてさて、これでPSアドベントカレンダー2011もおしまいです。楽しんでいただけたでしょうか? 私自身も自分で記事を書いていて楽しかったですし、他の方の記事を読むのも色々な発見があり、とても有意義な25日間でした。記事を書いて参加していただいた方々、そして読者の方々に厚く御礼申し上げます。これからもぜひ、PowerShellを活用し、楽しんでくださいませ。
それでは皆様、良いクリスマスをお過ごしください!
2006/09/21
チェック式 WSH入門 第5回 公開
第5回です。VBScriptにおけるデータ型の話題を取り上げました。ご存知のとおり、VBScriptには型がなく、すべてバリアント型であるわけです。が、実際は内部で扱われる型を意識しないとうまくコードが書けないことがしばしばあって、型の知識は不可欠と思い、今回連載1回分を割いて、これでもかとばかり詳説しました。
たぶんこれを読めば型でつまずくことはなくなると思います…が、初心者の方がついてこられてるかどうかちょっと心配です。なるべく分かりやすくと思って書いたのですがどうでしょうか。
元記事:http://blogs.wankuma.com/mutaguchi/archive/2006/09/21/39270.aspx
Copyright © 2005-2018 Daisuke Mutaguchi All rights reserved
mailto: mutaguchi at roy.hi-ho.ne.jp
プライバシーポリシー