CPU パフォーマンス: クロック速度またはコア数JMP を実行する場合、より低い周波数でより多くのコアを使用する方が良いでしょうか、それともその逆ですか? スレッド化されているプラットフォームはほとんどないため、クロック速度の方が重要であると考えられると思いました。しかし、これが今でも真実であるかどうかはわかりません。私が話しているのは一般的なケースであり、正確に話すのはほぼ不可能であることはわかっています。とにかくありがとう。
Re: CPU パフォーマンス: クロック速度またはコアJMP が利用可能なプロセッサをどの程度うまく利用できるかは、実行されている分析プラットフォームと処理されるデータによって異なります。 ここでは、行数 > プロセッサ数で、長い文書に対してテキスト解析フェーズ中にテキスト エクスプローラーを実行している JMP を示します。 (他のプラットフォームでは動作が異なり、一部のプラットフォームではスレッドを利用できない場合があります。 Text Explorer の解析は私が最近取り組んだものです。)
100% busy100% busy100%忙しい
Text Explorer のアルゴリズムは、常にマシンを 100% ビジー状態に保つことができるわけではありません。 一部の作業は、最初に完了する他の作業に依存しており、スレッド化された一部の作業は、スレッドを待機させる形でリソース (メモリ アクセスなど) を求めて競合します。
dt = New Table( "bigtext",
Add Rows( 1000 ),
New Column( "text", Character, "Nominal", formula( Repeat( "aaa bbb ccc ", 1e5 ) ) )
);
dt << Text Explorer(
Text Columns( :text )
);
CPU の追加には制限があります。ここではすべての 32/64 CPU がビジー状態に見えますが、作業はほぼ同じ速度で進行しています。
100% busy but not making progress much faster100% busy but not making progress much faster100% 忙しいが、進捗はそれほど速くない
これらの CPU が相互に邪魔をしているのではないかと思われます。 GB のドキュメントがメモリ内を移動すると、CPU のキャッシュ メモリが大量に消費される可能性があります。 ほとんどの JMP は 4 ～ 12 個の CPU を搭載したマシンで開発されており、おそらくそのためにアルゴリズムが調整されています。 たとえば、テキスト エクスプローラーは解析ステップを完了した後、プロセッサの半分を使用して解析結果を結合します。これは、8 CPU マシンですべてのプロセッサを使用するよりも高速であると判断したためです。
つまり、4 ～ 12 個の CPU、より高速な CPU、およびページングを回避するのに十分なメモリが必要です。 ディスクへのページングを行わずにデータを保持するのに十分なメモリがない場合は、他に何も役に立ちません。
Re: CPU パフォーマンス: クロック速度またはコア@vince_faller : 元の質問に答えるために、(Windows 上で) JMP の 1 つのコピーを最適化するための私の個人的な推奨事項は、可能な限り最速の 4 つまたは 6 つのプロセッサを入手することです。
@txnelson : もっと明確にすべきだったのですが、JMP はすべてのコアの一部を使用することがよくありますが、すべてのコアを最大限に使用するわけではありません。このことから、JMP は 8 ～ 12 個未満の実際の「ワーカー」スレッドで実行されており、処理はオペレーティング システムによってコアからコアへと移動されていると考えられます。
JMP のこの特性が私には気になるので、JMP が全コアの一部しか使用しないという私の理論をテストするのに時間を費やしました。 以下のスクリプトの 1、2、3、または 4 つのコピーをそれぞれの JMP インスタンスで同時に実行した場合の結果を次に示します。
1 つのインスタンス
19～21秒
2 つのインスタンス
26～28秒
3 つのインスタンス
34～39秒
4 つのインスタンス
43～47秒
2 つのコピーを同時に実行する時間は、1 つのコピーを 2 回実行する時間よりも確実に短くなります。
Names default to here( 1);
dt = Open( "$Sample_data/probe.jmp", Private );
Random reset(1);
valcol = dt << New Column( "Validation",
Numeric, "Nominal", Set formula( Random Category( 0.75, 0, 0.25, 1, 2 ) ),
Value Labels( {0 = "Training", 1 = "Validation", 2 = "Test"} ), Use Value Labels( 1 )
);
dt << Run Formulas; valcol << Delete Formula;
timeboot = Function( {},
start = Today();
xvars = Substitute(Char((dt << Get Column Names)[8::394]), "{", "", "}", "");
Eval( Parse(
"rf = dt << Bootstrap Forest(
Y( :Process ),
X( " || xvars || " ),
Validation Portion( :Validation ),
Method( \!"Bootstrap Forest\!" ),
Portion Bootstrap( 1 ),
Number Terms( 30 ),
Number Trees( 2000 ),
Early Stopping( 0 ),
Go
);"
));
rf << Close Window;
end = Today();
return(end - start);
);
win = New window("Time Bootstrap",
V List Box(
r = text box( "", << Set Width( 100 ) ),
H List Box(
Button Box( "Start", r << Set Text( Char( timeboot() ) || " seconds" ) ),
Button Box( "Close", dt << Close Window; win << Close Window; )
)
)
);Re: CPU パフォーマンス: クロック速度またはコア私の発見は異なりますが、それは私がテストしたプラットフォームが原因である可能性があります。Random Forrest を実行すると、Windows 7 と Windows 10 の両方のすべての CPU で簡単に実行できます。平均すると、総 CPU 能力の 35% 以上を占めます。プロセスは 8 つしかありません。合計 12 という素晴らしいプロセスではありませんが、8 つすべてが問題に取り組んでいます。
Re: CPU パフォーマンス: クロック速度またはコアWindows 7 デスクトップ上で、JMP の 1 つのインスタンスが 12 コアのうち 6 コア以上を使用しているのを目撃したことがありません。 通常、プロセッサ使用率が 25% になると、かなりの量が発生します。Re: CPU パフォーマンス: クロック速度またはコアヴィンス、
分析プラットフォームのほとんどはマルチスレッドですが、JSL はほとんどがシングルスレッドです。したがって、それは混合ケースです。私がお勧めするのは、タスク マネージャーを開き、その中の [パフォーマンス] タブを開くことです。次に、通常のジョブ フローを実行すると、アプリケーションがいつマルチコアでヒットしているのか、いつシングルコアでヒットしているのかが明確にわかります。そこから決定を下すことができます。
