2004/12/15(水)Virtual PC 2004 SP1 v.s. vmware workstation 4.5.2

2004/12/15 15:00 情報工学
昨日の続き。さらにvmwareとVirtual PC 2004 SP1を試してみたので書いてみる。
どうもverによって大分挙動が変わる気配なので、verを書くことにする。
なお以降めんどくさいのでMS Virtual PC 2004をVPC,vmware 4.5.2をvmwareと書く。

昨日のはSP1が当たってない奴だったらしくもう1回別のところから落としてみた。おどろいたことに、SP1なしとありでは別物のソフト。大分処理が変わったようだ。

ただ、結論から言ってしまえばどれもゲームにはならない。こんなことでストレスをためるくらいなら、実機でOSを動かす方法を考えた方がよい。

ただ、このテストは全てAthlonXP1GHz,Mem512MB,Radeon9200SE(メモリ遅い方),YMF744というリーズナブル環境で行っていることを追記しておく。

さて特にネックになるのはサウンド周りなのでその状況から書いていこう。

1.音声
 ハードをソフトでエミュレーションする際に一番問題になりそうなのがソフトとハードの割り込みをどうやって制御するかという点になるだろう。タイマ割り込みの管理が悪いのか、処理能力の限界か音声がブツ切れる。双方で挙動が違うが、

VPC- 全ブツ切れ。使い物にならず
VPC SP1 - 無印より大分良い。負荷が低いとき(mp3再生時等)には切れない。MIDIの再生が重いらしく、MIDIはブツ切れまくる。SXGY100はブツブツだった。
vmware - 全般的に何を再生してもちょっとずつ切れる。しかし余程忍耐力がないと我慢できないだろう。

2.処理の重さ
 マウスの挙動やゲストPC上の操作の重さ。
(1)マウス
 マウスは双方ホストカーソルをソフト側でキャプチャしてゲストOSに渡す方法に変更したようだ。
VPC - ワンテンポ遅れる。クリックゲーや高速なレスポンスを要するゲームには向かないだろう。
VPC SP1 - マウスの移動はホスト側に依存。クリックなどがスルーされることもあり、ちょっと不安はあるがVPCよりずっと良。
vmware - additionalでVPC SP1と同様にマウス移動はホスト側となる。若干軽めなせいかマウス感覚はもっとも良好。

(2)全般
VPC - 重い。重さについては昨日の記事を参考。
VPC SP1 - VPCよりはるかに軽くなっている気がする。OSインストールこそ試していないが、バックグラウンドでも動くようになったのではないか。負荷時に重くなるのは同じ。
vmware - 3つの中ではもっとも軽いが、やはり負荷時に重くなる。インストールなどは非常に早く実機~実機1/2位の速度が出ているようだ。ただし、ゲスト<->ホスト間ファイル転送などは非常に重くUSB1.1!?とか思う。

3.その他
VPC SP1 - ネットワークのインストールに失敗することがある。めんどくさいのでその後未調整。additionalで入る共有を使っていると、どうも普通のディレクトリと同様に扱われておらずそこからのインストール作業等に失敗することがある。まあローカルにいったん持ってくればそれですむ話ではあるが。なお、共有で仮想マシンのファイルがあるフォルダを指定すると、ゲストOSが死ぬ。

vmware - CD-ROMドライブの接続を変えたときに、認識してくれないことがある。こうなるとゲストOSの再起動が必要。ネットワークは最初から簡単に動くが、Win98だとSoundはデフォルトで認識してくれない。Creativeのサイトから、ENSONIQ Audio PCIのDriverを落とす必要があり。

2004/12/14(火)Virtual PC 2004 Trialを使ってみた

2004/12/14 5:00 PC(全般)
仮想マシンエミュレートソフトMicrosoft Virtual PC 2004 Trialを使ってみての感想。

ちなみに、目的はというと昔やってたゲームのデータを確認したくなったがWinXPじゃ動かんー という話。

さて感想。

1.実機より遅い
 ホスト側に普通にOSをインストールする方が早い。当たり前だという声もあるかもしれないが、エミュレートすることによって低速デバイスが加速する部分もあるはずで一概に確実に遅くなるとは言えない(はず)。だがまあこいつはだいたい遅い。マウスポインタ、ディスクアクセス、その他もろもろホストの能力の1/3~1/4位の感覚になる。

2.サウンド滅茶苦茶
 音に関しては相当酷い。ブツ切れるし、このMIDIの酷さは久方ぶり。PC-98 + ソフトウェアMIDIより多分悪い。

