アカウント名:
パスワード:
Wineが目指すものはUNIX系のOS上に、WindowsのAPIを実装することです。アプリケーションはx86のネイティブコードのまま、x86 CPU上で走ります。
アプリケーションがWindowsAPIを呼び出した時、Wineがこれを受け取りWindowsの代わりの動作をします、実際には対応するUNIX系のAPIをWineから呼び出すことになりますから、その分少しだけ手間は掛かりますが、UNIX系のAPIも、x86 CPUの上のネイティブコードで走ります。
アプリケーション本体とOSの両方ともがネイティブコードで走っていますからアプリケーションが仮想マシンのコードで走っている JAVAや.NET
Javaは下手に作ったC製より早いと言われていますよ。これはGUIも含めてなのかわからないけど。.NETはVB6に比べたらむちゃくちゃ遅い。GUIのアプリで実際に体験。差は明らか。特に起動が遅い。昔のJava並。
むかーしDebian上でWineで動かしたときはそこそこの速度でした。
Android上でWine動けば面白いとは思うけど、動かしたいアプリって思いつかないな。操作しにくいだろうし。むしろ、Windows上でAndroid動いたほうが色々便利。で既に複数ありますね。
・・・紙芝居系ゲームがお好きな方々向け？
それって結局、下手に作らなければCの方が早いと言う事ですよね？さらにいうなら、javaに下手に作ったらさらに遅いわけで。。。。
今のjavaなり.netは多少へたでもjitやhotspotががんばってくれる。がっちりチューニングすればcのほうが速いのは当然だけど
今のCなりC++は多少下手でも、コンパイラががんばってくれる。
訳ですが。
近年のJIT技術はC/C++コンパイラと同じ静的解析をふつうに取り入れてますし、C/C++では出来ない動的最適化が可能なぶんだけ有利なのは間違いないでしょう。「多少下手でも」のレベルならやっぱりVMのネイティブコード化に軍配が上がると思います。
動的コンパイル自体がオーバーヘッドだから、動的最適化で数%効率が上がったとしても不利なことには変わらないんじゃないかな。それにC/C++コンパイラならJIT以上の時間をかけて同じ最適化が出来るはず。x64ならSSE２までは標準の命令セットに入っているから。そこまで不利なわけでもない
VC6のコードvs最新VMとか、下っ端が書いた下手なC++コードvs最新VMなら最新VMが勝つと思います。が、VC2012vs最新VMで同じ人が書いたコードなら間違いなくVC2012の早い
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
これを思い出した (スコア:2)
この手のモノって、動作速度はやはり色々キツそうですね。。。
Wine on Android があったとして、どういう風な使われ方をされるのか自分には検討つきません。
#
誰か「こんなのができるんじゃない？」とか返信投げて戴ければ幸いです
----- ド素人につき突っ込み歓迎 アルミ製なので叩くと凹みます
Re: (スコア:3, 興味深い)
Wineが目指すものはUNIX系のOS上に、WindowsのAPIを実装することです。
アプリケーションはx86のネイティブコードのまま、x86 CPU上で走ります。
アプリケーションがWindowsAPIを呼び出した時、Wineがこれを受け取り
Windowsの代わりの動作をします、実際には対応するUNIX系のAPIをWine
から呼び出すことになりますから、その分少しだけ手間は掛かりますが、
UNIX系のAPIも、x86 CPUの上のネイティブコードで走ります。
アプリケーション本体とOSの両方ともがネイティブコードで走っています
からアプリケーションが仮想マシンのコードで走っている JAVAや.NET
Re: (スコア:0)
Javaは下手に作ったC製より早いと言われていますよ。これはGUIも含めてなのかわからないけど。
.NETはVB6に比べたらむちゃくちゃ遅い。GUIのアプリで実際に体験。差は明らか。特に起動が遅い。昔のJava並。
むかーしDebian上でWineで動かしたときはそこそこの速度でした。
Android上でWine動けば面白いとは思うけど、動かしたいアプリって思いつかないな。操作しにくいだろうし。
むしろ、Windows上でAndroid動いたほうが色々便利。で既に複数ありますね。
・・・紙芝居系ゲームがお好きな方々向け？
Re: (スコア:0)
それって結局、下手に作らなければCの方が早いと言う事ですよね？
さらにいうなら、javaに下手に作ったらさらに遅いわけで。。。。
Re: (スコア:1)
今のjavaなり.netは多少へたでもjitやhotspotががんばってくれる。
がっちりチューニングすればcのほうが速いのは当然だけど
Re: (スコア:0)
今のCなりC++は多少下手でも、コンパイラががんばってくれる。
訳ですが。
Re:これを思い出した (スコア:0)
近年のJIT技術はC/C++コンパイラと同じ静的解析をふつうに取り入れてますし、
C/C++では出来ない動的最適化が可能なぶんだけ有利なのは間違いないでしょう。
「多少下手でも」のレベルならやっぱりVMのネイティブコード化に軍配が上がると思います。
Re: (スコア:0)
動的コンパイル自体がオーバーヘッドだから、
動的最適化で数%効率が上がったとしても不利なことには変わらないんじゃないかな。
それにC/C++コンパイラならJIT以上の時間をかけて同じ最適化が出来るはず。
x64ならSSE２までは標準の命令セットに入っているから。そこまで不利なわけでもない
Re: (スコア:0)
VC6のコードvs最新VMとか、下っ端が書いた下手なC++コードvs最新VMなら最新VMが勝つと思います。が、VC2012vs最新VMで同じ人が書いたコードなら間違いなくVC2012の早い