  |
はてなキーワード: RAMとは
最近のゲーム機の起動が遅い理由は、ゲーム機の速度が速くなったからとしか言いようがないと思う。
具体的には、速いRAMが沢山載って、それに応じた速度でゲーム機が動くようになったので、ゲームのデータをRAMに載せてからじゃないと動かなくなった。で、その、ゲームのデータをRAMに載せるという処理が、起動時間にかかってくるんだ。ロード元のデータの場所がROMかCD-ROMかBDかHDDかによってロード速度は変わってくるけど、ROMだったらロードが必要ないなんてことは、今の速度のゲーム機ではありえない。
http://anond.hatelabo.jp/20090611230404
あまり意味がないような気がする。後にも述べるがPS3は内蔵HDDからダウンロード販売されたゲームを起動できるから。そしてHDDとカートリッジの速度差はあまりない。
同様の仕組みはWiiにもXBox360にもあるので、元増田が
これくらい現状の技術で簡単にできるだろ
小容量でも処理落ち無くなるって利点あるから制作側もやる気出るだろ
とか書いているようなことは、メディアからのロード時間という観点ではもう解決済みなのだ。
それ以外の、そもそも「PS3はゲームのロードにいくまで(メインメニューが出るまで)が遅すぎるだろ」という話はあるけど、それはゲームが入ってるメディアが何かって問題とは全然関係ないんだよな。
最近RAM-Diskが話題ですが、マザーボードの方でメモリーをドライブとして認識できるようにしてくれませんでしょうか？
メモリーは揮発性なので電源を落としてしまうとデータが消えてしまいますが、充電式の電池をマザーボードに搭載するかも、もしくは電源以外にマザーボードから直でメモリーのために電気をひいてはいかがでしょうか？
1)停電したらじんでまうでないか！
RAM領域はありえないくらい高速ですのでHDDに8GB（1GB~16GB）の予約を入れてメモリーに何か書きこまれるときHDDに同時に書き込まれるようにして、もし停電でRAMの内容が飛んだらHDDの内容をmemoryにコピーするようにすればいいと思う。
2)最速のOS
RAM領域にOSをインストールできるようにすればものすごいことになるのではないでしょうか？
そうするとメモリーソケットは8つほしい。といってもdrive用のDDRソケットはそれほど高速でなくても問題にはなりません。(HDDに比べればあり得ないくらい早いから
ということでこんなマザーボードを開発してください。
1)memoryをdriveとして認識できるDDR2 or 3ソケットを備えている。
2)ソケットの合計は8つ
3)停電対策などがしてある
4)ブートローダーはまずメモリーから読み込み、もし内容が蒸発していたらバックアップされている内容を起動時にコピーしなおしてメモリーから再度起動する。
旧OSで通用した設定は、大抵新OSにおいては邪魔で、トラブルの元でしかない。
私のマシンで起きた現象はUSBメモリを認識しても、読み書きできなくなったとか、
以前より起動が遅くなったとか、KDE4の仕様にとまどっちゃったとかうんたらかんたら……
ネットワークインストールとDVDに焼いてインストール、そしてローカルのハードディスクにISOイメージを置いてある状態でのインストール。
(最後の方法は既に別のLinux等のOSがインストールされている場合に限る……はず)
大体俺のネットワーク環境は1Mbpsも出ないし、DVDドライブもついてない。
とかいいながら潤沢にあるハードディスク資源を駆使して、ローカルハードディスクにISOイメージを置くことにした。
torrentファイルをゲットして、ktorrent(bittorrentクライアント)を何日も放置してようやくダウンロード完了。
よろこび勇んでインストール方法をチェックだぜ。
ふむふむ。カーネルとRAMディスクのイメージをISOから取り出して、起動可能なドライブに入れておき、grub(ブートローダ)に登録するのか。
ここまで書いて私は思う。
私ほどのぷぅろふぇっしょなるともなると、マシンガンのごとく文章が浮かび、手が動くのだが、scimの野郎、全然追い付かねえ。
それはさておき、喜びいさんで再起動。
インストール用のカーネルが起動したので、ローカルに保存されているISOイメージを指定して
インストーラを起動だ。起動！！！
「Out of range」
画面に現れた文字は、インストーラが使おうとしているディスプレイの解像度にディスプレイかビデオカードが対応していないことを示していた。
なんてことだ。
どこにもCUIインストールみたいなオプションは無かったぞ！！！
しばらく思い悩んだあと、ふと気がついた。
そこでCTRL-ALT-+/CTRL-ALT--を押して、画面の解像度を切替えてみた。
成功だ。
るんるん。
必要事項を設定してインストールだ！！
しかしだ。問題はここからだ。
実はISOイメージが入ってるパーティションにインストールする予定(ってか、パーティションがそこしかねえ)だったのだが、
さらに、もうひとつ別の警告が出ていたのだが、細かいことは忘れた。
ばっっっっっっっかやろおおおおおおおおお！！！！！！！！
アップグレードのための壮大な旅が始まった。
でででん！ででででーん♪ちゃちゃちゃん。
まあ確かに当初は、
Microsoft is expected to recommend that the "average" Longhorn PC feature a dual-core CPU running at 4 to 6GHz; a minimum of 2 gigs of RAM; up to a terabyte of storage; a 1 Gbit, built-in, Ethernet-wired port and an 802.11g wireless link; and a graphics processor that runs three times faster than those on the market today.
http://www.microsoft-watch.com/content/operating_systems/longhorn_to_steal_limelight_at_winhec.html
なんて言われたくらいだしねえ。そのうち実際の製品が出来上がってくるにつれ、いつも通り実際に必要なスペックは隠されて、マーケティング上の戦略で「もっと低スペックでも動きますよ」って言うようになっていくんだけど。
結局WinFSが無くなったりなんだりで必要スペックは実際に下がったんだろうけど、Windows Vista開発者の本音としてはこのくらいのスペックが必要だと思っていたんじゃないかな、って思う。
訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。
注意：以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が本当に以下のように述べているとは限りません。
なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)
Tuesday, February 19, 2008
先週、MicrosoftはOfficeのバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。
それぞれのExcelワークブックは1つのcompound fileに収められている
つまり、Excel 97-2003ファイルはOLE coumpound documentで、それは結局、1つのファイル内にあるファイルシステムである。これは、理解するのにあと9ページはスペックを読まなくちゃならないぐらいには十分に複雑だ。そしてこれらの「スペック」は、普通我々が考えるようなスペックというよりは、Cデータ構造みたいに見える。これ全体が階層的ファイルシステムなのだ。
もしあなたが週末を、Wordドキュメントをブログにインポートしたり、あなたの個人的な財務データからExcelフォーマットのスプレッドシートを生成するような気の利いたコードを書くのに使おうと思ってこれらのドキュメントを読み始めたなら、このスペックのややこしさと長さがそんな気をあっという間に失せさせるだろう。普通のプログラマはこのOfficeバイナリファイルフォーマットについて次のような結論を下す:
この4つ全てについて、きみは間違っている。ちょっとだけ掘り下げて、これらのファイルフォーマットがどうしてこんなに信じがたいくらいに複雑なのか、なぜMicrosoftの悪いプログラミングを反映しているのではないのか、そしてそれを回避するためにあなたに何ができるか、を明らかにしよう。
理解すべき最初のことは、これらのバイナリファイルフォーマットはちょっと違ったデザインゴールを持って設計されたということだ。たとえばHTMLとは。
これらはすごく古いコンピュータで速く処理できるようにデザインされた。Excel for Windowsの初期のバージョンでは、1MBのRAM、20MHz動作の80386が Excelを快適に走らせることができるための妥当なものだった。このファイルフォーマット内には、ファイルを素早く開いたり閉じたりするための最適化が沢山仕込まれている:
これはライブラリを使うことを想定して設計されている。もしあなたがバイナリをインポートするものを1から書き上げたいと思ったら、Windows Metafile Format (何か図を描く場合) や OLE Counpound Storage みたいなものをサポートしなくてはいけなくなる。もしあなたが Windows上でやるのなら、そうしたことをたいしたことのない作業にするためのライブラリのサポートが存在する... そういったフィーチャーを使うことは(元々)マイクロソフトチームのためのショートカットだった。でもあなたが全部を自分でスクラッチから書くなら、全部の作業を自分自身でやらなくてはいけない。
オフィスはcompound documentsに対して広範囲のサポートを持っている。例えば、スプレッドシートをWord文書に埋め込んだりできる。完璧なWordファイルフォーマットのparserは、同じように、埋め込まれたスプレッドシートで何かインテリジェントなことが出来るべきだろう。
それは相互協調性(interoperability)を意識してデザインされてはいない。仮定されていたのは、WordファイルフォーマットはWordからのみ読み書きされなくてはいけない、ということで、それは当時においては十分に合理的なものだった。これは、Wordチームのプログラマがファイルフォーマットをどう変更するかについて決定を行う場合にはいつでも、彼らが気にするのは (a)何が高速か (b)Wordのコードベースにおいて最小の行数になるのは何か、だったことを意味する。SGMLやHTML-interchangeableといった標準ファイルフォーマットのようなアイデアは、最初にインターネットがドキュメントの相互交換を実現するまで現実のものにはならなかった。それはOfficeバイナリフォーマットが最初に考案されてから10年後のことだったのだ。ドキュメントを交換するのにインポーターとエクスポーターを使うことができるという仮定が常にあった。実際Wordは簡便な交換のために設計されたRTFと呼ばれるフォーマットを持っており、そのフォーマットは殆ど最初のころからあり、今も100%サポートされている。
それはアプリケーションの全ての複雑さを反映していなくてはいけない。 全部のチェックボックス、全部のフォーマッティングオプション、そして全部の、Microsoft Officeのフィーチャーは、ファイルフォーマットのどこかで叙述されていなくてはいけない。Wordのパラグラフメニューにある、"Keep With Next" と呼ばれるチェックボックス、これはパラグラフを、その後ろのパラグラフと同じページに置くのに必要な場合は、次のページに移動させるもの(?)だが、これもファイルフォーマットの中に無くてはいけない。そしてこれはつまり、あなたがWordドキュメントを正しく読み込める完璧なWordクローンを実装したいなら、そういったフィーチャーを実装しなくてはいけないということだ。Wordドキュメントをロードする競争力のあるワードプロセッサを作っているのなら、ファイルフォーマットからそのビットをロードするコードを書くのには1分しかかからないかもしれないが、ページのレイアウトアルゴリズムをそれに対応させるのに何週間もかかるかもしれない。もしあなたがそうしない場合、カスタマーがあなたのクローンでWordファイルを読み込んだら、全部のページがぐちゃぐちゃになってしまうだろう。
それはアプリケーションの歴史を反映していなくてはいけない。 このファイルフォーマットに見られる多くの複雑さは、古く、複雑で、愛されず、めったに使われないフィーチャーを反映している。それらはファイルフォーマットのなかに後方互換性のためにまだあり、そしてMicrosoftにとってその辺りのコードを残しておくことには何らコストはかからない。しかしあなたがこれらのファイルフォーマットをparseおよびwriteする一貫した完全な仕事をしたいと思うなら、Microsoftのインターンが15年前にやったのと同じことを全て、またやらなくてはいけない。要点は、何千人年の仕事が今のWordやExcelには費やされてきたのであり、これらのアプリケーションの完璧なクローンを作りたいと本当に欲するなら、あなたは何千人年を費やさなくてはならないことになる、ということだ。ファイルフォーマットは単に、アプリケーションがサポートする全てのフィーチャーの簡潔なサマリーなのだ。
手始めに、小さな例を一つ、深く見てみよう。Excelのワークシートは色々なタイプのBIFFレコードの集まったものだ。私はスペックの一番最初のBIFFを見てみたい。1904と呼ばれるレコードだ。
Excelファイルフォーマット仕様のこのレコードについての記述は非常に曖昧なものだ。そこでは単に、1904レコードが「1904日付システムが使われているかどうか」を示すレコードだ、と述べているだけだ。ああ、使えない仕様書の典型的な一例だ。あなたがExcelファイルフォーマットで何かしている開発者で、そしてファイルフォーマット仕様にこう書いてあるのを見つけたなら、あなたがMiocrosoftは何かを隠しているのだと結論付けたとしても無理はない。この情報の断片は十分な情報をあなたに与えはしない。あなたには幾ばくか外部の情報が必要で、私は今ここで、それを提供しよう。Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンはMac版であり、それは単に簡単だったという理由でOSのエポックを使っていて、しかしWindows版のExcelは1-2-3のファイルをインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。あなたが涙ぐむのも無理はない。歴史のどの時点においても、プログラマが正しいことをしなかった、という時はないのだが、しかし現実にあなたが手にしているものはこれなのだ。
1900と1904のファイルタイプは両方とも世の中には広く存在しており、それは通常、ファイルがWindowsとMacのどちらで作られたかによる。一方のタイプから他方のタイプへ黙って変換するのはIntegrity的に問題があるので、Excelはファイルタイプを変換することをしない。Excelファイルをparseするためには、あなたは両方を扱わなくてはならない。それはファイルからこのbitをロードするだけの問題ではなく、あなたが日付表示と両方のエポックを扱うparsingのコードまで書き直さなくてはいけないということを意味する。実装には何日かかかるだろうと私は思う。
実際、あなたがExcelクローンの作業をするなら、日付の扱いについて、あらゆる種類の微妙なディティールを発見することになるだろう。Excelは日付の値をいつ変換するのか? 表示の整形はどうやっているのか? なぜ1/31は今年の January 31と翻訳され、また一方で1/50はJanuary 1st, 1950と翻訳されるのか? Excelのソースコードと同じだけの量のドキュメントを書かないがぎり、振る舞いに関しての微妙なビットを全て完全に記述することはできない。
そしてこのレコードは、あなたが扱う何百もあるBIFFレコードの最初の1つに過ぎず、しかももっとも単純なものなのだ。他のレコードの殆どは、より多くのプログラマーを涙に暮れさせるぐらいには十分複雑だ。
唯一導き得る結論はこれだ。
MicrosoftがMicrosoftとOfficeのファイルフォーマットをリリースしたことは大変有用なことだが、しかしそれでOfficeファイルフォーマットをインポートしたり保存したりするのが楽になるということは全く無さそうだ。それらは狂気じみて複雑で、リッチなアプリケーションで、そしてあなたは人気のある20%の部分を実装して80%の人々を幸せにするというくらいのことしかできない。バイナリファイル仕様によってなされるのは、多く見積もっても、著しく複雑なシステムのリバースエンジニアリングにかかる時間を何分か削減するくらいだろう。
オーケー, 私はいくつか回避法を教えると約束した。良いニュースは、殆どの良く知られたアプリケーションにとって、Officeバイナリファイルフォーマットを読み書きしようと試みることは誤った決定だということだ。あなたが真剣に考えなくてはいけない代案が2つある。Officeそのものにそれをやらせるか、書き込むのが簡単なファイルフォーマットを使うかだ。
ヘビーな仕事はOfficeにやらせよう。WordとExcelは実に完全なオブジェクトモデルを持っており、COMオートメーションの手段が可能で、これであなたは何でもプログラムでやるようにできる。多くのシチュエーションでは、Office内のコードを再利用するほうがそれを実装しようとするよりも良い。ここにいくつか例がある。
この手のアプローチは、全ての種類の一般的なOfficeタイプについての、サーバ上であなたがやりたいと思うであろうアプリケーションで、うまくいくだろう。例えば:
これらのケースの全てにおいて、Officeオブジェクトにインタラクティブ動作でないことを教えてやる方法があり、だから表示をアップデートするのに煩わされたり、ユーザに入力を促す必要はない。ところで、このようなやりかたでいく場合には、gotchas(?)がいくつかあり、そしてそれはMicrosoftは公式にサポートしているものではない。だからあなたがそれを始める前にはKnowledge baseの記事を読むように。
書き込むファイルにはもっとシンプルなフォーマットを使いなさい。単にOfficeドキュメントをプログラムで生成したいなら、殆どいつでもOfficeバイナリフォーマットよりももっと良いフォーマット、WordやExcelでも問題なく開くことができるようなフォーマットが存在する。
いずれにせよ、全てのOfficeファイルを完全に読み書きできるような、文字通りのOffice競合製品を作ろうとする(その場合には、何千年もの作業があなたに予約される) のでない限り、Officeバイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。
別に意欲がないわけじゃないんですよ。
そりゃ、誰だって成績あげたいと思うでしょ。
もちろん、楽して良い点とれないかなーなんて期待スンともモタンですよ。
準備万端で先生の横に座っても眠けが襲ってくるんですね。これが。
いや、失礼なのはわかってますよ。
「ちょっとすいません、トイレ・・・（で顔洗ってくる）」の度に
大変モウシワケない気持ちで一杯になりますよ。
原因もわかってるんです。
「内容をあんまり理解してないから」
なんだかんだでこれに尽きますです。はい、認めます。
すいません。
なんとか頑張って赤ペンで囲ってみたり、
「つまり、○○ってことなんですよね？」とか質問のポーズだけとってみたりしますが、
それでも、ごめんなさい先生、ほんとはわかってないんです。
自分でも何やってるのか、あなたが何を仰っておられるのか。
んで、そんなでぃふぃかるてぃーを乗り越え、
とりあえずの復習で大体のことは把握したつもりになっても
いざ問題を解いてみると詰まる詰まる。
先生に泣きついて解説をもとめて「なるほど！」とわかった気になっても
数秒後に同じ問題にまたつまる。
ええ、わかります。
あなたが
「てめーの脳みそは容量3メガしかないんか！
とそのマナコで語っておられるのは。
私だってなんとかしたいんです。
何も成績だけの問題じゃない。
でも、わからないんです。
自分が勉強が嫌いなのかも、そうでないのかすらも。
http://en.wikipedia.org/wiki/ASUS_Eee_PC から
（公式サイト：http://eeepc.asus.com ※ポータルなのか妙に重くて要JS？）
（追記15:35 4Gモデル分解レポート"ASUS Eee PC Exclusive Inside Look!"）
これはNECがいつ即死してもおかしくない、そんな緊張感のあるプロダクトだ。
PCは既に5年前にエンドユーザでの端末能力として飽和している。今となっては内部バスに比べりゃ糸電話に見えるイーサネットの帯域ごしのプロセッシングでも情報交換と整理が大半を占める事務業務やファミリーユースには支障がない。
選び放題のウェブサービスによってWindowsすら必須ではなくなりつつあり、所有データのストレージさえローカルにある必要もなくなってハードだけでなくソフトウェアまでも含め、全てが規模の経済に飲み込まれようとしている。
時代の変化は想像よりもずっと早く、コモディティアプライアンスのステージを飛び越え、手帳やバッグのように個別化の不経済を許容する高付加価値の逃げ道も絶たれ、紙と同様の「書ければ何でもいい」素材へ移行しつつあるのだ。
ここでサポートセンタを大連に移して日本人フリーターを使い捨てにしても、新入社員の初任給を20年間抑えつづけても、若手だけ年金制度を変更しても、追いつかない。
もう日本の“パソコン”メーカーに残された選択肢は国内大統合によってASUSに対抗できるだけのボリュームを確保しさらに効率よく安いものを作るか、ASUSから買い付け設置を請け負う小売になるか、あるいは事業部を10人に減らして資産を投資・運用に回すかしかないだろう。
うちはとても貧乏だったというのに、なぜか俺が小学三年生のときに、親父がパソコンを買ってきた。
親父は電気工事屋をやっていたから電気製品が好きだったんだろう。
当時小学六年生だった兄貴も機械いじりが好きだった。 電子ブロックなんてのが家にあった。
とはいえ、二十万円もするパソコンをコンビニでウーロン茶を買うかのように買ってきた親父が、あとでオカンになんて言われたのか、いまとなっては知るよしもない (いや、親父もオカンもまだ生きてるので、聞こうと思えば聞けるが) 。
ともかく、俺が小学三年生の時には家に MZ-2000 というパソコンがあった。
三年生のときはそもそもパソコンとはなにかも知らなかったし、親父も兄貴も壊れものを扱うかのように大事に触るので (実際壊れものだ) 、俺には触らせてもらえなかった。 親父や兄貴の背中越しに見ているだけだった。
当時はパソコン用のソフトなんてのがそこらに売っていたわけではないし、 DS のソフトのように気軽に買えるようなものでもなかったので、付属の BASIC でポチポチと入力しては RUN する、これしかなかった。
それでもなにかすごいことがこの銀色の箱の中で起きているということは、子供ながらに理解した。
そのうち学年が進んで小学五年生になるころには、俺も兄貴といっしょにプログラムを入力したりしていた、と思う。 六年生ぐらいだったかもしれない。
当時はベーマガという雑誌があった。 毎号買ってきては、短いプログラムだけ選んで入力した。
そういえば、 MZ-2000 に付属していたオレンジの本も、子供の知的好奇心をおおいにあおった。 中西さんの挿絵が絶妙だった。
ベーマガには、「アルゴリズム」という単語がわりあい頻繁に登場していたと思う。 体操じゃないよ。
高度な関数も使えない、グラフィックもろくに扱えない当時のパソコンで、おもしろいゲームを作るにはアイデア勝負、とりもなおせばアルゴリズム勝負みたいなところがあった。
サイン関数を使って放物線の動きを表現したり、 X 軸の動きと Y 軸の動きを入れ替えて物体の反射を表現したり。
いまではなんてことはない小手先以下の技だけど、そもそも当時のパソコンではそんなことぐらいしかできなかった。
パソコンサンデーでもアルゴリズムという単語がわりとよく出てきていたと思う。
そんななかで、パソコンというのが魔法の箱ではなく、ちいさな処理を組み合わせてなにかをするものだということを理解した。
そのころすでに親父はパソコンにさわりもせず、兄貴と俺のオモチャと化していた。
グラフィックボードと G-RAM とカラーディスプレイまで買ってくれたんだから、親父の無駄遣いもここに極まれりというもんだ。
数十しかない BASIC の命令を組み合わせれば、色つきのグラフィックや音まで出せた。 BASIC のプログラミングは楽しかった。
兄貴と夏休みを数日使って I/O に載っていた「フォボス」のダンプリストを打ち込んだりした。 ひとりがリストを読んで、もうひとりがそれをひたすら打ち込んだ。 ダンプリストの呪文を雑誌数十ページ分打ち込んだら、ものすごいゲームができた。 楽しかった。
中学に進んで、 Oh! MZ を読んでアセンブラや他の言語にも触れ合えた。 あまり深入りはしなかったけど。
高校は商業高校の情報処理科に進んだ。 校内のホストに TSS でログインして、 COBOL や FORTRAN なんかを習った。 情報処理二種も取った。
。
今年の四月で小学三年生になった。
子供には家の PC はさわらせてない。 たまにマウスで絵を描かせるくらい。
現代っ子らしく、 DS でポケモンなんかして遊んでいる。 Wii もある。
さて、この子にプログラミングの楽しさを教えるとしたら、どうしたらいいだろう?
いまの PC に BASIC は付属してない。 ベーマガもない。
あったとして、今の PC で、当時のような短いリストでなにができる?
エミュレータで古いパソコンの環境を再現してプログラムさせるか?
それは、周囲に表現力豊かなゲームがあふれている現代の子供が楽しいと思えるものか?
アルゴリズムというものをどうやって説明したらいい?
コンピュータが内部でどうやって動いているか、どうすれば簡潔に説明できるだろう?
そもそも現代の子供は、これだけソフトウェアがあふれているなか、コンピュータにプログラムを入力して、それを動かすことをおもしろいと思わないのではないか?
子供がプログラミングを理解するのに、取っつきやすい本やサイトなんかがあったら、誰か教えてください。
。
