今さら64bitで喜んでる奴はCPUがわかってない

64bitなんてローテクでしょ？
たいした恩恵もなし。

16bitの時代のように漢字が高速に扱えるようになったわけでもなし
32bitの時代のようにセグメントから解放されたわけでもなし
64bit演算なんてむかしっから出来るし

SIMD　> 64bit なんだよなぁ、ハード技術的には。

2げと

スルーの方向で

ぺ4様もスルーする。

5げと

ぬるぽ

これからは、それらを超越した「HitBit」だ。

256ビットですが何か？つい最近まで64ビット地雷でした

64ビットになっていくらメモリ使えるようになったの？

NINTENDO 64の話？

>>1
さあ、はやくCPUを梱包する作業に戻るんだ

専門学校でPCの歴史を習ったばかりなんだろ

自作CPU板でやれ

まぁマジな話、1プロセスでメモリを2GB以上使うのって、どんなアプリよ。

AMD64はIA64のﾊﾟｸﾘっていうのかと思ったらﾂﾏﾝﾈ

>>6　
うはあ、なつかしい。
所ジョージだったよなあ。CM。

え、松田聖子じゃなかったっけ？

会社のサーバーは64bit(SunUltra)化して久しいが、正直パーソナルユースPCでの
64Bit化は現状無意味だとは思うよ
正直今AMD64とかEM64Tに手を出して大喜びしてるのは厨房だけだと思う

開発環境もやっと出揃ってきたばかりだし、そもそも現状ニッチ過ぎる64bit実行環境
をターゲットに開発しても旨味無いし

64bitで喜んでる会社ってあほだろ

>>13,17
パーソナルユースでもHDTVクラスの動画を扱い出すと64ビットのアドレス空間が
必要になってくるんで無いかい？

64bitでじさっかー的にどういう旨みがあるのか、そこはっきりしとこうぜ

自己満足だけにきまっとろーが。
そんなこともワカンネーで自作してたのかよ

自己満足つってもたかが64bitだからな。

キーとヒットすると答えがビッとｸﾙ!!

人々のHitBit〜♪

>>13
JavaVMで動くWebアプリなんかかな。
そういうクソアプリが実際にあるんだな、これが。
Servret使えよ……いい加減。

JavaVMで1スレッド。アプリそのものはVM上でスレッド展開するから、OSから見たら1スレッドしか立たない。

っていう、あのアプリは恩恵を受けるんだろうか……
たぶん、ダメだろうなぁ……元々も作りが悪いから……

Servletな

トリビア
Socket939やLGA775など多ピンのCPUが増えてきたが、そのピンの半分以上は




電源・グランドピン

>>20
目立って速くなるのは圧縮とかファイル処理かな。

ジサカー的には64bitWindowsというあたらしいOSをインスコする楽しみがあること。

Linuxでデスクトップ環境作っていじってると64bitの恩恵受けまくりだけどな。
KDE、GNOMEの動作速度が32bit時と段違いだ。非常にキビキビ。

みなさん！
64bitの恩恵はちゃんとあるじゃないですか！

4GB以上のメモリが使える。

ほら、ちゃんと恩恵があるじゃないですか！

>>29
物理メモリは現行プロセッサでも一応64GBまでいけますがなにか？
http://www.linuxworld.jp/special/-/10994-3.html

>>28

プラシィィーボ

>>29
恩恵を被れるほどメモリが安くねーんだけど

>>19
なんで?

いまのDVDだって4GBオーバーだけど、32ビットでやりくりできてるじゃん。
64ビット化すべきタイミングは、もうとっくの昔に過ぎちゃってるから、もうどうでもいいっすよ。

>>28
それは64ビットの恩恵ではなく、ついでに行われたレジスタ倍増の恩恵ですよ。

>>33
ソフト作る側は一枚のアドレス空間にノペーッと展開して扱える方が楽だから。

>>34
だから、それは時期を逸したのですよ。

ちなみに、34さんは、本当にソフトを作ってる人ですか?

64ビットのアドレス空間は、ファイルをメモリマップするためにある、なんて馬鹿なことを言う人がいるんだよね。
やったことがあれば、そんなことは言わないんだけどな・・・。

>>17

基本的には、
「2年ほどすれば、どのユーザにも関係するようになる」程度で、
まだ必要性は薄いわけですが、