3.バックグラウンドにすると遅くなる
 Virtual PC固有だと思われる。バックグラウンドにすると途端にフォーマットなどが進まなくなる。今ひとつ使い勝手が悪い。

結論、使えるか使えないかというと”将来性に期待”というところか。マルチOSは決して勧められる物ではないが、ガチャポンあたりで余りHDD1つ使えるのなら実機にインストールした方が万倍良い。下手すると、Annex86+Win95あたりに負けるかも。Grandaleだかなんだか、ハードからのバーチャル化の方が早いかもしれない。

ただしこのソフトがやたら遅いのは、相当低レベルまでいちいちエミュレートしてるからだという話なので、動くOSの多さという点では強いのだろう。Unix系もおそらく動く。有り余るCPUパワーの下で、OSの互換性を保って作業というシチュエーションでは強力か。

2004/12/14(火)華式(Kshiki)Updateのやり方

2004/12/13 25:00 PC(全般)
前にも書いたのだが、記事として不足が多く今回苦労したので再確認。

KShikiの場合は、スタイルシートで全部色を変えたり出来ないので一苦労である。

1.全バックアップ
 とりもなおさず、現在動いてる奴を全ファイルバックアップ。

2.転送
 最新版を/data,/GraphixAをのぞいて全て転送。転送は普通に行えばいいが、sjisの所為かsamba経由だと上手くいかないことが多い。WinSCPで。パーミッションは継承されるので、多分問題ない。

3.書き換え
 具体的に書き換える必要があるファイルを以下に挙げる。ここでの「書き換える必要がある」とは、私が自分のサイトで使うために色変えなどで書き換えているファイルを含んでいる。

KshikiconfigD.cgi - デザインファイル。記事のボーダーカラーなど。将来的にはこれとスタイルシートで全部いじれる?
KshikiconfigP.cgi - パスワード関係ファイル。タイトル等。
KshikiFormMain.html - 外形生成ファイル。タイトルのバックカラー、ログインフォームの場所など。
KshikiFormParts.html - 検索フォーム、カレンダー等のバックカラー。

上記4ファイル。どうも散逸してるのが気になる。今回は差分を残しているので、どこを書き換えているか次回ExamDiffで直ぐ分かるはず。

以上3ステップで終了。

なお、画像のアップロードに失敗する問題はa50にしたところ直った。が、なんか記事追加時に消去ボタンしかでなかったりする。どうにもKshikiはバグが多い。おまけに遅い。

2004/12/06(月)数式-&gt;画像

2004/12/05 26:00 PC(全般)
数式が1個画像で突然欲しくなった場合どうするか。

Texで1から書くのはいかにもめんどくさい……
ということで、Microsoft数式エディターをPowerPointで使い、「図として保存」コマンドでjpg or gif or pngで書き出すのが楽だろう。

なお、この「図として保存」コマンドは背景色が設定されていないと黒ベタ画像を吐く。

つまり、


  1. 挿入->オブジェクト->Microsoft 数式3.0
  2. 開いた数式エディタWindowで編集->終了
  3. オブジェクトの書式設定->色と線->塗りつぶし->色:白
  4. オブジェクト選択->右クリック->図として保存


という手順になる。保存時のサイズ調整・パレット選択等は出来ないが、PowerPoint上での拡縮は比較的まともに動くのでサイズが合わなかったら目分量でサイズ変えて再出力。

JustSystemやOpenOfficeの数式エディタもさわってみたけれど、手早くということならMSのをWord or PowerPointで使うのが一番使い易かった。

花子あたりでMSの数式エディタが扱えれば良かったのだが、Word,PowerPoint以外だと数式エディタの挙動が変わり、この状態になるとどうも怪しい。BackSpaceが効かなくなることもあるし、編集終了すると画像に固定されるようで、拡縮がうまくできなくなる。

まあそんな感じで。数式が複数出現する文書とかなら、まあやっぱりTexなんだろうな。余程のよれが無い限りTexはあと1年ちょっとで永久卒業。数式コマンドを全部覚えてーなんて考えは持たないようにしたい。WinShell,EasyTexは使えるのかいな…… 次回チェックだな。
<追記>
知り合いからMimeTex.cgi(Texの数式を画像にしてくれるcgi)を使ってはどうかと勧められた。自サーバにおいて、数式を張りたいところに数式コマンドとリンクを書く。

うーん、それがいいやり方の1つだというのは納得できるがイマイチしっくり来ないのはなぜだろう? 外部画像がいやなのか。amazonだったらOKなのに? 著作権問題があるから納得できる?

