Windows XP Professional x64 Edition Customer Preview Program 140
ストーリー by Oliver
Linuxだともうお手軽に現実 部門より
Linuxだともうお手軽に現実 部門より
llm 曰く、 "64bitコンピューティングの世界の最新ニュースで、マイクロソフトがWindows XP Professional x64 Edition Customer Preview Programをはじめましたと言う記事がありました。 英語版(ページも全て英語)ですが、CDの郵送かisoイメージのダウンロードが選択できます。早速490メガバイトあるisoイメージをダウンロードしました。 先日Windows XP SP2 の開発が終わり、リリースが発表されたことでいよいよ AMD64/EM-64T対応のWindowsXP Professionalの開発に鞭が入るのではと期待されます。とりあえず早くAthlon64の真の実力が知りたいのですけど・・・。"
我々はまだ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: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をしゃぶり尽くしていない (スコア: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をしゃぶり尽くしていない (スコア:1)
一般的にはそうでしょうね。
別の例を挙げるとすれば、RDB派生でないOLAPとかデータマイニングとかのシステムなど。全文検索エンジンのインデックスファイルをメモリ上に展開、とかね。ま、世に富豪的プログラミング [pitecan.com]のタネは尽きまじ、ってとこですよ。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
- シートの大きさ(特に行数)制限がないExcel
- 10進16桁整数を入力しても桁落ちしないExcel
ふだんExcelばかりなので,Excelした思いつかん.
Re:我々はまだ32bitをしゃぶり尽くしていない(オフト (スコア:1)
ちゃんとやってくれるExcelが欲しいデス...。
(セルの中の文字列が長くなって折り返して10行
ぐらいになると、表示上の行数と内部的な行数が
変わってしまうらしく、セルのダブルクリックで
行数が自動調整できなくなるのです。)
MSの中の人はアレでいいと思ってるのかなあ。
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をしゃぶり尽くしていない (スコア:1)
それはともかく。
限界が遠いように見えるうちから切り替えるというのも、またよいではないかと思います。
誰の目にも明らかに状況が苦しくなったというのに面倒がってグズグズして、
ようやく重い腰を上げたら今度はもう慌てて切り替えなくちゃいけない、なんてよりは、ね。
# 先見の明と言ってもタイミングが難しい。
# 早すぎても遅すぎても失敗する。
迷機FMV-TOWNS (スコア:1)
汎用V-TOWNSカードの発売は…やっぱり無理ですかねぇ。
発表当時は技術的には無理じゃないといわれていたと思うんですが。
うちの棚ではタウンズ用ダンジョンマスター/ウィザードリィシリーズが埃をかぶってます…
RYZEN始めました
Re:迷機FMV-TOWNS (スコア:1)
# MS-DOS と RUN386.EXE で成り立ってたシステムだもんなぁ、確かに迷機だわなぁ、などという議論はよしとして (^_^;
くれ>ダンジョンマスター/うぃずシリーズ じゃなくて (^_^;、是非、うんづ [infoseek.co.jp] をお試しくだちゃれ。 Wiz シリーズなんかは 動作が確認されたものもあるみたい [nifty.com]ですよ。
# 現役マシンがまだ稼動しているので実はまだ使ったことないけど ID (^_^; 。つか、思いっきしオフトピやねこれ。。。
むらちより/あい/をこめて。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
誰の目にも明らかに状況が苦しくなったというのに面倒がってグズグズして、
ようやく重い腰を上げたら今度はもう慌てて切り替えなくちゃいけない、なんてよりは、ね。
680x0からPowerPCに…。
OS 9.x系列からOS Xに…。
32bitから64bitに…。
ハードごと売ってる会社は、それなりにできるもんだなぁ。
[udon]
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
昔と違って、今はなんだかんだで32-bitも64-bitもどっちも面倒みなきゃならないので、開発が辛いです。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
通信ログのようなものをファイルに保存して、
その内容を画面上で表示・検索するプログラムを
改造したことがあります。
で、クセ物だったのがそのファイル。
・ファイルは単なるバイナリ形式
・サイズの限界は規定していない。
(どのくらいのデータ量になるか見積もれない)
・リストボックスを使用して、
全データの一括表示・一括検索を可能とする。
(ついでに範囲選択でコピー・ペーストもしたい)
予算の都合上、新規に作り変えることが出来ず、
保守作業での修正を繰り返してきたなれの果てです。
作業そのものにあまり手間(工数)をかけられませんし、
ましてやデータベース導入などという
究極の切り札など、夢のまた夢。
どうしても64ビットにしたい!
という気分になりました。
# 今思えば、
# 「いずれ64ビットWindowsが出てくるので
# それまでじっと耐えて待つこと」を選んだ
# 先見の明があった・・・
# と言いたいやら、言いたくないやら。
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1, 参考になる)
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1, 興味深い)
88SRなんて何度「限界を超えた」ことか
Re:我々はまだ32bitをしゃぶり尽くしていない (スコア:1)
64bit級OS (スコア:2, おもしろおかしい)
Re:64bit級OS (スコア:1, おもしろおかしい)
64bit化するなら約43億個のWindowsが必要。
Re:64bit級OS (スコア:2, おもしろおかしい)
「えぇ、扱うデータが8bitCPUの倍になりますから」
# と言われてたのはすでに何年前~( ̄▽ ̄;)
Re:64bit級OS (スコア:1)
あれれ、Windows 2003 SP1? (スコア:1)
w2k3sp1_????_usa_x64fre_pro.iso
あれれ?Windows 2003 SP1ベースですか?
そりゃまたしかに2003 SP1ってXP SP2と同じ物を含むはずですが…(^^;;)
# rm -rf ./.
64bit版OSでのメモリアクセス(オフトピ) (スコア:1)
考えているところなので、有識者にコメントいただければ...
Athlon64プラットホームでは、メモリがSocket754のシングルチャネルと、
Scoket939/940のデュアルチャネルがありますけど、メモリアクセス以外で
そんなに有為な差があるようなベンチマーク結果が見当たらないみたいです。
で、OSやアプリケーションを64bit版にすると、メモリの帯域差は
より見えてくるものなのでしょうか?
それとも、変わらない?
そりゃ少なくともデュアル買っとけば間違いないと思いますけど、現状では高すぎですし...
Re:64bitより。。 (スコア:2, 興味深い)
エンジンなどの新技術を声高にアピールする一方で品質部門を日陰者においやって破綻を招いた某社のように命に関わる製品を作っていないから許されるのでしょうか。
Don't ask me why!
Re:64bitより。。 (スコア:1)
>いやその品質部門こそが主役だったのだが・・・。
まさに今、主役として脚光を浴びているようです。
(意に反して)
Don't ask me why!
Re:64bitより。。 (スコア:2, 参考になる)
>というのが、ライセンス契約書に書いてあったような。
それはEULAを見てのことでしょうか?
もしそうであれば、EULAというのはEnd User License Agreementの略であることからもわかるように「エンドユーザー」向けの契約です。
誰が使うかわからないようなEULAで、命にかかわるような保障をするのはかなり難しいかと思います。きちんとトレーニングされた人しか使わないのならともかくとして。
じゃ、Microsoftにエンドユーザー向け以外の契約があるのかといえば、あまり詳細を語ることはできませんが、一応あります。もちろん、失われてしまった生命を回復するような補償はできませんし、してもくれませんが、それなりの損害賠償契約が含まれた契約形態は一応用意されています。というか、ここまでやってくれるOS/機器ベンダーはかなり珍しいと思います。
もちろん、契約金額は推して知るべし、ですが、興味がある人は問い合わせてみればいいんじゃないでしょうか?
予断ですが、このことが功を奏しているのかどうかは定かではありませんけれど、実は生命にかかわるような分野の機器には、意外と高率でWindows系のOSは採用されています。もちろん外見からはそうとはわからないように隠蔽されていますが。
ICUに入ったことのある人(そうそう居ないかもしれませんが)は、知らないうちにあなたの生命がWindowsの管理下に置かれていた、なんて洒落にならない事態を経験しているかもしれません
Re:64bitより。。 (スコア:1)
「使ったとしても保証致しかねます」と解釈しています。
医療の立場からしても使っているのが現状です。
OracleとかWindowsとか必要だから。
Microsoftも
「お前の所のソフトで人が死んだ!」
って言われても、無関係っていういう契約も冷たいですね。ちょっとは責任を感じてほしいものです。
Re:真の実力 (スコア:2, おもしろおかしい)
どこか設定を間違えていませんか?
私のマシンでは、きちんと、頻繁に出ますよ。
青画面見ないとすると、 (スコア:3, 興味深い)
Re:真の実力 (スコア:2, 興味深い)
>特定のハードとソフトの組み合わせで高い頻度で発生する。
問題があるハードやソフトの使用時に青画面が出るのは『正常な動作』なのではないかと思うのですが…。
というより、そういう時は出ないとマズイでしょうし。
#xpに変えた辺りからアヤシイハードを使用する事が無くなったのが安定の理由だったりして。
#にしても、部品は換えているし環境だって良い訳でもなさげだが。
#まあそれでも、安定したハードであればソフト要因で死なないってのであれば、
#それはそれで立派な改善だと思いますが。
#昔はその比では無かったからね~。
Re:真の実力 (スコア:2, すばらしい洞察)
Re:真の実力 (スコア:2, おもしろおかしい)
あなたが欲しいのは、このゆっくり描画するGForceのドライバですか?それとも速いけれどもたまには黒い風景で目を休めたいドライバですか?
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:真の実力 (スコア:1, おもしろおかしい)
そんなバッタモンを使ってるから…
Re:それだけWindowsも熟成が進んで (スコア:1)
CNNの新製品発表の席で青画面だしときながら製品版ではこんなこと「絶対、絶対」にないからなんてぬかしといてからに。
Re:MS Officeユーザには必要ない (スコア:1)
パワーポイントとかのファイルが普通に
4Gを超えてたりして。
Re:MS Officeユーザには必要ない (スコア:1)
そろそろPC更新かなぁ。
Re:MS Officeユーザには必要ない (スコア:1)
そうなると不揮発性メモリのキャッシュが必要になってくるなぁ。
MRAMとかそのあたりでいかがでしょう?
Re:MS Officeユーザには必要ない (スコア:1)
Re:MS Officeユーザには必要ない (スコア:1)
32-bitのアプリケーションも素で動くのが売りなのですから、OSは64-bit版を枯れさせる方が将来的にお得ではないかと。
# ハードの移行がそこまで早くないでしょうし、MS Officeがちゃんと動くかどうかも知りませんけど。