Intel CPUのスレッド並列のスケーラビリティがAMD CPUより悪い件について
なぜかIntelのCPUのスレッド並列でのスケーリングが悪いんですよね。なぜなのかわかる人いたら教えてほしいです。
- OpenMPでのスレッド並列
- イテレーション一回当たり160[us]程度の処理
- それぞれのメモリアクセスはほぼ独立で、コンフリクトもしない。
- IntelのCPUだとものすごくスケールできないが、AMDだとすごくきれいにスケールする。最適化をかけても同じ。
- gcc 8.3.1&OpenMP
- 全てCentOS 8
比較マシンのCPUはこんな感じです。 * AMD Ryzen 3900(12C) * AMD EPYC 7352 (24C) x2 socket * Intel Xeon Gold 6238 (22C) x2 socket
で、結果です。IntelマシンとAMD Ryzenのマシンの比較ですが、EPYCでもきれいにスケールします。
は?
いやいや、おかしいでしょ、裏で何か動いているのかと思いきや何も動いてないし、Intelは全然スケールしないし。 AMD EPYCのほうも似たような結果になりました。なぜかIntelだとスケールしないです。メモリ帯域は、Ryzenでも飽和しなかったので、Intelだともっと余裕があるはずだし、チップ内部のトポロジーの問題なのでしょうか??
スレッド並列が不得意だとしても、さすがにこの結果はひどいと思いました。 ちなみに、EPYCでは20C並列を2つ動かしても性能低下は特にみられませんでした。(おそらくメモリアクセスはそこまで頻繁ではなさそう) Intelのほうでも、1Cのみのプロセスを2つ動かした際、性能低下はなかったのでおそらくOpenMPのスレッド並列がうまくいってないと思われます。 同じような不具合の方いたら教えてもらえればと思います。
2021/01/07補足
intelコンパイラでやっても、Intelマシンで性能が出ませんでした。AMDが爆速でしたね。
また、スレッド並列化はだめですが、同じプログラムを繰り返したり、問題のサイズを大きくするとまぁまぁうまくスケールするみたいです。が、AMDと同じくらいのサイズでスケールしてもらいたいものです。
アルゴリズムを可視化したいときの描画エンジンの話
アルゴリズムを解く最中に何かアニメーションしたりして可視化したい時がありますね。 そんなとき、どんな方法で可視化するのがいいのか悩むことがあります。
ざっと手法をいくつか比較してみます。
printfで頑張る
ログも追えていいと思います。 ただ、どのように動いたのかわかりにくいことがあります。 テキストベースであるには限界があります。
GUI
グラフィックベースで描画するとき、2Dのエンジンの中でどんなものがいいか、スタイルに合わせた選び方が重要だと思います。
イベントドリブンな描画
描画ルーチンをdrawの中で分けて書く方法です。これは、向いているものと向いていないものがあると思います。 アニメーションを意識して分けながら実装できるか、そうでないかで変わると思います。
- 2Dルービックキューブの場合
ルービックキューブを解く過程で、解法をメモリに入れて最後にアニメーションするような場合はイベントドリブンでも問題にはなりません。 しかし、実際に解きながらアニメーションする場合はかなり複雑になってしまいます。 具体的には、アルゴリズムの進行をアニメーションに同期するような処理が複雑になります。 この場合は、マルチスレッドにしてアルゴリズムの処理と描画を通信することも考えられますが、複雑になりすぎてしまいます。
- SDL2などパッシブな描画エンジン
ドローをこちらで制御できるメリットとして描画のタイミングをこちらで制御できます。 たとえば、move関数にアニメーションを追加しておけば、アニメーション後にコールから復帰してその後の処理をしてまたアニメーションに入るみたいなことが簡単にできます。
SDL2のメリットとして、描画が非常に高速です。ゲームエンジンが目的なので、30x30の900タイルを全更新しながらループを回しても処理が全然追いつきます。 これは、GPUによるアクセラレートの力が強いです。20%くらいのGPU使用率で100fpsの滑らかなアニメーションができます(笑)
(さらに本気出せば、GPUのドローコールを減らすために大き目なテクスチャからUV頂点を切り出して2D描画すればおそらくもっと高速に全体描画できると思います。ただ、そこまでする必要があるかは、、わかりません。)
パッシブな方式には、SDL2などのローレベルなもの以外にも、プロットに適したGNUplotやmatplotlibなど様々なツールがあります。 最近では高速な描画が可能なものが増えてきているようで、アニメーションもできるものがあるそうです。 様々なツールを、その場のニーズに応じて使えればいいと思います。
Processingなどのイベントコールでの描画
コールルーティン内で描画だけを分けて書く方式です。webやprocessingなどはこの方式で、広く使われています。 ただ、プログラムの再設計が必要になることが多く、すでに組んだプログラムへ手軽に描画を追加というわけにはいかなそうです。 最初はprocessingで実装しようと思ったのですが、移植が大変そうなのでやめました。
ゲーミングノートのバッテリーの消費がなぜか激しいときにチェックすること
ゲーミングノート買った人はだれもが経験するだろう一瞬で電池がなくなる現象、なんもしてないはずなのに発熱がやばい現象の原因がやっとわかりました。
ゲーミングノートでは、iGPUではない高性能なGPUを使うと一気に消費電力が増え、電池も消費が激しく、ファンも回り、本体も熱くなります。
なぜかほぼ無操作でCPU負荷率も5%くらい、なのにPCのが熱くてファンが回りだすとか、バッテリーがなぜかすごい減る場合は、以下の点を確認してみてはいかがでしょうか。
1. グラフィックのパフォーマンス設定が原因なとき
Windows 10 からは設定からグラフィックのパフォーマンス切り替えに対応しています。 一部アプリケーションは、必要もないのに高パフォーマンスモードになっていることがあり、その場合はそのアプリを起動中、+15W以上電気を食うことになります。この発熱も結構やばく、ファンが回ってしまいます。
私のPCの場合、ノートPCベンダー製のControl Centerが高パフォーマンスモードになっていて、これを起動中は熱くなりました。 なお、このアプリの場合は内蔵グラフィックにすると起動しなくなってしまったので多分バグを隠すためにこのように設定されているのだと思います。
Control Centerを在中させないようにすれば大丈夫です(オイ
その他の一部Utilityもグラフィックを使うようです。hwinfoからGPUの消費電力などを確認できます。GPUのパワーゲートがオフの場合は(電源が入っていない場合)0と表示されます。
2. 外部モニタにつなぐと起きるとき
これは、いい点でも悪い点でもありますが、外部モニタのコネクタが一部のゲーミングノートでは、GPUに直付けされています。これにはメリットとデメリットがあります。
メリットは、ゲームを外部モニタでする場合、パフォーマンスが数%向上する報告があります。内蔵グラフィックからの出力では対応していないリフレッシュレートに対応していることもあるかも。
デメリットは、GPUでレンダリングしなくともGPUのパワーゲートをOnにするため、これも消費電力が相当増えてしまいます。
外部モニタは必要な時に接続するか、内蔵グラフィックからのバイパスになるような出力口がtype-Cなどにあることがあるので、そちらを使うことで解決します。
最後に
以上の2つのうちどれかでも引っかかっていると、高パフォーマンスなGPUの電源が入り、消費電力がかなり上がります。
逆にゲーミングPCでも軽めなタスク(例えばブラウジング、文章作成、コーディングなど)なら、設定ちゃんとしたらこの時期6/23でもファンを回すことなく静かな常用も可能だと思います。
環境
GALLERIA GCR2070RGF-QC ブラックモデル 画面も15.6インチなのに軽くて(1.87kg)、電池もまぁまぁ持つし、性能も高めでおすすめなPCです。
https://www.dospara.co.jp/5shopping/detail_prime.php?tg=8&tc=60&ft=&mc=8944&sn=2954&st=1&vr=10
余談ですが、レイトレーシング要らないなら1660tiがいいと思います。性能はあまり変わらないそうです。じゃあなぜっていうと、私の場合はBlender使いたかったし、Tensorコアで機械学習とかもしたかったので2070Max-Qのこれにしました。GRAMも8GBあります。
20200623現在売り切れになってますね。。これ、あうpayの20%キャンペーンの時に奮発して買ったやつで、その後のポイントでモニターや扇風機などを買っています。軽いPCがそのほかに比べて高いのはしょうがないですね。それでも持ち運ぶときは電池持ちがよくて軽いほうがいいと思います。
科学計算にPythonとC++どっちがいいか、いやjuliaを検討すべきかも
データサイエンス分野
データを扱ううえで、行列計算などのタスクはnumpyを使って処理することが増えてきました。 pythonの特徴である動的な型付けによる気軽なプログラミングは、他のC++などの言語よりもっと簡単にいろいろな作業ができるようになってきました。 より具体的に言えば、pythonはより簡潔に高速なプロトタイピングをすることができ、研究活動やテストなどを高速化してきました。
一方でC++は、コンパイルという作業を必要とし、さらに静的な型付けにより、Pythonより多くのコーディングが必要です。 しかし、逆に性的な型付けとコンパイルのおかげで局所的な最適化が可能になり、高速な実行が可能です。 データ同化のテストでは、実行時間がC++のほうが100倍くらい速くなりました。 まだ、C++も素人ですが、お互いにどのような場面で向いていて、どのような場面で不向きなのかを考察してみました。
コード
Pythonは、numpyを使うことで科学計算を高速化することができました。 動的な型付けやリスト内方表記などは、コードを簡潔にわかりやすく書くことができます。
c++ with Eigen 3
return MatrixXf::Identity(J,J).topRows(n);
python with Numpy
return np.identity(J)[:n]
C++では、Eigen3という算術演算のライブラリを用いて比較しました。リスト内方表記等はなく、代わりにジェネレータ等の他の文法で補うこともありますが、Pythonほどシンプルに書くことはできません。
時間
開発というのは、環境整備からコーディングとコンパイル、実行、検証に分かれます。
環境整備
Pythonは包括的なライブラリが充実していることから、そのままで様々なテストを強力に推し進めることができます。 また、何かあってもpip等で管理もできます。
一方でC++は自分で管理する必要があります。必要なライブラリをそろえて組み込むことはユーザーの責任で行います。面倒ですね。
コーディング
C++よりpythonのほうが簡潔にかけてコードを書く量が短いと思います。
コンパイル
Pythonにはコンパイルという概念がありません。C++では、ファイルの分割により、コンパイル時間は短縮しますが、テストしたLETKFのコードだけの関数でも15秒程度ビルドに時間が必要でした。 すべてのファイルをコンパイルするとき、一番長いコンパイル時間に足を引っ張られるので、最低でも15秒程度はかかりそうです。結構イライラします。
実行時間
私のテストしたコードではPythonは実行が長いです。C++のほうがパフォーマンスの最適化がしやすいので、私が簡単にチューニングした結果、100倍ものスピードアップを達成しました。後でもう少し詳しく書いています。
検証
検証は、何をもって検証というかにもよりますが、一般的にPythonのほうがコンパイルの時間がない分、実行途中で中止することで最後まで実行しなければ繰り返し試行することができます。 一方で、最後まで実行して誤差のパフォーマンス比較をしたいときは、繰り返し実行時はC++のほうが高いパフォーマンスを発揮できます。検証もC++のほうが早く終わると思われます。
合計時間
重めの検証から、誤差のパフォーマンスまで完全にするならC++で実装するのがよいと思います。 ただ、既存の軽めの技術を追試するだけだったらPythonでいいと思います。
実行時間について
1年分(1460ステップ)、40要素のデータ同化を100メンバー、8モンテカルロサンプリングのPFで実行時間がどう変化するかを観測しました。 計算のオーダーは上の示した数値の積になります。
結果としては、C++が2.28秒、pythonが数分だったので、かなり速くなりました。ほかのデータ同化テスト(フィルターテスト)でも、100倍程度のパフォーマンスゲインが得られています。
考えられる理由は以下の通りです。
- 小さなデータを繰り返し処理することが多く、PythonだとAPIオーバーヘッドが大きい
- C++では、ベクトル演算を有効に使って計算できた
- C++では局所的な最適化により、不必要な計算が省略された
- openmpによる並列化による性能向上(Pythonでは、アルゴリズムに並列化を入れることが難しい)
まとめ
PythonはAPIのオーバーヘッドが大きく、局所的なコードが大きく足を引っ張ることになりそうです。 一方で記述が簡潔であることから、プロトタイプに向いているとも言えます。
一方で、C++は計算のアルゴリズムを記述するとオーバーヘッドも少なく、高速な実行ができ、局所的な最適化も可能です。
おっと、そういえば思い出したわ。 Julia が強いらしいので、それも検証してみたいと思います。simd演算や、並列計算などをサポートしていて、かなり速いらしいです。
そしてすべて検証し終わったところでQiitaにでも投稿しようかな。
SIMD命令を使うと早くなるのか? 重力計算でみるコンパイラ最適化の限界とかの比較
結果から言うと、コンパイラが頑張ってベクトル演算をつかって最適化しても、人力で命令を指定したときのほうが30%くらい速くなった。
以前N体問題でSIMD命令を使った衝突系の重力計算のコードを書いたことがある。その時にSIMD命令を使うと早くなるのかを検証したことがあるので、それについてここでまとめておく。
SIMD命令とは
Single Instruction Multiple Data streamsの略で、その逆の通常の命令群はSISDなどと呼ばれる。 SIMDを使うためには、まとまった長さのデータ配列を丸ごとベクトルとして扱う技術を要する。今回の検証ではIntelのAVX2 256bit長レジスタを使う命令を用いた。恩恵を見るために128bit長の時の結果も考慮に入れる。
SIMD命令の概略はここでもわかる。
SIMD化とは何か / Basics of SIMD - Speaker Deck
ここも非常に参考になった。SIMD命令の役割とか結構わかりやすい。
SIMDプログラミング入門(AVX-512から始める編) - Qiita
256ビットの単精度浮動小数点演算では、32ビットのレジスタが8つのベクトルレジスタを持つ。性能をフルに生かすためにはなるべくデータのロード、ストアはアドレスの境界は正しくする必要がある。 ここでは各粒子の変数をSoA(Structure of Array)構造にすることで、多数の粒子の重力計算をレジスタを使い切った状態でほぼ完全に処理することができる。
また、重力計算のスキームの部分などの解説はここではしないが、SIMDの並列化の恩恵をちゃんと見れる環境である。詳しくはソースコードみて。時間があったら解説するかも。
結果
表には実行時間を秒で示している。512, 1024などは粒子数で、計算オーダーはO(N2)である。
テスト環境は、Ubuntu18.04LTS、i7-4790を用いている。
参考までに、マルチスレッドでの並列化による効果も併せて示しておく。コア数が増えるとスケーリングが低下しているのは、CPU全体のpower budgetが限られているためで、SIMD命令をかなり多く使ったとき特有の現象で電力不足で動作周波数が下げられてしまう。(詳しくはIntelのマニュアル見て。簡単に言えば、SIMD命令は電力をめちゃくちゃ食う!!)
CORE COUNT | SOLVER TYPE | 512 | 1024 | 2048 | 4096 | 8192 |
---|---|---|---|---|---|---|
4 | optimized by compiler | 0.89 | 1.18 | 2.21 | 6.34 | 21.92 |
4 | 128bit hand | 0.92 | 1.28 | 2.65 | 8.03 | 28.56 |
4 | 256bit hand avx-2 | 0.87 | 1.11 | 1.94 | 5.2 | 17.64 |
2 | optimized by compiler | 0.94 | 1.44 | 3.33 | 11.2 | 40.35 |
2 | 128bit hand | 0.98 | 1.64 | 4.06 | 14.17 | 53 |
2 | 256bit hand avx-2 | 0.91 | 1.31 | 2.76 | 8.84 | 31.39 |
1 | optimized by compiler | 1.07 | 2 | 5.56 | 19.57 | 74.66 |
1 | 128bit hand | 1.17 | 2.41 | 7.1 | 25.8 | 100.08 |
1 | 256bit hand avx-2 | 1.02 | 1.73 | 4.47 | 15.3 | 57.64 |
考察
128ビット長から256長は大幅に性能が向上していることがわかる。ただ、コンパイラによる最適化も256ビット長の命令を使っているので、128ビット長の時より高速であるものの、256ビット長の手動で命令を指定した時ほど速度が出なかった。 コンパイラにすべて最適化を任せたときよりシングルコアのとき30%くらい早い結果が得られた。ただ、思ったよりコンパイラの最適化が限られていることも同時に分かった。
コンパイラによる最適化
すべてのコードがベクトル演算に向けられたものではない。ベクトル演算のデータのロードストアはキャッシュのアライメント整列していることと、データ構造がベクトル演算化しやすくないとコンパイラが最適化できない。 ここでは、SIMD命令のソルバーを単純に書き直したものをコンパイルしているので構造上はコンパイラもベクトル演算化できるはずである。
コンパイラの最適は-march=native -fopenmp -Ofast
を用いた。これらのすべてを解説はできないが、Ofastは通常は勧められないオプションになる。このオプションは浮動小数点演算の実行結果に誤差を含むことを許容する(--ffast-math)。その分高速化できるのだが、SIMD命令自体が本来の計算結果から誤差を含む可能性が命令規約に含まれているからである。通常の最適化O2までは期待通りの動作になるだろう。
逆にOfastまでつければ、誤差を許す代わりに積極的に誤差が含まれるベクトル演算命令を使うようになり、コンパイラができる最大限の最適化ができるようになる。
まとめ
やはり人力のほうが速度は出やすい。すべての命令セットが使えてない感じが見受けられた。ループアンローリングからベクトル演算化、リスケジューリングまで、ある程度機能はしているが完全ではない感じ。ループアンローリングの回数が制約されているせいかもしれない。ループアンローリングの数が制限されていると、ここら辺の恩恵が小さくなってしまう。また、iccがベクトル演算化が優秀とどこかで聞いたことがあるので、試してもいいかもしれない。
ソースコード
SIMD化のときに参考になるサイト
KiCadやBlenderなどのRTX 2070とオンボのIntel UHD 630のパフォーマンス比較
レンダリング時にグラボとオンボードとの違いを見てみたいと思います。
ただ、実際にLinuxでfps計測するツールが見当たらなかったので、感覚でお伝えしたいと思います。
結論から言うと、KiCadは基本オンボードグラフィックで十分だがレイヤーが多い基板で解像度を上げたりアンチエイリアシングの設定によってはグラボが必要だがレイヤーを非表示にしたりすることで不要にもなる。
Blenderはポリゴン数によってはビューポートパフォーマンス向上でグラボが有効になる。といった感じです。正直、グラボなくても一通り動くしなんとかなるけどあるとちょっと便利になる程度です。
KiCad 5.1.4のpcbnew
まぁ、人によるという感じだと思いますが、レイヤーが多くなりレイヤーを増やすと結構オンボードだとしんどいです。
アンチエイリアシングの設定は、なし,サブピクセル High, Ultra, 2x SSSA, 4x SSAAの順に重くなりますが、綺麗になります。綺麗になるだけではなくピクセル以下までレンダリングされるため得られる情報量も増えます。SAAは特に解像度を上げたのと同様の負荷がかかるので、FHDディスプレイの2x SSAAは4kディスプレイのアンチエイリアスなしに近い負荷がかかります。
オンボードグラフィックのとき
FHD~1440pの場合はレイヤーが少なめで簡単な設計なら2x のSSAAまでならオンボードグラフィックでもなんとかなりそうですが、複雑な設計ではレイヤーを非表示にしないと重くなります。アンチエイリアシングを切るかレイヤを非表示にしたり解像度を下げる必要がありそうです。
4kでもアンチエイリアシングの設定を下げればオンボードグラフィックでも快適に設計できることもありますが、一概に全てとは言えませんが、大規模設計するならグラボがあったほうがいいかもと思いました。
オープンハードウェアで公開されていた10層基板でみてみました。◎はパフォーマンスの低下は見られないことを示してて、○は使用できるかなぁといった感じ、△は、表示項目を絞れば使えそうで×は使えそうにない感じです。
解像度 | なし | サブピクセルアンチエイリアシング | SSAA | ||
High | Ultra | 2x | 4x | ||
FHD | ◎ | ◎ | ◎ | ○ | △ |
1440p | ○ | ○ | ○ | △ | × |
4k | △ | △ | △ | × |
|
特にベタの表示がかなり重い印象を受けました。ベタを切ったりレイヤーを非表示にするだけでかなり軽くなります。まぁ、いずれにせよ10層基板でもアンチエイリアシングを切れば綺麗に見えるという結論になりました。
見るときは、普通の有機ELなどではなく液晶ディスプレイで等倍で見ることをおすすめします。少し解説すると、アンチエイリアシングを切れば当然かなりギザギザしてます。SSAAの4倍は一番キレイにエッジがぼかされてます。少しぼやけた見た目ですが、高品質です。サブピクセルのアンチエイリアスは横方向にRGBに並んだサブピクセルの輝度を変化させますが、横方向のみエイリアシングが目立たなくなります。斜め線でも結構綺麗になります。1pxのラインにはアンチエイリアシングがかからないようです。
グラボ使ったとき
最高のアンチエイリアシング設定でもかなり動きました。パフォーマンスはかなり向上します。
Blender
blenderは、ポリゴン数に応じて負荷が重くなります。ハイポリゴンな球を設置してビューポートのパフォーマンスを見てみました。オンボードグラフィックのときは〜2M個の三角形までは快適、5M個があるオブジェクトの描画でガクガクになります。グラボがあると、その数倍はあっても行けるかなといった感じです。(あくまでも体感的ですが)
これもモニターの大きさやオブジェクトの映り方見え方によってかなりの差があると思うので一概には言えませんが、大規模なシーンを作りたいならあったほうがいいともいます。
ちなみにレンダリングはCPUのみより30倍位速くなりました。これもシーン依存ですが、グラボはあったほうがいいという結果になりました。
まとめ
グラボはあったほうがいいですが、オブジェクトの非表示やレイヤの切り替えをきちんと行って設定を落として負荷を減らせばなくてもなんとかなりそうです。
ただ、そうは言ってもグラボあったほうが快適なので、これらの作業をガチでやりたい人はグラボ付きのPCのほうがいいと思います。
今の世代のオンボードグラフィックって進化してるんですね。昔のラップトップ向けオンボードグラフィックってかなりガタガタだったのですが、今のものは統合型グラフィックでも良かったかもと思いました。Intel とAMDが競争してくれたおかげですね。
無料の動画編集ソフトの比較(blender,shotcut,ymm4α,aviutl)
最近はyoutubeとかの動画の力が増してきてて動画編集とかもホットになってきています。
動画編集ソフトにはいろいろありますが、無料にフォーカスしてみたいと思います。いろいろ使ってみて少し思ったことなどを書きます。
1. blender
Blenderって3dアニメーションのためだという印象が強いのですが、動画編集もできます。ノードエディタも強力で、いろいろなことができて高機能ですが、いまいちな点としてはプレイバックが重いです。キャッシュを増やすこともできますが、それでも長いものを編集するにはそれなりの根気が必要かもです。
クロスプラットフォームなのでLinuxでも動きます。
2. Shotcut
Shotcutは海外製のオープンソースの動画編集ソフトで実際にいろいろな動画を編集してみました。特にエフェクトやエクスポートの機能は充実していてエンコードが高速であるのが特徴です。
その一方で動作が不安定で落ちたりプレイバックはそれなりなんですが再生位置移動が弱いです。結構重い部類。今後の開発次第ですね。あと日本語も少し弱いかも。
クロスプラットフォームなのでLinuxでも動きます。
3. ymm3(ゆっくりムービーメーカ3)
これはあまりお勧めしません。ymm4αをお勧めします。
4. ymm4α
α版ですがかなり安定していると思います。今まで落ちてません。今現在(2020年3月)も活発に開発されています。
動作はかなり高速です。(最初のほう不安定かなと思いましたがエンコーダやデコーダは外部で導入する必要があるようです。)
再生位置移動はかなり素早く、プレイバックもスムーズです。また、動画が1080pでもかなり高速に動作できます。レンダリングにグラフィックアクセラレータを使用しており、非常に早くレンダリングできるようです。複数レイヤーの重くなりやすい処理もかなりスムーズに再生できました。これ無料ってやばくない??ってレベルです。
書き出しも結構早いです。グラボもちゃんと使ってるようで、あっという間に書き出せます。
基本的な編集はこれでやってもいいと思います。機能は他と比べるとそこまで多くはありませんが基本編集はできます。とにかく軽くて安定しててとても好きです。
機能が足りないときはaviutlにエクスポートする機能もあります。どうしてもってときはエクスポートするのもいいと思います。
一部の人にはどうでもいいかもしれませんが、欠点としては機能が少し少ないのとバックグラウンドでもGPU食われるので必要ないときは保存して終了しないと電気食われます。これ簡単に解決できそうな話なので早く解決してほしいですね。GPU10~20%くらい常に食われるのはノートPCには少しきついかもしれません。それでも他よりもめちゃめちゃ軽量なので、放置しなければ野外でもこれが一番バッテリーが持つと思います。
5. aviutl
高機能です。プラグインは豊富です。これもいいところですね。ただ重いです。カーソル移動とかは激重で12スレッドCPUでも100%に張り付きます。プレイバックも1レイヤですら結構重ためです。FHDは少し重め、720pくらいまでなら何とかなると思います。(正直720pで十分綺麗だと思います。)
機能については、かなり豊富にあるなという印象です。
ymm4と似ています。使いこなしたい場合はaviutlでもいいと思いました。
まとめ
blenderは、ノードエディタを通じた画像ごとの編集(コンポジット)とかそういった用途は向いている印象がありました。動作は軽量ではないのでなめらかにプレイバックはできなそうです。
Shotcutは、プレイバックはリアルタイムにできるのですが、再生位置移動が重い印象です。あと不安定です。
ymm4αは、一番好きです。めっちゃ軽いし動作も安定しています。最低限の機能はそろっていますが、必要に応じてaviutlの力を借りてもいいと思います。
aviutlは、プラグインも豊富で拡張性は良さそうです。ymm4αでは足りない分補完できるかなという感じです。再生位置移動が重めです。プレイバックはFHDではなめらかです。
個人的には大体の編集をymm4αで行い、足りない分をaviutlで仕上げるのが一番いいと思います。