それと1つ書きたいときというのがたいてい自分であれこれ考えながら数式を書いているときだというのがある。wysiwygじゃないと使えないのだ。あとはCってのはどうなんだろうな。このサーバ潰れたら外部リンクだよな。

2004/11/23(火)なにかがおかしい(作業マシンのIE)

******  スパイウェアが原因でした  ******

spy bot1.3でpossible hijacker検出。修復したら直りやんの。

orz
        • Old-------------------------------------------------------------------
以下の記事は、なんと作業用マシンのIEでしか発生していない。ノートパソコンでの表示(同じXP SP1、同update状態、低スペック、ビデオカードRade系統、同DHCPにぶら下げている)は"admin mode"でも3秒弱と問題ないスピード。

また、知り合い3人に同ページを読んでもらったところ、IEを使っている3人ともが3秒程度で表示されるという状況。

正直原因・打開策全く思いつきません。まだブラウザ環境変える気にはならないし、このマシンから速くないと意味がないんだが……

.NET frameworkが悪さしてる可能性を考えて、アンインストールしたが変わらず。
IEの再インストールも試みたが変わらず。
        • Old----
さて、ユーザモードは2~3秒で開くようになったので満足としても、管理者モードだと未だ7秒超かかる。アウトプットは0.2秒で出来ているため、ブラウザの描画での問題。なんかいい資料が見つからなかったので自分でざっと実験。きっとあると思うんだが。

結論から言うと、描画するボタンの総数とhiddenフィールドが描画時間の足を引っ張っているようだ。
<<調査内容(超手計測)>>
の数 -> 影響なし
の数 -> ほぼ影響なし
の数 -> 影響あり
の数 -> 影響あり
・cssの使用、および記述内容 -> ほぼ影響なし

ボタン100個、hiddenフィールド200個につき1秒超くらいかかっている気配。このCGIが吐くページでないと再現性がない? でもValidatorは一応通ってるからなあ…… トップの検索から、ノードデータの編集に飛べないのは不便、なんとかしたい。

ラジオボタンが1つ逃げの打開策。hiddenフィールド、ボタンを減らす方向で1ボタンであとで分岐させるのが折衷案。

うーんもうちょい考えますか。

P.S.
Firefoxだとhiddenがいくらあろうが2秒で表示してくれます。IE固有? ションボリ。

2004/11/23(火)xml -> csv

REXMLを断念した。

REXMLを使用した場合、100件程度のデータの表示において私の腕では、
$ time ruby value.cgi > test.out
による計測で4.2sec~4.6secと4秒を切れない。「表示まで5秒」ルールを達成するのはどうやら無理。

奇っ怪な記法で多少の速度アップは出来ないことはないが、スクリプト言語の最大の利点は読みやすさにあるべきだと考える。そもなぜXMLを使おうとしたかというと、データの可読性と保守性が欲しかったから。まあ実際は、腕の問題か。

そんなわけで、csvで実装し直した。それなりに冗長に書いたのにもかかわらず同計測で、0.2sec。同じデータを使用していないので、公平なテストではないが100件程度で揃えてはある。ruby + xmlを使うのは時期尚早だったようだ……

さて、rubyの場合なにせHashクラスがあるためcsvの管理は相当楽。csvは1行目にkey、2行目以降を実際のデータとして、1行目と各行をzipで閉じてHashにつっこむ。csv自体の可読性・保守性もアップと実にありがたい話。疑似ツリーも簡単に作れるし、REXMLのAPIとにらめっこしたのはなんだったんだろうか。

ちなみに、計測に使用したCPUはC3 800A MHzナリ。単体で買えるCPUで現役最低消費電力。

2004/11/22(月)REXMLの速度をどう見るか

WEBの動的生成でREXMLはなかなか厳しいものがあるようだ。

REXMLを色々いじってみたが相当遅い。XML文書のパースにもそこそこ時間がかかるのだが、それ以上にXPathを使った関数を書くと、まあ遅いこと遅いこと。

"/foo/bar"のような簡単なものでも100ループで2秒、複雑なものを書いてコレクションで取ってこようとすると1発0.3~0.5秒くらいかかるようだ。ピュアRubyの限界か……

さて、妥協案だが単体ノードを取ってくるのにXPathを使わないってのが1つ。

REXML::Elements#[index, name=nil]
REXML::Elements#[xpath]