・フォトショなどで、非常にピクセル数の多い画像を使う人
　広告・チラシ用の画像を処理する人かな？
・データベースサーバ
ぐらいしか、今はまだ恩恵がないでしょ。

>>33
DVDの場合、1GBのファイルに分割して対処している。
4GBを超えるファイルなぞ使っていない。

>>27
じつは、本当の強化点は、レジスタ数の増加にある。
汎用レジスタの不足ゆえに、RISCにくらべ
クロックあたりの性能が低かったわけだが、
汎用レジスタを増やすことにより、同クロックでも性能が伸びる。
(アプリの構造によっては、今と同等だが。)

汎用レジスタってCASLII勉強したけどいまだに意味わかんねー
とりあえず汎用レジスタが32から倍増したってのはわかるんだけど

>>34はバカ

ム板のなっちがすみません・・・

いやだからおめーらCPUベンダは自作オタだけ相手にして商売してるわけじゃねーんだってむしろ眼中にねーんだって

つかジサカーは64bitだから喜んでたか?

よろこんでいるのは俺だけさ

>>42
誤爆スレな希ガス

64bitモードで遅くなるEM64Tは確かにいらないな

>>36
UNIX屋からすると、IO Bufferが4GB超えるのはうれしいのは事実。
vmの構造上アプリでうだうだやるよりmmapかけてkernelに任せたほうが軽い。

IntelのPAEは複数プロセスで合計4GBを超えることは可能だけど、
ページドマップで使うと1プロセスでは相変わらず4GB。
みんなセグメント嫌いだから。

まあ、あれだ。DIMMも128bitにして欲しいのう。
と言って32bitCPUを締め出してやるテスト

とまあ、ソフトだけじゃなくてハードからも見てみなさいよというわけです。

>>48
CPU外のハード的には128bitだろうと256bitだろうと好きなの選べばいいよ別に。
どうせbufferやcacheで全部吸収しちゃうから、そのあとちまちま32bit処理
すればいい。データはどうせおまいら、byteやwordは捨てられないだろ？

>>38

汎用レジスタもSSEレジスタも8個ずつしかありませんでした。
EM64Tでは、16個ずつ、倍増です。

これの効果が絶大と予想。


汎用レジスタのビット数が32→64ビットになることの効果は、
まだ実感できる場面がないと思われます。

ごく一部の場合に、効果が出る場合もある、って程度。

これが本格的に有効になるのは、まだ何年か将来のことでしょう。

セガサターンで十分

セガサターンは32ビットCPUｼﾞｬﾏｲｶ

32bitCPUが2つで64bit級です

>>46
だからさ、それ、やったことあるの?

ファイルサイズの合計よりも多くのメモリを積んだモンスターマシンなら恩恵があるけど、
PCの範疇の搭載メモリ量では、かえってパフォーマンスが激しく劣化することが多々あるんだよ。

俺も一時期、これからは全部メモリマップで楽々〜なんて浮かれてた時期があったんだけど、
実際にやってみたら酷いパフォーマンスで、手抜きはしちゃいかんと改心したわけですよ。

PS2は128bitですが何か？

256Bit、って、いつできて、なにが、できるようになる？

>>56
とりあえず、おまえには使えない。

うさだ君には4bitで十分だと思いますよ。

abit

セガサターンは
メインの32bitCPU SH2x2
CDC用の32bitCPU SH1x1
外部機器コントロール用の組み込み4bitCPU SMPCx1
サウンド用の16bitCPU 68EC000x1
で116bit級です

簡単に言えば扱えるデータの幅が増えるだけ。
まあ、その増えるってのが重要なんだけどね。

>>54
おれは34でもないんだが、あんたvmやmmapって言われて理解してる？

Fileのmmapなんて普通にやるよ。openしてread/write/lseekなんてsystem call
乱発するより、openしてmmapかけてあとはメモリ操作と同様にいじったほうが
確実に早い。アクセスしない場所はメモリに読み込まれないし、メモリ足りなく
なっても変更がされていなければその場で捨てられるだけ。変更があったら元の
ファイルに書き戻されてぽい。このあたりはpagerが勝手にやってくれる。

あんたvm理解せずにmallocでもかけてどっちゃっとメモリに読み込んでとか、
無駄なことやったんだろ。それやるとprocessのdata領域に乗るから、メモリ
足りなくなるとpage outされる。それをファイルに戻そうとすると、また
page in してからディスクに書き出しだから、遅くなってあたりまえ。

