Windows10とMacOS(BigSur)でメモリ管理の比較をしたら？

Windows10とMacOS(BigSur)でメモリ管理の比較をしたら？

2020年12月26日

Windows10 と MacOS(BigSur)でメモリ管理の比較をしたら？

最近、新しい Mac(M1 MacBook Air)を買ったので色々なテストをしています。 前回までの記事で、Firebase などを使った Web 開発が主目的の場合、エントリモデルの８ GB メモリ／２５６ GB の SSD のモデルでも十分と書いていますが、もう少し具体的な根拠がないかと思い、少しメモリの使用容量のテストをしてみました。

MacOS (BigSur)は動作の限界がありました

結論から書いてしまうと、MacOS の方はテストの途中で限界に達しました。 このように書くと、Windows １０の方が良いのか？という疑問も出てきますが、今回行ったテストは現実的な PC の使用形態でのテストではないので、結果を見ると実用上問題になる物ではないと言えます。

行ったテストは？

Web 開発ということで、Vue のプロダクションイメージ（公開用のデータ）を作るのにかかる時間を計測しました。 計測は、あるプロジェクトで作った UI をビルドする時間を Vue UI が表示する時間を基準に比較を行うという物です。

基準の時間は、システムを起動して Vue UI の GUI を起動して、公開用のデータをビルドした時の時間を基準にしてメモリの使用量を増やして行くとどの様に処理時間に影響が出るかを調べた物です。

最初に時間を計測した後、幾つかアプリを立ち上げています。

  • Vscode で３つのプロジェクトフォルダを開く
  • Adobe のアプリ（フォトショップ、ライトルーム、イラストレータ、プレミアプロ）を開く
  • Microsoft のオフィス（ワード、エクセル、パワーポイント）を開く

その上で、Google Chrome のタブを一つづつ開いて、YouTube のビデオを再生することでメモリの使用量を増やした上で、同じ公開用のイメージの作成時間を測るという方法でデータを取りました。

比較は２台の PC でおこないました

  • M1 MacBookAir 　（BigSur)
  • Intel Core i3 (4005U/4th Gen)　(Windows10/20H2)

どちらもメモリは８ GB です。

最初の処理時間

普通にシステムを立ち上げてイメージをビルドした時間です。 当然、最新の CPU を搭載している Mac の方が高速で約２倍程度の差があります。

M1 Mac(sec)Core i3 4th Gen(sec)
Vue イメージ作成2240

条件は同じではありませんが、この時のメモリの使用容量は、

Mac (M1)Windows(Core i3)
Vue イメージ作成事４.８ 0GB５.６５ GB

でした。

YouTube を再生するタブを増やしていくと

Google Chrome のタブをあけて YouTube の再生を行う数を増やしていくと、処理時間が多くなって行きます。Mac の場合、YouTube の再生タブが４２になった時点で Vue UI のサーバーがクラッシュしました。Windows10 の場合は４７でもタブを開いて再生できました。しかし、Windows の場合、途中から（２０を過ぎたあたり）から動画の動きがスムーズでなくなり、タブは開けられるものの実用的ではありませんでした。Mac の方はクラッシュする直前まで実用範囲内でした。

Mac(M1)(rasio)Windows(Core i3)(recio)備考
122.4(1.0) / 5.4GB40.2(1.0) / 6.5GB
522.2(1.0) / 4.6GB44.8(1.1) / 6.7GB
1021.9(1.0) / 6.0GB50.2(1.3) / 7.1GB
1522.5(1.0) / 6.3GB53.3(1.4) / 7.2GB
2023.2(1.0) / 6.4GB56.8(1.5) / 7.1GB
2523.7(1.1) / 6.4GB57.5(1.5) / 6.7GB
3023.9(1.1) / 6.5GB69.1(1.8) / 7.0GB
3532.3(1.4) / 6.7GB72.1(1.8) / 6.7GB
4048.4(2.2) / 7.3GB86.4(2.2) / 7.2GB
45-- / --122.2(3.1) / 7.4GBMac は開発用のサーバーがクラッシュ

Mac の場合クラッシュしてしまいましたが、タブが３０前後までは、処理時間に大きな変化はなく、実用上どちらが上かと言うと Mac の方が実用上は上です。ただし、これはメモリの管理能力だけではなく、CPU の処理能力も関係しているので比較するのは少し無理があると言えます。

Windows １０の方は、Vue のイメージ作成中は概ね 7.5GB から 7.７ GB のメモリを消費する感じで、上手く必要なメモリを確保しているようです。Mac の方は徐々に使用容量が増えていく感じでした。Mac の方がメモリ上に圧縮したイメージを残しているようで、このサイズが増えすぎるとクラッシュしてしまうようです。Windows １０の場合は圧縮したイメージは１００ MB 程度しか使用していないようです。

これからわかることは？

子の実験からわかることは、OS が使うメモリを上手く管理しているということです。実際にアプリを沢山起動したり、Web ブラウザのタブを沢山開いた場合、多くのメモリが必要になります。しかし、OS が上手く調整してくれるので何もしていない場合にメモリの半分以上を使用しているとしても、負荷の高い仕事を動かしてもメモリがすぐに不足すると言うわけではありません。

動画の編集の場合、一度に大量のメモリが必要になることもあると思いますが、短い動画の場合は、実験の結果を見る限り十分 OS が管理できる範囲だと考えられます。つまり、多くの PC で行う仕事は常識的な使用では、メモリ不足で仕事ができなくなる可能性は少ないという事です。

