07/11/15 00:26:42 gZ75je9D0
bitたけし
20:名称未設定
07/11/15 00:28:55 Wui+tUNt0
>>7
x86 の長年のネックだった GPR が増えるんだから凄いべよ。
21:名称未設定
07/11/15 02:01:16 EeMrHmUo0
まあカーネル自体が32bitプロセスなのは間違いない
% file /mach_kernel
してみりゃ分かるが
Leopardは64bitに対応したAPIが増えただけで、別にTigerから特別大きく変わった訳じゃない。
4GB以上のメモリ空間が使えて64bitモードでCPUを動かせる以上
一般ユーザや開発者にとってカーネルが32bitだろうが64bitだろうがどうでも良い話ではある
22:名称未設定
07/11/15 04:57:45 Y44Cgnwf0
その昔Win32Sという16bit Windowsで32bitAPIが動かせるしくみがあったんだよね。
それと同じだと思えばまあいいんじゃないの。
AppleのLeopardの宣伝文句はやりすぎだと思うけど。
23:名称未設定
07/11/15 07:45:56 T2FrZuve0
使えるメモリが増えただけでもイイ。
32bitアプリが殆どの現代、孤高の完全なる64bitは無用では？
24:名称未設定
07/11/15 08:27:21 3jRr32UQ0
windowsは遅れてますね
25:名称未設定
07/11/15 09:47:25 Y44Cgnwf0
>>24
具体てきにはなにが？
26:名称未設定
07/11/15 09:50:31 ybOHEjph0
Win32Sものすごい虎馬
これからはWin32の時代だぜ！という宣伝文句に踊らされて
アプリ全部32Sで作り直したらバグ地獄
27:名称未設定
07/11/15 10:29:37 C6Iu9C680
kernelが32bitなのはars technicaのレビューが出た時点で分かってたと思うが
28:名称未設定
07/11/15 12:43:53 LOy5WNgj0
>>19不覚にもワラタ
29:名称未設定
07/11/15 20:48:39 hXCIGa1t0
やっぱり真の64bitOSじゃないのね。
Windows9xがカーネルのほとんど32bitなのに、ごく一部に16bitコードが
含まれただけで16bit OSだと言うやつがいたが、そいつに言わせれば
カーネルが32bitのLeopardは完全な32bit OSなのだろうね。
30:名称未設定
07/11/15 21:08:29 DiLVRWoB0
まあ64bitカーネルになってたら今頃はドライバが全く無くて大変だっただろうな。
広告の文言以外は堅実な選択だな。
31:名称未設定
07/11/15 21:16:06 TMHoKTA70
よく分からんのは、未だ32bitカーネルである事と、
URLﾘﾝｸ(developer.apple.com)
"Mac OS X supports both 32-bit and 64-bit drivers."
とか
URLﾘﾝｸ(www.apple.com)
＞さらに嬉しいことに、新しい64ビット対応ドライバにアップグレードすると、32ビットアプリ
＞ケーションのスループットも向上します。
とかの記述との関連性。
この「64ビット対応ドライバ」って、
URLﾘﾝｸ(developer.apple.com)
の記述にある「DMA関係をupdate」したドライバってことなのか？
32:名称未設定
07/11/16 11:06:32 z0DH8S830
>>31
ドライバーにはカーネルドライバーとユーザーランドドライバーがあるよ。
33:名称未設定
07/11/16 20:08:08 DcLlPhOB0
無知どうし罵り合うスレはここですかw
34:名称未設定
07/11/16 20:25:19 lrie6kYE0
安い煽りは要らないから、貴方の溢れんばかりの知識をここで
存分に披露して下さいな
35:名称未設定
07/11/16 22:56:12 9jrKGH8Y0
はい。結論。
Leopardは真の32bit OSでした。
36:名称未設定
07/11/17 00:39:35 boskS6O+0
まあ、上層レイヤは64bitだからどっちでもいんじゃね？
それより32bitマシンが32/64bit Universalアプリの64bitバイナリを開こうとして華麗に落ちる方が問題だよなあ
37:名称未設定
07/11/17 09:57:13 4a9IpoNr0
>>36
そんなこと起こる？うちの CoreDuo マシンで XCode 開いてもだい丈夫だけど。
38:名称未設定
07/11/17 17:44:42 boskS6O+0
Finderから開くと大丈夫だけど、ターミナルから開くと落ちる。
それとも俺がなにかミスってるのかなあ
39:名称未設定
07/11/17 22:12:53 tBkOtQNH0
やっぱり32bitなんだね。
40:名称未設定
07/11/17 22:34:15 FOdztiNd0
32bit級。
41:名称未設定
07/11/17 22:47:02 RX38yaFG0
Kernel processes will still run in 32-bit memory space.
42:名称未設定
07/11/17 23:33:04 GZnrhasK0
iMacもWindowsみたいに認識してるメモリーは3GBだけなの？
43:名称未設定
07/11/17 23:47:17 J88eC3sZ0
OSごと落ちるのはドザのお家芸
44:名称未設定
07/11/18 00:04:35 i3s2PxJ10
>>42
旧機種はintelのチップセットの制約で3GB
OS Xの制約ではない
45:名称未設定
07/11/18 00:46:45 zIdZozCC0
カーネルが32bitだと他の部分で足引っ張るってことやっぱりあるの？
46:名称未設定
07/11/18 01:13:20 Av1EOJmJ0
>>38
それ、ちゃんとFeedbackしといて。
URLﾘﾝｸ(regist.apple.co.jp)
俺が10.5.3くらいになってからLeopardを導入する時までに、そういう地味な問題は
Fixしておいて欲しいw
47:名称未設定
07/11/18 01:30:31 HhFI8v3k0
ドザって1bitらしいね
48:名称未設定
07/11/18 03:35:16 xvKPV8GY0
またSHARPのミニコンポみたいな事言って…
49:名称未設定
07/11/18 03:40:54 N4fjTTux0
NINTENDO64でLeopardは動きますか?
50:名称未設定
07/11/18 06:37:33 LxsxGvmb0
>>43
kernerlモジュールに不具合があればOSごと落ちる可能性はWindowsでもOSXでもFeeBSDでもLinuxでもSolarisでもなんでも同じようなもの。
51:名称未設定
07/11/18 07:51:15 9M4JqGBn0
>>47
ポーク…じゃねえか？
52:名称未設定
07/11/18 12:20:07 62d1X69g0
今はいいけど
来年以降Nehalemが出てから完全64bitOSにして欲しいな
この調子なら68kからPPCに移行期みたくいつまでたっても32bitのコードが残りそうで
足かせになるぞ
53:名称未設定
07/11/18 12:46:11 PxWpUj+40
64bitのコードしかネイティブに実行できないCPUが出ない限り別に足枷にならないから。
32bit環境の問題はプロセス当たりのメモリ空間のみで、
16bit->32bitや68k->PPCの移行の時とは違って速度の問題は無い。
まあx86の場合論理レジスタが増えると言うおまけはあるけど。
54:名称未設定
07/11/18 12:47:58 YFIOeH3f0
gdgd言う奴は、カーネルが64bitじゃないと何が困るか書いてみろ。
55:名称未設定
07/11/18 13:49:13 2ZjCCQ2T0
>>54
仮想メモリが 32bit で動いているならアドレス変換のオーバーヘッドがあるね
ページサイズも 4KB なんでしょ
56:名称未設定
07/11/18 13:53:59 2ZjCCQ2T0
>>54
あと x86 に限った話だけど、64bit にするとレジスタ数が一気に増えるから
当然速度が速くなる
57:名称未設定
07/11/18 14:11:13 IxLochVz0
まあ、レジスタ増えてもそれを使ってなきゃ意味がないから、
64bit用に再コンパイルが必要だけどね。
ソース手に入れられないメーカー品は対応してくれるまで待て。
既存のソフトが早くなるわけじゃない。
58:名称未設定
07/11/18 14:19:17 2ZjCCQ2T0
kernel の話ですよ?
59:名称未設定
07/11/18 14:32:54 IxLochVz0
あと、命令を64bitにすると長さが2倍になるから、
その分メモリの使用量が増えてしまうね。
60:名称未設定
07/11/18 14:33:23 thinLfml0
PPCG5がでたときに
「CPUは64bitでOSは32bitだけどスピードのロスはないよ」
って言ってたよな。あれも妄想ベンチ？
61:名称未設定
07/11/18 14:38:15 X4aNm9TT0
まぁ、32bitでも64bitでも、普通に使うぶんには何ら問題ないわけだし
Leopardが便利きわまりないものであることも、何ら変わりはない、、と。
62:名称未設定
07/11/18 14:46:07 xb1Ii9wH0
>>60
PPC は x86 とちがってそういうものらしい
63:名称未設定
07/11/18 16:15:14 2ZjCCQ2T0
>>61
痘痕もえくぼって奴だな。
64:名称未設定
07/11/18 16:40:50 2ZjCCQ2T0
>>59
Instruction の長さなんて誤差の範囲じゃないの。
バイナリのサイズなんて頑張っても数十 MB だからね。
一方で long とポインタの長さが増えるのは確かに
メモリを消費するけど、物理メモリ搭載量も以前とは
比較にならない程増えているし、アドレス空間も広大。
メモリ帯域の事を考えても、引数をレジスタ渡し出来る
メリットに比べたら微々たるもの。
65:名称未設定
07/11/18 17:00:42 Mcgcg9Gf0
>>64
でもヒープなどは64bitにすると、オーバーヘッドは無視できないよ。
もちろん使用メモリが倍になっても、最近は乗り切れちゃうけど
個人的には、userlandは32bitで十分と思う。64bitが必要なのはごく一部
ただ、32bitのメモリ食いアプリを複数動かせる64bitOSは歓迎。
なんとまあ、普通の結論ですなｗ
66:名称未設定
07/11/18 17:01:23 a3QfhndJ0
ID: 2ZjCCQ2T0 はさっきから何を頑張ってるだろう
67:名称未設定
07/11/18 17:23:21 qtuNFTC60
>>66
>何を頑張ってる
Vistaを64bitでインストールしてしまい後悔を隠したい、とかでないことを期待。
68:名称未設定
07/11/18 17:58:25 2ZjCCQ2T0
>>66
おかしなレスが飛び交ってるから、突っついてるの。
例えばさ、『ヒープを 64bit にする』って表現として意味不明じゃん。
普通はそういう風には言わない。64bit ってデータ長かアドレス空間の
大きさを指すのが普通じゃん。LP64 にしても使用メモリは倍になんか
ならないし、ちゃんと分かって書いてるのか心配だったのね。
まあこの板で似非技術用語を指摘しても意味ないかもしらんけど。
69:名称未設定
07/11/18 18:02:14 ndzXdl+y0
正直なところ、Intelの64bit実装はAMD64の劣化版なので、フル64bitにしなかったのは
懸命な措置だと思うよ。
>>56
>あと x86 に限った話だけど、64bit にするとレジスタ数が一気に増えるから
>当然速度が速くなる
これは嘘。確かにレジスタの数は多いが、現在のIntel版64bit実装だと、5個
ぐらいの汎用レジスタを同時使用するとストールするよ。AMDなら全然問題なし。
70:名称未設定
07/11/18 18:09:40 zIyuf+DC0
お前ら今ごろ何言い合ってるんだよ。圧倒的に64bitの方が高速だろ。
もっともLeopardは32bit OSだから恩恵も無いがな。ｗ
URLﾘﾝｸ(jndb.pc.mycom.co.jp)
71:名称未設定
07/11/18 18:17:38 2ZjCCQ2T0
>>69
>現在のIntel版64bit実装だと、5個
>ぐらいの汎用レジスタを同時使用するとストールするよ。
済まん。それは知らなかった。
gcc で 64bit でコンパイルすると普通に引数を
レジスタに積んでるけど、そんな罠があるのか。
Xeon でもそうなの?
72:名称未設定
07/11/18 18:17:52 Z6CfSPdaO
64ビットOSという表現をやめて64ビット級OSという表現を使うべき。
73:名称未設定
07/11/18 18:28:52 TP8f/+qM0
>>68
Xcodeを32bitモードと64bitモードで動かしてRSIZE比べると約倍になってるよ。
オーバーヘッドの分速度もやや遅くなる。
>>69
増えるのは「見かけの」レジスタ数だからね。ハードウエア上のレジスタ数は変わらない。
64bitモードになると死んでたレジスタに火が入るわけではない。
「見かけの」レジスタ数が増える事によって生成コードが改善される分有利になる。
74:名称未設定
07/11/18 18:30:06 fjyNnsFv0
2コアだと、64bit級のCPUが二つで、128bit級だな(`･ω･´)
75:名称未設定
07/11/18 18:30:06 PxWpUj+40
そもそもレジスタ数が云々、使用メモリサイズが云々なんて話は
カーネルが32bitか64bitかとは関係ない話。動かすアプリケーション次第。
汎用レジスタが増えると言ってもソフトウェアから見えるレジスタが増えてるだけだから
実際に効くかはフロントエンドのリネームのロジック次第で何とも言えん
76:名称未設定
07/11/18 18:33:30 PxWpUj+40
まあ遅くなる要素はコンテクストスイッチのオーバーヘッドぐらいで
速くなる可能性の方が高いけど。
77:名称未設定
07/11/18 18:46:01 ndzXdl+y0
>>71
Xeonでも同じ。
MSがAMD64実装のほうをWindowsでサポートすると発表したためにIntelがあわてて
自社の32bitCPUにAMD64の64bit命令を「解釈できる」機構を無理やり導入したのが
混乱の発端。
だもんで、例のサプライズはAMD搭載機の発表だと思ってたんだよね。Core2で
64bitOSなんて悪い冗談みたいだから。
78:名称未設定
07/11/18 18:50:48 PxWpUj+40
現状でAMDの採用とかあり得ないでしょ。
いくらCore MAの64bitモードに不備があるとはいえ、絶対的に遅いものを採用する意味は無い。
79:名称未設定
07/11/18 18:54:33 HTIbu+LF0
>>49
メモリを512MB積むため、メモリー拡張パックを買い占めろ。
インストールメディアは64DDな。
80:名称未設定
07/11/18 19:03:20 2ZjCCQ2T0
>>73
>RSIZE比べると約倍になってるよ。
Xcode じゃないけど、手元のコードではそうはならなかったよ。
ヒープのデータが全て long か pointer なプログラムなんて
そう無いと思うけど。
>>77
さんきゅ。今度 Xeon マシンを借りられるので、実際に試してみます。
確かに悪い冗談というか悪夢だね。
81:名称未設定
07/11/18 20:38:44 4uoHkZ4y0
>>78
64bitモードの不備は来年発表のNehalemで解消されるらしい。
82:名称未設定
07/11/18 21:18:39 Mcgcg9Gf0
>>80
じゃなくて、ヒープなどは管理そのものにポインタ使ってるでしょ
小さいサイズでアロケートの回数が多いアプリは、もろに64bitで重くなるよ？
83:名称未設定
07/11/18 21:31:34 2ZjCCQ2T0
>>82
>じゃなくて
何じゃないんだよ。省略せずにきちんと書くようにしなよ。
俺は重くならないなんて書いてないよ。
1. 他人のレスをちゃんと読む
2. 投稿する前に自分のレスを読み直す
これだけで他人との会話がだいぶ変わってくると思うぞ。
84:名称未設定
07/11/18 21:36:35 48JPa0p10
2chで何を言ってるんだ？
85:名称未設定
07/11/18 22:38:40 Mcgcg9Gf0
>>83
言葉足らずでｽﾏﾝね
>>ヒープのデータが全て long か pointer なプログラムなんて
>>そう無いと思うけど。
に対する、「じゃなくて」って意味。
現実にはヒープのデータだけではなく、
アロケート回数に標準ポインタサイズがかなり影響するという話。
86:名称未設定
07/11/18 23:00:23 2ZjCCQ2T0
>>85
それを俺にレスして何が言いたいのか分からないよ。
1. アロケータ内の pointer 変数とプログラム用の pointer 変数を区別しようが
しまいが、元レス (>>80) の趣旨には影響しない（int も char も絶対使わねえよ
というのなら話は違うけど）
2. Resident の SIZE にはアロケータ用の pointer も含まれるから、元々ヒープの
データだけを見ているわけではない（RSIZE って break した領域のサイズだよね?）
3. それがそんなに気になるなら Hoard とか別のアロケータを試してみたら
良いんじゃないかな（メモリの利用効率について比較したペーパーがどっかに
あったと思う）
87:名称未設定
07/11/18 23:14:36 Mcgcg9Gf0
>>86
>>85だけど、俺は>>73とは別人だよ
>1. アロケータ内…
それは当たり前の話。
>2. Resident…
これも当たり前の話。
>>80の、
>Xcode じゃないけど、手元のコードではそうはならなかったよ。
という、ひとつのサンプルは、
>>73の
>RSIZE比べると約倍になってるよ。
という別のサンプルを否定できない。
なのに、
>ヒープのデータが全て long か pointer なプログラムなんて
>そう無いと思うけど。
「そう無い」って結論は強引かな。
>3. それがそんなに気になるなら Hoard とか…
これはまた別の話だな。
俺自身は、フル64bit化って、結構メモリの経済感覚が変わるって言いたかっただけだけど…
88:名称未設定
07/11/18 23:19:15 ndzXdl+y0
>>78
残念ながらピュアな64bitコード（汎用レジスタ使いまくり）の土俵では、桁違い
とまではいわないがAMDの圧勝になる。AMDは64bitモードで処理効率が上昇することは
あっても低下する要因がゼロだから。Intelが1だとするとAMDが1.5～2.5ぐらい
じゃないかな。
逆に32bit環境だとIntelが強くなる。だから32bitOSのままにとどめたLeopardは
英断だと思うんだよ。
89:名称未設定
07/11/18 23:43:48 AZLk7ltv0
あむむし
90:名称未設定
07/11/18 23:50:19 f85CVL+w0
>>88
書いてて恥ずかしくないか？
>Loepardは、64ビットのパワーを発揮する万能オペレーティングシステム。
URLﾘﾝｸ(www.apple.com)
91:名称未設定
07/11/19 00:55:38 3VfMUqmK0
>>88
ただどっかで完全ピュア64bitOSになる時がこなきゃ
その時はMac OS X10.×じゃなくMac OS11になると思うけど
92:名称未設定
07/11/19 01:31:58 eFDg/yWT0
>>91
いずれは確実にそうなるだろうけど、
将来OSXのインストール対象リストから32bitマシンが完全に消えるまで、
なんだかんだでゆっくりやりそうな悪寒
これまでも徐々に段階的に、って進め方だったし
今回の拡張で当面の状況は凌げそうな感じでもあるし
そのときにはまだOSX10.xを名乗ってると思う
93:名称未設定
07/11/19 01:48:03 CzeF477W0
そういえば URLﾘﾝｸ(www.apple.com) に書いてあることが
ちょっと気になった。
>仮想メモリで最大16エクサバイト
単に64ビットだからということか。Mac OS Xで実際にアドレス可能なユーザ空間は
もっと小さいのだが。
>物理メモリで4テラバイトの64ビットアドレス指定
4テラって何? 42ビットだねえ。ということは単にG5でアドレス可能な範囲のことを書いてる?
今使われてるCore 2って確か36ビットじゃなかったっけ?
94:名称未設定
07/11/19 02:10:28 gsvQhkNs0
>>88
適当なことを言わないように。
つーかDPレベルだとIntelが圧勝しないベンチを見つける方が難しい
64bit環境での比較 (Harpertown vs Barcelona)
URLﾘﾝｸ(techreport.com)
URLﾘﾝｸ(techreport.com)
URLﾘﾝｸ(techreport.com)
URLﾘﾝｸ(techreport.com)
URLﾘﾝｸ(techreport.com)
95:名称未設定
07/11/19 02:19:26 gsvQhkNs0
というかピュアな64bitコードって何だよw
64bitアプリケーションに含まれる(dynamic linkされる物を含む)コードは
LinuxやMacOSのように32bitと64bitが混在する(できる)環境だろうが
64bit Windowsのように64bit only(除ブリッジ)の環境だろうが
全部64bitのコードだから。
96:名称未設定
07/11/19 03:01:37 yC6wO/it0
>>95
＞LinuxやMacOSのように32bitと64bitが混在する(できる)環境だろうが
URLﾘﾝｸ(arstechnica.com)
>There is no "mixed mode" in Leopard. Every process is either 32-bit or 64-bit.
>Since a 64-bit process cannot load 32-bit plug-ins (and vice versa)
>there will be a significant transition period for applications that rely heavily on plug-ins.
>(I don't envy Adobe's developers... and it gets even worse for them, as you'll soon see.)
97:名称未設定
07/11/19 03:21:44 gsvQhkNs0
???
そこに書いてある通りだけど。
つーかコードレベルでは混在してないって95に書いたのを読んでないのか?
Tigerも64bit APIがLeopardより少ないだけで同じ。
98:名称未設定
07/11/19 03:32:47 gsvQhkNs0
そもそもこんな当たり前のような話を説明しなければならんのは
68kからPPCの過渡期に68kのToolbox APIがネイティブのPPCバイナリから
MixedModeManagerを介して呼び出されていたという過去があるからかね?
だから当時はシステムの一部に68kコードが残ってPPCの最適化が...という話になった訳だが。
現在の32bit環境と64bit環境の混在は、MixedModeManagerのような仕組みを使った物ではなく
完全な「並立」。だから64bitでアプリケーションを作った時点で
現行のOSXに32bitのシステムが存在する事によるオーバーヘッドを気にする必要はない。
99:名称未設定
07/11/19 04:34:01 CzeF477W0
強いて言えば、IPCでオーバーヘッドがある場合はあるかも。
100:名称未設定
07/11/19 09:32:30 yC6wO/it0
>>97
「64bitアプリケーションに含まれる(dynamic linkされる物を含む)コードは全部64bitのコードだから。」
はどうでもよくて、
「LinuxやMacOSのように32bitと64bitが混在する(できる)環境」
「64bit Windowsのように64bit only(除ブリッジ)の環境」
の意味がよく分からんかった。
アプリの話をふりつつここはカーネルの話をしてないかい？
そんだけ。
101:名称未設定
07/11/19 09:48:54 NCC56ZWi0
苦しくなると話をそらすのはドザチョンズによくあること
102:名称未設定
07/11/19 09:58:50 zzJdaFGe0
>>100
いや、どっちもアプリケーション(提供されているAPIレベル)の話だけど。
103:名称未設定
07/11/19 10:05:44 yC6wO/it0
>>102
もしかして「(除ブリッジ)」ってWindows on Windows64を除くって意味？
URLﾘﾝｸ(ja.wikipedia.org)
104:名称未設定
07/11/19 10:18:06 li5anQAb0
そんなもん、Windowsno設計が悪いだけの話じゃない
アホだ
105:名称未設定
07/11/19 11:17:10 VUl/Ctdi0
どう考えてもOSが32bitで、アプリが32bitと64bit混在のMac OS Xの方が過渡期の状態だろ。
Win64のWOW64は完全64bit環境で32bitアプリを動作させるエミュレータなんだから。
106:名称未設定
07/11/19 12:09:54 ufCkEcHm0
64bitと32bitの違いって、シングルCPUとマルチCPUの違いと実質的に
つながる所があると感じるけど、このあたり詳しい人いますかね。
つまり32bit-CPUを2セット「並列処理」できる状態と64bit-CPUひとつと
同じ機能ではないのかと。時代が次第にマルチコアCPUの方向にシフトしてきている今、
スレッド処理をいかに無理なくスムーズに処理できるかに重点が移ってきてると思う。
107:名称未設定
07/11/19 12:11:38 VUl/Ctdi0
>>106
完全に勘違いというより抜本的な理解不足。小学校からやり直せ。
108:名称未設定
07/11/19 12:26:14 ufCkEcHm0
>>107
32bitとか64bitとかの本質的な違いを説明したサイトがうまく見つけられんのよ。
どこもかしこも「64bitであるか32bitであるか」の言い合いばかりでね。
CPUの処理の幅が64bitか32bitかの違いであるのなら、マルチCPUでこれらの
違いは一挙に意味を失うのではないのかと感じる。
それともメモリ空間のアドレスの大きさを言ってるのかしらね。
109:名称未設定
07/11/19 12:37:35 li5anQAb0
なにいっってやがるんだよw
64bitになったら、64bitマンセーしてるよwwwwwwwwwwwwwwwwwwwwww
110:名称未設定
07/11/19 12:39:14 hjfNPILj0
こうなると、何を持って「xxxビットのOS」と言うのか...。
そうゆうのはだんだん意味を持たなくなるのかな。
111:名称未設定
07/11/19 12:52:34 ufCkEcHm0
やっとそれっぽい記事を見つけた
これのことかねぇ
URLﾘﾝｸ(journal.mycom.co.jp)
どうやらCPUの一括処理の単位およびメモリ空間のアドレス空間の大きさ
双方を指し示しているみたいですね。
112:名称未設定
07/11/19 13:58:52 zzJdaFGe0
>>103
そうです。
113:名称未設定
07/11/19 14:07:41 DxnjZeNd0
まあそういう意味で64bitへの移行手段はLeopardで着々と進んでる。
ライブラリは全て64bit対応だし、
Input MethodもアプリがどちらでもOKな様に独立プロセスになった。
kernel driverも32/64bitのUniversalに対応してる。
QuickTimeのCodecは、32bit QT serverで64bitアプリに対応。
問題は3rd partyの対応だが、
Printer driverのPDEもOSバンドル品は64bitになってるのが多い。
物理的に8G以上積めるのは現状MacProだけだから、
メリットが出てくればマイナーアップデートで64bit kernelのせる鴨ね。
114:名称未設定
07/11/19 15:06:07 r8sanitS0
おまいらそういう知識どこから仕入れるの？
エロサイト？
115:名称未設定
07/11/19 16:08:08 Qri/s4Wv0
>>114
まぁ大半の人はエロサイトだろうな
116:名称未設定
07/11/19 16:32:17 uz5lWwIe0
32bitよりも64bitのほうがモザイクが薄くなるんだ。
117:名称未設定
07/11/19 16:40:45 DxnjZeNd0
WWDC
118:名称未設定
07/11/19 16:47:56 PeaucL070
Leopardは64bit APIを備えたOS。
以上。
119:名称未設定
07/11/19 17:02:45 ufCkEcHm0
実際、64bitでの一括演算というのは1.8x10^19程度を上限とする
整数の四則演算が一挙にできるか、というレベルの話なんですかねぇ。
いろいろ巡ってみても、まだよくわからん。
120:名称未設定
07/11/19 17:16:22 zzJdaFGe0
演算器の幅に関して言えば、32bitでいうlong long型を使う必要があるような場面で
少ないクロックサイクルで終えられるという程度の利点。
そもそもそんな場面はほとんど無いし、SSE2があれば32bitCPUでもできるし。
AltiVecではできないけど。
そもそもこれに関してはOSの64bit化とはほとんど関係ない。
121:名称未設定
07/11/19 17:23:58 ufCkEcHm0
>>120
そうでしたか、ですとOSの64bit化というのは具体的にはメモリ空間が
64bitで管理できるかどうか、あたりの話になるんでしょうかね
122:名称未設定
07/11/19 17:29:36 In4q82oq0
URLﾘﾝｸ(developer.apple.com)
123:名称未設定
07/11/19 21:24:02 DxnjZeNd0
URLﾘﾝｸ(developer.apple.com)
Myth: The kernel needs to be 64-bit in order to be fully optimized for 64-bit processors.
Fact: The kernel does not generally need to directly address more than 4 GB of RAM at once.
The kernel is able to make larger amounts of memory available to applications by using long
long data types to keep track of mappings internally.
124:名称未設定
07/11/19 21:27:22 gCnjvcXf0
なんか微妙な言い方だけど、
要するに64bitじゃないことの言い訳かな？
125:名称未設定
07/11/19 21:28:42 Gom9RQoZ0
なんかもの悲しいスレだな。
126:名称未設定
07/11/19 23:01:37 NZGjvECs0
>>123
これはあと数年は 64bit 化しないよという宣言なのかな
ちゃんと Myth #5 で Intel では 64bit 化した方が速くなる事を
認めているのに何で Myth #2 で余計な事を書いてしまうんだろうか
分かってて手を抜いたんだから、言い訳する必要なんか無いのに
127:名称未設定
07/11/19 23:15:29 uz5lWwIe0
でも、Tigerではカーネル部分が64bit対応だって言っていたよね。
だからTigerでは64bitのアドレス空間がサポートされたと聞いたが。
そしてLeopardではCocoaなどが64bit対応になったって話なのだろう。
128:名称未設定
07/11/19 23:33:50 gsvQhkNs0
>>126
いやだからアプリケーションレベルで64bit化してればいいわけで
カーネル自体が64bitプロセスになっても個々のアプリケーションのパフォーマンスは変わらんよ
いい加減理解しないかね。
129:名称未設定
07/11/19 23:36:52 NZGjvECs0
>>127
仮想メモリが 64bit アドレス空間を扱える様になるのと
カーネルが 64bit で動く様になるのとは、天と地ほどの
差があるよ。今の Mac OS X は前者のみ。現代において
後者が出来ないのは純粋技術的にはかなりダサイと言って
差し支えない。まあサーバ用途で使う OS じゃないから
実質的な問題は無いと判断したのでしょうね。1,2 割の
性能ロスくらい構わない、と。
130:名称未設定
07/11/19 23:41:02 NZGjvECs0
>>128
>カーネル自体が64bitプロセスになっても個々のアプリケーションの
>パフォーマンスは変わらんよ
理屈で考えたら分かると思うけど、カーネルのレスポンスが
速くなれば当然アプリも速くなるよ。sys が全く発生しない
ページングも絶対しない、スケジューラの影響も受けない様な
アプリなら君の言う通りかもしれないけどね。
131:名称未設定
07/11/19 23:59:30 gsvQhkNs0
>>130
それは99の言うIPCとかコンテクストスイッチのようなプロセス間の相互干渉が
クリティカルに影響してるようなケースの場合。さもなきゃ体感は不可能でしょう。
それも、カーネル自体が64bitで動いてるかどうかよりは、実装に依存する話。
あまり変な幻想を抱いてると、本当に64bitカーネルになった時に落胆するよ。
132:名称未設定
07/11/20 00:07:21 eG/Kxnw50
>>131
俺は↓これが間違いだって論理的に理解して貰えれば
何でも良いよ。
>カーネル自体が64bitプロセスになっても個々のアプリケーションの
>パフォーマンスは変わらんよ
それに 64bit で動いているかどうかも実装の問題だよね。
普段は純然たる 64bit Kernel な OS を使ってるので、
ページスキャナが long long でメモリを舐めていると
考えると悲しくなるよ。
133:名称未設定
07/11/20 00:11:59 eG/Kxnw50
つうか気付いてなかったけど、俺ずっと age てたね。スマソ。
134:名称未設定
07/11/20 00:12:07 rYXJ+HDw0
ところで
x64で64/32の混在だと、CPUはMixed Modeで動作することになるんだよね？
それによる速度低下はどの程度？
135:名称未設定
07/11/20 00:27:50 eG/Kxnw50
>>131
>それは99の言うIPCとかコンテクストスイッチのようなプロセス間の相互干渉が
>クリティカルに影響してるようなケースの場合。
一応書いておくけど、プロセス間やスレッド間でリソースの取り合いが
発生しているかはこの場合全く関係無いよ。何でそう思ったのか知らんけど。
そもそも Myth #5 で書かれている、関数呼び出しの際に引数がレジスタに
積まれて渡されるから速くなるという所から俺の話は始まっているんだけど、
カーネル内の関数コールが速くなれば、カーネルサービスに依存している
アプリの処理性能も結果的に上がるという話だからね。
Do you understand?
136:名称未設定
07/11/20 00:43:05 ymuEzXkQ0
>>135
いや...だから何でシステムコールがアプリケーションの速度を律速するようなケースが前提になってるの?
137:名称未設定
07/11/20 00:49:10 OSW4g0lD0
forkとかmallocで飯を食ってる人だから
138:名称未設定
07/11/20 00:51:10 eG/Kxnw50
>>136
律速するかどうかは関係無い。全体のフローの中で時間を短縮
可能な箇所があれば、全体に掛かる時間も短くなるというだけ。
例えば家から会社までの道のりで考えると、家から駅まではバス、
駅から会社の最寄り駅までは電車、そこから事務所までは徒歩で
行くとするよね。今まで各駅停車に乗っていたのが、新しく
急行電車が並走する様になりました。急行に乗ったら通勤時間が
短くなりました。
この電車が I/O だったりメモリ要求だったりのカーネルサービスね。
各駅停車は 32bit Kernel, 急行は 64bit Kernel だと考えてみ。
勿論、通勤時間はアプリの処理時間に相当するよ。
139:名称未設定
07/11/20 00:53:57 2o0+XUTp0
まあ本当にどうでもいい事だと考えているのなら今後appleが64bit kernelを採用する事は全く無いだろうね。
俺は採用すると思うけど。
140:名称未設定
07/11/20 01:03:38 ymuEzXkQ0
>>138
自分で1割2割ロスしてると言ってるでしょ。
そんだけパフォーマンスを上げるには、明らかにシステムコールが処理時間の相当量を占めてなきゃ不可能。
超多めに見積もってカーネルの64bit化でカーネルサービスに費やす時間が半分になるとしても
処理時間に占める割合は1割ロスで1/8、2割だと1/3だよ。
どう考えても律速してるし、現実にそんなケースは無いよ。
141:名称未設定
07/11/20 01:07:20 ymuEzXkQ0
ごめん1/8、1/3じゃなくて1/9、1/4だった
142:名称未設定
07/11/20 01:13:44 eG/Kxnw50
>>140
割とどうでも良いところに噛み付いたね。
>どう考えても律速してるし
俺は律速していないと言ってるんじゃなくて、
「律速するかどうかは関係無い」って書いたと
思ったけど。
あと、1,2 割は sys の 1,2 割と読んでくれ。
これはスマソ。sys の割合は俺の経験上は
10-50% くらいが一般的かな。10% 以下なら
かなり優秀なアプリだと思う。
で、結論としては処理速度は上がるで良いかな?
143:名称未設定
07/11/20 01:26:10 ymuEzXkQ0
>>142
50%が一般的てどんな状況だよw
144:名称未設定
07/11/20 01:31:10 mCYTBfd80
まあ Vista あたりが 64bit 化にあたって糞みたいな実装をしてきたのに対し
アプルは随分クールで現実的な解決策を持ってきたと思うよ。
>>139 とか >>138 は >>140 の書いてあることをちゃんと理解してから
反論してくれよな。ymuEzXkQ0 は、
>カーネルの64bit化でカーネルサービスに費やす時間が半分になるとしても
という相当な無理がある仮定をしても、結果的にプロセス全体への影響は
少ないということを言っている。eG/Kxnw50 はカーネルの 64bit 化で
OSサービスが現実的にどの程度早くなると見込んでいるのだろう？
145:名称未設定
07/11/20 01:34:59 mCYTBfd80
>>143
やぱり fork と malloc で飯を食ってる人なのかもw
146:名称未設定
07/11/20 01:37:02 cszpg1Al0
処理速度を気にしない処理ほど改善が大きくなりそう。
ベンチマークで比較されるような処理は普通%sysが非常に小さくなるから
一般ユーザが実際に恩恵を受けるような場合はあまりないだろうね。
それをふまえてAppleはあんな風に書いたんでしょう。
147:名称未設定
07/11/20 01:38:25 eG/Kxnw50
>>143
もう、どうでも良いところにしか突っ込めないのね…
I/O とか Network に依存するアプリは結構 sys 出るよ。
細かいパケットを送受信したりする作りだとね。
>>144
君がスレの流れを読んでくれ。64bit 化しただけで
倍速くなるくらいなら何年も前に皆そうしてるよ…
どれだけ速くなるかではなく、確実に速くなるという
話をしているんだよ。
148:名称未設定
07/11/20 01:40:55 mCYTBfd80
>>146
それにしても「一般的なアプリ」で見込まれる%sysも大きいし、
eG/Kxnw50 がカーネルの64bit化で見込んでいる速度向上率について興味ある。
149:名称未設定
07/11/20 01:41:19 eG/Kxnw50
話を元に戻すけど、俺の話は↓これが間違っているという事。
>カーネル自体が64bitプロセスになっても個々のアプリケーションの
>パフォーマンスは変わらんよ
それだけの事を理解させるのにこんなに説明が必要とは思わなかったよ…
150:名称未設定
07/11/20 01:46:27 mCYTBfd80
>>147
>I/O とか Network に依存するアプリは結構 sys 出るよ。
何で%sysが大きくなるか考えてくれないと…
これらが 64bit化でどの程度高速化できると思う？
これと引き換えに失うものを考えたら、アプルの実装はかなり理に適っている
と思うけどね。
151:名称未設定
07/11/20 01:50:36 eG/Kxnw50
>>150
>>149 を読んでくれ
1. Apple の実装が間違ってるとは言っていない
2. どの程度高速化するかはまた別の話
2 については君は不満なんだろうが、>>149 に決着が付いたら
そっちも相手してあげるよ。ホントはもう寝たいんだけどね。
152:名称未設定
07/11/20 01:53:17 mCYTBfd80
>>149
>>話を元に戻すけど、俺の話は↓これが間違っているという事。
いや、だから ymuEzXkQ0 が言いたいのは、カーネルの 64bit 化は、
アプリの処理速度への現実的な影響は殆どないということでしょ。
（オレはymuEzXkQ0じゃないから推測だが）
現実的に見て間違っているとは言いがたいなぁ。
アプリの%sysと、64bit カーネルの速度向上（ホントにあるの？）
をどの程度見込んでいるかによるけどね。
殆どあり得ない数字を前提にするなら、それはまた別の話。
153:名称未設定
07/11/20 01:54:16 ymuEzXkQ0
>>151
いくら言ってもコーナーケースの話をされて終わるということは分かったので
もう寝てくださって結構ですw
154:名称未設定
07/11/20 01:59:22 OSW4g0lD0
I/OとかNetworkなんてそもそもCPU時間を使わん処理は
%sysが改善したところで処理時間に差はでない
155:名称未設定
07/11/20 02:05:47 eG/Kxnw50
>>152
俺は fork とか malloc で飯食ってるから、君の現実感とは違うんだろうな。
1 sec でも速くなれば、それは処理速度が向上しているという事だよ。
実際 32bit の VM で 64bit のアドレス空間を捌くオーバーヘッドはかなり
大きいと思うよ。まあ 1 割速くなる程度じゃ現実的じゃないと言われるかも
しらんけどね。
156:名称未設定
07/11/20 02:08:11 eG/Kxnw50
>>153
カーネル内関数コールがコーナーケースな人には
カーネルの話は無理じゃないかな。
157:名称未設定
07/11/20 02:09:17 OSW4g0lD0
やべえ適当に言ったら当たった
そういう玄人さんはここに来て素人に講釈垂れるだけ無駄だと思うよ
感覚からして合わないだろうし
158:名称未設定
07/11/20 02:10:53 eG/Kxnw50
>>154
>NetworkなんてそもそもCPU時間を使わん処理は
Ethernet から Socket Buffer まで、ずっと CPU 処理ですよ
良い加減まんどくさくなってきた...
159:名称未設定
07/11/20 07:29:28 6LXH3Xpx0
>>144
Vistaの64bit実装のどの辺が糞なんだろう？
Solaris8やLeopardあたりと比べるとまだましな部類に入ると思うんだが。
160:名称未設定
07/11/20 07:37:15 vgrsNHYQ0
それで、カーネルが64bitになれば、
iPhotoとかのアプリが1割速くなったりするのかな？
そこが重要だとおもうんだけど。
161:名称未設定
07/11/20 07:38:30 l5H4qjyT0
>>159
既に感情論の領域に入っていますので、まともな反論は難しいものと思われます。ｗ
162:名称未設定
07/11/20 08:21:13 6LXH3Xpx0
>>161
なるほど。要はなんでもいいからLeopard以外は糞と言いたかっただけなのね。了解です。
163:名称未設定
07/11/20 08:27:15 OdT0j6ekO
APIが64bitってどうゆう意味ですか？
164:名称未設定
07/11/20 09:11:33 eG/Kxnw50
>>159
>Solaris8
Sol 8 って何か問題あったのけ?
だいぶ昔だから、どんなだったかもう忘れちゃったけど。
165:名称未設定
07/11/20 10:06:39 /pt+6y3e0
カーネルの内部関数あたりの話そのものを述べると少しかじったくらいの
人では少し追いつけない話になりますわね…。
なかなか64bitというものを具体的に解説した書物がなさそうな状態で、
なんとなく64bitはすごいというイメージが一人歩きしてるのではないかと
自分的には思うけれどどうなんだろう。
倍以上の性能になるといえばそういうわけでもなさそうですよね。
166:名称未設定
07/11/20 11:55:48 J+zz8lwJ0
>>164
正確に言うとSol7からだな。Sol7は2000年問題の対応時期と重なった関係で特に企業でスキップしたとこが多いから8で
問題が顕在化したところが多いんじゃないだろうか。
OBPアップデート、/proc問題、Largefile問題etc...導入規模が大きな所ほど影響が大きかったような気がする。特に
ドライバの揃わなっぷりはx64Windowsの比じゃなかった。
167:名称未設定
07/11/20 12:10:44 bpcPpSPZ0
そもそもｘ64で32ビットカーネルで64ビットアプリって動くの？
64Bitのロングモード使う場合は64Bitカーネルが必要では？
PowerPCは知らんけど
168:名称未設定
07/11/20 12:29:47 xK/rJZ3Z0
話をぶったぎってすまんけど、自分で Darwin のソースをとってきて、
64bit モードでコンパイルしててもとのカーネルと置き換えてウハウハ、とか
できるの？
169:名称未設定
07/11/20 12:34:06 2bCls0W80
URLﾘﾝｸ(journal.mycom.co.jp)
170:名称未設定
07/11/20 12:52:11 DVkEcb000
URLﾘﾝｸ(journal.mycom.co.jp)
どうせならこの方がいいだろう。
171:名称未設定
07/11/20 16:29:56 ud5nBSO60
Machカーネルも32bitと64bitの両方のモードで動作するってことだろ。
あと、32bitのWindows95でも16bitアプリが動作したから。って言ってるけど、
それって今回の場合と違うだろ？ 32bitWinで64bitアプリが動作するか？
16bitWinで32bitアプリが動作したのか？
172:名称未設定
07/11/20 16:38:49 l5H4qjyT0
>>167
動く。
そういえば、Leopardは完全64bitだが、32bitドライバも問題なくシームレスに動作が保証されて
いるから、下位互換性に関しても全く問題無いなんて主張している奴もいたな。全てが空しい。ｗ
173:名称未設定
07/11/20 16:41:30 l5H4qjyT0
>>171
違うだろ、UniversalBinaryの仕組みで、32bitと64bit両方のアプリが環境に応じて自動で
選択起動されるってこと。
174:名称未設定
07/11/20 16:47:35 /pt+6y3e0
要するに64bitのメモリアドレスをネイティブで取り扱えるかどうかという話？
175:名称未設定
07/11/20 16:56:48 wFbxk/Fu0
ロングモードの場合、割り込みハンドラとかは64 bitモードで動かす必要があったはず。
まあそれ以外のMachカーネルはほとんど互換モードで動いてそうだけど。
176:名称未設定
07/11/20 17:04:05 ud5nBSO60
>173
環境に応じてそれぞれのモードで起動する、
だから違うという話に何故なるんだ。
177:名称未設定
07/11/20 17:37:13 rYXJ+HDw0
>>167
俺もそこが分からん。
x64の3つの動作モードを知る (1/2)
URLﾘﾝｸ(www.itmedia.co.jp)
32bitカーネル＋64bitAPIのLeoの仕組みは、
上記のTable2のどれにも該当していないように思える。
178:名称未設定
07/11/20 17:53:02 ud5nBSO60
>177
>32bitカーネル＋64bitAPIのLeoの仕組みは、
そもそもこれから違うのだと考えつかないのかよ。
179:名称未設定
07/11/20 18:01:56 ud5nBSO60
>172
動かないよ。
なんで間違ったこと断言できるのか不思議なんだが。
x64の互換モードは、64bitカーネルと互換モードで32bitが動く。
32bitカーネルから互換モードで64bitは出来ない。
180:名称未設定
07/11/20 18:45:46 xK/rJZ3Z0
URLﾘﾝｸ(episteme.arstechnica.com)
URLﾘﾝｸ(episteme.arstechnica.com)
181:名称未設定
07/11/20 18:50:00 xK/rJZ3Z0
ふたつめで LordHunter さんが明快に答えているようだ。
彼の情報の出所がわからんけど。Oct 20 って発売前だから、NDA やぶってるんだろうね。まあいまや Darwin のソース公開されてるので。
182:名称未設定
07/11/20 18:50:46 ud5nBSO60
>>1のチェスしか64bit化されてないという指摘だけど、以下の
Apache 2、MySQL 5、Postfix、Podcast Producer、QuickTime Streaming Server、Java VM on Intel
これらは、サーバー版では64bit版が採用されてる。サーバー版も基盤は同じだよ。
183:名称未設定
07/11/20 19:19:19 ud5nBSO60
同時に処理なんて無理だろという人も結構いるみたいだから、
参考になる記事を探してみたけど、こういう例があるよ。
着実に成長を重ねる64ビットLinuxとBSD
URLﾘﾝｸ(opentechpress.jp)
>AMD64のワークステーションやサーバシステムを販売するようになった。
>だがおかしなことに、その大半は32ビットOSをデフォルトでインストール
>して出荷している。AMD64アーキテクチャは64ビットと32ビットの両方の
>ソフトウェアを快適に（しかも同時に）処理できるにもかかわらずだ。
この記事の続きは、主にAMD64（まあx64)とUNIXの記事だけど、
OSXの対応を考える上でも参考になるかな。
184:名称未設定
07/11/20 19:48:47 ud5nBSO60
因みにTigerの時の文書だけど、LinuxやBSDのカーネルと同じLP64モデルを採用してる。
URLﾘﾝｸ(developer.apple.com)
ドライバの問題をどう解決したのか（iokitがクッションになってる？）、
それは個人的にも興味あるけど、32bitカーネルでx64を利用して64bitアプリを
動かしてるという理屈がこのスレで成り立ってるのは驚いた。
185:名称未設定
07/11/20 20:04:04 Hd7AquSE0
>>182
サーバー版では64bit版が採用されているということは、
つまり、クライアント版では32bit版ということかね。
基盤は同じだというが、きっとアプリに互換性問題が発生して
カーネルを32bitで動かし、その為にそのほかのソフトも
32bitとして動かしているのだろうね。
チェスだけはうまく動いたのかな？
186:名称未設定
07/11/20 20:08:30 bekKr84S0
Chessに64bitバイナリを用意したのはサンプル的な意味合いが強いでしょ。
187:名称未設定
07/11/20 21:56:59 kRVXOBCK0
未だにCarbonで動いてる中核アプリが多いんだから少しずつ移植していくしか無いと思うけどね
チェスしか無いのはとりあえず組みやすい小さいアプリで実証しただけの事でしょ
188:名称未設定
07/11/20 22:24:16 wFbxk/Fu0
>>184
32 bitカーネルの定義の問題なんじゃねーの？
URLﾘﾝｸ(developer.apple.com)
この文章はLast updated: 2007-05-10だけど明らかにLeopardについて言及している。
んで、こうある。
Because 64-bit applications will be supported using a 32-bit kernel,
this 64-bit support will have minimal impact on most writers of device drivers or kernel extensions.
However, there are exceptions, as explained in “Device Driver Changes.”
もちろんAMD64のlongモード使うわけで、
割り込みハンドラは64 bitモードで実装しないといけないし
メモリ管理のページエントリだって64 bitに拡張しないといけない。
DMAだって物理アドレス4 GB以上の領域まで自由に使いたい。
これらについては64 bit “対応” が必要だ。
一方で、AMD64のlongモードの互換サブモードによって、Leopardでは
32 bit環境で動くmach_kernelが64 bit環境でも再利用できている。
ドライバも同じで、32 bit/64 bitの違いはI/O Kitが吸収してくれるので
作法に従って書いていれば、32 bit用のドライバでも64 bitの物理メモリと連携できる。
この状況を「32 bitカーネル」と書いて伝わると思っている奴もいれば(他ならぬAppleがそうだ)
「64 bitカーネル」と書かないと気がすまないという人間(例えば>>184)もいるというだけじゃなかろうか。
189:名称未設定
07/11/20 22:40:37 AD2bH6AL0
>>187
移植されていないのではなく、64bitのバイナリとしてビルドされたアプリをあえて
入れてないだけ、と考えるのが妥当では? フレームワークとかはほとんど64bitの
バイナリが付いてきてるんだから。
190:名称未設定
07/11/20 22:45:34 rYXJ+HDw0
>>180,188
なるほどー
凄い参考になった
191:名称未設定
07/11/21 00:00:21 3OGQGuVl0
なんか、よくわかんないけど、32bitってことですね。
192:名称未設定
07/11/21 00:03:35 S/oLCL9I0
mach_kernelより上位のｘ64ロングモードで動くカーネルがあるってことか・・・
193:名称未設定
07/11/21 00:26:06 Pw5o4wXU0
>>191
正確には、32bitカーネルと32/64bitライブラリのハイブリットOS。
32bitコードが完全に消えるには、CoreDuo機の切捨てが必要だし、あと10年
ぐらいは掛かるんじゃないかな。
194:名称未設定
07/11/21 01:01:49 YS3F0otU0
>>192
>mach_kernelより上位のｘ64ロングモードで動くカーネルがあるってことか・・・
上位の人などいないw
195:名称未設定
07/11/21 01:05:45 9mHKD2LV0
>>193
じゃあ10年はむねをはって32bit OSっていえばいいんだよな。
64bitだ！なんて恥ずかしい事をAppleはかかなきゃいい。
196:名称未設定
07/11/21 01:25:42 Vpfxmlg+0
>>195
しかし、MSもWindows95で16bitコードを多数含みながらも胸を張って
『うちは32bitOSです』と自慢していたから、別にどうでもいいのではないか。
197:名称未設定
07/11/21 01:33:04 YS3F0otU0
>>193
64bitなカーネル自体はもっと早く出てくるだろ、Appleが出す気があれば。
カーネル自体をハイブリッドにして32bit機をサポートするとかできるだろうし。
198:名称未設定
07/11/21 01:34:03 gCZ1ZI8V0
まあ、Microsoft / Apple がマーケティングのために "32bit" "64bit" とレッテルづけして売ってるのと別に、
実際にそれぞれのカーネルがどういう仕組みで動いているかを認識するのはいいことなんじゃないかな ...
実情は "32bit" "64bit" とひとことであらわせない点がいろいろあるわけだし。
199:名称未設定
07/11/21 02:02:24 Vpfxmlg+0
Leopardは32bitと64bitを自動識別して動くOS。
Vistaは64bitの中に32bit互換環境を作ったOS。
どちらも64bitOSと名乗っても別におかしいところは無いよね。
要は定義の仕方の違いであって、このぐらいの誤解は誤差の範囲内と
思ってもいいのでは。
200:名称未設定
07/11/21 04:07:19 S/oLCL9I0
>>194
mach_kernelのプロセスが32Bitだったら・・・
やっぱり上位の64Bitカーネルがいるような・・・
201:名称未設定
07/11/21 06:45:15 bdLN08l60
>>200
>>180-181を参照
単純な意味での32bitカーネルではなく、最低限必要な部分は64bit対応のための
工夫がなされている模様
202:名称未設定
07/11/21 09:27:24 WihqcEbJ0
これらの内容って既に Panther の時の実装で、Leopard になった今の時点で
誤解も含めこんなに揉めるのかがよくわからない。
64bit プロセスと 32bit ドライバの関連に関しては、
URLﾘﾝｸ(developer.apple.com)
が参考になると思う（2003年6月の記事だが）
簡単に言えば、32bit のドライバを 64bit プロセスでも使えるように
工夫がされているということ。
アップルは Panther の時点で過去の（32bit）ドライバーやフレームワークを
64bit のシステムにフィットさせるか方向性を示すとともに必要な修正を即し、
Tigher で 64bit プロセスを 32bit プロセスが共存する機構を実装し、
Lepard で 64bit Cocoa フレームワークなどを実際に実装し、
段階的に 64bit 環境が使えるように整備してきた。
>>165
単純に 64bit化＝高速化ではないですね。64bit 化はコストがかかるのを
忘れてはいけないでしょう。Intel の場合はここに命令の拡張があるから
話が厄介になるのでしょうけど。
>>166
>>183
個人的に、教条主義的に 64bit 化を進めない、アップルの開発方針に賛同します。
多くのコンシューマーユーザーでも 64bit 化のメリットを得られる上に
デメリットは最小限にとどめようとしているように感じます。
203:名称未設定
07/11/21 09:28:08 WihqcEbJ0
>>167
>>172
>>177
>>178
>>179
32bit カーネルの定義が必要ですね。
レガシーモードで動作させるような、64bit を考慮していない旧来の
32bit カーネルという意味では記事の通り「動かない」けれども、
Leopard （というか Panther 以降）を 32bit カーネルとするならば、
ちゃんと動くが正解。
>>185
>>182 が言っているのは、普通の Leopard と同じサーバー版では
64bit 版アプリが普通に動いて使われているということでしょ。
>>200
前出の LordHunter さんいわく、
As such, you must have some 64-bit code in the kernel. Apple made the
decision to provide a thin thunking layer. Essentially, the 64-bit code
immediately jumps in to the 32-bit mode. There's also some code to jump
into 64-bit mode to perform the instructions that must be done there, but
the majority of the kernel runs in 32-bit. This is fine.
と書いている。
204:名称未設定
07/11/21 09:39:01 WihqcEbJ0
URLﾘﾝｸ(developer.apple.com)
- Kernel and I/O Kit APIs
All supported BSD kernel interfaces (KPIs) and system calls should already be 64-bit clean in Mac OS X v10.4.
The I/O Kit is being extended somewhat to include support for 64-bit applications.
These changes are primarily in the form of additional methods in the IOMemoryDescriptor class.
205:名称未設定
07/11/21 10:38:05 BehfpLg70
このスレ見てたらバイクの「ナンシー」を思い出した。
URLﾘﾝｸ(homepage3.nifty.com)
コンピュータを使ってたら「ナンビット」が寄って来たりするんだろうかw
206:名称未設定
07/11/21 11:21:55 4aqgS6710
>>202
それって、ドライバに関しては詭弁もいいとこだよな。64bitプロセスでも使用できるように
変更された32bitドライバだけが正常に動作すると言う事であって、既存の32bitドライバが
修正なしでの動作を保証しているわけじゃないしね。だいいちカーネル内のIOKitドライバは
いまだに32bitだろ。
207:名称未設定
07/11/21 11:25:28 v8YFnSOI0
64bitっていうのは、メインメモリだけでなくIOなど外部にも64bitの
アドレスを持たせて操作するのですかね
208:名称未設定
07/11/21 11:41:31 WihqcEbJ0
>>206
32bit ドライバの扱いに関しては２つの側面がある。
64bit のメモリ空間を管理する OS 上での 32bit プロセスからの利用と、64bit プロセスからの利用。
32bit プロセスからの利用に関しては前出の資料を見てもわかる通り、
（64bit）物理アドレス空間と I/O アドレス空間をわけることで解決した。
これによって起きる問題も、アップルのガイドラインに従った（ガイドラインに
明記されている API のみを使った）ドライバであれば、この回避処理は自動的に
行われる。
実際、これが上手く移行できていなかったら、G5 上で 2GB を超えるマシンで
トラブル大発生だったはずなのだが、64bit 化によるドライバ関係でのトラブルは
ほとんど聞かない。
64bit プロセスからの利用に関しては、BSD kernel interface と system call が既に 64bit clean であり、実際に
>Apache 2、MySQL 5、Postfix、Podcast Producer、QuickTime Streaming >Server、Java VM on Intel
>これらは、サーバー版では64bit版が採用されてる。
ことで明白だと思うが。
209:名称未設定
07/11/21 11:47:48 gCZ1ZI8V0
あと Xcode もふつうに 64bit アプリですよ。
210:名称未設定
07/11/21 11:51:44 RRByoLOp0
MacBookProに搭載可能なメモリーはいくら
211:名称未設定
07/11/21 11:52:59 gCZ1ZI8V0
>>206
>64bitプロセスでも使用できるように変更された32bitドライバだけが正常に動作すると言う事であって、既存の32bitドライバが
>修正なしでの動作を保証しているわけじゃないしね。だいいちカーネル内のIOKitドライバはいまだに32bitだろ。
というか、その文書は 2003 年でパンサーのときだから、それ以前の 3rd party kext で未だにそのままってのはないでしょ。そんなものがあったら ppc でしか動かんし。
Apple はじゃんじゃん前のバージョンのソフトが動かないようにするので、ある程度の書き換えはしかたがないかと。
212:名称未設定
07/11/21 12:00:06 WihqcEbJ0
URLﾘﾝｸ(developer.apple.com)
- Device Driver Changes
The kernel (including the I/O Kit) remains a 32-bit environment in Mac OS X. Most device drivers (those written using I/O Kit families) work unchanged
when used in conjunction with 64-bit processes.
213:名称未設定
07/11/21 12:18:15 ODjP/2fn0
>>212
32bitOSで32bitドライバがそのまま動いたからなんだって言うんだよ。それにその下も引用すべきじゃ
ないの？
On Intel-based Macintosh computers with 64-bit Intel processors,device drivers that support direct
memory access (DMA)must be updated to use the IODMACommand class beginning with Mac OS X
v10.4.7.
214:名称未設定
07/11/21 12:29:58 WihqcEbJ0
>>213
>32bitOSで32bitドライバがそのまま動いたからなんだって言うんだよ。
Most device drivers (those written using I/O Kit families) work unchanged
when used in conjunction with 64-bit processes.
わかる？
>それにその下も引用すべきじゃないの？
それが何か？
215:名称未設定
07/11/21 13:12:23 WihqcEbJ0
>>159
>>195
>>196
>>199
Leopard（の実装）は 32bit か 64bit かユーザーは全く気にせずに済む。
OSとしては 4GB を超えるメモリを扱え、アプリケーションや
ドライバーが 32bit か 64bit かも気にせず、ただインストールすればいい。
URLﾘﾝｸ(www.winvistacafe.com)
>使用者が64bit環境を意識せず使えるようになるのは、次の次の世代くらいになりそうです。
216:名称未設定
07/11/21 13:19:46 Mm0c3VSR0
今はまだよく理解できないけど、保存に値する良スレのような気がする。
217:名称未設定
07/11/21 14:30:33 Y8Suflxb0
>>215
>Leopard（の実装）は 32bit か 64bit かユーザーは全く気にせずに済む。
いまどき意識するOSって珍しくねぇか？
SolarisだってAIXだってLinuxだって使う分には意識なんてしてないぞ。
ビルドが必要な時に64bitライブラリとリンクするか32bitライブラリにリンクするか気にするけど、どれも同じようなもんじゃねぇの？
218:名称未設定
07/11/21 14:37:03 Vpfxmlg+0
Vistaは思いっきり64bitか32bitかを気にしないといけないようだが。
219:名称未設定
07/11/21 15:08:26 gCZ1ZI8V0
>>218
217 は暗黙に Windows は OS ですらないと言いたいんではないかと ...
220:名称未設定
07/11/21 15:34:05 KOaSh/Ut0
>>217
>SolarisだってAIXだってLinuxだって使う分には意識なんてしてないぞ。
前出でちょっと古い記事だけど
URLﾘﾝｸ(opentechpress.jp)
こんなのも
URLﾘﾝｸ(opentechpress.jp)
221:名称未設定
07/11/21 15:53:20 gCZ1ZI8V0
Leopard は 64 bit process から 64 bit plugin は読み込めないよ。
だから、64 bit Web ブラウザ, 64 bit Photoshop が出た日には、これまでのプラグインは読み込めなくなって困ったことになる。
まあ ブラウザで 64 bit ? はまだまだ非現実的だし、
64 bit Photoshop は多分出ない (64bit Carbon がごにょごにょ) だから関係ないけど、
64bit quicktime は既に API としてはあって、Final Cut Pro とか Apple 純正ビデオソフトが 64 bit になるとプラグインも全部新しくしないといけなくなると思われる。(まあ 32 bit 版を立ち上げておけばいいだろうけど。)
そういう意味ではレパードでも問題は無くはない。
というか手元で 32bit Obj-C, GC on で QTKit を使うソフトをつくってみたら、GC compatibility 問題で Perian が読み込めなかったんだけども ...
いつアップデートがでるのかな。むむ。
222:名称未設定
07/11/21 18:18:07 Y8Suflxb0
>>220
なるほどね。ブラウザにプラグインかー。
ちょびっと気にする必要があるかもね。
#AIXで32bitブラウザか64bitブラウザかなんて気にした事が無かったよ。
223:名称未設定
07/11/21 19:27:39 Ne6exJ8T0
flash plugin
java plugin
は64bit出してねえだろ、確か
224:名称未設定
07/11/21 20:32:09 4q3Zt5vh0
Windowsの場合，64bitネイティブのアプリは倍増したレジスタが使えると喧伝
してるけど，Macはしてないな。
やはり開発者の思いとしてはPowerPCこそが全てだからか。
225:名称未設定
07/11/21 20:35:15 4q3Zt5vh0
>>24
ドライバのサポートとMSの熱意か
226:名称未設定
07/11/21 21:29:02 yQN0fe1K0
>>221
それはPPC/Intelの時と同じ。
OSバンドルの新しめのPrinter Dialog Extensionなんかも64bit対応してる。これ3rd party製だよな。
227:名称未設定
07/11/21 22:09:30 S/oLCL9I0
>>225
MSはサーバーでは殆ど64Bitに移行済みだし、
クライアントもVistaから64Bitに力入れてるよ。
WindowｓVistaの認定ロゴはｘ64版での動作が必須。
ということで、なにげにVista対応版はｘ64版も対応
最新プリンタとかもドライバが揃ってる。
228:名称未設定
07/11/21 22:40:54 KOaSh/Ut0
>>227
>WindowｓVistaの認定ロゴはｘ64版での動作が必須。
世の中は 32bit 版が殆どだし、実際に今必要なのは 32bit 版があれば
十分だけど、MS が 64bit 版ドライバを開発させるための圧力の１つ
として使った感じだよな。＞認定ロゴ
229:名称未設定
07/11/22 01:37:16 t1d4JZIa0
それぐらいの圧力をかけないと、誰も64bit用のドライバなんて作ってくれないよ。
ただでさえVista64はシェアが少ないのだから。
だからみんなVistaを嫌がってXPを使っているのだろう。
DELLとか見てごらん。未だにXP搭載モデルなんて販売している。
230:名称未設定
07/11/22 01:45:01 2vfoOBIh0
>>213
G5には面白い仕組みがあったんだよね。
231:名称未設定
07/11/22 01:46:33 Hw/yFP3P0
ソフトウェアの進化ってほんと遅いよな。
未だに32bitOSばかり。
232:名称未設定
07/11/22 02:00:05 5HeKlI2c0
32bitが一番バランスが良いからじゃないのか？なんとなく
核爆弾の起爆装置も32個だし
233:名称未設定
07/11/22 02:32:50 t1d4JZIa0
他のOSも含めて今は、32bitから64bit移行の過渡期だからね。
でも、32bitから64bitへの移行のメリットが、16bitから32bitへのメリット
ほどの魅力が感じられないから、移行は今後ゆっくりと行われるのだろうな。
234:名称未設定
07/11/22 02:37:54 W6KfYvJg0
>>233
メモリ４G以上使いたい場合は64BitOSが必要だから
メモリ暴落がこのままなら急速に進むと思われ・・・
32Biｔアプリだけ使う場合でも64BitOS側はメモリを
キャッシュに使えるので大きい
235:名称未設定
07/11/22 03:00:30 t1d4JZIa0
しかし、32bit用のドライバとの互換性問題があるだろう。すんなりと
64bitに移行するとは考えられない。まあサードパーティーの努力しだいとでも
言っておこうか。
236:名称未設定
07/11/22 03:03:04 t1d4JZIa0
それに、メモリの暴落は一時のものと思われるのだが。どうせ新しい規格である
DDR3が主流になる頃にはまた値を戻すだろう。
237:名称未設定
07/11/22 10:33:01 1kBFvQHf0
折角メモリが安くなってるのに、その安いメモリをたった 3GB～4GB しか
積めないのが痛い。2GB で１万円しないんだから、8GB～16GB とか
積めば、Leopard のメモリ管理がもっと生かせるのに。
238:名称未設定
07/11/22 10:41:27 rpeNlFV+0
>>237
"たった"？？？
239:名称未設定
07/11/22 10:56:53 1kBFvQHf0
Mach は元々広大な粗なメモリ空間と、運用に対して十分なメモリ領域と、
２つや３つでない多数のマルチプロセッサを生かすよう開発されている。
URLﾘﾝｸ(ja.wikipedia.org)
当時は２つのプロセッサ、128MB の実メモリと 4GB のメモリ空間は
十分と言えたが、GUI や数百 MB～数GB の動画、数万ファイルの画像
を一般的に扱う今は、２つのプロセッサ、3GB の実メモリと 4GB の
メモリ空間は mach（や最近のモダンな OS）の設計を十分に生かす
量ではないと思ってる。
たった数GBの SSD に何万も払って高速化するより、十分な主メモリを
積んで、OS の特質を生かしたほうが、なんとかSuperFetchとか、
なんとかReadyBoostとか、なんとかReadyDriveみたいな場当たり的な
技法よりずっとスマートな解決策だと思うのだけど。
240:名称未設定
07/11/22 12:16:37 1kBFvQHf0
>>229
>DELLとか見てごらん。未だにXP搭載モデルなんて販売している。
DELL だけじゃなく、色々な企業がまだ出しているね。
企業での購入でも Xp 指定がまだまだ大多数らしい。
241:名称未設定
07/11/22 14:31:41 HP8rM5rb0
それどころか、VIstaも32bitがほとんど
242:名称未設定
07/11/22 19:42:53 J/kmrjyN0
Macの世界はまだ仮想化が熱心じゃないけど、他のOSは仮想化ビジネスに
熱心だから、64GBとか乗るマシンのために64bit化はすごいメリットがある。
箱庭の中は32bitでもいいさ。
うちの会社もマシンの統合で64GBマシンを複数導入して使ってかなり便利。
243:名称未設定
07/11/22 19:57:34 4ZlI4DOw0
いまiMac使っていて、メモリー4GBまでしか使えないんだけど、
MacProとかに変えれば、もっとメモリー使えるようになるよね？
スワップしないくらいメモリー積んでみたい(´･ω･`)
244:名称未設定
07/11/22 20:25:07 WIJ+8ZlG0
>>239
> たった数GBの SSD に何万も払って高速化するより、十分な主メモリを
> 積んで、OS の特質を生かしたほうが、なんとかSuperFetchとか、
> なんとかReadyBoostとか、なんとかReadyDriveみたいな場当たり的な
> 技法よりずっとスマートな解決策だと思うのだけど。
十分なメモリをつんでいたとしよう。
その状態でマシンを起動して、はじめてアプリを起動したとき
その起動が早くなるかね？
245:名称未設定
07/11/22 21:52:37 dy3aChzI0
>>244
ファイルシステムの先読みが賢ければある程度は
246:名称未設定
07/11/22 22:01:28 WIJ+8ZlG0
> ファイルシステムの先読みが
MacOSXに搭載されている（？）
そのファイルシステムの先読みとは
いったいどういうデータを先読みしてくれるの？
247:名称未設定
07/11/22 22:05:57 tfBAvFyP0
これではドザ共を馬鹿にできないではないか。
なんたる体たらく。
248:名称未設定
07/11/22 22:13:14 dy3aChzI0
>>246
もちろん
249:名称未設定
07/11/22 22:14:13 WIJ+8ZlG0
>>248
答えになってないぞ。
どういうデータを先読みしてくれるんだ？
ソースありで教えてくれ
250:名称未設定
07/11/22 22:17:40 dy3aChzI0
何で質問者がそんなに居丈高なんだ?
ファイルシステムが読むデータなんて決まってるだろ
251:名称未設定
07/11/22 22:20:26 WIJ+8ZlG0
決まってるなら教えてくれよ。
たとえばよく使うプログラムを先読みしてくれるのか？
それぐらい賢いのか？
252:名称未設定
07/11/22 22:21:18 dy3aChzI0
そんなわけ無いじゃんw
253:名称未設定
07/11/22 22:25:36 WIJ+8ZlG0
どうせ先読みするのなら、
よく使うプログラムまで
先読みしてくれたらもっと良いと思わない？
254:名称未設定
07/11/22 23:02:45 J/kmrjyN0
じゃあ起動時に全部アプリを実行すりゃいいって事で。
255:名称未設定
07/11/22 23:11:10 WIJ+8ZlG0
それじゃ、起動時が重くなるじゃん。
こういうものはCPU・HDDの空き時間に読み込むものでしょ？
256:名称未設定
07/11/22 23:31:35 lqyZcs2e0
OS、アプリの初回起動の遅さが我慢できないってどんだけー、と思うけどな。
OSなら使わないときはスリープしときゃいいし、
メモリ大量に積んでるんなら、アプリも常時起動しとけばいいしね。
まぁ、流石にVistaクラスの遅さだと我慢できんけどねw
>>243
16GBだが、FB-DIMMだからちょっと高く付く。
とはいえ、ノーブランドでよければ12万ちょいで16GB積める時代なのか…。
257:名称未設定
07/11/22 23:36:58 WIJ+8ZlG0
メモリ無駄遣いするOS。それがMacといわんばかりだなｗ
258:名称未設定
07/11/23 00:01:50 CbCzjNT20
>>244
>その状態でマシンを起動して、はじめてアプリを起動したとき
下手な煽りに付き合うのもなんだが、起動した直後に起動するアプリを
高速化したい、という発想自体が随分レガシーな印象を受ける。
Vistaの「起動時間」「シャットダウン時間」に不満の声
URLﾘﾝｸ(www.computerworld.jp)
>起動するまでに約10分、ログインして使えるようになるまで5分も
>かかっている。この状態を改善できないと、XPに戻すと家族に
>約束させられてしまった。
MacOS X なら起動時間が気になるならスリープで使うだろうし、
（コールドスタートだって１０分どころか１分もかからないし）
スペースバー叩けば１秒で起動する。しかもさっきまで使ってた
アプリも既に起動してるしw
259:名称未設定
07/11/23 01:11:55 YeD4RVVC0
起動した直後のアプリを起動するために SSD を導入するってw
メインメモリを隅々までキチンと使ってくれるのが MacOS X
余った分は空きメモリとして表示されるだけの Windows Xp
そもそもメモリが余らない 32bit OS の Windows Vista
WindowsXp の Office って、Office の起動時間を速めるために、
Windows 起動直後に Office 関連の DLL なんかを先読みするように
なっている。でも、逆に OS の起動時間はかかるから、
結局見かけだけ素早く起動するように「見える」だけ。
しかも、Office を使わなくても DLL がメモリを占有するw
MacOS X で同じことをしようと思ったら、スタートアップに
Office を起動して終了させるスクリプトを入れればいいだけ。
しかも、Office だけじゃなくて好きなアプリケーションで使えるし
Offce を使わなければそのメモリは他の用途に流用される。
260:名称未設定
07/11/23 01:43:29 15mafHHB0
MacOSの場合ディスクからメモリーに読み込まれた内容は、使い終わったあとも
即座にははき去れず、むしろ積極的にメモリー上に残される。そして次に内容が
必要になったとき、ディスクからではなくメモリー上に残しておいたデータを
再利用することでディスクの読み書きの処理を減らすことになる。
これらのメモリー領域が「アクティビティモニタ」で「現在非使用中」と分類
されている部分である。
このようにMacOSXは効率よくメモリーを使用している。
261:名称未設定
07/11/23 02:27:08 hcJ8Hx2n0
>>251 >>252
Tiger の時の話だが、
URLﾘﾝｸ(www.osxbook.com)
を読め。
良く使われるファイルはハードディスクの先頭にもってきて、
ハードディスクのヘッドがあまり動かなくて良いようにするし、
ファイルが HDD 上でばらばらになっていたらのが
ファイルを開いたときに判ったら、その際に自動でデフラグしたりする。
262:名称未設定
07/11/23 02:36:27 YeD4RVVC0
URLﾘﾝｸ(plusd.itmedia.co.jp)
>電源オフの状態から起動すると完全に起動するのに10分程度かかってしまう
263:名称未設定
07/11/23 02:37:21 15mafHHB0
>>261
遅延再配置とHot-File-Adaptive-Clusteringのことだね。
メモリー読み込みに関する話ではないが、ディスクの最適化に関しては
NTFSよりは優れている機能だ。
>>251はたぶんVistaのSuperFetchのような機能を聞いているのでは。
264:名称未設定
07/11/23 02:40:54 15mafHHB0
>>262
仕方が無いさ。Vistaはスリープからの起動を推奨しているからね。
265:名称未設定
07/11/23 02:41:27 +0Sez8Kw0
MacOSXは積極的にキャッシュを利用する。
といっても、それは一度読んだデータを取っておくというだけで、
一度も読んでないデータは当然キャッシュされない。
VistaのSuperFetchはその一度も読んでないデータでさえもキャッシュしてしまう優れもの。
過去のデータ使用履歴から最適なものを先読みキャッシュする。
266:名称未設定
07/11/23 02:44:46 hcJ8Hx2n0
その記事にのってる、working set detection は違うの？
267:名称未設定
07/11/23 02:49:21 zMwwy8J60
もしかしたら使わないかもしれないデータまでキャッシュしとくってどうなの？
268:名称未設定
07/11/23 02:52:57 +0Sez8Kw0
何か問題が？
269:名称未設定
07/11/23 02:59:01 YeD4RVVC0
SuperFetch に関してはこの辺り
URLﾘﾝｸ(pc.watch.impress.co.jp)
例えば、会社で12時から昼食に出かけ、その間にウイルスチェックやバックアップなど
のタスクをスケジューリングしているという状況を例に挙げると、Windows XPでは、
アイドル時のタスクにメモリを割り当て、それまでフォアグランドで作業していた
アプリケーションデータはHDDに待避させる。そのため、昼食から戻ってきて、
作業を再開しようとすると、その時点で初めてアプリケーションデータをHDDから
読み込むため、作業を開始するのに待たされる。
SuperFetchでは、過去のユーザー行動のパターン(ここでは、ユーザーが作業を
再開する時間やアイドル後に行なう作業内容)を記憶しているため、アイドルタスクが
終了次第、HDDに待避させていたアプリケーションデータをメモリに読み戻すので、
ユーザーが戻ってきた時には、即座にアプリケーションが反応するという具合だ。
で、メモリが十分にあればこんなアホなことはする必要はない。
そもそも、人間の行動パターンなんてそんな簡単なものではないから、
得てしてこういう予測機能なんてのは失敗する。
【失敗機能】 VistaのSuperFetchは絶対に切れ！
ｽﾚﾘﾝｸ(win板)l50
先読みされた無駄なデータは、メモリが足りなければ捨てられる。その上、
必要なデータで上書きしなければいけないから、無駄なHDDの動作が増える
だけ。マイ糞のエンジニアは、なぜ先人達が遅延評価などという機構を
導入したのか判っていないようだ。
270:名称未設定
07/11/23 03:02:55 +0Sez8Kw0
> で、メモリが十分にあればこんなアホなことはする必要はない。
十分じゃない場合は？
271:名称未設定
07/11/23 03:05:01 +0Sez8Kw0
> 先読みされた無駄なデータは、メモリが足りなければ捨てられる。
別に捨てないよ？
読み込んだデータで上書きするだけ。
コストは0
> その上、 必要なデータで上書きしなければいけないから、
それは、キャッシュされていなくても同じこと。
使用されていないメモリ領域にだって
何らかのデータが入っているわけで、それを上書きする。
> 無駄なHDDの動作が増える
意味不明。
272:名称未設定
07/11/23 03:06:01 YeD4RVVC0
>>270
>十分じゃない場合は？
メモリを増設しろ。
>>239 も読め。
273:名称未設定
07/11/23 03:06:46 +0Sez8Kw0
> メモリを増設しろ。
できない場合は？
274:名称未設定
07/11/23 03:15:45 YeD4RVVC0
>>271
>読み込んだデータで上書きするだけ。
>コストは0
アホだな。上書きするデータはどこから持ってくるんだw
先読みされたデータが外れた場合は、先読みする為に必要だった動作は全部無駄になる。
当たり前の話。
>> 無駄なHDDの動作が増える
>意味不明。
その足りない脳みそを有効に使ってくれ
>>273
>できない場合は？
働いて人並みの金を稼げ
275:名称未設定
07/11/23 03:18:30 +0Sez8Kw0
> 先読みされたデータが外れた場合は、先読みする為に必要だった動作は全部無駄になる。
だから？
べつに、先読みするために必要だった動作は、
空き時間にやるんだから問題ないじゃん
276:名称未設定
07/11/23 03:26:06 YeD4RVVC0
URLﾘﾝｸ(pc.watch.impress.co.jp)
ReadyBoostによってフラッシュメモリにSuperFetchデータが書き込まれる間、CPU負荷が2～3割程度になっていた。ちなみに、1,840MBの書き込みが終わるまでは約7分かかった。つまり、PC起動後、数分間はReadyBoostがPCの性能を低減させることがあるということだ。
277:名称未設定
07/11/23 03:44:19 YeD4RVVC0
>>275
>つまり、PC起動後、数分間はReadyBoostがPCの性能を低減させることがあるということだ。
>つまり、PC起動後、数分間はReadyBoostがPCの性能を低減させることがあるということだ。
>つまり、PC起動後、数分間はReadyBoostがPCの性能を低減させることがあるということだ。
278:名称未設定
07/11/23 03:59:50 +0Sez8Kw0
しょせん机上の空論だな。
実際は処理は空き時間に行われるから
性能は低減されない。
279:名称未設定
07/11/23 04:11:36 YeD4RVVC0
>>275
大容量メモリ＋スリープで運用すれば、なんたらSuperFetchみたいなものはそもそも
必要ないというのは判ると思う。
第５回 パソコンの処理速度高める「見えざる新技術」・ユーザー行動学習も
URLﾘﾝｸ(it.nikkei.co.jp)
筆者も４ギガバイトの製品を購入してReadyBoostデバイスとして使用している。
ただし、こちらも速度向上が実感できるとは言い難い。各種ツールを用いると、
確かにReadyBoostキャッシュファイルの更新が行なわれていることが確認できる
が、その効果はSuperFetchと同じく体感レベルに達しないのだ。
たまに再起動したとしても、最初にアプリケーションを起動するための数秒のコストが
問題にならないことは MacOS X のみならず、多くのモダン OS を使ってる人間なら
良くわかると思う。
もし、これを問題にするのなら、アプリケーションの起動時間より、起動時間の大部分
を占めると思われるマシンの起動時間を考えた方がいい。
280:名称未設定
07/11/23 04:14:09 YeD4RVVC0
>>278
>しょせん机上の空論だな。
SuperFetch や ReadyBoost のことですネ！
>実際は処理は空き時間に行われるから
PC起動後、数分間はPCを使わないのですね。
何のためにPCを起動したのか忘れてしまったのでしょうか。
281:名称未設定
07/11/23 04:21:30 BUBWC0t40
ナイス燃料投下 >>239
282:名称未設定
07/11/23 04:50:57 +0Sez8Kw0
>>280
知らないかもしれないけど、
実は、CPUってかなり空き時間があるんだよ？
CPU使用率が100%未満の場合、CPUは休んでるのさ。
知らなかったでしょ？
283:名称未設定
07/11/23 05:47:58 hcJ8Hx2n0
というかいまどき Windows にしろ Mac にしろ、電源をいちいち切っているひとのことが信じられない。なんでスリープにしないの？
284:名称未設定
07/11/23 07:11:50 O9e3cCYD0
>>282
君んちのPCも、主が前に座るたび、
「このボトルネックめ、さっさと動けよノロマめ。」と思ってる事間違いなし。
285:名称未設定
07/11/23 07:21:08 CJZX8PdB0
>>283
ノートブック型を頻繁に持ち運ぶ人はしょうがないんじゃない？
場所を動かさない用途ならいちいち電源落とす意味はあんまりないが
286:名称未設定
07/11/23 07:44:55 hcJ8Hx2n0
僕ノート型だけどスリープで済ませてますが ...
うちの macbook だと飛行機で太平洋渡っても大丈夫だよ。
立ち上がり時の激しい HDD のアクセスとかのほうが電気を食うんじゃないだろうか ... とおもってスリープにしてますが。
電力測ったことないからわからないけど。
287:名称未設定
07/11/23 12:11:50 YeD4RVVC0
>>282
>実は、CPUってかなり空き時間があるんだよ？
あまりアホな煽りを相手にしてもしょうがないが、
皆がお前みたいに負荷の軽い仕事しかしない訳じゃないし、
無駄な仕事＝無駄な電力であることは変わりない。
スリープを使って欲しいのはマイクロソフトも同じで、
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
とのこと。
SuperFetch でアプリケーションの起動時間が短くなると謳っているが、
メモリに展開する時間が起動時にかかっていることを考えれば差し引きはゼロ。
展開したりキャッシュしたが、使われなかった分がマイナスになるだけ。
そんなことをやるより、起動時間をマトモにする方が重要だと思うが。
288:名称未設定
07/11/23 13:31:19 Rw0Tf7HJ0
マジアフォには技術的なことはわからないなｗ
> SuperFetch でアプリケーションの起動時間が短くなると謳っているが、
> メモリに展開する時間が起動時にかかっていることを考えれば差し引きはゼロ。
ゼロってそれは処理全体にかかった時間な。
CPUってのはあまり使われていないの。
CPU使用率って知っている？
使用率が100%未満のとき、CPUは遊んでいる。
その遊んでいる時間に先に実行する。
なんでも、先に済ませていたほうが良いだろ。
CPUが使用されていないときにやるのだから、ほかに影響はないし。
289:名称未設定
07/11/23 15:09:21 NnAv9r5C0
>>287は「俺の思考を予測して、俺が起動するアプリだけスパーフェチしてくれ。それ以外は無駄だからやるな」と言ってるのかなw
290:名称未設定
07/11/23 15:33:56 15mafHHB0
SuperFetchはメモリが少ないときは性能が悪い事が分かっている。
予測が失敗したときは先読みした処理の分が無駄になるから。
HDDを余計に動かしただけの無駄な行為になってしまう。
SuperFetchは大容量メモリで始めて生きてくる技術だろう。
291:名称未設定
07/11/23 15:39:07 Mpx7xPgJ0
>>287
> スリープを使って欲しいのはマイクロソフトも同じで、
> URLﾘﾝｸ(itpro.nikkeibp.co.jp)
> とのこと。
ReadyBoost使ってるとスリープから戻るたびに数分ほどフラッシュに書き込みw
レスポンスは悪くなるわ、バッテリーは減るわ
結局XPにダウングレードというなのアップグレードをしたオレが来ましたよ
292:名称未設定
07/11/23 16:16:30 vPgLaMG30
まあ将来的には全面64bitの方が良いんだろうが
今の段階でカーネルまで64bitに書き換えても
一般的には使い道がなかったり
諸問題で64bitが普及しないのはWindowsが証明している訳で・・・
学術分野とかだと知らんが
とりあえず64bitになったとしても
一般的には一部のアニメオタが
エンコ10分が7分になったよ！64bitSUGEEEEE
って位しか今のとこメリットがないと思うんだが・・・
293:名称未設定
07/11/23 16:25:22 J2nbPZ8E0
サーバサイドは Solaris も Linux も普通に 64bit 化されてるよ。
DB のキャッシュや Java の Heap に 4GB 以上のメモリを
割り当てたり、大容量ファイルシステム用のキャッシュとか。
サーバ市場を諦めるなら、しばらくは必要ないかもね。
294:名称未設定
07/11/23 16:27:27 vPgLaMG30
どう考えてもAppleがサーバ市場本気で狙ってるとは思えんのだが・・・
一応サーバもやってますってくらいじゃね？
295:名称未設定
07/11/23 16:30:53 vBC4oFan0
DTPとかVideo Serverとか、特殊な用途だよな。
URLﾘﾝｸ(www.apple.com)
296:名称未設定
07/11/23 16:49:06 vPgLaMG30
>>295
放送業界の市場規模って3.5兆円規模だよ
全然特殊な用途じゃないよ
ちなみにIMAGICAは日本のポスプロ最大手
297:名称未設定
07/11/23 16:57:25 4kMvc+Jj0
InterBeeでLinuxつかってデモしてたが・・・今時価
298:名称未設定
07/11/23 18:24:58 GrRcdRUz0
>>297
俺もそれみた。
299:名称未設定
07/11/23 22:20:14 YeD4RVVC0
>>288
>なんでも、先に済ませていたほうが良いだろ。
あのな、お前の戯言が技術論だと妄想するなら、
今のモダンな OS がどうやってメモリ管理しているかぐらい調べてくれ。
SuperFetch の発想そのものがレガシーで、今のメモリ管理指向から
逆行しているの気付くことはないだろうがな。
lazy evaluation がなぜ行われるかぐらいは（ry
>>290
>SuperFetchは大容量メモリで始めて生きてくる技術だろう。
で、大容量メモリ＋スリープだと必要ない技術。
300:名称未設定
07/11/23 23:16:32 J2nbPZ8E0
>>299
>lazy evaluation
デマンドページングの事?
301:名称未設定
07/11/24 06:09:07 Atc5ayog0
>SSD搭載のMacBook Proは爆速！
URLﾘﾝｸ(applembp.blogspot.com)
>ランダム・アクセス・リードは20-33倍に！
↑将来的にSSDが有望。容量面や価格的にまだまだ時間かかるかな？
302:名称未設定
07/11/24 08:34:01 Atc5ayog0
URLﾘﾝｸ(pc.watch.impress.co.jp)
>アップルによればTigerにおける64bit対応は、PowerPC版、Intel版ともに
>同等の対応を実現しているということで、メモリ空間、データバス、レジスタ、
>マスライブラリなどがOSレベルでは64bit化されているという。
ちょっとソースと言えないレベルだけど、レジスタも64bitで拡張された部分を
利用出来る。これに関してだけど、以前TigerのCUIアプリベンチ（32/64bitの）
の記事でレジスタの拡張による高速化という結果になっていた。この記事が検索
しても見つからないのだけど、グラフ付きで、Web上の日本のITニュース系の記事だったよ。
もしよければ誰か見つけて貼って欲しい。Tiger登場後のやつ。
こうして考えると、64bit化によるメリット→より大きなメモリ空間、拡張されたレジスタ
という部分を利用出来る64bitアプリの実行環境を広めるという意味で、Leopardの今回の対応
が段取りとして一番理にかなってるように思う。なにせ、今のところほとんどの人が64bit化
なんて興味が無いのだし、ユーザーに意識させずに環境を整えないと移行できないでしょ。
Vistaが8800万本を販売したという話を聞いたけど、例えばそれがPCにプリインストールされて
販売されたものがほとんどの場合、その多くが32bit版を採用しているけど、Vistaの普及時点で、
そこからさらに移行させるというのはかなりの難関になる気がする。
BootCampが32bitVistaにしか対応しないというのもAppleの戦略なのかも（汗）
303:名称未設定
07/11/24 10:38:36 tbMjlkuc0
iPodと同数の台数が買われているという状況ならSSD搭載も実現していた。
304:Nehalem
07/11/24 10:39:10 tbMjlkuc0
Nehalem
305:名称未設定
07/11/24 11:02:22 eoFljY6k0
PPCは32bit addressingでも64bit命令使えたが、Intelはどうなの？
306:名称未設定
07/11/24 11:27:41 oVHzW4pn0
>>302
まあ要するに今後も64bit kernelにする気はないって事だろうな。
307:名称未設定
07/11/24 12:18:15 Ybd0qjmh0
>>305
G5の汎用レジスタ幅は無条件に64bit
本当にレジスタ幅が効いてくる処理は128bit幅のAltivecやSSEを使うから
汎用レジスタ幅が64bitになるのはそれほど効果は無いよ。
馬力が必要なコーデック系の処理はもちろん。単純なメモリコピーですら
サイズが大きくなるとAltivecやSSEを使ってる。
308:名称未設定
07/11/24 14:32:31 AI0RxFy/0
>>307
ちょっとずれてる気がするが...
例えば32bitモードでlong longの加算をしたい時に、64bit命令は使えないのか
とかそういう事でしょ。
Intelの場合はSSE2のスカラ64bit命令があるから
32bitモードでも64bitの整数演算命令は使える
ただし当然ながら乗除算とかはできないけど。
SSE2スカラ64bit加算命令のレイテンシを見てみると
32bit整数加算の2倍だから、使用価値は微妙だ。
309:名称未設定
07/11/24 16:35:27 P1VjKLu30
>>308
>例えば32bitモードでlong longの加算をしたい時に、
>64bit命令は使えないのかとかそういう事でしょ。
G5 だったらできるでしょ
310:名称未設定
07/11/24 17:33:36 AI0RxFy/0
>>309
いやだから305はG5はできるけどIntelはできるのかって質問でしょ
311:名称未設定
07/11/24 22:29:48 nqKqlaP50
SSEとかで64bitの計算はできるな。
312:名称未設定
07/11/25 07:32:10 MmyRPxwW0
Leopardが64bitOSというレベルは
ちょうどWindows95が32bitOSだというレベルと考えてよろしいでしょうか？
313:名称未設定
07/11/25 07:47:02 bOknGjgI0
違います
314:名称未設定
07/11/25 13:19:35 YzcKeIf80
XP が 32 bit OS だというのとは同じ？
315:名称未設定
07/11/25 21:33:16 uHq1I4OS0
おなじ
316:名称未設定
07/11/25 22:53:43 Czek/gsq0
違うよ、ぜんぜんちが(ry
317:名称未設定
07/11/26 01:49:10 g72efW7f0
16bitカーネルで32bitアプリを実行できるwin32sのような、
32bitカーネルで64bitアプリを実行できるのがMac OS X。
318:名称未設定
07/11/26 16:23:24 oBuzx4hS0
32bitのメモリを複数「平行処理」するのと
64bitのメモリを一括処理するのとどちらが能率が良いのだろう。
よくわからん。bitを上げればこそ効率が上がるというわけでもないと思うし。
319:名称未設定
07/11/26 21:14:54 vtEvK/6y0
>>318
意味不明
320:名称未設定
07/11/26 21:23:28 29V7RODF0
32bit のデータを 2 回 load するのと
64bit のデータを 1 回 load するのは
どっちが速いかって話じゃないの
64bit のデータを 1 回 load する方が速い
321:名称未設定
07/11/27 00:51:25 1Vfxvj100
というわけで Leopard のカーネルの話題に戻したりするとw
カーネルは 64bit のアドレス空間を管理しないといけないから 64bit 整数の演算を
32bit のコード中で行っていると思うんのだが(?)、
普通にやったら 32bit ずつロードして、キャリー等のある計算が必要ですよね。面倒～。
こういうのってどの位ペナルティーになってるのかちょっと気になる。
322:名称未設定
07/11/27 01:24:57 IanKJAAy0
ちょっと前に話してるSSE2の64bit整数演算命令使っても別に良いんじゃね
まあ32bitの演算器を使っても演算自体はレイテンシが少々増えるだけだろうけど。
CSAライクに素直にcmovを使うか、分岐予測に期待するか、どっちが速いんだろ。
323:名称未設定
07/11/27 02:56:09 uSpAIJkr0
カーネルはメモリー渡しておしまいだろ。アクセスはアプリが自分でやる。
324:名称未設定
07/11/27 03:27:16 kwMrbrKO0
要はMachカーネルはメモリの管理が仕事なわけだろう。（その他にもすることがあるが）
その他の仕事は64bitAPIがそれをやってくれるわけだから。
確かMachカーネルはTigerでプロセスの用いる仮想アドレスが64bitに対応したと
あるが、Mach自身が32bitならどうやってそれを行っているのだろうか？
どうもG5では32bit上でも64bitアドレスが指定可能なようだが、Core2では可能なのか？
325:名称未設定
07/11/27 03:36:04 kwMrbrKO0
URLﾘﾝｸ(journal.mycom.co.jp)
どちらかというと逆みたいで64bit上で32bit環境を動かしているようだね。
だからMachカーネルは32bitでも良かったのではないか。
しかし、そんなことが、IntelのCoreアーキテクチャでは出来るの？
326:名称未設定
07/11/27 06:39:11 m4Z4El7R0
>>321
32bit整数演算はメモリ管理と関係ない。
アドレス空間ってのはカーネルから見える物理メモリ上に確保された対応表できまる。
対応表には物理アドレスA～Bは仮想アドレスのX～Yにみたいなのが延々書いてある。
実際のアドレス変換はCPUが勝手に行う。
つまり、
・対応表の書き換えは32 bitのカーネルで行う
・対応表に従ったアドレス変換はCPUの専用回路で行う (64 bitネイティブ)
というわけ。
対応表の書き換えを32 bit整数演算で行うことのペナルティはほとんどない。
対応表の変更ってそんなに起きないから。
アドレス変換はCPU内部で専用回路で行われているので
カーネルが32 bitだろうが64 bitだろうが同じ速度で動く。
327:名称未設定
07/11/27 07:39:02 J4eQOMci0
>>326
>アドレス変換はCPU内部で専用回路で行われているので
TLB なんて余裕で溢れるよ
TLB miss は常に発生していると考えた方が良い
Mac からじゃ見えないけど、他の OS 入れれば分かる
328:名称未設定
07/11/27 07:47:17 m4Z4El7R0
>>327
カーネルの大半が互換モード(32 bit)で動いていた場合に
アドレス変換で何かデメリットがあるかって話だと思ったんだけど。
カーネルを完全に64 bitモードしたとして、
それでTLBミスヒットが減るような要因ってなんかあるっけ？
329:名称未設定
07/11/27 07:51:25 J4eQOMci0
TLB miss したら CPU で演算する事になるけど、その時に
32bit で動いているとペナルティが発生する
330:名称未設定
07/11/27 08:02:44 m4Z4El7R0
>>329
もしかしてx86以外の話してた？
URLﾘﾝｸ(blogs.sun.com)
>実際には、TLBミスが発生した時にどうするのかっていうのは、CPU次第。
>X86アーキのように、カーネルがPage Directory Table等々のTableを用意してあげて、
<CPUがTable Walkingを行って捜し出すものもあれば、
>CPUがtrapをあげてカーネルに教えて頂戴って言ってくるのもあります。
>UltraSPARCは後者を採用しているわけなんですね。
>X86アーキに慣れている人は、なんか面倒だなって感じるかも知れないけど、
>この手法は結構ポピュラーな方法です。
>Andrew S. Tanenbaum教授の(有名な)著書"Operationg Systems Design and Implementation"にも
>Software TLB Managementとして説明(注2)されていて、
>数々のRISC CPUに採用されている方法でもあるんですね。(*_*)
それともAMD64になってSoftware TLB Managementに移行したんだっけ？
だとしたらこちらの不勉強。その場合はスマソ。
331:名称未設定
07/11/27 08:07:32 J4eQOMci0
それ、どっちも CPU 使うでしょ。
332:名称未設定
07/11/27 08:13:00 J4eQOMci0
PDE って良く分かってないんだけど、CPU 内部に専用命令と
TLB 以外の専用領域が用意されていているの?
もしそうであれば、まあペナルティはそんなに無いかもね。
333:名称未設定
07/11/27 08:33:53 CLrQM84E0
>>326
なるほどどうも。
>実際のアドレス変換はCPUが勝手に行う。
この辺はぼんやり理解していたつもりです。要は
>対応表の変更ってそんなに起きないから。
ですね。
具体的にはどんなときに対応表の変更って起きるんでしょうか?
334:名称未設定
07/11/27 08:38:38 m4Z4El7R0
>>332
＞PDE って良く分かってないんだけど、CPU 内部に専用命令と
＞TLB 以外の専用領域が用意されていているの?
そう。
でかいのでx86はCPU内部に持つじゃなくてメインメモリを流用してる。
URLﾘﾝｸ(caspar.hazymoon.jp)
具体的にはメインメモリ上に多段ルックアップテーブルを構築して
その最上段(ページディレクトリ)の先頭物理アドレスをcr3レジスタに登録する。
URLﾘﾝｸ(caspar.hazymoon.jp)
x86のTLBはCPU内部の非公開キャッシュ。
キャッシュの細かい制御はルックアップテーブル内のビットで間接制御。
OSから明示的にTLBの内容を制御することはできない。
(せいぜい内容をフラッシュするぐらい)
TLBミスヒットが起きるとメインメモリへのアクセスが発生する。
335:名称未設定
07/11/27 09:09:05 m4Z4El7R0
>>333
＞具体的にはどんなときに対応表の変更って起きるんでしょうか?
例えばプロセスにメモリが割り当てられたときとかプロセスからメモリが解放されたときとか。
ただし大抵の言語だとライブラリがまとめてOSからメモリを確保して、
そこから切り売りされたメモリをプログラムは使っている。
言語のメモリ割り当て/解放命令ごとに対応表が書き換わるわけじゃない。
あとプロセスごとに対応表を区別してるので、
プロセス切り替えでは対応表の切り替えも必要。
こんな感じで、ｘ86の場合、実際のカーネルの仕事は電話帳作っているようなもの。
実際に電話かけるのはCPU内の専用回路。
カーネルの大半が32 bitコードでも64 bitアプリのメモリ管理にそこまで支障はない。
(どっちみち割り込みハンドラは64 bitコードで書くことになるけど)
336:名称未設定
07/11/27 09:19:40 J4eQOMci0
>>334
>TLBミスヒットが起きるとメインメモリへのアクセスが発生する。
これって load は 32bit 操作なんだよね?
そこが遅くなるんじゃないかなあと思ってるんだけど。
337:名称未設定
07/11/27 09:32:51 m4Z4El7R0
>>336
x86の場合そこはCPUの専用回路が自律的に読み込みを行う。
そもそもプログラマブルじゃないので
32 bitのロード命令とか64 bitのロード命令とか関係ないような。
割り込みによってOSで制御してるわけじゃないんで。
338:名称未設定
07/11/27 10:50:55 kwMrbrKO0
それでは、32bitカーネルでも64bitアドレッシングは可能なのですか？
339:名称未設定
07/11/27 11:42:44 CLrQM84E0
>>335
>プロセス切り替えでは対応表の切り替えも必要。
>>336
>x86の場合そこはCPUの専用回路が自律的に読み込みを行う。
たびたびごめんなさい、
処理をする実体(?)が「カーネル」と「CPU（の回路?）」との2つに分けられるとすると、
確かプロセスの切り替えはカーネルがやっていることになると思いますが、
「対応表の切り替え」もカーネルがやるんでしょうか?
あと、「対応表」は少なくとも x86 の場合メモリ上の部分と TLB の（キャッシュされた）
部分があって複雑ですね。>>335 の「対応表」とは両方を指しますか?
340:名称未設定
07/11/27 11:43:47 CLrQM84E0
>>339
あ、すいません、引用の後半は >>336 じゃなくて >>337 でした。
341:名称未設定
07/11/27 13:17:15 uSpAIJkr0
コンテキストスイッチングも１命令(+α)でしょ。CPU。