本年9月のバージョンアップ (Ver. 5.6) によって内部 32bit 処理化に踏み切りました。それでどの程度消費メモリ量に影響があるのか、あるいはどの程度データ量が増えた分だけパフォーマスンが落ちているのか気になったので、ちょっと実験してみました。
まず、8G のメモリを積んだ MacBook Air (ARM M1チップ, 2020年発売) では、7500 x 5000 ピクセルの画像を処理させるとエラーで途中で止まってしまいます。プログラム上はミスがないはずなので、どうやらメモリ量が確保出来ずに止まってしまうようです。なお、ImageJ 上のオプションでメモリは 約8 G を確保しています (以下いずれも同条件です)。
今度は同じファイルを 6000 x 4000 (6000p) ピクセルの画像を処理してみると、時間は 11 分ほどかかりますが、処理は可能でした。
4000 x 2600 (4000p) ピクセルの画像では、処理時間は 4 分ほど、2400 x 1600 (2400p) ピクセルでは 2 分ほどです。1920 x 1280 (1920p) では、1 〜 1分半ほどでした。
さらに、Macbook Air で 16G のメモリを積んだモデル (ARM M2, 2022年発売 8スレッド) では、1920p で 1 〜 1分半、2400p で、1 分半前後、4000p で、3 分半程度、6000p で、6 分程度、7500p で、9 分半程度というところでした。
尤もマニュアルでファイルを選んだり、選択肢を選択する過程が含まれていますので、純粋な PC 処理時間で比較しているわけではありません。
ピクセル数では、1920p を 1 としますと、2400p では約 1.5 倍、4000p では約 4.2 倍、6000p では約 9.7 倍、7500p で約 15 倍なので、8G M1 のマシンの場合、ほぼピクセル数分時間がかかっています。なお M1 の 8G メモリと M2 の 16G メモリでは 6000p では処理時間が半分近くになっていますが、4000p ではそこまで速くなっていないので、もちろん、マニュアル操作のもたつきの問題もあるかもしれませんが、CPU 効果よりも、メモリ量効果の方が大きいのではないでしょうか?
やはり 8G のメモリを積んだ Windows マシン (ノートPC Panasonic CF-Z6, 2017年発売 + Windows 10) では、1920p で、50秒程度、2400p ではやはり 1分半程度、4000pでは4分弱、6000p では 6分半、7500p では、15分以上と非常に時間がかかりましたが、Mac のようにエラーが起こることはなく、何とか終わりました。なおこのモデルはインテル Core i5 の第7世代を搭載した CPU を採用していますが、2020年発売の ARM M1 CPU を採用した Macbook より速い速度で処理します。M2 + 2倍のメモリ搭載のMacbook Air にもほぼ速度的に迫ります。
さらにより古い 13 年前発売のインテルの第2世代の Core i7 (4 コア、8 スレッド) を搭載し、メモリに 24G を積んだデスクトップでは、7500p の画像でも 5分程度、6000p は3分強で処理しますので、CPU の性能よりもメモリの搭載量の方が処理速度に対して効果が効くようです。おそらく仮想メモリを使わずに済むので、処理速度が早いものと思われます。しかも 2 年前発売の Macbook Air 16G よりも処理速度が速く半分近い速度で処理します。
また、Intel 第12世代の Core i5 に 32G のメモリを積んだマシン (12スレッド) では、7500p のファイル処理に 3 分ほど、6000p で1分4~50秒程度でした。
なお、ImageJ でどれほどのメモリとスレッドを使うのかは [Edit] → [Options] → [Memory & Threads... ] で指定できます。
Mac ARM系 CPU はインテルの CPU より性能が良いと喧伝されていましたが、実用上はさほどでもない (むしろ劣る?) ようです。もっともこれは ImageJ が依拠する Java が Mac OS にあまり最適化されていないためかもしれません。Java 自体、ARM 用 Mac OS 上ではロゼッタ2を使って走っているはずです。
とはいえ、ARM M2 + 16G のマシンが、いくらメモリ量は多いとはいえ、13年前の Core i7 + 24G メモリのマシンに負けてしまうとは... 端的にクロック周波数の問題なのでしょうか? 13年前のデスクトップ向け Core i7 は明らかに周波数が高く、最近の CPU は省電力のため低めになっているのは確かです。GPU や NPU を使わない場合は、ARM 系チップのメリットはないということかもしれません。Adobe 系の画像処理ソフトで固めている場合はメリットが大きいかもしれませんが、FOSS だとメリットがあるのは darktable ぐらいでしょうか。
さらに、おなじ Panasonic CF-SZ6 上で Ubuntu を走らせて試してみると、1920p で1 〜１分半程度、2400p で 2 分程度、4000p で 4 分程度、6000p で 8 分弱、そして 7500p では途中メモリ不足でハングアップしてしまいました。Unix 系 OS では元の物理メモリの大きさに応じて確保できる仮想メモリ量に限界があるのかもしれません。また、Windows 10 の方が Ubuntu よりも実行速度が速めというのも意外でした。Linux の方が最低必要メモリは、Windows より少なくて済むと言われているのに、実行速度が遅めとは... ただ、ART も Linux より Windows の方が処理速度が速めのような気がしていたので、ほぼ体感速度に合致します。
それはともかく、32bit 処理版では、Intel アーキテクチャマシン、iMac を問わず、物理メモリ 8G だと本ツールで処理できる画像の大きさは、6000 x 4000 ピクセル程度がほぼ限界のようです。
なお、非32bit 版 (オリジナル画像の bit 深度で処理する) の実行処理速度と 32bit 版の実行処理速度を比較すると、インテルの第2世代の Core i7 (4 コア、8 スレッド) を搭載し、メモリに 24G を積んだデスクトップで、16bit 6000p の画像を処理すると 2分弱でした。32bit 版では、3分強ですので、処理時間は 2/3 程度になります。また 7500p では2分半と、処理時間は半分近くになります。
インテル第7世代の Corei5 + Windows10 で 8G メモリ + 16bit ファイルの場合は、6000p で処理時間は 3 分程度、7500p では 6分強というところでした。32bit 版と比べると半分以下となっています。やはり処理するデータ量が小さいようなので、おそらくメモリの消費量も少ないものと思います。
率直に言って、非32bit 版でも、変褪色の状態が中程度までで、かつ処理するファイルのビット数が 16 bit なら、そんなに悪くはありません。メモリサイズや CPU パワーが限られている場合は、16bit ファイルを使っていただくことを前提として、非 32bit 版をそのまま使っていただくのも手です。その場合非 32bit 版の最終バージョンは現状 8 月にリリースした、Ver. 5.53 ですので、これを使っていただければと思います。
なお、現在次期バージョンのアップデートに向け開発 & テスト中ですが、8bit で変褪色がひどい画像の場合は、32bit & リニア処理の効果が出ています。次バージョンが 32bit 処理版のある程度決定版になるのではないかと思っています。ただ、32bit 化で結構パフォーマンスが下がっているのでなにか考えなくてはならないかもしれません。
-----------
Intel 第12世代と Apple M2 を比較した記事を見つけました。
pc.watch.impress.co.jp Intel のノート向け第12世代の CPU は Apple M2 より 118%早いとありますが、こちらの結果では Intel の第12代 (ただしデスクトップ向け Core i5) + 32G メモリと M2 + 16G メモリでは、6000p の画像処理で、Intel のほうが4倍早いです。Intel 第2世代の Core i7 + 24G ですら M2 の2倍の速さです。
M2 のキモは GPU にあるようですが、おそらく Java および ImageJ は全く GPU を使っていないと思います。それにしても... おそらく電力消費量のわりにはパフォーマンスが高いということなのでしょうか。
Mac に関してはこんな記事も見つけました。
またこんな記事も。M3 よりも M1 の方が速いようです。