んで、32bitだとメモリポインタも32bitまでしか扱えないから、
vmの種類にもよるけど2GB〜4GBまでのファイルしかその手は使えない。
最近そのくらいのファイルはごろごろしてるから、ちょっとつらい。

64bitになるとメモリポインタは16EBまで使えるから、まぁしばらく大丈夫。
物理メモリも4GBなんてそろそろ普通に乗せられるようになってきたし、
64bit化は実際うれしい。

>>13
昔、初代PC-9801を見たとき、64KB以上のメモリを使うようなアプリなんて
一体どこの馬鹿が作るんだ？とか思ったものさ。

>>62
巨大なメモリマップドファイルなんて普通の家庭では行いません。

>>65
うんうん、そうだね、一般家庭じゃプログラムなんてしないし、
UNIXなんてつかわないもんね。

↑怒るなよｗ

論破されちゃって論理的に反論できなくなっちゃった人には
同情してあげるといいんだよ？ ；−）

>>62
ファイルサイズの合計と言ったのが悪かったかな。
より厳密には、ファイルの中で触る部分の合計、ね。

UNIXは捨ててWindowsに転向したので、
CreateFileしてCreateFileMappingしてMapViewOfFileExしてますが、何か。

UNIXとWindowsで、そんなにVMやメモリマップドファイルの挙動は違わないと思うけど、
そんなにUNIX(ってOSによってVMなんてまるっきり違うような・・・)のVMは賢いの?

DemandPage式が広く使われるようになってからvmの挙動はそれほど差はないんで、
WindowsとUNIXでもそんなに差があるようには僕もおもえんけど。

MapViewOfFileExがファイルを仮想メモリにマップしてポインタを返す関数だよね。
僕の感覚だとこの関数が呼ばれた時点では実メモリは消費されないはずだけど、
もし既に使われてたら「このタコ！」って叫んでいいかも。

ただ、MSDNのマニュアル眺めると、32bit限界を解決するためにPeepHole的に操作を
する関数なんで、呼び出した時点で指定したバイト数、実メモリにLoadしているかも。
書き戻しもFlush呼ぶ必要あるみたいだし。その場合、>>62後半と同じ事をしているの
ことになるので、おっしゃるとおり大量の実メモリが必要だし、すべてのファイルを
Mapしようとするのは間違い。

一方、mmapの場合は必要な仮想メモリの領域を予約するだけで、その時点では
まだ何もしない。返されたポインタが指し示す場所には実は実メモリすら配置
されてない。

