アカウント名:
パスワード:
メモリ空間が広がるのは、すごく助かるんですが、こういうユーザってあまりいないのでしょうか。
逆に言うと、そういう大型アプリケーションがPCの世界に降りてきたがために、一般ユーザーがまだ32bitに不足を感じないうちから64bitを用意しなければならないようになったということでしょう。それだけx86は多くの分野に浸透したというわけですね。
いないでしょうねぇ。今のところ1プロセス2GB以上のメモリを必要とするのはRDBMSぐらいです。
必要なのは、物理メモリの容量じゃなくて仮想メモリ空間ですよ。
今時、2GBを超える容量のファイルなんて、マルチメディア系データでは普通にあるので、これをメモリ空間にマップできるだけで、コーディングがどれだけ楽になって、性能が上がることか。
32bitまでの世界では、ファイルサイズに比べて仮想メモリ空間が狭い。OSにどうしてファイルI/OのためのAPIがあるかというと、この狭い仮想空間に、巨大なファイルの一部だけを読み込む必要があるからです。仮想メモリ空間が64bitになると、ファイルをそのまま仮想メモリにマップできますので、ファイルI/OのAPIが不要になります。その結果、ファイルI/Oは全て配列へのアクセスとしてコーディングできるようになります。ファイルI/OのAPIの処理より、仮想メモリの処理の方が圧倒的に軽い処理なので、ファイルI/Oの性能が劇的に改善されます。
慣れの問題じゃないでしょうかね? 似たような資料を、似たような時間で、それぞれExcel, PowerPoint, Visioで作る人間ってのがいると思います。
ちなみにあたしはExcel使い。 64bitになったら...。 気持ちが乗るかも。
# MS-DOS と RUN386.EXE で成り立ってたシステムだもんなぁ、確かに迷機だわなぁ、などという議論はよしとして (^_^;
くれ>ダンジョンマスター/うぃずシリーズ じゃなくて (^_^;、是非、うんづ [infoseek.co.jp] をお試しくだちゃれ。 Wiz シリーズなんかは 動作が確認されたものもあるみたい [nifty.com]ですよ。
# 現役マシンがまだ稼動しているので実はまだ使ったことないけど ID (^_^; 。つか、思いっきしオフトピやねこれ。。。
昔は、当時の一太郎程度の機能ですら辛かったのだが、今は果たして辛い状況なんてどれほどあるのか…
昔と違って、今はなんだかんだで32-bitも64-bitもどっちも面倒みなきゃならないので、開発が辛いです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
我々はまだ32bitをしゃぶり尽くしていない (スコア:2, 参考になる)
漏れはそれがイヤで、FM-TOWNSという迷機を買って、High-Cという迷コンパイラで32bit環境を楽しんでいた(メモリモデルがないとかfarの出番がほとんどないとか)。
翻って、現在。多くの64bitプロセッサは32bitのOSで動いているわけで、これは15年前の状況と同じだな。けれど、あのころのように、どうしても64bitにしたい!という気分になれないのは、我々は
まだ32bitを使いきってないからなんだろうな。多くのユーザにとって、32bitの限界はまだ見えていない。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
すぐに限界を見せてくれるアプリケーションが登場して、移行を促すようになると思います。
Windows XP Pro x64 の仮想メモリページサイズは 4KB? (スコア:4, 興味深い)
Platform SDK の ドキュメント [microsoft.com] を読むと、x64/Windows は互換性を重視して仮想メモリのページサイズは 4KB / page で行くようです。 広いメモリ空間をじゃかじゃか使うプログラムを書くと TLB ミスが足を引っ張って性能の出し切るのが難しそうですね。
# 4KB/page は細かすぎるよ。
IA-64 の Windows 2003 はデフォルトが 8KB/page で、Advanced Server (AS) 以上では 16MB/page への変更が可能でした。おそらく x64 でもページサイズの変更が可能になるのは、2003 AS 以上になるのではないでしょうか?
コンタミは発見の母
スワップしたら負け、の時代じゃないのですか? (スコア:1)
HPC でもスワップしないようにとか。
ギガのメモリモジュールでいっぱいに。
Re:スワップしたら負け、の時代じゃないのですか? (スコア:2, 興味深い)
触りだけを簡単に言うと、
仮想メモリのページサイズは論理アドレス空間に物理メモリを何バイトづつ割り当てるかという単位です。ページサイズが小さくなると同じサイズのメモリも細かく分割することになり、ページ数が増えます。
ページ数が増えると論理アドレスから物理アドレスへの変換表が大きくなります。アドレス変換表はメインメモリ上に構成されるのですが、CPU は TLB と呼ばれる機構に変換表の一部をキャッシュします。IA-32 系の CPU だと TLB は 64 ~ 512 エントリぐらいです (1エントリが1ページ分の変換ルールを記憶できる)。ページサイズが小さいと扱うページ数が増え、TLB ミスが増大します。そして、TLB のミスヒットは、メモリキャッシュのミスヒットよりもペナルティが大きいです。
広大な実メモリを積んだシステム、たとえば 64GB のメモリがある場合、ページサイズが 4KB/page なら 16,777,216 ページあります(しかもプロセス毎に変換表はある)。TLB はミスしまくりは必至です。これが仮想メモリのページサイズが 16MB/page ぐらいになると、ページ数は 4,096 ページと減り、TLB もヒットしやすくなります。
無論、仮想メモリを使わなければこのオーバーヘッドは解決すると思いますが、HPC 分野でも仮想メモリを使わないというのは難しいのではないでしょうか?
# 通信ライブラリの内部とか例外チェックの効率化とかで仮想メモリの仕組みを使っているかもしれない。
<おふとぴ>MacOS 9 の仮想メモリは 論理アドレス空間がシステムに 1 つしかなく、プロセス(インスタンス?)単位のメモリ保護がない機構だったはず。</おふとぴ>
コンタミは発見の母
Re:スワップしたら負け、の時代じゃないのですか? (スコア:0)
Re:スワップしたら負け、の時代じゃないのですか? (スコア:0)
でしたっけ?>Mac(System7 の頃からだっけ?>仮想メモリ)
# OSX でも off に出来るのかなぁ?
Re:スワップしたら負け、の時代じゃないのですか? (スコア:0)
MacOSXではoffにできません。
#コメントへのフォローの上にそれだけなのでAC
Re:Windows XP Pro x64 の仮想メモリページサイズは 4 (スコア:2, 興味深い)
1. 同じメモリサイズを少ないページ数で割り当てられるので、ページ割り当て・解放の回数が減る。
2. TLB に対するプレッシャーが減り、TLB ミスが減る。
現在の Windows には仮想メモリを 10 MB 以上使うようなプログラムはざらにあります。
# 今、ここを見ている Netscaspe は 27MB も消費しています。単純計算で 4KB/page だと 27MB は 6912 ページです。
さすがに 16MB/page はコンシューマー用途では無駄が多いと思いますが、ページサイズを 16KB/page ~ 512KB/page ぐらいにすると IA-32/Windows でも高速化が期待できるのではないでしょうか?
コンタミは発見の母
Re:Windows XP Pro x64 の仮想メモリページサイズは 4 (スコア:2, 参考になる)
x86/Windows は仮想メモリのページサイズは 4,096 バイト。
キャッシュのラインサイズは Pentium Pro 系が 32 バイト、Pentium4 が 128 バイト。
コンタミは発見の母
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
逆に言うと、そういう大型アプリケーションがPCの世界に降りてきたがために、一般ユーザーがまだ32bitに不足を感じないうちから64bitを用意しなければならないようになったということでしょう。それだけx86は多くの分野に浸透したというわけですね。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:2, 興味深い)
必要なのは、物理メモリの容量じゃなくて仮想メモリ空間ですよ。
今時、2GBを超える容量のファイルなんて、マルチメディア系データでは普通にあるので、これをメモリ空間にマップできるだけで、コーディングがどれだけ楽になって、性能が上がることか。
32bitまでの世界では、ファイルサイズに比べて仮想メモリ空間が狭い。OSにどうしてファイルI/OのためのAPIがあるかというと、この狭い仮想空間に、巨大なファイルの一部だけを読み込む必要があるからです。仮想メモリ空間が64bitになると、ファイルをそのまま仮想メモリにマップできますので、ファイルI/OのAPIが不要になります。その結果、ファイルI/Oは全て配列へのアクセスとしてコーディングできるようになります。ファイルI/OのAPIの処理より、仮想メモリの処理の方が圧倒的に軽い処理なので、ファイルI/Oの性能が劇的に改善されます。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
どっちもあったほうがいいと思うけど。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
そう思っているのはあなただけだったりして。
ファイルI/Oなんか関係なしに、仮想メモリのスワップの方が
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
HDDにスワップするかどうかは関係なくて、変な細工無しに32bitのアドレスに収まらない巨大なファイルを丸ごと読み込めるかどうかって話でしょ。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
現状でもマルチメディア系以外のデータであれば楽勝でマッピング出来る筈なんですが、結局はファイルとして扱う事が主流になっているのにはそれなりの理由が在るのでは?と思っておりますが。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:2, すばらしい洞察)
メモリマップドファイルの標準規格が無いからじゃないですかね。
プラットホームによって、CreateFileMapping だとか mmap だとか、やり方が違う。
fopen/fread/fclose はCが使えるならどこでも使えるので、とりあえず fread ですましてしまう。
とか。
あと、メモリマップドファイルは万能じゃないというか、ランダムアクセスする場合はいいんですが、シーケンシャルに一回読むだけとかだと効率が悪いというのもあるかも。
ありがちですが、ファイルサイズ調べて同じだけメモリ確保して、ファイルまるごとreadする、なんてコードにするぐらいなら、マッピングしろよ、とは思います。
#16ビット時代の名残で、適当にシークしながらバッファに16kBずつ読むようなコードを今でも使ってますがID。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
ちょいちょいやってます。CPUの制限よりライブラリやOSの制限でやらざるを得ないのです。
・java1.3での開発で。(1.4ならメモリマップがあるけど1.3には無い)
死ぬほど遅いです... Cならシークして必要な所だけ読めるけどjavaでは……
・95,98,Meの場合、Cで書いていても「丸ごとread」です。
(文句を言われたときは『OSをXPにするか、メモリ増設してください』と回答してます。)
notice : I ignore an anonymous contribution.
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:2, 参考になる)
ファイルサイズで処理の切り分けをしなきゃいけなかったり、ファイルサイズが 2GB よりも大きかったら view を張り直したりと、結局フラットにアクセスできないという面倒さがあるからだと思う。
64bit になったら、それでフラットにアクセスできるようになったら、本当に楽になると思うなあ。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
Gaussianとか.
これだけのためにG5を買う人がいるとか.
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
GaussianよりはADFのほうが…
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
一般的にはそうでしょうね。
別の例を挙げるとすれば、RDB派生でないOLAPとかデータマイニングとかのシステムなど。全文検索エンジンのインデックスファイルをメモリ上に展開、とかね。ま、世に富豪的プログラミング [pitecan.com]のタネは尽きまじ、ってとこですよ。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
# 現段階でまともに3Dゲーム動かすのに最低1GB必要なことを考えると、あと2年もしたらメモリ2GB必要なのが当然になってるような気がする。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
- シートの大きさ(特に行数)制限がないExcel
- 10進16桁整数を入力しても桁落ちしないExcel
ふだんExcelばかりなので,Excelした思いつかん.
Re:我々はまだ32bitをしゃぶり尽くしていない(オフト (スコア:1)
ちゃんとやってくれるExcelが欲しいデス...。
(セルの中の文字列が長くなって折り返して10行
ぐらいになると、表示上の行数と内部的な行数が
変わってしまうらしく、セルのダブルクリックで
行数が自動調整できなくなるのです。)
MSの中の人はアレでいいと思ってるのかなあ。
Re:我々はまだ32bitをしゃぶり尽くしていない(オフト (スコア:0)
不具合があったほうがいいです。
というか、頼むからExcelで作るな。
Re:我々はまだ32bitをしゃぶり尽くしていない(オフト (スコア:0)
たまに、行と列の幅を同じにして方眼紙のように使って仕様書書いているところをみるが、そんなことに労力を使うんだったら、内容に労力を使えといいたいね。
Re:我々はまだ32bitをしゃぶり尽くしていない(オフト (スコア:1)
方眼紙書くなら、Freeware Program to Print Graph Paper [ctech.ac.za]みたいなのを使った方が簡単かも。
ブレインストーミングにエクセルを使う事がありますけど、後々データを転用したりする時に、便利だったりします。扱うデーターが多い時などは特に。
色々考えるのには、MS VISIO 2003 [microsoft.com]が便利そうに見えます。これを使う事を考えているのですが、これはどうなんでしょう。。。
Re:我々はまだ32bitをしゃぶり尽くしていない(オフト (スコア:1)
慣れの問題じゃないでしょうかね? 似たような資料を、似たような時間で、それぞれExcel, PowerPoint, Visioで作る人間ってのがいると思います。
ちなみにあたしはExcel使い。 64bitになったら...。 気持ちが乗るかも。
Re:我々はまだ32bitをしゃぶり尽くしていない(オフト (スコア:0)
Excel方眼紙で仕様書書くのはお手軽なので愛用してるよ。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
なり不満が増すことになるという事を学んだユーザが多い
のでしょう。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
それはともかく。
限界が遠いように見えるうちから切り替えるというのも、またよいではないかと思います。
誰の目にも明らかに状況が苦しくなったというのに面倒がってグズグズして、
ようやく重い腰を上げたら今度はもう慌てて切り替えなくちゃいけない、なんてよりは、ね。
# 先見の明と言ってもタイミングが難しい。
# 早すぎても遅すぎても失敗する。
迷機FMV-TOWNS (スコア:1)
汎用V-TOWNSカードの発売は…やっぱり無理ですかねぇ。
発表当時は技術的には無理じゃないといわれていたと思うんですが。
うちの棚ではタウンズ用ダンジョンマスター/ウィザードリィシリーズが埃をかぶってます…
RYZEN始めました
Re:迷機FMV-TOWNS (スコア:1)
# MS-DOS と RUN386.EXE で成り立ってたシステムだもんなぁ、確かに迷機だわなぁ、などという議論はよしとして (^_^;
くれ>ダンジョンマスター/うぃずシリーズ じゃなくて (^_^;、是非、うんづ [infoseek.co.jp] をお試しくだちゃれ。 Wiz シリーズなんかは 動作が確認されたものもあるみたい [nifty.com]ですよ。
# 現役マシンがまだ稼動しているので実はまだ使ったことないけど ID (^_^; 。つか、思いっきしオフトピやねこれ。。。
むらちより/あい/をこめて。
Re:迷機FMV-TOWNS (スコア:0)
FMV-TOWNSのそれとは違って、ボード上にFM-TOWNSのCPUやチップ・モジュールを搭載していて、電源・キーボード・ストレージ以外は単体で動作しているのが特徴といえば特徴(CPUは386。V-TOWNSカードはCPU・メモリなどもPCと共有)。
今となっては、
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
誰の目にも明らかに状況が苦しくなったというのに面倒がってグズグズして、
ようやく重い腰を上げたら今度はもう慌てて切り替えなくちゃいけない、なんてよりは、ね。
680x0からPowerPCに…。
OS 9.x系列からOS Xに…。
32bitから64bitに…。
ハードごと売ってる会社は、それなりにできるもんだなぁ。
[udon]
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
少なくともMacの進化は映像関係に限って言えば限界をとうに
迎えた状態で切り替えをやって変更後数年は不具合を蒙るという
構図だったかと・・・
68kからPPCの時はハードの不良に苦しまされた(涙)
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
50km/h出るかどうかの車しかなかった頃は性能向上の要求も多かっただろうが、どんな車でも普通に高速道路を走れるような状況で300km/hだとかそれ以上の物を求める人は少なかろう。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
昔と違って、今はなんだかんだで32-bitも64-bitもどっちも面倒みなきゃならないので、開発が辛いです。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
つDOOM3 [doom3.com]
つWMV9 [microsoft.com]
# 64bitな最適化が行われたとしてもそんなに差はでなさそうではある。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
よく飛ばして遊びました
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
通信ログのようなものをファイルに保存して、
その内容を画面上で表示・検索するプログラムを
改造したことがあります。
で、クセ物だったのがそのファイル。
・ファイルは単なるバイナリ形式
・サイズの限界は規定していない。
(どのくらいのデータ量になるか見積もれない)
・リストボックスを使用して、
全データの一括表示・一括検索を可能とする。
(ついでに範囲選択でコピー・ペーストもしたい)
予算の都合上、新規に作り変えることが出来ず、
保守作業での修正を繰り返してきたなれの果てです。
作業そのものにあまり手間(工数)をかけられませんし、
ましてやデータベース導入などという
究極の切り札など、夢のまた夢。
どうしても64ビットにしたい!
という気分になりました。
# 今思えば、
# 「いずれ64ビットWindowsが出てくるので
# それまでじっと耐えて待つこと」を選んだ
# 先見の明があった・・・
# と言いたいやら、言いたくないやら。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:0)
64bitでアドレスする必要があるほど、
メモリを買えないんでわ?
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1, 参考になる)
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1, 興味深い)
88SRなんて何度「限界を超えた」ことか
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
VS 中古パソコン (スコア:0)
時が経つのは早い (スコア:0)
まだ20代半ばだと言うのに、年寄り気分だ。
Re:時が経つのは早い (スコア:0)
IBMのFuture Systemはメモリ空間が24ビットから31ビットになるんだそうな、と騒がれたのをつい先日の様に思い返す。
以下同文...
#あ、s/20代/40代/ (笑)