もちろん、狭いメモリの範囲をやりくりする事を考えると、大きなメモリがあった方が高速に仕事ができるのも事実です。しかし、YouTube のビデオ再生のタブを３０個開けても処理時間が余り変わらなかった事を考えれば実用上は、８ GB のメモリで遅くなると言うのは殆どないと考えても良さそうです。そう考えると、エントリモデルの８ GB のモデルはお買い得と言えるのではないでしょうか？

まとめ

Firebase などの Web 開発を行う場合、Mac に限らず、８ GB のメモリがあれば、最新の Windows10 をインストールしていれば、殆どの場合十分に対応できると言えます。

ただ、負荷をかけた場合、実用的な処理ができる限界は MacOS の方が上という印象です。 Mac はある時点で、アプリがクラッシュすることがありましたが、実用上は大きな問題ではないと思います。Windows は処理時間の低下が早い段階でおきましたが、これは CPU の処理能力も関係していると思われます。

機会があれば、最新の CPU を使った状態での Windows のテストをしてみようと思います。

Copyright(c) 2017-2020 by Silicon Valley Super Ware, all rights reserved.

コメント

コメントを投稿

このブログの人気の投稿

ユーザーインターフェースの設計

イメージ
ホーム ブログ Firebase情報 ユーザーインターフェースの設計 2022年10月12日 ユーザーインターフェースの設計 前回は、入力フォームを変更して四則演算をできるようにしました。利用しているフォームは数式の穴埋め形式になっています。計算をする場合、一般的な電卓のようなインターフェースの方が一般の方には使いやすい場合が多いと言えます。今回は、ユーザーインターフェースを変更して一般的な電卓のようにする方法について考えてみました。 HTML でデザイン これまでの、ユーザーインターフェースは、数式の穴埋め形式のフォームでした。 今回は、一般的な電卓のようなユーザーインターフェースを実現します。 この記事では、プログラムの部分は取り敢えず別にして、まずはユーザーインターフェースを作成することにします。 Web アプリの場合、ユーザーインターフェースは基本的に HTML で記述します。 今回の電卓形式のユーザーインターフェースは、電卓の数字を表示する部分（ディスプレイ部分）と数字や演算子を入力する部分（ボタン部分）に分けて考えることができます。 HTML では、「input」のタグでディスプレイ部分を、「button」のタグでボタン部分を記述できます。 <!DOCTYPE html> <html> <head> <title>Calculator</title> </head> <body> <div class="calc"> <div> <input class="display" type="text" /> </div> <div class="keypad"> <div> <button class="clea
続きを読む

足し算以外もできるようにする

イメージ
ホーム ブログ Firebase情報 足し算以外もできるようにする 2022年9月29日 足し算以外もできるようにする 穴埋め形式の数式のフォームを使って足し算をするプログラムを紹介しましたが、同じ要領で、引き算、掛け算、割り算もサポートできるとさらに便利です。この記事では、足し算のプログラムを拡張して、整数の子息演算をできるようにした例を紹介します。 演算子を選べるように変更する 足し算のアプリでは、計算できるのは足し算だけだったので、フォームには「＋」を固定で表示していました。 この部分に変更を加えて、必要な演算子を選択できるようにすれば、引き算、掛け算、割り算もサポートできるようにできます。 これには、HTML の記述を変更してフォームを変更する必要があります。 <label>+</label> を以下のように変更します。 <select onchange="operatorChanged(event)"> <option>+</option> <option>-</option> <option>*</option> <option>/</option> </select> HTML の「select」タグを使って、選択肢は、「option」タグで記述するだけです。 演算子の変更を反映する プログラム側でやることは三つです。 初期状態の演算子を設定する　（最初にフォーム上で表示されている演算子をセットする） 演算子の変更を検出して、現在選択されている選択肢を更新する 「Calcullate」ボタンがクリックされたら必要な処理を呼び出す 現在どの演算子が選択されているかを知る必要があります。実装方法は幾つかありますが、今回は選択が変更される度に現在選択されている演算子を更新する方法を採用した例を紹介します。 これには、現在選択されている演算子を保存する変数「operator」を用意して管理します。
続きを読む

改良版足し算プログラム

イメージ
ホーム ブログ Firebase情報 改良版足し算プログラム 2022年9月15日 改良版足し算プログラム 前回は、入力データのチェックを工夫することで、データを処理する前に想定外のデータの入力を制限するユーザーインターフェースの設計について紹介しました。この記事では、そのコンセプトを使って、実際に足し算をするプログラムにしてみました。今回のポイントは、ユーザーインターフェースとデータ処理を分けるという点に注目してみました。プログラムの設計の際には、この二つの境界をきちんと設定する事が大切です。 データの処理は？ このプログラムは、入力された二つの整数を足して結果を表示するというシンプルなプログラムです。 このプログラムのデータ処理部分は、実は二つの整数の足し算をするだけです。 つまり、プログラムのデータ処理部分は以下の関数「add(a, b)」だけです。 function add(a, b) { return a + b; } 処理自体は、二つの整数「a」と「b」を受け取って、この二つの整数を足し算した結果を返すというシンプルなものです。 残りのプログラムは？ このプログラムのデータ処理部分は、至ってシンプルです。 では、残りのプログラムは何かというと、これがユーザーインターフェースになります。 <!DOCTYPE html> <html> <head> <title>Add Program</title> </head> <body> <div> <input id="opeland0" type="text" placeholder="Please input integer" /> <label>+</label> <input id="opeland1" type="text&qu
続きを読む