APIをみると、単体ノードを取ってくるのに上記2通りの書き方がある。上の方は用途が限定的になるものの、下よりも100倍以上速い。しかし上の書き方に限定するなら、いっそcsvでやれという気もする……

コレクションを取ってくる場合も、elements.eachとせずに上の書き方でwhileループを使えば若干の速度向上が見られる。とはいえソースは汚くなる。

ソート部などに下の書き方があったので、全部上になおしたところ130件程度のデータで、13sec -> 7sec程度の速度向上。まだちょっと厳しいが……

とりあえず、当初の構想はどんどん曲げよう。

2004/11/17(水)rexml仕様メモ

(? XPathの仕様を読んだ限りでは、以下は通りそうなんだが)
↑友人からの指摘で仕様書読み直してみましたが、ノードテストのところに(|)は書けなさそう?、文法能力低いのでちゃんとは分からない。

rexmlにおいては、

"/data/(software|category)"

は望み通りの結果を与えない。"/data/*"と同じ集合がかえってくるようだ。他にも幾通りか試したが、rexmlでは(|)が使えない気配。

この場合、
"/data/*[name()='software' or name()='category']"

とすることでsoftwareとcategoryの集合がかえってくる。当たり前だが、name()をnameとすると全く違う意味になるので気をつけろ! うーん、なんか間違えてるんだろうか。

2004/11/15(月)DOM? DHTML? in Mozilla? IE?

DOMに従ってればほぼどのブラウザでも動くという話は分かったけれども、今ひとつ納得いかないのは、タグ内のテキストへのアクセス。

innerHTMLだけはGeckoで通るようだが…… 将来消されそうな。
↓而して、これはスマートな方法か!?

span_el.childNodes[0].nodeValue = "a brand new bag";

childNodes[0]がものすごく気になる…… それ以外のアクセス方法はちょっと調べただけだと分からなかった。まあいくら何でももっとちゃんとした方法があるんだろうけど。

なんだかんだいって、(inner|outer) + (HTML|Text)はあると楽。無いと困るかどうかは???

あとはとりあえず、childNodes(0)はだめだってことをしっとくべきか。[]でないとIE:OK, Gecko:NGになる。

childnodes[0]は共にNG。大文字小文字キニシナイ文化圏の人間なのできつい。

idから書き始めるのはどちらも通るのだね。

test

は共にOK。WEBの資料はよく分からぬ。やっぱ本買わないとダメかも。

<参考>
DOM in mozilla - http://www.mozilla-japan.org/docs/web-developer/upgrade_2.html#dom
IE専ならえらく使えるが嘘多し - http://tomizawa-web.hp.infoseek.co.jp/dom.htm
IE v.s. N6なら結局ここか - http://tohoho.wakusei.ne.jp/js/dom.htm

あたもう、わかりませんずら。一度ちゃんとHTMLの書き方を覚えた方が良いな。めんどいけど。

2004/11/14(日)Ruby開発環境

注:あらかじめ。この記事には多分の嘘と誤解と無知が含まれていることをお詫びします。ともあれ、使いやすい機能というのは標準装備、アクセスが容易であるに限るというのは持論。

・RDE
日本人がRubyの開発をするということに限れば、最有力候補。他の開発環境で出来る機能はほぼ完備。しかしUTF-8の解析が怪しく、しかも対処法無いっぽい。今回のには不適。イマイチ補完機能が働いてない?
更新が半年以上止まっていて将来性も不安。アドレス違反がしょっちゅう起こるので怖い。

・Eclipse + RDT
ちゃんと動いてない? 組み込みクラスの補完機能が無いのか働いていないのか。自分の環境が悪い可能性大だが、ドキュメントがないので今ひとつ。これも半年以上更新が止まっている。機能的には多分RDEよりしょぼい。

・xyzzy + Ruby-mode
lispわかりません。xyzzyもわかりません。以上。

・sakura + Ruby
結局ここか! えーと、sakuraはプログラマユーザが少ないためにスクリプト言語のキーワードファイルがイマイチ整備されていない。一応Rubyの強調表示はあるが制御構造と、関数定義部くらい。でもこれでいい気が。使いこなすために、今度キーワードファイルの書き方調べてみる。少なくとも上よりましだと、ええもう。慣れたエディタは使い易いってことで。

正直スクリプト言語ごときで、IDEなんてバカかという話で。調べに走ってるのも愚かという話で。
以前聞いた話ではEclipse+多言語が世界を制覇するということだった気がするんだが、Rubyでこの調子だとまだまだか。
OK キャンセル 確認 その他