M1 Macのファイル処理の性能

M1 Macのファイル処理の性能

たまたま、開発中のコンピュータのプリント基板の設計支援アプリでかなり大きなテキストファイルの処理があったので、ファイルの処理時間の性能をテストしてみました。

ファイルの概要は、1,641,089 行のテキストファイルでキーワードを元に必要な情報を抽出する処理をしています。

これは、データの処理をしているので CPU の処理時間も関係はしますが、処理時間の多くはファイルの読み込みによるものが大きくなる例です。 以前の Vue の公開用のイメージ作成の場合は、ファイルの読み込みもありますがどちらかと言うとデータの処理時間の方が大きい処理です。

M1 Mac と Pentium G3258 の比較

M1 Mac と Pentium G3258 のデスクトップで比べてみました。 M1 Mac は８ GB のメモリ、Pentium G3258 は 32GB のメモリを使っているので公平な比較ではありませんが、興味深いデータが出たので紹介します。

まずは、結果です。

M1 Mac　 　Pentium G3258　 Ratio

ファイルの読み込み 　1175msec 　1927msec 　　　0.6

Vue のイメージ作成 　21.73sec 　　26,14sec 　　　0.83

参考まで、以前紹介した Vue の公開用のイメージの作成の所要時間も入れてあります。

Pentium G3258 は 6 年以上前の CPU ですが、Vue のイメージの作成にかかる時間をご覧になると分かるかと思いますが、最新の M1 チップと比べても良い勝負をしています。時間換算すると、M1 チップは Pentium G3258 の処理時間に比べて８割程度の時間で処理しています。

ところが、大きなテキストファイルの処理になるとその差が大きくなっています。M1 チップと Pentium G3258 の処理時間の比率は、約６割です。

テストのケースでは、Javascript のコンソールへのデバッグメッセージは最小限にしているので差が少なくなっていますが、実際はデバッグのメッセージを表示させると更に差が大きくなります。

この実験結果が示す物は何か？

ただ処理時間を比較しただけでは面白くありませんよね？

そこで、この数字の差はどこから来るかを考えてみました。

Vue の公開イメージの作成の処理時間が近い理由

まずは、6 年以上前の CPU と最新の CPU の処理時間があまり変わらない理由です。

一番の理由はメモリ容量の差です。この処理はファイルの読み込みよりはメモリ上のデータの処理が中心になります。勿論、ソースコードを読み込んで作成するイメージを書き出す処理もありますが、中心はデータ処理になります。

M1 Mac のメモリの使用量をみていると分かりますが、M1 Mac のメモリ管理が改善されて効率よく処理をしていると行っても、スワップは発生しています。 スワップとは、メモリ上のデータで行われている処理では使っていないデータを一時的にディスク（この場合は SSD）に退避させて、使用する際は SSD からメモリにデータを戻したりする処理です。

一方で Pentimum G3258 の場合、メモリ容量は３２ GB もあるので、スワップは発生していません。少し前のシステムでメモリのアクセススピードも SSD のスピードも M1 Mac に比べると遅いのですが、SSD のアクセススピードとメモリのアクセススピードでは数桁の違いがあります。スワップの発生しない Pentium G3258 の場合、一旦メモリに読み込んでしまえば、SSD にデータを退避させる事なく処理ができるので CPU の処理が遅い分をカバーしていると考えられます。

参考データですが、古い Windows のノート型の PC の場合、M1 Mac と同じ８ GB のメモリの PC では、倍以上の処理時間がかかっています。（ただし、CPU の処理能力も低いので公平な比較はできません。あくまで参考です。）

大きなファイルデータの処理は M1 が速い理由

一方で、大きなファイルのデータ処理は、M1 Mac が更に優位に立っています。 この理由も考えてみました。

この理由は、ファイルへのアクセスの時間の差から来ています。 今回のファイルは、約 160 万行もある大きなファイルです。

当然、ファイルの読み込みには時間がかかります。ファイルは SSD に保存されているため、ファイルの読み込みは SSD からデータを読み出す時間が支配的になります。当然、データの処理も行っているのでデータの処理時間ももう一つの要因です。

Pentium G3258 の PC は SSD は SATA の物を使っています。（SATA の M.2)です。一方で M1 Mac の場合は、NVME の SSD を使っています。NVME は、実際のインターフェースは PCI エクスプレスを利用しているので、SATA より高速にデータ転送ができます。読み込みの回数が多くなるので、僅かなアクセスタイムの差が大きな差になって現れます。

このファイル処理は CPU での処理は少ないので処理時間の大部分はファイルの読み込み時間の差だと考えられます。

Web 開発に使う PC の場合余り大きなメモリが必要ない理由

ところで、この開発では別の経験もしました。 実は、現在の開発は従来、Java のデスクトップアプリで処理していたものを、Web 版に移植して機能の追加、改善をするという物です。

テストに使ったテキストファイルの行数は約 160 万行ですが、元々は別の形で設計データを抜き出しているファイルを使っていて、そのファイルは約１０倍の行数があって、重複するデータが含まれていました。（約 1600 万行）

このファイルは Java のプログラムでは問題なく処理できたのですが、Javascript で同じファイルを読もうとするとエラーになりました。原因は Web ブラウザのサポート範囲を超えているためでした。

対策としてバックエンドで処理をすることも考えましたが、別の形でサイズの小さいデータを抽出することで解決したのでフロントエンドだけで処理ができました。

勿論、仮想環境でテストをしたり、バックエンドの処理などで大きなデータを扱う場合は大きなメモリを持っている方が有利といえます。 しかし、多くの Web アプリの利用者は大きなメモリの端末（PC やスマホ）を使うケースの方が少なくなります。

それを考えると、大きなメモリの PC で余り意識せずに大きなメモリを使用するアプリを作るよりは、工夫して、限られたメモリで上手く動作するアプリを作った方が利用者にとって良いアプリが作れるとも言えます。

お金に余裕がある場合、大きなメモリの PC を買うこと自体は何も問題ないと思いますが、殆どの Web 開発は、８ GB のメモリでもここ数年は対応できるのではないかと言うのが個人的な見解です。

まとめ

M1 Mac の性能の比較を今回は大きなファイルの処理でやってみました。

結果自体は、予想通りでしたが、これから言えることは、M1 Mac は CPU の処理能力だけではなく、ファイルのアクセスなど総合的なシステムの性能を実現しているコンピュータであることが再認識できました。

今回は、動画や高解像度の写真ではありませんが、大きなサイズのファイルを複数扱うアプリを Java と Javascript(Typescript)のプログラムで処理を行っていますが、M1 Mac の８ GB メモリモデルで十分に対応できています。