Linux内のWindows7は、メインOS（特にグラフィックスとビデオ）と同じくらい優れていますか？
新しいLinuxユーザー。 VMPlayerを介してUbuntu/LinuxMint内でWindows7を実行することは、メインOSとしてWindows7を実行することとまったく同じになるかどうか疑問に思っていました。
「同じ」とは、特に次のことを意味します。
グラフィックとビデオのレンダリング品質は同じくらい良いでしょうか？
HDMIやWiDiの使用などのハードウェアの問題はありますか？
RAMが割り当てられている限り、アプリケーションは同じようにスムーズに実行されますか？
目立った違いがないためには、マシンはどれほど強力である必要がありますか？私のマシンの特定の仕様は次のとおりです： http://www.gadgetspecs.info/2011/07/asus-u46e-bal5-review-of-specs-and.html 。 SSDもインストールしています。
背景：現在、Windows7内でLinuxMintとUbuntuを使用して反対の設定を行っていますが、ビデオ品質がWindows7ほど良くないことがわかりました。
私は以下の私の答えに多くを追加しましたが、参考のために元の答えをそのまま残しました。
TL：DR：仮想マシンはツールであり、あるOSを別のOS内で簡単に使用できる一方で、システムを最大限に活用するためには、コンピューターの本来の主な用途を十分に認識する必要があります。 。
あなたの質問は、仮想マシンを使用した場合のグラフィカルおよびインターフェースパフォーマンスの可能性に大きく傾いているようです。そこで、その可能性についてお答えします。
主な問題は、デバイスへのゲストオペレーティングシステムのアクセスを安全に管理するために（したがって、ゲストOSがホストを踏みにじって物を壊すのを防ぐために）、使用するすべてのデバイスを「エミュレート」する必要があることです。
これが意味するのは、ゲストOSが見ることができるグラフィックカードは、ホストOSが見ることができるグラフィックカードと同じではないということです。ゲストで3Dレンダリングなどの機能を有効にできる場合がありますが、これはゲストの中間ドライバーによって処理され、3Dがそこでレンダリングされるように、リクエストを安全な方法でホストに渡します。
サポートされているHDMIディスプレイでブルーレイディスクを安全に再生するために必要な機能がゲストグラフィックカードドライバによってエミュレートされることは非常に疑わしいため、これは機能しない可能性があります。
基本的に、ホストでハードウェアサポートを必要とするものは、ゲストではうまく機能しない可能性があります。 WiDiの仕組みはわかりませんが、テレビで共有するためにビデオカードメモリに直接アクセスする必要がある場合は、ホスト（Linux）オペレーティングシステムから使用しない限り機能しません。
それ以外のパフォーマンスの点では、a VMはメインOSの場合に近づく可能性がありますが、ハードドライブデバイスへのアクセスや他のデバイスとの競合に関しては常にペナルティがありますホストが使用しているリソース。
はじめに...
最初はコンピューターがありましたが、そのコンピューターで実行できるオペレーティングシステムは1つだけでした。そのオペレーティングシステムは、マシンに搭載されている特定のプロセッサやその他のハードウェアでのみ正常に動作する傾向があり、他のオペレーティングシステムは、使用可能なネイティブハードウェアでしか動作しませんでした。
ある特定のプラットフォーム用のソフトウェアを別のプラットフォームで使用できるようにするには（たとえば、Commodore AmigaでPre-OSX MacOSソフトウェアを使用する場合）、「ソフトウェアをインストールする」だけでは不十分です。これら2つのマシンは、まったく異なるプロセッサアーキテクチャと補助ハードウェアを使用していました。あるOSを別のマシンのハードウェアで実行する方法はありませんでした。
エミュレーション
エミュレーションは仮想化の従兄弟のようなものであり、実際には関連しており、同様の目標があります。片方がもう片方を生んだ。
これらの異なるハードウェアプラットフォームが意味するのは、マシン上の別のOSのソフトウェアを使用する場合、そのマシンに関するすべてを分析して、その動作を確認する必要があるということです。 、次に、ハードウェア部分と同じように機能するように記述されたコードの一部。これは、プロセッサ、グラフィックコントローラ、メモリコントローラ、すべてのすべての部分に対して実行する必要がありました。
次に、これらのすべての部品がまとめられ、各部品がハードウェアのビットをエミュレートするので、これをエミュレートされたマシンと呼びます。次に、このエミュレートされたマシン上でオペレーティングシステムを実行します。
問題は、このアプローチが遅いことです。元のハードウェアの1/10の速度を達成できれば、非常に簡単に言えます。エミュレートされたコンピューターをフルスピードに近い速度で実行するには、文字通り、ターゲットのエミュレートされたマシンよりも数倍速いマシンが必要でした。
では、何が変わったのでしょうか？
さて、ここにクールなものがあります。それほど多くはありません。唯一の大きな変更は、ハードウェアプラットフォームが標準化されたことです。すべてのOSのカスタムハードウェアの入手をやめ、すべてのOSが単一の標準プラットフォームに移行または作成されました。
最近のMacを構成するコンポーネントは、概して、PCを構成するコンポーネントと同じです。 Linuxは常にPCハードウェアで実行されていたため、新しいものは何もありません。
あるOSから別のOSでソフトウェアを実行したい場合は、長い間エミュレーションが標準でした。または、デュアルブートしてどちらのオペレーティングシステムも必要に応じて実行できますが、LinuxでのコーディングからWindowsでのゲームのプレイに移行したい場合、これは面倒で煩わしいものになりました。
その後..
基盤となるハードウェアは同じなので、なぜ両方のOSで共有できないのでしょうか？
最終的に、QEMUとWiNE、および同様のソフトウェアソリューションが完成しました。 QEMUは長い間、マシンのハードエミュレーションで人気がありましたが、WiNEは、OS API呼び出しをトラップしてパッチを適用し、コードをプロセッサ上でネイティブに実行できるようにすることで、WindowsアプリケーションをLinux上で実行できるようにしました。
QEMUはWiNEと同様のことを行いましたが、はるかに低いレベルで行いました。それでも事実上エミュレーターですが、行われたすべてのハードウェア呼び出しに対して、「パッチとリダイレクト」方式を使用して、呼び出しが代わりに独自のエミュレートされたハードウェアプラットフォームに送られるようにしました。プログラム内のほとんどの作業コードは実際にはハードウェア呼び出しを含まなかったためです（ほとんどは、結果を表示するための呼び出しが最後にある単純な計算ストリームです）。
これにより、現在の本当にエミュレートされていないマシンのほぼすべてのプログラムの瞬間的な速度向上が実現しました。プログラムは、マシンをどれだけエミュレートできるかに依存するのではなく、「仮想」ハードウェアにどれだけアクセスしたかに依存して、スローダウンで実行されました。速度の1/10で実行するのではなく、ネイティブの場合とほぼ同じ速度で実行するようになりました。
では、現在プロセッサで実行している場合、グラフィックカードが機能しないのはなぜですか？
これらの新しい仮想マシンの唯一の問題は、オペレーティングシステムがその性質上、コンピュータにあるすべてのすべてのハードウェアを直接制御していると想定していることです。メモリ管理などの機能、およびハードウェアへのアクセスの制御。
ただし、これは、少なくとも方法では、仮想マシンがエミュレーションを完全に回避できないことを意味します。それでも、ソフトウェアで特定の機能をエミュレートする必要があります。たとえば、グラフィックスカードやネットワークカードを仮想マシンで実行しているOSに提示して、「ゲスト」オペレーティングシステムがそれを認識できるようにする必要がありますそのハードウェアの完全な制御。メインOS（セキュリティの要件による）は、ハードウェアに直接アクセスするプログラムから自分自身を保護する必要があり、これによりゲストオペレーティングシステムが制限されます。
これを行うには、コンピュータ内のすべてのハードウェアの「仮想」部分をエミュレートする必要があります。現在、すべてのコードはプロセッサによってネイティブに実行されるため、低速ではありませんが、仮想ハードウェアの各部分をソフトウェアで作成する必要があります。これにより、パフォーマンスがわずかに低下し、機能が大幅に低下する可能性があります。 。
つまり、仮想グラフィックスカードは実際のグラフィックスカードと同じ機能を持つことはできず、また持つこともありません。最高のパフォーマンスを得るために、仮想ハードウェアは最も使用される機能をサポートするように作成でき、仮想マシンで3Dレンダリングが可能になりましたが、それでも実際のハードウェアと同じではありません。
これは、ゲストオペレーティングシステムがgenericハードウェアオプションを取得しながら、ホストオペレーティングシステムが最適なハードウェアオプションを取得することを意味します。
仮想マシンは実際のハードウェアほど優れているわけではなく、あるシステムのツールを別のシステムで簡単に操作できるようにするためのツールにすぎません。
だから私は何をしますか？
コンピュータの主な目的を選択する必要があります。
ハイパワーのグラフィックカードで最新のゲームをプレイし、同じグラフィックカードのパワーを使用して400インチHDMI TVでフル1080pムービーを再生したいが、Linuxプログラミングをたまにしか実行したくない場合は、Windowsが最善の策かもしれません。 Linuxをゲストとして使用します。
Linuxカーネルで作業し、コンピューター内のデバイス用のハードウェアドライバーを作成し、場合によってはWindows用のソフトウェアを作成して、「標準」のWindowsシステムの適切な近似でテストする場合は、Linuxの方が適している可能性があります。ホストとして、Windowsをゲストとして。
Macの使いやすさが好きであるが、Windows用にプログラミングしたい場合（またはWindows専用のソフトウェアパッケージが必要な場合）、それもオプションです。
Linuxはゲームをプレイできないとか、MacOSはプログラマー向けではないということではありません。どのOSがあなたのやりたいことにもっと適しているかを言うことができるのはあなただけです。
あなたは本当にあなたがあなたのマシンに何をして欲しいかを理解する必要があります最初に。そうして初めて、仮想マシンで何ができるかを理解できます。
あなたの質問に答えるには：
Will the graphics and video rendering quality will be just as good?
いいえ。エミュレートされたグラフィックカードは、ホストグラフィックカードの一部の機能を提供する場合がありますが、ハードウェアビデオアクセラレーションやCUDAプログラミング機能などの複雑な機能をサポートしない可能性があります。
Will there be any hardware issue such as using HDMI or WiDi?
繰り返しますが、これらの追加機能は、利用可能なエミュレート/仮想ハードウェアの機能ではない可能性があります。
Will applications run just as smoothly as long as enough RAM is allocated?
ほとんどのアプリケーション（特定のハードウェア機能を必要としない限り）は、ホストまたはゲストのどちらかを飢えさせない限り、実際のハードウェアと同じくらい速く実行されますメモリの。
仮想マシン（VM）は、ホストシステムで実行されるプログラムであるため、ゲストシステムがホストにグラフィックカード、ハードドライブ、メモリなどのハードウェアとのインターフェイスを要求する必要があるため、常にホストシステムよりも実行速度が遅くなります。ハードウェアを直接制御することはできません。ただし、ハードウェアがそれを処理できる場合、速度の低下はあまり目立ちません。
これは、プロセッサが一度に1つの命令しか実行できないためです。プログラムは通常、数千または数百万の機械語命令で構成されています。マシンが起動すると、マスターブートレコード（MBR）をスキャンしてブートローダーを探します。次に、ブートローダーがカーネルを起動します。カーネルは、すべてのハードウェアを制御するメインプロセスです。複数のタスクを切り替えるマルチタスクを使用すると、特定の時点で1つしか実行されていない場合でも、一度に複数のプログラムを実行できます。ほとんどのプロセッサは、数学計算の実行に費やす時間の約20％しかありません。マルチコアプロセッサでは、別のコアが計算を行うのを待っている間に次の命令をフェッチできるため、アイドル時間が短縮され、システムが大幅に高速化されます。カーネルに加えて、シェル（ユーザーへのインターフェースを提供）、サービス/デーモン（システム、セキュリティなどをサポートするためにバックグラウンドで実行されるプロセス）、およびアプリケーションがあります。
仮想化ソフトウェアは、他のアプリケーションと同様に、カーネルによって管理されるアプリケーションです。したがって、VMのカーネルはホストカーネルからの許可を待って何かを行う必要があり、頻繁に中断されます。ホストシステムで実行されているプロセスが多いほど、VMに割り当てられる実行時間が短くなり、VMが遅くなります。 VMは通常、物理マシンより3〜4倍遅く実行されます。
ゲームやそのようなものを実行する場合は、RAMと可能な限り多くのカーネル時間を割り当てます。ただし、複数のプロセッサが役立ちます。ただし、割り当てすぎるRAMデータへのアクセスに時間がかかり、ホストシステムで過剰なハードディスクキャッシュが発生する可能性があるため、システムの速度が低下します。ただし、少なすぎると、ゲストで過剰な量のハードディスクキャッシュが発生します。リソースに非常に飢えているので、少なくとも2〜4 GBのRAMを割り当てますが、RAMの半分以上をVMに割り当てないでください。
応答が遅すぎる場合は、デュアルブートをお勧めします。この方法では、両方でシステムリソースを完全に利用できますが、残念ながら一度に1つしか実行できません。これを行う場合、おそらく少なくとも3つのパーティションが必要になります。1つはLinux用、1つはWindows用、そして1つ（またはそれ以上）はファイル用です。
そう。 VMWarePlayerはタイプ2ハイパーバイザーです。つまり、ゲストはOSの上に座っています。タイプ1ハイパーバイザーでは、仮想化プラットフォームはハードウェアの上にあります。 VMWarePlayerがType2 Hypervisor上にあるため、Type 1上のものよりも実行速度が遅くなります。ただし、VMWare Playerには、VMのハードウェア要件をカスタマイズする機能があります。したがって、4GBのRAMを搭載したクアッドコアプロセッサを搭載したシステムの場合、1つまたは2つのコアを提供してから、2GBのRAM（Windows x64の最小要件）を提供する余裕があります。 a VMそれは効率的に実行されます。
たとえば、XPS 14zがあり、Windows 7がインストールされています。私はWindows7を実行していますVMも-私はそれに2GBのRAM＆2つのプロセッサコア（私の4つのうち）を割り当てました。
したがって、プログラム（Notepad ++、Transwiz、Outlook、Word、Excelなど）を実行すると、目立った速度低下はありません。強力なソフトウェア（Photoshopなど）を実行しようとしたことがありません。したがって、使用目的に応じて、タイプ2ハイパーバイザーはニーズに合う場合と合わない場合があります。ゲームで使用したい場合は、ゲームによって異なります。私はいくつかのSteamゲームを実行しましたが、何の問題もありませんでした（FedoraマシンからVM時々）へのRDPです）が、実際にはゲーム。あらゆる意味でのゲームでは、VMを使用してそれを行うことはありません。W7マシンでゲームを行ってから、VM（Fedora、実際に）他のことをするために最も集中的なアプリケーションがハードウェアに最初にアクセスできるようにしたいとします。
VMテクノロジの問題は、メモリを使用して実際のOSを実行している場合、物理メモリを同じ方法でアドレス指定できないことです。AVM image同じ物理アドレス空間を使用して実行された場合、論理メモリアドレス指定を使用します。両方のオペレーティングシステムを同時に実行することはできません。最近のVMは長い道のりを進んでいますが、90％〜95％の品質のゲームとさえ言えます。彼らはまだあなたのゲームをフルスピードで実行する能力を欠いています。その90％-95％は純粋にあなたのコンピュータメモリの論理アドレスと物理アドレスを目的としています。メモリアドレス/割り当ての議論だけをカバーするようになった今、他の問題はWindowsがDirectXを使用することです私の知る限り、VM VMwareを含むソフトウェアは最新のDXを完全にサポートしていません。したがって、DX 9以外のものを使用すると、かなり困惑します。
Linux上のQEMUはおそらくゲームに最適です！
そのため、VMWare Playerを介してLinux Mint 12にWindows 7をインストールしました。 LinuxMint内のWindows7のビデオレンダリングは、メインOSとしてのWindows7よりも劣っています。私は何も設定しておらず、aviファイルのビデオレンダリングを改善するために設定するものがあるかどうかわかりません。
8GBのメモリマシンでは、アプリの実行速度が速いことがわかりました。それは問題ではありませんでした。そうは言っても、私はビデオや写真の編集のようにメモリを大量に消費するものは何も試していません。通常のOfficeアプリだけです。