その状態でメモリ操作を行うと、当然メモリが準備されてないんで、page faultを
起こして、kernalとpagerが「ああ、やべぇ」と慌ててFileから該当するページを
読み込む(page inする）わけ。でもこの時点ではまだそのpageはcleanなのね。

どんどん読み込んでいって実メモリが足りなくなると、cleanなページは別にいつでも
fileから読めるわけなんで、古いのから捨ててしまう。書き込みがあってdartyな場合、
更新されてるわけなんで、Fileに対して書き出す（Page outする）。

仮想メモリの管理の一環として扱うんだよね。だから、Flushの必要もない。
メモリが空いてるなら、プログラムが終了してもメモリに残ってる。Syncされると
書き出されるし、ファイルが消されるとメモリからも消えるけど。

こっちの場合だと、メモリは空いてる分しか使われない（最悪、1page分の空きが
あればいい）し、必要最低限のファイルアクセスしかしないんで、繰り返し
ファイルの中身をいじればいじるほど、速度的にも有利。

一度しか読み込まないような使い方は…あんまりメリットないけど。

vmの違いじゃなくて、「ファイルをマップする」関数の違いだろうな。

jVeRSQD/って調べればわかるような知識をひけらかして、どうしたもんだか。
おなぬぅするなよ。

＞呼び出した時点で指定したバイト数、実メモリにLoadしているかも。
AWEのメモリウィンドウ割付の際の実メモリは割り当ては
オプションで指定できる。

MEや9xだと悲惨なことになるが

>>73
俺？
ME&9xじゃ使えませんけど。

>>72
こんなところでAWEの話題が。
教えていただきたいのですが、AllocateUserPhysicalPages()ほかAWEの
関数が自分のところのkernel32.libに入っていないのです。
これらAWEの関数はどのライブラリに入っているのですか？

ム板できいても返答がないもので、お願いします。

>>70
MapViewOfFileExは実メモリをすぐに消費はしてないと思う。

呼び出しは一瞬で帰ってくるので、
ディスクからメモリに全部読むなんてマヌケなこともしてないと思う。

パフォーマンスが落ちるのでメモリマップが向かないのは、
ファイルから読むサイズは実メモリに対して大きいけど、メモリ上に置くべきサイズが小さい場合。
(最も顕著なのは、シーケンシャルにファイルの中身を舐める場合かな。)
もう読まないページが最近アクセスしたということで優先的に実メモリが与えられてしまい、
ディスクキャッシュの中身が捨てられたり、EXEやDLLのイメージが捨てられたりするようですよ。

ディスクがガリガリ鳴って速度が激しく低下するので、すぐに失敗だとわかります。
OSにたくさんのヒントを与えられればいいのですけどね・・・

>もう読まないページが最近アクセスしたということで優先的に実メモリが与えられてしまい、
>ディスクキャッシュの中身が捨てられたり、EXEやDLLのイメージが捨てられたりするようですよ。
ファイルマップ関連でProcessのData領域をつかっちゃって、他のtextやdataと
同じ扱いにされちゃうんですね。それはきっつい。

まぁ、
>64ビットのアドレス空間は、ファイルをメモリマップするためにある、なんて馬鹿なことを言う人がいるんだよね。
>やったことがあれば、そんなことは言わないんだけどな・・・。
てのがUNIXではアリで、誤解というのがご理解いただければ幸いです。

まぁね…家庭クラスでUNIXなんてつかってるの一部のスキモノとMacくらいだしね…
サーバですらだいぶ駆逐されてきちゃったしね…Linuxは伸びてるけどね…。

>>77
>まぁね…家庭クラスでUNIXなんてつかってるの一部のスキモノとMacくらいだしね…
>サーバですらだいぶ駆逐されてきちゃったしね…Linuxは伸びてるけどね…。

意味不明。
LinuxはUNIXに含まれる。

>>78

文章から察するに
77はロートルです。

見　逃　し　て　や　り　ま　し　ょ　う。

>>79
LinuxをUNIXとは別物と思い込むのは、ロートルというよりは初心者、あるいは
非アカデミックな人なんだけど。

>78-80

お前等は両生動物のクソをかき集めた値打ちしかない！

>>75
なければ、LIBコマンドでインポートライブラリを作れよ。

PAEかつOSがsever系でなければ、4GB（-PCI領域）を超える物理アドレスは
確保できないよ。

>>まぁね…家庭クラスでUNIXなんてつかってるの一部のスキモノとMacくらいだしね…
>>サーバですらだいぶ駆逐されてきちゃったしね…Linuxは伸びてるけどね…。
>意味不明。
>LinuxはUNIXに含まれる。
日本語不自由？

>>82
4GB制限については知っています。
ページを完全にロックしたいのでAWEを使っているのです。

なんとか実行するとこまで漕ぎ着けたのですが、プロセスにページロック権限を
与えようとするとエラーコード1413が返ってきて上手くいきません。
MSDNのサンプルプログラムでも駄目でした。
どこがおかしいのでしょうか？
板違いなのでこれで最後にします。お願いします。

>>84
セキュリティポリシーの設定で、ユーザーかグループに
ページロックの権限を与えていますか？

>>85
動きました。
ありがとうございました。

LinuxはUNIXクローン

既出かもしれんが
MSXは最後128bitだった希ガス

うんにゃ、再度はTURBO R（R800）の１６bitだった希ガス

LinuxはUNIXのわりに伸びてるってイミダロ

ttp://bio3d.colorado.edu/imod/
↑4GB以上のメモリを素で食うソフト

この世には貴様等の知らん世界がある
貴様等の狭い見識だけで要不要論を語るな

というか、要不要論も自由だよ。

どんな技術に喜んで、何に価値を置くのかも自由。
その為にPCなんて自分で組み立ててるんでしょ。

　

64bitOSないと意味ないしな。

レジスタ増設があるのでアプリが対応してくれば速くなるだろう。
少し後かもしれないけど。

age

将来のOSはハードウェアも仮想化されて、一台のマシンで
複数のシステムがエミュられて動く。
セキリティの面でもメリットがでかいので、
広大なアドレス空間はいずれ必要なんだわさ。

ハードウェアの仮想化がOSの元々の目的な罠

で、結局「bit」ってなんだよ。

そんなもんどうでもいいじゃねいか

噂だけど、64bit版マインスイーパーは凄いらしいぞ、
盤面の広さが4倍になってるらしい。
たぶん32bit x 32bitが64bit x 64bitになったので、2x2=4
という計算になるんじゃないかな。

SUGEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE

最近のｹﾞｰﾑは1GBﾒﾓﾘ積んでも足りないのがでてきてるしな
そのうち本当に必要になるだろ、64bit
ﾚｼﾞｽﾀ増えてるから意味あるし
それと32bitだって最初はﾊｧｰ？とか言われてたｗ
386ｵｾｰ、286のがﾊｴｴｴって

Linux、UNIXの中でも世界に受け入れらていることから
出来がいいと思ってる人がたくさんいるが
実際は、逆なんだがな…
Linuxは、作者が個人でｵｰﾌﾟﾝであったが故にひろまってしまったが
いいのか悪いのか

今でもVMwareで、1台のPCで5つのWindowsを走らせてるぞ。

VMware自体の作りの問題で制限があるけど、それぞれ別プロセスなので、
本質的にはアドレス空間が32ビットでも、メモリ2GBのVMを10個走らせることも、
不可能ではない。

さっくり64ビット化したほうが楽なのは言うまでもないけどね。

64bitOSｷﾀｰ!と喜んでるヤツのCPUは実は32bit
とスレタイを深読みしてみた。

AMDｺｱ欠け & 焼け焼けばっかりでuzeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

（ ´,_ゝ｀）ﾌﾟｯ

（ ´,_ゝ｀）AMDﾌﾟｯ

>>106
いつの時代のAthlonのことを言っているのかな？

ID:tZPZ6eni　は虚言癖があります。
たぶん病院から逃げてきたんじゃないかな？

てかID:tZPZ6eniで今日のカキコ全部検索したら奴がどれだけ可哀相な人間か分かるぞ。
マジでそっとしといてやった方がいいと思う。

>>98
共立出版の雑誌だろ？

AMD64って、もともと、Itaniumに対抗する形で
構想が発表された希ガス。

実際の発売はItaniumより大きく遅れて、
Itanium2の後だったが。

最終的に、MSとの交渉の成果か、
Intelにもx86という形で採用させれたから良かったが、
ヘタしたらどうなってた事やら。

当初からAMDは64ビットはオマケだと言ってたので、
そのまま盲腸のまま終わっても、大して痛くなかったと思う。

大半のユーザが高速な32ビットCPUとして買って使ってるわけで。

まあ早めに64ビットCPUの提供をしておくことで、いずれOSが本格的に64ビットに移行したときに
最新CPUでないと使えませんってなことになるのを避けようとしたんじゃあるまいかと。

age

現状じゃ64を生かす環境は無いのは確かだけど、64といっても、32bitとしても最速な訳で、
ユーザーは64目当てじゃないよな。
メーカ側としては早期に64版を開発提供していくことによって、近い将来必ずやってくる64ビット化の波に乗り遅れず、
最前線でやっていけるから、そういう意味での64bitCPUだな今は。
いずれにしてもユーザー側としては、64の功は少なくても、不利益な要素は全くないわけで。

ただしAMDのせいで建て増しで64bitCPUとしては効率の悪いAMD64
が主流になってしまったせいで今後性能と電力のバランスを取るのが
極端に難しくなっていく気がする。
RISCには永遠に勝てないのかも。

intelがムーアの腰巾着だからこうなったとも思えるけどね。
ジジーの言いなりでクロック周波数だけ上げてどおすんだよ。

CISC vs RISC という区別は、もはや意味がないよ。
CISCはRISC化し、RISCはCISC化して、どっちも同じようなものだから。

RISCを名乗っているCPUに対して、RISCの産みの親の教授が、
こんなのはRISCではない! って激怒したとかいう話もあるし。

ただ、x86はいくらなんでも過去のシガラミが大きすぎるね。
そこは、開発費も製造コストも、大量生産でカバーしてるけど。

でも、AMD64/EM64Tは、x86の過去のシガラミをそれなりには絶ちきってる。
これを言うと荒れるんだけど、AMD64/EM64Tの64ビットのモードは、x86とは互換性がない。

80386で32ビットに拡張した時は、16ビット計算と32ビット計算の命令を命令単位で混在できた。
そのために、32ビット計算の命令は未定義の部分を使って、かなり歪だった。

今回のAMD64/EM64Tは、
64ビットのモードでの32ビット計算の命令と32ビットのモードでの32ビット計算の命令はコードが違う。
だから、そんなに将来は暗くないと思うよ。

REXのために、オペコードの割り当てを変えただけでは？

録音bit

メモリは多ければ多いほど良い！











ヒント：シ　ス　テ　ム　キャッ　シュ

Windows文化がこれだけ発展した以上、x86ベースのソフトウェア資産が生かせるメリットのほうがずっと大きいもんねえ
どんなに性能の大きいシステムでも、資産を生かせないようでは絶対に普及し得ない
Intelはその点が全くわかってなかったねえ

>>122
そんなんフォトショとか使う人のみだろ。
普通、余りまくる。

ローテクでもマイチェンでも
時代が日々進歩してるのを感じることができるのはありがたいよ

最新のネトゲはアホみたいにメモリ食うよ
必須１G、推奨２Gとか
フォトショだけじゃない

現状でもアフエフ使った映像制作の現場なんかでは、メモリ不足は深刻みたいだしな
普通のPC環境でハイエンドなグラフィック環境が手に入るのはすごい便利だろうな

あと、こういったソフトウェアは64bitカラーが基本だからコードの64bit化の恩恵も大きい

ウインドウズムービーメーカー（OS付属）で高画質ビデオ大でビデオの取り込み
やったらCPU速度が遅い場合、メモリを喰うよ

>>126
推奨２Gのネトゲって何か教えてくれ

大量のディスクキャッシュが必要になるようなアプリって、
そのアプリの作りが悪かったりするのよ。

ディスクアクセスを先行してできるのにやらないとか、
バックグラウンドでディスクアクセスしないとか。
ディスクキャッシュを汚染してしまうとか。

>>123
Intelは、それはよくわかっていたはずだよ。
Intelはx86以外のCPUを作ったけど、ことごとく売れなかったからね。

IA-64のCPUも当初の計画では、
登場時点で最速のx86と同等の速度を持ち、
なんら速度的なハンデなしに移行していくはずだった。

ただ、登場が何年も遅れたために悲惨なことになっただけ。

x86以外はことごとく？

StrongARMだけは売れてるでそ？

まあ、あれは買収したものだが。

StrongARMはごく最近で、IA-64の計画が立てられた頃は、まったくインテルとは関係なかったと思う。

ちょっと時系列を失念してた。

確かそうだったっけ。

もっとも、IA64の発売よりは前だったか。
(IA64の開発、遅れすぎ)

>>130
IA-64は当初の予定ではいつ頃出るはずだったっけ？

>>134
何度も延期されたような気がするけど、
1999年に量産出荷を予定してた時期があったよ。

1999年は
1月にPentiumII Xeon 450MHzが量産出荷開始
3月にPentium!!! 500MHzが量産出荷開始
12月にPentium!!!は800MHzが量産出荷開始

同クロックのPentium!!!と同等のx86実行能力があると言われていたけど、
実際には半分以下だったらしい。

（131＆133です）

開発開始（発表か?）は94年だっけ？

ちょうど、PentiumProが、
16ビットコードの実行時に遅くなると分かった頃。

で、翌年には、HPがPA-9000シリーズをキャンセルして、
（仮称）痛でやっていく事にして、共同開発に全力投球したんだっけ？

それが、遅れに遅れて、PentiumIIIの1GHzとほぼ同時期になった？

開発開始はもっと前だったような・・・。

もうx86の性能向上は無理だ、今後RISC勢との性能の差が開きすぎる、
という悲観的なムードの時に期待の星だったような気がするから、
P6アーキテクチャが形になる前だったのではないかと。

2001年
3月 Pentium!!! Xeon 900MHz 量産出荷開始、モバイル版Pentium!!! 1GHz量産出荷開始
4月 Pentium4 1.7GHz 量産出荷開始
5月 初代Itaniumの「供給体制が整う」という、笑えないタイトルのプレスリリース

世界を代表する牛丼専門店サンボのスレもいよいよ４スレ目！！！！

【秋葉原】サンボ４杯【牛丼】(丼板)
http://food6.2ch.net/test/read.cgi/don/1116140956/