Leopardが実は32bit OSだという噂があるのですが

64bitアプリはチェスだけ。
その他のアプリ、カーネルやドライバは32bit。

64bitドライバを作っても
カーネルが32bitだから読み込まれない。

などという噂がありますが
誰か検証した人いますか？

これが本当なら由々しき問題です。

http://forums.macrumors.com/showthread.php?t=383492

↑ブラクラ注意

いや別に普通のサイトだけど

ブラクラってwwwww

単発質問スレが乱立する方が由々しき問題

↓再利用法

この内容でなんでこんなスレが立てられるか説明してくれw

無知のくせに「64bit＝スゴイ」とか思ってる短絡思考のバカはもうウンザリ

http://hosted.met-art.com/met-art_vol_51_36//full/met-art_vol_51_16.jpg

elleさま(;´Д`)ﾊｧﾊｧ

海の向こうの噂サイトの「ググったけどよくわかんねぇから教えて」程度の質問スレッドで
噂だなんだと言ってこんなスレを立てれる根性は尊敬しなくもないw

ドザチョンのバカは底なしですから

俺のPowerBook G4で動いてるから32bit OSで間違いないな。

G4のデュアルは32bitx2で64bit !?

一応G4でも64bit処理は出来るがわざわざそんな事はしねーよな

>>13
正確には64bit「級」かな

33bit

脳天直撃

好きにしてくださいwwwwwwwww
32/64bit問題なんていう恥ずかしいバグはありませんwwwwwww

bitたけし

>>7
x86 の長年のネックだった GPR が増えるんだから凄いべよ。

まあカーネル自体が32bitプロセスなのは間違いない
% file /mach_kernel
してみりゃ分かるが

Leopardは64bitに対応したAPIが増えただけで、別にTigerから特別大きく変わった訳じゃない。
4GB以上のメモリ空間が使えて64bitモードでCPUを動かせる以上
一般ユーザや開発者にとってカーネルが32bitだろうが64bitだろうがどうでも良い話ではある

その昔Win32Sという16bit Windowsで32bitAPIが動かせるしくみがあったんだよね。
それと同じだと思えばまあいいんじゃないの。

AppleのLeopardの宣伝文句はやりすぎだと思うけど。

使えるメモリが増えただけでもイイ。
32bitアプリが殆どの現代、孤高の完全なる64bitは無用では？

windowsは遅れてますね

>>24
具体てきにはなにが？

Win32Sものすごい虎馬
これからはWin32の時代だぜ！という宣伝文句に踊らされて
アプリ全部32Sで作り直したらバグ地獄

kernelが32bitなのはars technicaのレビューが出た時点で分かってたと思うが

>>19不覚にもワラタ

やっぱり真の64bitOSじゃないのね。

Windows9xがカーネルのほとんど32bitなのに、ごく一部に16bitコードが
含まれただけで16bit OSだと言うやつがいたが、そいつに言わせれば
カーネルが32bitのLeopardは完全な32bit OSなのだろうね。

まあ64bitカーネルになってたら今頃はドライバが全く無くて大変だっただろうな。

広告の文言以外は堅実な選択だな。

よく分からんのは、未だ32bitカーネルである事と、

ttp://developer.apple.com/hardwaredrivers/overview.html
"Mac OS X supports both 32-bit and 64-bit drivers."
とか

ttp://www.apple.com/jp/macosx/technology/64bit.html
＞さらに嬉しいことに、新しい64ビット対応ドライバにアップグレードすると、32ビットアプリ　
＞ケーションのスループットも向上します。
とかの記述との関連性。

この「64ビット対応ドライバ」って、
ttp://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/transition/chapter_3_section_4.html
の記述にある「DMA関係をupdate」したドライバってことなのか？

>>31

ドライバーにはカーネルドライバーとユーザーランドドライバーがあるよ。

無知どうし罵り合うスレはここですかw

安い煽りは要らないから、貴方の溢れんばかりの知識をここで
存分に披露して下さいな

はい。結論。
Leopardは真の32bit OSでした。

まあ、上層レイヤは64bitだからどっちでもいんじゃね？
それより32bitマシンが32/64bit Universalアプリの64bitバイナリを開こうとして華麗に落ちる方が問題だよなあ

>>36
そんなこと起こる？うちの CoreDuo マシンで XCode 開いてもだい丈夫だけど。

Finderから開くと大丈夫だけど、ターミナルから開くと落ちる。
それとも俺がなにかミスってるのかなあ

やっぱり32bitなんだね。

32bit級。

Kernel processes will still run in 32-bit memory space.

iMacもWindowsみたいに認識してるメモリーは3GBだけなの？

OSごと落ちるのはドザのお家芸

>>42
旧機種はintelのチップセットの制約で3GB
OS Xの制約ではない

カーネルが32bitだと他の部分で足引っ張るってことやっぱりあるの？

>>38
それ、ちゃんとFeedbackしといて。
https://regist.apple.co.jp/feedback/macosx/

俺が10.5.3くらいになってからLeopardを導入する時までに、そういう地味な問題は
Fixしておいて欲しいw

ドザって1bitらしいね

またSHARPのミニコンポみたいな事言って…

NINTENDO64でLeopardは動きますか?

>>43
kernerlモジュールに不具合があればOSごと落ちる可能性はWindowsでもOSXでもFeeBSDでもLinuxでもSolarisでもなんでも同じようなもの。

>>47
ポーク…じゃねえか？

今はいいけど
来年以降Nehalemが出てから完全64bitOSにして欲しいな
この調子なら68kからPPCに移行期みたくいつまでたっても32bitのコードが残りそうで
足かせになるぞ

64bitのコードしかネイティブに実行できないCPUが出ない限り別に足枷にならないから。
32bit環境の問題はプロセス当たりのメモリ空間のみで、
16bit->32bitや68k->PPCの移行の時とは違って速度の問題は無い。
まあx86の場合論理レジスタが増えると言うおまけはあるけど。

gdgd言う奴は、カーネルが64bitじゃないと何が困るか書いてみろ。

>>54
仮想メモリが 32bit で動いているならアドレス変換のオーバーヘッドがあるね
ページサイズも 4KB なんでしょ

>>54
あと x86 に限った話だけど、64bit にするとレジスタ数が一気に増えるから
当然速度が速くなる

まあ、レジスタ増えてもそれを使ってなきゃ意味がないから、
64bit用に再コンパイルが必要だけどね。
ソース手に入れられないメーカー品は対応してくれるまで待て。
既存のソフトが早くなるわけじゃない。

kernel の話ですよ?

あと、命令を64bitにすると長さが2倍になるから、
その分メモリの使用量が増えてしまうね。

PPCG5がでたときに
「CPUは64bitでOSは32bitだけどスピードのロスはないよ」
って言ってたよな。あれも妄想ベンチ？

まぁ、32bitでも64bitでも、普通に使うぶんには何ら問題ないわけだし
Leopardが便利きわまりないものであることも、何ら変わりはない、、と。

>>60
PPC は x86 とちがってそういうものらしい

>>61
痘痕もえくぼって奴だな。

>>59
Instruction の長さなんて誤差の範囲じゃないの。
バイナリのサイズなんて頑張っても数十 MB だからね。

一方で long とポインタの長さが増えるのは確かに
メモリを消費するけど、物理メモリ搭載量も以前とは
比較にならない程増えているし、アドレス空間も広大。
メモリ帯域の事を考えても、引数をレジスタ渡し出来る
メリットに比べたら微々たるもの。

>>64
でもヒープなどは64bitにすると、オーバーヘッドは無視できないよ。
もちろん使用メモリが倍になっても、最近は乗り切れちゃうけど

個人的には、userlandは32bitで十分と思う。64bitが必要なのはごく一部
ただ、32bitのメモリ食いアプリを複数動かせる64bitOSは歓迎。
なんとまあ、普通の結論ですなｗ

ID: 2ZjCCQ2T0 はさっきから何を頑張ってるだろう

>>66
>何を頑張ってる
Vistaを64bitでインストールしてしまい後悔を隠したい、とかでないことを期待。

>>66
おかしなレスが飛び交ってるから、突っついてるの。
例えばさ、『ヒープを 64bit にする』って表現として意味不明じゃん。
普通はそういう風には言わない。64bit ってデータ長かアドレス空間の
大きさを指すのが普通じゃん。LP64 にしても使用メモリは倍になんか
ならないし、ちゃんと分かって書いてるのか心配だったのね。

まあこの板で似非技術用語を指摘しても意味ないかもしらんけど。

正直なところ、Intelの64bit実装はAMD64の劣化版なので、フル64bitにしなかったのは
懸命な措置だと思うよ。

>>56
>あと x86 に限った話だけど、64bit にするとレジスタ数が一気に増えるから
>当然速度が速くなる

これは嘘。確かにレジスタの数は多いが、現在のIntel版64bit実装だと、5個
ぐらいの汎用レジスタを同時使用するとストールするよ。AMDなら全然問題なし。

お前ら今ごろ何言い合ってるんだよ。圧倒的に64bitの方が高速だろ。
もっともLeopardは32bit OSだから恩恵も無いがな。ｗ
https://jndb.pc.mycom.co.jp/special/2005/compiler/010.html

>>69
>現在のIntel版64bit実装だと、5個
>ぐらいの汎用レジスタを同時使用するとストールするよ。

済まん。それは知らなかった。
gcc で 64bit でコンパイルすると普通に引数を
レジスタに積んでるけど、そんな罠があるのか。

Xeon でもそうなの?

64ビットOSという表現をやめて64ビット級OSという表現を使うべき。

>>68
Xcodeを32bitモードと64bitモードで動かしてRSIZE比べると約倍になってるよ。
オーバーヘッドの分速度もやや遅くなる。
>>69
増えるのは「見かけの」レジスタ数だからね。ハードウエア上のレジスタ数は変わらない。
64bitモードになると死んでたレジスタに火が入るわけではない。
「見かけの」レジスタ数が増える事によって生成コードが改善される分有利になる。

2コアだと、64bit級のCPUが二つで、128bit級だな(`･ω･´)

そもそもレジスタ数が云々、使用メモリサイズが云々なんて話は
カーネルが32bitか64bitかとは関係ない話。動かすアプリケーション次第。

汎用レジスタが増えると言ってもソフトウェアから見えるレジスタが増えてるだけだから
実際に効くかはフロントエンドのリネームのロジック次第で何とも言えん

まあ遅くなる要素はコンテクストスイッチのオーバーヘッドぐらいで
速くなる可能性の方が高いけど。

>>71
Xeonでも同じ。
MSがAMD64実装のほうをWindowsでサポートすると発表したためにIntelがあわてて
自社の32bitCPUにAMD64の64bit命令を「解釈できる」機構を無理やり導入したのが
混乱の発端。

だもんで、例のサプライズはAMD搭載機の発表だと思ってたんだよね。Core2で
64bitOSなんて悪い冗談みたいだから。

現状でAMDの採用とかあり得ないでしょ。
いくらCore MAの64bitモードに不備があるとはいえ、絶対的に遅いものを採用する意味は無い。

>>49
メモリを512MB積むため、メモリー拡張パックを買い占めろ。
インストールメディアは64DDな。

>>73
>RSIZE比べると約倍になってるよ。

Xcode じゃないけど、手元のコードではそうはならなかったよ。
ヒープのデータが全て long か pointer なプログラムなんて
そう無いと思うけど。

>>77
さんきゅ。今度 Xeon マシンを借りられるので、実際に試してみます。
確かに悪い冗談というか悪夢だね。

>>78
64bitモードの不備は来年発表のNehalemで解消されるらしい。

>>80

じゃなくて、ヒープなどは管理そのものにポインタ使ってるでしょ
小さいサイズでアロケートの回数が多いアプリは、もろに64bitで重くなるよ？

>>82
>じゃなくて

何じゃないんだよ。省略せずにきちんと書くようにしなよ。
俺は重くならないなんて書いてないよ。

1. 他人のレスをちゃんと読む
2. 投稿する前に自分のレスを読み直す

これだけで他人との会話がだいぶ変わってくると思うぞ。

2chで何を言ってるんだ？

>>83

言葉足らずでｽﾏﾝね

>>ヒープのデータが全て long か pointer なプログラムなんて
>>そう無いと思うけど。

に対する、「じゃなくて」って意味。

現実にはヒープのデータだけではなく、
アロケート回数に標準ポインタサイズがかなり影響するという話。

>>85
それを俺にレスして何が言いたいのか分からないよ。

1. アロケータ内の pointer 変数とプログラム用の pointer 変数を区別しようが
しまいが、元レス (>>80) の趣旨には影響しない（int も char も絶対使わねえよ
というのなら話は違うけど）

2. Resident の SIZE にはアロケータ用の pointer も含まれるから、元々ヒープの
データだけを見ているわけではない（RSIZE って break した領域のサイズだよね?）

3. それがそんなに気になるなら Hoard とか別のアロケータを試してみたら
良いんじゃないかな（メモリの利用効率について比較したペーパーがどっかに
あったと思う）

>>86

>>85だけど、俺は>>73とは別人だよ

>1. アロケータ内…
それは当たり前の話。
>2. Resident…
これも当たり前の話。

>>80の、
>Xcode じゃないけど、手元のコードではそうはならなかったよ。
という、ひとつのサンプルは、

>>73の
>RSIZE比べると約倍になってるよ。
という別のサンプルを否定できない。

なのに、
>ヒープのデータが全て long か pointer なプログラムなんて
>そう無いと思うけど。

「そう無い」って結論は強引かな。

>3. それがそんなに気になるなら Hoard とか…
これはまた別の話だな。

俺自身は、フル64bit化って、結構メモリの経済感覚が変わるって言いたかっただけだけど…

>>78
残念ながらピュアな64bitコード（汎用レジスタ使いまくり）の土俵では、桁違い
とまではいわないがAMDの圧勝になる。AMDは64bitモードで処理効率が上昇することは
あっても低下する要因がゼロだから。Intelが1だとするとAMDが1.5〜2.5ぐらい
じゃないかな。

逆に32bit環境だとIntelが強くなる。だから32bitOSのままにとどめたLeopardは
英断だと思うんだよ。

あむむし

>>88
書いてて恥ずかしくないか？

>Loepardは、64ビットのパワーを発揮する万能オペレーティングシステム。
http://www.apple.com/jp/macosx/technology/64bit.html

>>88
ただどっかで完全ピュア64bitOSになる時がこなきゃ
その時はMac OS X10.×じゃなくMac OS11になると思うけど

>>91
いずれは確実にそうなるだろうけど、
将来OSXのインストール対象リストから32bitマシンが完全に消えるまで、
なんだかんだでゆっくりやりそうな悪寒
これまでも徐々に段階的に、って進め方だったし
今回の拡張で当面の状況は凌げそうな感じでもあるし

そのときにはまだOSX10.xを名乗ってると思う

そういえば http://www.apple.com/jp/macosx/technology/64bit.html に書いてあることが
ちょっと気になった。

>仮想メモリで最大16エクサバイト
単に64ビットだからということか。Mac OS Xで実際にアドレス可能なユーザ空間は
もっと小さいのだが。

>物理メモリで4テラバイトの64ビットアドレス指定
4テラって何? 42ビットだねえ。ということは単にG5でアドレス可能な範囲のことを書いてる?
今使われてるCore 2って確か36ビットじゃなかったっけ?

>>88
適当なことを言わないように。
つーかDPレベルだとIntelが圧勝しないベンチを見つける方が難しい
64bit環境での比較 (Harpertown vs Barcelona)
http://techreport.com/articles.x/13224/4
http://techreport.com/articles.x/13224/5
http://techreport.com/articles.x/13224/6
http://techreport.com/articles.x/13224/7
http://techreport.com/articles.x/13224/8

というかピュアな64bitコードって何だよw
64bitアプリケーションに含まれる(dynamic linkされる物を含む)コードは
LinuxやMacOSのように32bitと64bitが混在する(できる)環境だろうが
64bit Windowsのように64bit only(除ブリッジ)の環境だろうが
全部64bitのコードだから。

>>95
＞LinuxやMacOSのように32bitと64bitが混在する(できる)環境だろうが

ttp://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6
>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.)

???
そこに書いてある通りだけど。
つーかコードレベルでは混在してないって95に書いたのを読んでないのか?
Tigerも64bit APIがLeopardより少ないだけで同じ。

そもそもこんな当たり前のような話を説明しなければならんのは
68kからPPCの過渡期に68kのToolbox APIがネイティブのPPCバイナリから
MixedModeManagerを介して呼び出されていたという過去があるからかね?
だから当時はシステムの一部に68kコードが残ってPPCの最適化が...という話になった訳だが。

現在の32bit環境と64bit環境の混在は、MixedModeManagerのような仕組みを使った物ではなく
完全な「並立」。だから64bitでアプリケーションを作った時点で
現行のOSXに32bitのシステムが存在する事によるオーバーヘッドを気にする必要はない。

強いて言えば、IPCでオーバーヘッドがある場合はあるかも。

>>97

「64bitアプリケーションに含まれる(dynamic linkされる物を含む)コードは全部64bitのコードだから。」
はどうでもよくて、

「LinuxやMacOSのように32bitと64bitが混在する(できる)環境」
「64bit Windowsのように64bit only(除ブリッジ)の環境」
の意味がよく分からんかった。
アプリの話をふりつつここはカーネルの話をしてないかい？
そんだけ。

苦しくなると話をそらすのはドザチョンズによくあること

>>100
いや、どっちもアプリケーション(提供されているAPIレベル)の話だけど。

>>102
もしかして「(除ブリッジ)」ってWindows on Windows64を除くって意味？
ttp://ja.wikipedia.org/wiki/WOW64

そんなもん、Windowsno設計が悪いだけの話じゃない
アホだ

どう考えてもOSが32bitで、アプリが32bitと64bit混在のMac OS Xの方が過渡期の状態だろ。
Win64のWOW64は完全64bit環境で32bitアプリを動作させるエミュレータなんだから。

64bitと32bitの違いって、シングルCPUとマルチCPUの違いと実質的に
つながる所があると感じるけど、このあたり詳しい人いますかね。

つまり32bit-CPUを2セット「並列処理」できる状態と64bit-CPUひとつと
同じ機能ではないのかと。時代が次第にマルチコアCPUの方向にシフトしてきている今、
スレッド処理をいかに無理なくスムーズに処理できるかに重点が移ってきてると思う。

>>106
完全に勘違いというより抜本的な理解不足。小学校からやり直せ。

>>107
32bitとか64bitとかの本質的な違いを説明したサイトがうまく見つけられんのよ。
どこもかしこも「64bitであるか32bitであるか」の言い合いばかりでね。

CPUの処理の幅が64bitか32bitかの違いであるのなら、マルチCPUでこれらの
違いは一挙に意味を失うのではないのかと感じる。
それともメモリ空間のアドレスの大きさを言ってるのかしらね。

なにいっってやがるんだよw
64bitになったら、64bitマンセーしてるよwwwwwwwwwwwwwwwwwwwwww

こうなると、何を持って「xxxビットのOS」と言うのか...。
そうゆうのはだんだん意味を持たなくなるのかな。

やっとそれっぽい記事を見つけた
これのことかねぇ
ttp://journal.mycom.co.jp/column/sopinion/001/index.html


どうやらCPUの一括処理の単位およびメモリ空間のアドレス空間の大きさ
双方を指し示しているみたいですね。

>>103
そうです。

まあそういう意味で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
まぁ大半の人はエロサイトだろうな

32bitよりも64bitのほうがモザイクが薄くなるんだ。

WWDC

Leopardは64bit APIを備えたOS。
以上。

実際、64bitでの一括演算というのは1.8x10^19程度を上限とする
整数の四則演算が一挙にできるか、というレベルの話なんですかねぇ。

いろいろ巡ってみても、まだよくわからん。

演算器の幅に関して言えば、32bitでいうlong long型を使う必要があるような場面で
少ないクロックサイクルで終えられるという程度の利点。
そもそもそんな場面はほとんど無いし、SSE2があれば32bitCPUでもできるし。
AltiVecではできないけど。
そもそもこれに関してはOSの64bit化とはほとんど関係ない。

>>120
そうでしたか、ですとOSの64bit化というのは具体的にはメモリ空間が
64bitで管理できるかどうか、あたりの話になるんでしょうかね

http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/

http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/indications/chapter_2_section_2.html

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.

なんか微妙な言い方だけど、
要するに64bitじゃないことの言い訳かな？

なんかもの悲しいスレだな。

>>123
これはあと数年は 64bit 化しないよという宣言なのかな
ちゃんと Myth #5 で Intel では 64bit 化した方が速くなる事を
認めているのに何で Myth #2 で余計な事を書いてしまうんだろうか
分かってて手を抜いたんだから、言い訳する必要なんか無いのに

でも、Tigerではカーネル部分が64bit対応だって言っていたよね。
だからTigerでは64bitのアドレス空間がサポートされたと聞いたが。
そしてLeopardではCocoaなどが64bit対応になったって話なのだろう。

>>126
いやだからアプリケーションレベルで64bit化してればいいわけで
カーネル自体が64bitプロセスになっても個々のアプリケーションのパフォーマンスは変わらんよ

いい加減理解しないかね。

>>127
仮想メモリが 64bit アドレス空間を扱える様になるのと
カーネルが 64bit で動く様になるのとは、天と地ほどの
差があるよ。今の Mac OS X は前者のみ。現代において
後者が出来ないのは純粋技術的にはかなりダサイと言って
差し支えない。まあサーバ用途で使う OS じゃないから
実質的な問題は無いと判断したのでしょうね。1,2 割の
性能ロスくらい構わない、と。

>>128
>カーネル自体が64bitプロセスになっても個々のアプリケーションの
>パフォーマンスは変わらんよ

理屈で考えたら分かると思うけど、カーネルのレスポンスが
速くなれば当然アプリも速くなるよ。sys が全く発生しない
ページングも絶対しない、スケジューラの影響も受けない様な
アプリなら君の言う通りかもしれないけどね。

>>130
それは99の言うIPCとかコンテクストスイッチのようなプロセス間の相互干渉が
クリティカルに影響してるようなケースの場合。さもなきゃ体感は不可能でしょう。

それも、カーネル自体が64bitで動いてるかどうかよりは、実装に依存する話。
あまり変な幻想を抱いてると、本当に64bitカーネルになった時に落胆するよ。

>>131
俺は↓これが間違いだって論理的に理解して貰えれば
何でも良いよ。

>カーネル自体が64bitプロセスになっても個々のアプリケーションの
>パフォーマンスは変わらんよ

それに 64bit で動いているかどうかも実装の問題だよね。
普段は純然たる 64bit Kernel な OS を使ってるので、
ページスキャナが long long でメモリを舐めていると
考えると悲しくなるよ。

つうか気付いてなかったけど、俺ずっと age てたね。スマソ。

ところで
x64で64/32の混在だと、CPUはMixed Modeで動作することになるんだよね？
それによる速度低下はどの程度？

>>131
>それは99の言うIPCとかコンテクストスイッチのようなプロセス間の相互干渉が
>クリティカルに影響してるようなケースの場合。

一応書いておくけど、プロセス間やスレッド間でリソースの取り合いが
発生しているかはこの場合全く関係無いよ。何でそう思ったのか知らんけど。

そもそも Myth #5 で書かれている、関数呼び出しの際に引数がレジスタに
積まれて渡されるから速くなるという所から俺の話は始まっているんだけど、
カーネル内の関数コールが速くなれば、カーネルサービスに依存している
アプリの処理性能も結果的に上がるという話だからね。

Do you understand?

>>135
いや...だから何でシステムコールがアプリケーションの速度を律速するようなケースが前提になってるの?

forkとかmallocで飯を食ってる人だから

>>136
律速するかどうかは関係無い。全体のフローの中で時間を短縮
可能な箇所があれば、全体に掛かる時間も短くなるというだけ。

例えば家から会社までの道のりで考えると、家から駅まではバス、
駅から会社の最寄り駅までは電車、そこから事務所までは徒歩で
行くとするよね。今まで各駅停車に乗っていたのが、新しく
急行電車が並走する様になりました。急行に乗ったら通勤時間が
短くなりました。

この電車が I/O だったりメモリ要求だったりのカーネルサービスね。
各駅停車は 32bit Kernel, 急行は 64bit Kernel だと考えてみ。
勿論、通勤時間はアプリの処理時間に相当するよ。

まあ本当にどうでもいい事だと考えているのなら今後appleが64bit kernelを採用する事は全く無いだろうね。

俺は採用すると思うけど。

>>138
自分で1割2割ロスしてると言ってるでしょ。
そんだけパフォーマンスを上げるには、明らかにシステムコールが処理時間の相当量を占めてなきゃ不可能。
超多めに見積もってカーネルの64bit化でカーネルサービスに費やす時間が半分になるとしても
処理時間に占める割合は1割ロスで1/8、2割だと1/3だよ。
どう考えても律速してるし、現実にそんなケースは無いよ。

ごめん1/8、1/3じゃなくて1/9、1/4だった

>>140
割とどうでも良いところに噛み付いたね。

>どう考えても律速してるし

俺は律速していないと言ってるんじゃなくて、
「律速するかどうかは関係無い」って書いたと
思ったけど。
あと、1,2 割は sys の 1,2 割と読んでくれ。
これはスマソ。sys の割合は俺の経験上は
10-50% くらいが一般的かな。10% 以下なら
かなり優秀なアプリだと思う。

で、結論としては処理速度は上がるで良いかな?

>>142
50%が一般的てどんな状況だよw

まあ Vista あたりが 64bit 化にあたって糞みたいな実装をしてきたのに対し
アプルは随分クールで現実的な解決策を持ってきたと思うよ。
>>139 とか >>138 は >>140 の書いてあることをちゃんと理解してから
反論してくれよな。ymuEzXkQ0 は、

>カーネルの64bit化でカーネルサービスに費やす時間が半分になるとしても

という相当な無理がある仮定をしても、結果的にプロセス全体への影響は
少ないということを言っている。eG/Kxnw50 はカーネルの 64bit 化で
OSサービスが現実的にどの程度早くなると見込んでいるのだろう？

>>143
やぱり fork と malloc で飯を食ってる人なのかもw

処理速度を気にしない処理ほど改善が大きくなりそう。
ベンチマークで比較されるような処理は普通%sysが非常に小さくなるから
一般ユーザが実際に恩恵を受けるような場合はあまりないだろうね。
それをふまえてAppleはあんな風に書いたんでしょう。

>>143
もう、どうでも良いところにしか突っ込めないのね…
I/O とか Network に依存するアプリは結構 sys 出るよ。
細かいパケットを送受信したりする作りだとね。

>>144
君がスレの流れを読んでくれ。64bit 化しただけで
倍速くなるくらいなら何年も前に皆そうしてるよ…
どれだけ速くなるかではなく、確実に速くなるという
話をしているんだよ。

>>146
それにしても「一般的なアプリ」で見込まれる%sysも大きいし、
eG/Kxnw50　がカーネルの64bit化で見込んでいる速度向上率について興味ある。

話を元に戻すけど、俺の話は↓これが間違っているという事。

>カーネル自体が64bitプロセスになっても個々のアプリケーションの
>パフォーマンスは変わらんよ

それだけの事を理解させるのにこんなに説明が必要とは思わなかったよ…

>>147
>I/O とか Network に依存するアプリは結構 sys 出るよ。

何で%sysが大きくなるか考えてくれないと…
これらが 64bit化でどの程度高速化できると思う？

これと引き換えに失うものを考えたら、アプルの実装はかなり理に適っている
と思うけどね。

>>150
>>149 を読んでくれ

1. Apple の実装が間違ってるとは言っていない
2. どの程度高速化するかはまた別の話

2 については君は不満なんだろうが、>>149 に決着が付いたら
そっちも相手してあげるよ。ホントはもう寝たいんだけどね。

>>149
>>話を元に戻すけど、俺の話は↓これが間違っているという事。

いや、だから ymuEzXkQ0 が言いたいのは、カーネルの 64bit 化は、
アプリの処理速度への現実的な影響は殆どないということでしょ。
（オレはymuEzXkQ0じゃないから推測だが）
現実的に見て間違っているとは言いがたいなぁ。

アプリの%sysと、64bit カーネルの速度向上（ホントにあるの？）
をどの程度見込んでいるかによるけどね。
殆どあり得ない数字を前提にするなら、それはまた別の話。

>>151
いくら言ってもコーナーケースの話をされて終わるということは分かったので
もう寝てくださって結構ですw

I/OとかNetworkなんてそもそもCPU時間を使わん処理は
%sysが改善したところで処理時間に差はでない

>>152
俺は fork とか malloc で飯食ってるから、君の現実感とは違うんだろうな。
1 sec でも速くなれば、それは処理速度が向上しているという事だよ。

実際 32bit の VM で 64bit のアドレス空間を捌くオーバーヘッドはかなり
大きいと思うよ。まあ 1 割速くなる程度じゃ現実的じゃないと言われるかも
しらんけどね。

>>153
カーネル内関数コールがコーナーケースな人には
カーネルの話は無理じゃないかな。

やべえ適当に言ったら当たった
そういう玄人さんはここに来て素人に講釈垂れるだけ無駄だと思うよ
感覚からして合わないだろうし

>>154
>NetworkなんてそもそもCPU時間を使わん処理は

Ethernet から Socket Buffer まで、ずっと CPU 処理ですよ

良い加減まんどくさくなってきた...

>>144
Vistaの64bit実装のどの辺が糞なんだろう？
Solaris8やLeopardあたりと比べるとまだましな部類に入ると思うんだが。

それで、カーネルが64bitになれば、
iPhotoとかのアプリが1割速くなったりするのかな？
そこが重要だとおもうんだけど。

>>159
既に感情論の領域に入っていますので、まともな反論は難しいものと思われます。ｗ

>>161
なるほど。要はなんでもいいからLeopard以外は糞と言いたかっただけなのね。了解です。

APIが64bitってどうゆう意味ですか？

>>159
>Solaris8

Sol 8 って何か問題あったのけ?
だいぶ昔だから、どんなだったかもう忘れちゃったけど。

カーネルの内部関数あたりの話そのものを述べると少しかじったくらいの
人では少し追いつけない話になりますわね…。
なかなか64bitというものを具体的に解説した書物がなさそうな状態で、
なんとなく64bitはすごいというイメージが一人歩きしてるのではないかと
自分的には思うけれどどうなんだろう。

倍以上の性能になるといえばそういうわけでもなさそうですよね。

>>164
正確に言うとSol7からだな。Sol7は2000年問題の対応時期と重なった関係で特に企業でスキップしたとこが多いから8で
問題が顕在化したところが多いんじゃないだろうか。

OBPアップデート、/proc問題、Largefile問題etc...導入規模が大きな所ほど影響が大きかったような気がする。特に
ドライバの揃わなっぷりはx64Windowsの比じゃなかった。

そもそもｘ64で32ビットカーネルで64ビットアプリって動くの？
64Bitのロングモード使う場合は64Bitカーネルが必要では？

PowerPCは知らんけど

話をぶったぎってすまんけど、自分で Darwin のソースをとってきて、
64bit モードでコンパイルしててもとのカーネルと置き換えてウハウハ、とか
できるの？

http://journal.mycom.co.jp/photo/articles/2007/11/20/iul00/images/001l.jpg

ttp://journal.mycom.co.jp/articles/2007/11/20/iul00/index.html
どうせならこの方がいいだろう。

Machカーネルも32bitと64bitの両方のモードで動作するってことだろ。

あと、32bitのWindows95でも16bitアプリが動作したから。って言ってるけど、
それって今回の場合と違うだろ？　32bitWinで64bitアプリが動作するか？
16bitWinで32bitアプリが動作したのか？

>>167
動く。

そういえば、Leopardは完全64bitだが、32bitドライバも問題なくシームレスに動作が保証されて
いるから、下位互換性に関しても全く問題無いなんて主張している奴もいたな。全てが空しい。ｗ

>>171
違うだろ、UniversalBinaryの仕組みで、32bitと64bit両方のアプリが環境に応じて自動で
選択起動されるってこと。

要するに64bitのメモリアドレスをネイティブで取り扱えるかどうかという話？

ロングモードの場合、割り込みハンドラとかは64 bitモードで動かす必要があったはず。
まあそれ以外のMachカーネルはほとんど互換モードで動いてそうだけど。

>173
環境に応じてそれぞれのモードで起動する、
だから違うという話に何故なるんだ。

>>167
俺もそこが分からん。

x64の3つの動作モードを知る (1/2)
ttp://www.itmedia.co.jp/enterprise/articles/0506/27/news008.html

32bitカーネル＋64bitAPIのLeoの仕組みは、
上記のTable2のどれにも該当していないように思える。

>177
>32bitカーネル＋64bitAPIのLeoの仕組みは、
そもそもこれから違うのだと考えつかないのかよ。

>172
動かないよ。
なんで間違ったこと断言できるのか不思議なんだが。
x64の互換モードは、64bitカーネルと互換モードで32bitが動く。
32bitカーネルから互換モードで64bitは出来ない。

http://episteme.arstechnica.com/eve/forums/a/tpc/f/48409524/m/811002208831

http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/678006608831

ふたつめで LordHunter さんが明快に答えているようだ。
彼の情報の出所がわからんけど。Oct 20 って発売前だから、NDA やぶってるんだろうね。まあいまや Darwin のソース公開されてるので。

>>1のチェスしか64bit化されてないという指摘だけど、以下の
Apache 2、MySQL 5、Postfix、Podcast Producer、QuickTime Streaming Server、Java VM on Intel
これらは、サーバー版では64bit版が採用されてる。サーバー版も基盤は同じだよ。

同時に処理なんて無理だろという人も結構いるみたいだから、
参考になる記事を探してみたけど、こういう例があるよ。

着実に成長を重ねる64ビットLinuxとBSD
http://opentechpress.jp/desktop/05/04/06/059213.shtml
>AMD64のワークステーションやサーバシステムを販売するようになった。
>だがおかしなことに、その大半は32ビットOSをデフォルトでインストール
>して出荷している。AMD64アーキテクチャは64ビットと32ビットの両方の
>ソフトウェアを快適に（しかも同時に）処理できるにもかかわらずだ。

この記事の続きは、主にAMD64（まあx64)とUNIXの記事だけど、
OSXの対応を考える上でも参考になるかな。

因みにTigerの時の文書だけど、LinuxやBSDのカーネルと同じLP64モデルを採用してる。
http://developer.apple.com/macosx/64bit.html

ドライバの問題をどう解決したのか（iokitがクッションになってる？）、
それは個人的にも興味あるけど、32bitカーネルでx64を利用して64bitアプリを
動かしてるという理屈がこのスレで成り立ってるのは驚いた。

>>182
サーバー版では64bit版が採用されているということは、
つまり、クライアント版では32bit版ということかね。

基盤は同じだというが、きっとアプリに互換性問題が発生して
カーネルを32bitで動かし、その為にそのほかのソフトも
32bitとして動かしているのだろうね。
チェスだけはうまく動いたのかな？

Chessに64bitバイナリを用意したのはサンプル的な意味合いが強いでしょ。

未だにCarbonで動いてる中核アプリが多いんだから少しずつ移植していくしか無いと思うけどね
チェスしか無いのはとりあえず組みやすい小さいアプリで実証しただけの事でしょ

>>184
32 bitカーネルの定義の問題なんじゃねーの？

ttp://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/intro/chapter_1_section_1.html

この文章は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)もいるというだけじゃなかろうか。

>>187
移植されていないのではなく、64bitのバイナリとしてビルドされたアプリをあえて
入れてないだけ、と考えるのが妥当では? フレームワークとかはほとんど64bitの
バイナリが付いてきてるんだから。

>>180,188
なるほどー
凄い参考になった

なんか、よくわかんないけど、32bitってことですね。

mach_kernelより上位のｘ64ロングモードで動くカーネルがあるってことか・・・

>>191
正確には、32bitカーネルと32/64bitライブラリのハイブリットOS。
32bitコードが完全に消えるには、CoreDuo機の切捨てが必要だし、あと10年
ぐらいは掛かるんじゃないかな。

>>192
>mach_kernelより上位のｘ64ロングモードで動くカーネルがあるってことか・・・

上位の人などいないw

>>193
じゃあ10年はむねをはって32bit OSっていえばいいんだよな。
64bitだ！なんて恥ずかしい事をAppleはかかなきゃいい。

>>195
しかし、MSもWindows95で16bitコードを多数含みながらも胸を張って
『うちは32bitOSです』と自慢していたから、別にどうでもいいのではないか。

>>193
64bitなカーネル自体はもっと早く出てくるだろ、Appleが出す気があれば。
カーネル自体をハイブリッドにして32bit機をサポートするとかできるだろうし。

まあ、Microsoft / Apple がマーケティングのために "32bit" "64bit" とレッテルづけして売ってるのと別に、
実際にそれぞれのカーネルがどういう仕組みで動いているかを認識するのはいいことなんじゃないかな ...
実情は "32bit" "64bit" とひとことであらわせない点がいろいろあるわけだし。

Leopardは32bitと64bitを自動識別して動くOS。
Vistaは64bitの中に32bit互換環境を作ったOS。

どちらも64bitOSと名乗っても別におかしいところは無いよね。
要は定義の仕方の違いであって、このぐらいの誤解は誤差の範囲内と
思ってもいいのでは。

>>194
mach_kernelのプロセスが32Bitだったら・・・
やっぱり上位の64Bitカーネルがいるような・・・

>>200
>>180-181を参照
単純な意味での32bitカーネルではなく、最低限必要な部分は64bit対応のための
工夫がなされている模様

これらの内容って既に Panther の時の実装で、Leopard になった今の時点で
誤解も含めこんなに揉めるのかがよくわからない。

64bit プロセスと 32bit ドライバの関連に関しては、
http://developer.apple.com/jp/technotes/tn2090.html
が参考になると思う（2003年6月の記事だが）
簡単に言えば、32bit のドライバを 64bit プロセスでも使えるように
工夫がされているということ。

アップルは Panther の時点で過去の（32bit）ドライバーやフレームワークを
64bit のシステムにフィットさせるか方向性を示すとともに必要な修正を即し、
Tigher で 64bit プロセスを 32bit プロセスが共存する機構を実装し、
Lepard で 64bit Cocoa フレームワークなどを実際に実装し、
段階的に 64bit 環境が使えるように整備してきた。

>>165
単純に 64bit化＝高速化ではないですね。64bit 化はコストがかかるのを
忘れてはいけないでしょう。Intel の場合はここに命令の拡張があるから
話が厄介になるのでしょうけど。

>>166
>>183
個人的に、教条主義的に 64bit 化を進めない、アップルの開発方針に賛同します。
多くのコンシューマーユーザーでも 64bit 化のメリットを得られる上に
デメリットは最小限にとどめようとしているように感じます。

>>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.
と書いている。

http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/64bitPorting.pdf

- 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.

このスレ見てたらバイクの「ナンシー」を思い出した。
ttp://homepage3.nifty.com/gakira/nancy.htm

コンピュータを使ってたら「ナンビット」が寄って来たりするんだろうかw

>>202
それって、ドライバに関しては詭弁もいいとこだよな。64bitプロセスでも使用できるように
変更された32bitドライバだけが正常に動作すると言う事であって、既存の32bitドライバが
修正なしでの動作を保証しているわけじゃないしね。だいいちカーネル内のIOKitドライバは
いまだに32bitだろ。

64bitっていうのは、メインメモリだけでなくIOなど外部にも64bitの
アドレスを持たせて操作するのですかね

>>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版が採用されてる。
ことで明白だと思うが。

あと Xcode もふつうに 64bit アプリですよ。

MacBookProに搭載可能なメモリーはいくら

>>206
>64bitプロセスでも使用できるように変更された32bitドライバだけが正常に動作すると言う事であって、既存の32bitドライバが
>修正なしでの動作を保証しているわけじゃないしね。だいいちカーネル内のIOKitドライバはいまだに32bitだろ。

というか、その文書は 2003 年でパンサーのときだから、それ以前の 3rd party kext で未だにそのままってのはないでしょ。そんなものがあったら ppc でしか動かんし。

Apple はじゃんじゃん前のバージョンのソフトが動かないようにするので、ある程度の書き換えはしかたがないかと。

http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/64bitPorting.pdf

- 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.

>>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.

>>213
>32bitOSで32bitドライバがそのまま動いたからなんだって言うんだよ。
Most device drivers (those written using I/O Kit families) work unchanged
when used in conjunction with 64-bit processes.
わかる？

>それにその下も引用すべきじゃないの？
それが何か？

>>159
>>195
>>196
>>199
Leopard（の実装）は 32bit か 64bit かユーザーは全く気にせずに済む。
OSとしては 4GB を超えるメモリを扱え、アプリケーションや
ドライバーが 32bit か 64bit かも気にせず、ただインストールすればいい。

http://www.winvistacafe.com/edition/topics06.html
>使用者が64bit環境を意識せず使えるようになるのは、次の次の世代くらいになりそうです。

今はまだよく理解できないけど、保存に値する良スレのような気がする。

>>215
>Leopard（の実装）は 32bit か 64bit かユーザーは全く気にせずに済む。
いまどき意識するOSって珍しくねぇか？
SolarisだってAIXだってLinuxだって使う分には意識なんてしてないぞ。

ビルドが必要な時に64bitライブラリとリンクするか32bitライブラリにリンクするか気にするけど、どれも同じようなもんじゃねぇの？

Vistaは思いっきり64bitか32bitかを気にしないといけないようだが。

>>218
217 は暗黙に Windows は OS ですらないと言いたいんではないかと ...

>>217
>SolarisだってAIXだってLinuxだって使う分には意識なんてしてないぞ。

前出でちょっと古い記事だけど
http://opentechpress.jp/desktop/05/04/06/059213.shtml
こんなのも
http://opentechpress.jp/developer/06/05/19/0241229.shtml

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 が読み込めなかったんだけども ...
いつアップデートがでるのかな。むむ。

>>220
なるほどね。ブラウザにプラグインかー。
ちょびっと気にする必要があるかもね。

#AIXで32bitブラウザか64bitブラウザかなんて気にした事が無かったよ。

flash plugin
java plugin
は64bit出してねえだろ、確か

Windowsの場合，64bitネイティブのアプリは倍増したレジスタが使えると喧伝
してるけど，Macはしてないな。
やはり開発者の思いとしてはPowerPCこそが全てだからか。

>>24
ドライバのサポートとMSの熱意か

>>221

それはPPC/Intelの時と同じ。
OSバンドルの新しめのPrinter Dialog Extensionなんかも64bit対応してる。これ3rd party製だよな。

>>225
MSはサーバーでは殆ど64Bitに移行済みだし、
クライアントもVistaから64Bitに力入れてるよ。

WindowｓVistaの認定ロゴはｘ64版での動作が必須。
ということで、なにげにVista対応版はｘ64版も対応
最新プリンタとかもドライバが揃ってる。

>>227
>WindowｓVistaの認定ロゴはｘ64版での動作が必須。

世の中は 32bit 版が殆どだし、実際に今必要なのは 32bit 版があれば
十分だけど、MS が 64bit 版ドライバを開発させるための圧力の１つ
として使った感じだよな。＞認定ロゴ

それぐらいの圧力をかけないと、誰も64bit用のドライバなんて作ってくれないよ。
ただでさえVista64はシェアが少ないのだから。
だからみんなVistaを嫌がってXPを使っているのだろう。
DELLとか見てごらん。未だにXP搭載モデルなんて販売している。

>>213
G5には面白い仕組みがあったんだよね。

ソフトウェアの進化ってほんと遅いよな。
未だに32bitOSばかり。

32bitが一番バランスが良いからじゃないのか？なんとなく
核爆弾の起爆装置も32個だし

他のOSも含めて今は、32bitから64bit移行の過渡期だからね。
でも、32bitから64bitへの移行のメリットが、16bitから32bitへのメリット
ほどの魅力が感じられないから、移行は今後ゆっくりと行われるのだろうな。

>>233
メモリ４G以上使いたい場合は64BitOSが必要だから
メモリ暴落がこのままなら急速に進むと思われ・・・

32Biｔアプリだけ使う場合でも64BitOS側はメモリを
キャッシュに使えるので大きい

しかし、32bit用のドライバとの互換性問題があるだろう。すんなりと
64bitに移行するとは考えられない。まあサードパーティーの努力しだいとでも
言っておこうか。

それに、メモリの暴落は一時のものと思われるのだが。どうせ新しい規格である
DDR3が主流になる頃にはまた値を戻すだろう。

折角メモリが安くなってるのに、その安いメモリをたった 3GB〜4GB しか
積めないのが痛い。2GB で１万円しないんだから、8GB〜16GB とか
積めば、Leopard のメモリ管理がもっと生かせるのに。

>>237

"たった"？？？

Mach は元々広大な粗なメモリ空間と、運用に対して十分なメモリ領域と、
２つや３つでない多数のマルチプロセッサを生かすよう開発されている。
http://ja.wikipedia.org/wiki/Mach

当時は２つのプロセッサ、128MB の実メモリと 4GB のメモリ空間は
十分と言えたが、GUI や数百 MB〜数GB の動画、数万ファイルの画像
を一般的に扱う今は、２つのプロセッサ、3GB の実メモリと 4GB の
メモリ空間は mach（や最近のモダンな OS）の設計を十分に生かす
量ではないと思ってる。

たった数GBの SSD に何万も払って高速化するより、十分な主メモリを
積んで、OS の特質を生かしたほうが、なんとかSuperFetchとか、
なんとかReadyBoostとか、なんとかReadyDriveみたいな場当たり的な
技法よりずっとスマートな解決策だと思うのだけど。

>>229
>DELLとか見てごらん。未だにXP搭載モデルなんて販売している。

DELL だけじゃなく、色々な企業がまだ出しているね。
企業での購入でも Xp 指定がまだまだ大多数らしい。

それどころか、VIstaも32bitがほとんど

Macの世界はまだ仮想化が熱心じゃないけど、他のOSは仮想化ビジネスに
熱心だから、64GBとか乗るマシンのために64bit化はすごいメリットがある。
箱庭の中は32bitでもいいさ。

うちの会社もマシンの統合で64GBマシンを複数導入して使ってかなり便利。

いまiMac使っていて、メモリー4GBまでしか使えないんだけど、
MacProとかに変えれば、もっとメモリー使えるようになるよね？
スワップしないくらいメモリー積んでみたい(´･ω･`)

>>239
> たった数GBの SSD に何万も払って高速化するより、十分な主メモリを
> 積んで、OS の特質を生かしたほうが、なんとかSuperFetchとか、
> なんとかReadyBoostとか、なんとかReadyDriveみたいな場当たり的な
> 技法よりずっとスマートな解決策だと思うのだけど。

十分なメモリをつんでいたとしよう。
その状態でマシンを起動して、はじめてアプリを起動したとき
その起動が早くなるかね？

>>244
ファイルシステムの先読みが賢ければある程度は

> ファイルシステムの先読みが

MacOSXに搭載されている（？）
そのファイルシステムの先読みとは
いったいどういうデータを先読みしてくれるの？

これではドザ共を馬鹿にできないではないか。
なんたる体たらく。

>>246
もちろん

>>248
答えになってないぞ。
どういうデータを先読みしてくれるんだ？
ソースありで教えてくれ

何で質問者がそんなに居丈高なんだ?
ファイルシステムが読むデータなんて決まってるだろ

決まってるなら教えてくれよ。

たとえばよく使うプログラムを先読みしてくれるのか？
それぐらい賢いのか？

そんなわけ無いじゃんw

どうせ先読みするのなら、
よく使うプログラムまで
先読みしてくれたらもっと良いと思わない？

じゃあ起動時に全部アプリを実行すりゃいいって事で。

それじゃ、起動時が重くなるじゃん。
こういうものはCPU・HDDの空き時間に読み込むものでしょ？

OS、アプリの初回起動の遅さが我慢できないってどんだけー、と思うけどな。
OSなら使わないときはスリープしときゃいいし、
メモリ大量に積んでるんなら、アプリも常時起動しとけばいいしね。
まぁ、流石にVistaクラスの遅さだと我慢できんけどねw

>>243
16GBだが、FB-DIMMだからちょっと高く付く。
とはいえ、ノーブランドでよければ12万ちょいで16GB積める時代なのか…。

メモリ無駄遣いするOS。それがMacといわんばかりだなｗ

>>244
>その状態でマシンを起動して、はじめてアプリを起動したとき

下手な煽りに付き合うのもなんだが、起動した直後に起動するアプリを
高速化したい、という発想自体が随分レガシーな印象を受ける。

Vistaの「起動時間」「シャットダウン時間」に不満の声
http://www.computerworld.jp/news/plf/62250.html
>起動するまでに約10分、ログインして使えるようになるまで5分も
>かかっている。この状態を改善できないと、XPに戻すと家族に
>約束させられてしまった。

MacOS X なら起動時間が気になるならスリープで使うだろうし、
（コールドスタートだって１０分どころか１分もかからないし）
スペースバー叩けば１秒で起動する。しかもさっきまで使ってた
アプリも既に起動してるしw

起動した直後のアプリを起動するために 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 を使わなければそのメモリは他の用途に流用される。

MacOSの場合ディスクからメモリーに読み込まれた内容は、使い終わったあとも
即座にははき去れず、むしろ積極的にメモリー上に残される。そして次に内容が
必要になったとき、ディスクからではなくメモリー上に残しておいたデータを
再利用することでディスクの読み書きの処理を減らすことになる。

これらのメモリー領域が「アクティビティモニタ」で「現在非使用中」と分類
されている部分である。

このようにMacOSXは効率よくメモリーを使用している。

>>251 >>252
Tiger の時の話だが、
http://www.osxbook.com/book/bonus/misc/optimizations/
を読め。

良く使われるファイルはハードディスクの先頭にもってきて、
ハードディスクのヘッドがあまり動かなくて良いようにするし、
ファイルが HDD 上でばらばらになっていたらのが
ファイルを開いたときに判ったら、その際に自動でデフラグしたりする。

http://plusd.itmedia.co.jp/pcuser/articles/0703/22/news051_2.html

>電源オフの状態から起動すると完全に起動するのに10分程度かかってしまう

>>261
遅延再配置とHot-File-Adaptive-Clusteringのことだね。
メモリー読み込みに関する話ではないが、ディスクの最適化に関しては
NTFSよりは優れている機能だ。

>>251はたぶんVistaのSuperFetchのような機能を聞いているのでは。

>>262
仕方が無いさ。Vistaはスリープからの起動を推奨しているからね。

MacOSXは積極的にキャッシュを利用する。

といっても、それは一度読んだデータを取っておくというだけで、
一度も読んでないデータは当然キャッシュされない。

VistaのSuperFetchはその一度も読んでないデータでさえもキャッシュしてしまう優れもの。
過去のデータ使用履歴から最適なものを先読みキャッシュする。

その記事にのってる、working set detection は違うの？

もしかしたら使わないかもしれないデータまでキャッシュしとくってどうなの？

何か問題が？

SuperFetch に関してはこの辺り

http://pc.watch.impress.co.jp/docs/2007/0605/vistamech1.htm

例えば、会社で12時から昼食に出かけ、その間にウイルスチェックやバックアップなど
のタスクをスケジューリングしているという状況を例に挙げると、Windows XPでは、
アイドル時のタスクにメモリを割り当て、それまでフォアグランドで作業していた
アプリケーションデータはHDDに待避させる。そのため、昼食から戻ってきて、
作業を再開しようとすると、その時点で初めてアプリケーションデータをHDDから
読み込むため、作業を開始するのに待たされる。

　SuperFetchでは、過去のユーザー行動のパターン(ここでは、ユーザーが作業を
再開する時間やアイドル後に行なう作業内容)を記憶しているため、アイドルタスクが
終了次第、HDDに待避させていたアプリケーションデータをメモリに読み戻すので、
ユーザーが戻ってきた時には、即座にアプリケーションが反応するという具合だ。


で、メモリが十分にあればこんなアホなことはする必要はない。
そもそも、人間の行動パターンなんてそんな簡単なものではないから、
得てしてこういう予測機能なんてのは失敗する。

【失敗機能】　VistaのSuperFetchは絶対に切れ！
http://pc11.2ch.net/test/read.cgi/win/1178624264/l50

先読みされた無駄なデータは、メモリが足りなければ捨てられる。その上、
必要なデータで上書きしなければいけないから、無駄なHDDの動作が増える
だけ。マイ糞のエンジニアは、なぜ先人達が遅延評価などという機構を
導入したのか判っていないようだ。

> で、メモリが十分にあればこんなアホなことはする必要はない。

十分じゃない場合は？

> 先読みされた無駄なデータは、メモリが足りなければ捨てられる。

別に捨てないよ？
読み込んだデータで上書きするだけ。
コストは0

> その上、 必要なデータで上書きしなければいけないから、
それは、キャッシュされていなくても同じこと。
使用されていないメモリ領域にだって
何らかのデータが入っているわけで、それを上書きする。

> 無駄なHDDの動作が増える
意味不明。

>>270
>十分じゃない場合は？

メモリを増設しろ。
>>239 も読め。

> メモリを増設しろ。
できない場合は？

>>271
>読み込んだデータで上書きするだけ。
>コストは0

アホだな。上書きするデータはどこから持ってくるんだw
先読みされたデータが外れた場合は、先読みする為に必要だった動作は全部無駄になる。
当たり前の話。

>> 無駄なHDDの動作が増える
>意味不明。
その足りない脳みそを有効に使ってくれ

>>273
>できない場合は？
働いて人並みの金を稼げ

> 先読みされたデータが外れた場合は、先読みする為に必要だった動作は全部無駄になる。

だから？

べつに、先読みするために必要だった動作は、
空き時間にやるんだから問題ないじゃん

ttp://pc.watch.impress.co.jp/docs/2007/0605/vistamech1.htm

ReadyBoostによってフラッシュメモリにSuperFetchデータが書き込まれる間、CPU負荷が2〜3割程度になっていた。ちなみに、1,840MBの書き込みが終わるまでは約7分かかった。つまり、PC起動後、数分間はReadyBoostがPCの性能を低減させることがあるということだ。

>>275
>つまり、PC起動後、数分間はReadyBoostがPCの性能を低減させることがあるということだ。
>つまり、PC起動後、数分間はReadyBoostがPCの性能を低減させることがあるということだ。
>つまり、PC起動後、数分間はReadyBoostがPCの性能を低減させることがあるということだ。

しょせん机上の空論だな。
実際は処理は空き時間に行われるから
性能は低減されない。

>>275
大容量メモリ＋スリープで運用すれば、なんたらSuperFetchみたいなものはそもそも
必要ないというのは判ると思う。

第５回　パソコンの処理速度高める「見えざる新技術」・ユーザー行動学習も
http://it.nikkei.co.jp/pc/column/akutsu.aspx?n=MMIT1a000024012007
　筆者も４ギガバイトの製品を購入してReadyBoostデバイスとして使用している。
　ただし、こちらも速度向上が実感できるとは言い難い。各種ツールを用いると、
　確かにReadyBoostキャッシュファイルの更新が行なわれていることが確認できる
　が、その効果はSuperFetchと同じく体感レベルに達しないのだ。

たまに再起動したとしても、最初にアプリケーションを起動するための数秒のコストが
問題にならないことは MacOS X のみならず、多くのモダン OS を使ってる人間なら
良くわかると思う。

もし、これを問題にするのなら、アプリケーションの起動時間より、起動時間の大部分
を占めると思われるマシンの起動時間を考えた方がいい。

>>278
>しょせん机上の空論だな。
SuperFetch や ReadyBoost のことですネ！

>実際は処理は空き時間に行われるから
PC起動後、数分間はPCを使わないのですね。
何のためにPCを起動したのか忘れてしまったのでしょうか。

ナイス燃料投下 >>239

>>280
知らないかもしれないけど、
実は、CPUってかなり空き時間があるんだよ？

CPU使用率が100%未満の場合、CPUは休んでるのさ。
知らなかったでしょ？

というかいまどき Windows にしろ Mac にしろ、電源をいちいち切っているひとのことが信じられない。なんでスリープにしないの？

>>282
君んちのPCも、主が前に座るたび、
「このボトルネックめ、さっさと動けよノロマめ。」と思ってる事間違いなし。

>>283
ノートブック型を頻繁に持ち運ぶ人はしょうがないんじゃない？

場所を動かさない用途ならいちいち電源落とす意味はあんまりないが

僕ノート型だけどスリープで済ませてますが ...
うちの macbook だと飛行機で太平洋渡っても大丈夫だよ。

立ち上がり時の激しい HDD のアクセスとかのほうが電気を食うんじゃないだろうか ... とおもってスリープにしてますが。

電力測ったことないからわからないけど。

>>282
>実は、CPUってかなり空き時間があるんだよ？

あまりアホな煽りを相手にしてもしょうがないが、
皆がお前みたいに負荷の軽い仕事しかしない訳じゃないし、
無駄な仕事＝無駄な電力であることは変わりない。

スリープを使って欲しいのはマイクロソフトも同じで、
http://itpro.nikkeibp.co.jp/article/NEWS/20060904/247116/?P=1&ST=vista
とのこと。
SuperFetch でアプリケーションの起動時間が短くなると謳っているが、
メモリに展開する時間が起動時にかかっていることを考えれば差し引きはゼロ。
展開したりキャッシュしたが、使われなかった分がマイナスになるだけ。

そんなことをやるより、起動時間をマトモにする方が重要だと思うが。

マジアフォには技術的なことはわからないなｗ

> SuperFetch でアプリケーションの起動時間が短くなると謳っているが、
> メモリに展開する時間が起動時にかかっていることを考えれば差し引きはゼロ。

ゼロってそれは処理全体にかかった時間な。

CPUってのはあまり使われていないの。
CPU使用率って知っている？
使用率が100%未満のとき、CPUは遊んでいる。
その遊んでいる時間に先に実行する。

なんでも、先に済ませていたほうが良いだろ。
CPUが使用されていないときにやるのだから、ほかに影響はないし。

>>287は「俺の思考を予測して、俺が起動するアプリだけスパーフェチしてくれ。それ以外は無駄だからやるな」と言ってるのかなw

SuperFetchはメモリが少ないときは性能が悪い事が分かっている。
予測が失敗したときは先読みした処理の分が無駄になるから。
HDDを余計に動かしただけの無駄な行為になってしまう。
SuperFetchは大容量メモリで始めて生きてくる技術だろう。

>>287
> スリープを使って欲しいのはマイクロソフトも同じで、
> http://itpro.nikkeibp.co.jp/article/NEWS/20060904/247116/?P=1&ST=vista
> とのこと。

ReadyBoost使ってるとスリープから戻るたびに数分ほどフラッシュに書き込みw
レスポンスは悪くなるわ、バッテリーは減るわ

結局XPにダウングレードというなのアップグレードをしたオレが来ましたよ

まあ将来的には全面64bitの方が良いんだろうが
今の段階でカーネルまで64bitに書き換えても
一般的には使い道がなかったり
諸問題で64bitが普及しないのはWindowsが証明している訳で・・・

学術分野とかだと知らんが
とりあえず64bitになったとしても
一般的には一部のアニメオタが
エンコ10分が7分になったよ！64bitSUGEEEEE
って位しか今のとこメリットがないと思うんだが・・・

サーバサイドは Solaris も Linux も普通に 64bit 化されてるよ。
DB のキャッシュや Java の Heap に 4GB 以上のメモリを
割り当てたり、大容量ファイルシステム用のキャッシュとか。

サーバ市場を諦めるなら、しばらくは必要ないかもね。

どう考えてもAppleがサーバ市場本気で狙ってるとは思えんのだが・・・
一応サーバもやってますってくらいじゃね？

DTPとかVideo Serverとか、特殊な用途だよな。
http://www.apple.com/jp/pro/profiles/imagica

>>295
放送業界の市場規模って3.5兆円規模だよ
全然特殊な用途じゃないよ

ちなみにIMAGICAは日本のポスプロ最大手

InterBeeでLinuxつかってデモしてたが・・・今時価

>>297
俺もそれみた。

>>288
>なんでも、先に済ませていたほうが良いだろ。
あのな、お前の戯言が技術論だと妄想するなら、
今のモダンな OS がどうやってメモリ管理しているかぐらい調べてくれ。
SuperFetch の発想そのものがレガシーで、今のメモリ管理指向から
逆行しているの気付くことはないだろうがな。
lazy evaluation がなぜ行われるかぐらいは（ry

>>290
>SuperFetchは大容量メモリで始めて生きてくる技術だろう。
で、大容量メモリ＋スリープだと必要ない技術。

>>299
>lazy evaluation

デマンドページングの事?

>SSD搭載のMacBook Proは爆速！
http://applembp.blogspot.com/2007/11/ssdmacbook-pro.html
>ランダム・アクセス・リードは20-33倍に！

↑将来的にSSDが有望。容量面や価格的にまだまだ時間かかるかな？

http://pc.watch.impress.co.jp/docs/2006/0904/macpro.htm
>アップルによれば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の戦略なのかも（汗）

iPodと同数の台数が買われているという状況ならSSD搭載も実現していた。

Nehalem

PPCは32bit addressingでも64bit命令使えたが、Intelはどうなの？

>>302
まあ要するに今後も64bit kernelにする気はないって事だろうな。

>>305
G5の汎用レジスタ幅は無条件に64bit
本当にレジスタ幅が効いてくる処理は128bit幅のAltivecやSSEを使うから
汎用レジスタ幅が64bitになるのはそれほど効果は無いよ。
馬力が必要なコーデック系の処理はもちろん。単純なメモリコピーですら
サイズが大きくなるとAltivecやSSEを使ってる。

>>307
ちょっとずれてる気がするが...
例えば32bitモードでlong longの加算をしたい時に、64bit命令は使えないのか
とかそういう事でしょ。

Intelの場合はSSE2のスカラ64bit命令があるから
32bitモードでも64bitの整数演算命令は使える
ただし当然ながら乗除算とかはできないけど。

SSE2スカラ64bit加算命令のレイテンシを見てみると
32bit整数加算の2倍だから、使用価値は微妙だ。

>>308
>例えば32bitモードでlong longの加算をしたい時に、
>64bit命令は使えないのかとかそういう事でしょ。

G5 だったらできるでしょ

>>309
いやだから305はG5はできるけどIntelはできるのかって質問でしょ

SSEとかで64bitの計算はできるな。

Leopardが64bitOSというレベルは
ちょうどWindows95が32bitOSだというレベルと考えてよろしいでしょうか？

違います

XP が 32 bit OS だというのとは同じ？

おなじ

違うよ、ぜんぜんちが(ry

16bitカーネルで32bitアプリを実行できるwin32sのような、
32bitカーネルで64bitアプリを実行できるのがMac OS X。

32bitのメモリを複数「平行処理」するのと
64bitのメモリを一括処理するのとどちらが能率が良いのだろう。

よくわからん。bitを上げればこそ効率が上がるというわけでもないと思うし。

>>318
意味不明

32bit のデータを 2 回 load するのと
64bit のデータを 1 回 load するのは
どっちが速いかって話じゃないの

64bit のデータを 1 回 load する方が速い

というわけで Leopard のカーネルの話題に戻したりするとw

カーネルは 64bit のアドレス空間を管理しないといけないから 64bit 整数の演算を
32bit のコード中で行っていると思うんのだが(?)、
普通にやったら 32bit ずつロードして、キャリー等のある計算が必要ですよね。面倒〜。
こういうのってどの位ペナルティーになってるのかちょっと気になる。

ちょっと前に話してるSSE2の64bit整数演算命令使っても別に良いんじゃね

まあ32bitの演算器を使っても演算自体はレイテンシが少々増えるだけだろうけど。
CSAライクに素直にcmovを使うか、分岐予測に期待するか、どっちが速いんだろ。

カーネルはメモリー渡しておしまいだろ。アクセスはアプリが自分でやる。

要はMachカーネルはメモリの管理が仕事なわけだろう。（その他にもすることがあるが）
その他の仕事は64bitAPIがそれをやってくれるわけだから。

確かMachカーネルはTigerでプロセスの用いる仮想アドレスが64bitに対応したと
あるが、Mach自身が32bitならどうやってそれを行っているのだろうか？

どうもG5では32bit上でも64bitアドレスが指定可能なようだが、Core2では可能なのか？

ttp://journal.mycom.co.jp/news/2003/06/24/12.html
どちらかというと逆みたいで64bit上で32bit環境を動かしているようだね。
だからMachカーネルは32bitでも良かったのではないか。

しかし、そんなことが、IntelのCoreアーキテクチャでは出来るの？

>>321
32bit整数演算はメモリ管理と関係ない。
アドレス空間ってのはカーネルから見える物理メモリ上に確保された対応表できまる。
対応表には物理アドレスA〜Bは仮想アドレスのX〜Yにみたいなのが延々書いてある。
実際のアドレス変換はCPUが勝手に行う。

つまり、
・対応表の書き換えは32 bitのカーネルで行う
・対応表に従ったアドレス変換はCPUの専用回路で行う (64 bitネイティブ)
というわけ。

対応表の書き換えを32 bit整数演算で行うことのペナルティはほとんどない。
対応表の変更ってそんなに起きないから。

アドレス変換はCPU内部で専用回路で行われているので
カーネルが32 bitだろうが64 bitだろうが同じ速度で動く。

>>326
>アドレス変換はCPU内部で専用回路で行われているので

TLB なんて余裕で溢れるよ
TLB miss は常に発生していると考えた方が良い
Mac からじゃ見えないけど、他の OS 入れれば分かる

>>327
カーネルの大半が互換モード(32 bit)で動いていた場合に
アドレス変換で何かデメリットがあるかって話だと思ったんだけど。

カーネルを完全に64 bitモードしたとして、
それでTLBミスヒットが減るような要因ってなんかあるっけ？

TLB miss したら CPU で演算する事になるけど、その時に
32bit で動いているとペナルティが発生する

>>329
もしかしてx86以外の話してた？

ttp://blogs.sun.com/eota/entry/ultrasparc_sfmmu_%E7%94%9F%E3%81%8D%E6%AE%8B%E3%82%8Bspitfire%E7%B2%BE%E7%A5%9E_ultrasparc%E3%81%A8%E3%81%A8%E3%82%82%E3%81%AB

>実際には、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に移行したんだっけ？
だとしたらこちらの不勉強。その場合はスマソ。

それ、どっちも CPU 使うでしょ。

PDE って良く分かってないんだけど、CPU 内部に専用命令と
TLB 以外の専用領域が用意されていているの?

もしそうであれば、まあペナルティはそんなに無いかもね。

>>326
なるほどどうも。

>実際のアドレス変換はCPUが勝手に行う。
この辺はぼんやり理解していたつもりです。要は

>対応表の変更ってそんなに起きないから。
ですね。
具体的にはどんなときに対応表の変更って起きるんでしょうか?

>>332
＞PDE って良く分かってないんだけど、CPU 内部に専用命令と
＞TLB 以外の専用領域が用意されていているの?

そう。
でかいのでx86はCPU内部に持つじゃなくてメインメモリを流用してる。
ttp://caspar.hazymoon.jp/OpenBSD/annex/intel_paging.html

具体的にはメインメモリ上に多段ルックアップテーブルを構築して
その最上段(ページディレクトリ)の先頭物理アドレスをcr3レジスタに登録する。
ttp://caspar.hazymoon.jp/OpenBSD/annex/intel_arc.html#cr3

x86のTLBはCPU内部の非公開キャッシュ。
キャッシュの細かい制御はルックアップテーブル内のビットで間接制御。
OSから明示的にTLBの内容を制御することはできない。
(せいぜい内容をフラッシュするぐらい)

TLBミスヒットが起きるとメインメモリへのアクセスが発生する。

>>333
＞具体的にはどんなときに対応表の変更って起きるんでしょうか?

例えばプロセスにメモリが割り当てられたときとかプロセスからメモリが解放されたときとか。

ただし大抵の言語だとライブラリがまとめてOSからメモリを確保して、
そこから切り売りされたメモリをプログラムは使っている。
言語のメモリ割り当て/解放命令ごとに対応表が書き換わるわけじゃない。

あとプロセスごとに対応表を区別してるので、
プロセス切り替えでは対応表の切り替えも必要。

こんな感じで、ｘ86の場合、実際のカーネルの仕事は電話帳作っているようなもの。
実際に電話かけるのはCPU内の専用回路。
カーネルの大半が32 bitコードでも64 bitアプリのメモリ管理にそこまで支障はない。
(どっちみち割り込みハンドラは64 bitコードで書くことになるけど)

>>334
>TLBミスヒットが起きるとメインメモリへのアクセスが発生する。

これって load は 32bit 操作なんだよね?
そこが遅くなるんじゃないかなあと思ってるんだけど。

>>336
x86の場合そこはCPUの専用回路が自律的に読み込みを行う。

そもそもプログラマブルじゃないので
32 bitのロード命令とか64 bitのロード命令とか関係ないような。
割り込みによってOSで制御してるわけじゃないんで。

それでは、32bitカーネルでも64bitアドレッシングは可能なのですか？

>>335
>プロセス切り替えでは対応表の切り替えも必要。
>>336
>x86の場合そこはCPUの専用回路が自律的に読み込みを行う。

たびたびごめんなさい、

処理をする実体(?)が「カーネル」と「CPU（の回路?）」との2つに分けられるとすると、
確かプロセスの切り替えはカーネルがやっていることになると思いますが、
「対応表の切り替え」もカーネルがやるんでしょうか?

あと、「対応表」は少なくとも x86 の場合メモリ上の部分と TLB の（キャッシュされた）
部分があって複雑ですね。>>335 の「対応表」とは両方を指しますか?

>>339
あ、すいません、引用の後半は >>336 じゃなくて >>337 でした。

コンテキストスイッチングも１命令(+α)でしょ。CPU。

http://journal.mycom.co.jp/column/sopinion/232/index.html
Intelのアドレス変換。

>>339
「対応表の切り替え」もカーネルがやってる。
>>342 も書いてくれてるけど例えば「プロセス cr3」でぐぐってみると出てくるよ。

例えばこれはLinuxの例。
ttp://d.hatena.ne.jp/naoya/20071008/1191824562

>あと、「対応表」は少なくとも x86 の場合メモリ上の部分と TLB の（キャッシュされた）
>部分があって複雑ですね。>>335 の「対応表」とは両方を指しますか?

メモリ上の部分のみを指す。
TLBはCPUが勝手に作ってるキャッシュなので
プロセスを切り替えるときに、特にOSがTLBに対して何かするということはないよ。
cr3レジスタを変更したらCPUが勝手にTLBを作り直す。

実際はもうちょっと複雑だけど、
そこまで詳しく知りたかったらCPUのドキュメント読むか何かの解説書にあたった方が良いかと。

>>343
どうも詳しい説明ありがとうございます。
自分で調べてみようと思いますが、最初のとっかかりを教えてもらえると結構違います。

バスケットシューズシューズ

あいつまたいつもですねん
かってにうごいてほしいん　　　　　　　　だ

結局のところカーネル部分はIntelCPUで64bitモードで動作するの、しないの？

する

IOKitドライバは32bit、それ以外は64bit。
http://journal.mycom.co.jp/articles/2007/11/20/iul00/001.html

「対応」なだけっしょ

それじゃカーネルが32bitでも64bitOSと名乗ってもいいことになるのではないか。

>>350
「64bit」と「64bit対応」の違いって何？

少なくともAppleが言う
---------------
Loepardは、64ビットのパワーを発揮する万能オペレーティングシステム。Cocoaアプリケーションフレームワークからグラフィックス、スクリプティング、UNIX基盤まで、システム全体が64ビット。
---------------
ではないだけ。

Cocoa もライブラリも API も 64bit 対応なら、Apple が言う通りじゃん
アホか

>>354
おまえのとこではシステム全体にFinderは入ってないのか。

32bitと64bitアプリケーションを区別無く動かせるけれど、
大半のアプリケーションは、32bitのままって状態って事だよね。

>>355
ちなみに「Cocoaアプリケーションフレームワークから... 」の件の元の英文は

Now the Cocoa application frameworks, as well as graphics, scripting, and the UNIX foundations of the Mac, are all 64-bit.

なんで、少なくとも >>355 が思うような意味で「システム全体」とは言ってないようだ。
意訳というか誤訳というか... ま、よくあることなんでw

カーネルまで64bitにするとPowerPC G4やCoreDuoとかが動かなくなるから
仕方なく32bitにしているの？

それとも、64bit環境なら32bitカーネルでも64bitモードでも動作してくれるの？
PowerPC G5ならどうも可能な感じだがIntelCPUではそんなことが可能なの？

>>358
>それとも、64bit環境なら32bitカーネルでも64bitモードでも動作してくれるの？
>PowerPC G5ならどうも可能な感じだがIntelCPUではそんなことが可能なの？
答えは Yes です。カーネルは全部 32 bit なわけじゃなくて、64 bit の部分も多少ある。さんざん既出なのでスレを読み返してください

>>359
ありがとう。このスレ読み返してみるよ。

ちなみに >>180 からあたりが真っ当な議論になってるので。
いろいろ煽りやらあって読みにくいですが。

>>352
かつてセガ サターンが32bitCPUを2つ乗せて、
64bit(級)を銘打ったことと同じ？

確かにアプリは32bitも64bitもうまく動くようだが。64bitアプリから32bitドライバは
まともに呼び出せて上手く動かせるの？
I/OKitが上手くしているから出来るということらしいが、そんな都合のいいことが可能
なのですか？

いまいち何を言いたいのかわからんが、
別にドライバはソフトが直接呼び出すものじゃないでしょう
カーネルが仲介するために間に一回挟まるわけなので、
「ほぼ32bitカーネル」で64bitアプリがうまく動くのを受け入れるなら、
なにが疑問なのか判らん。

それでは、LeopardはVista64bitのように64bit用のドライバが必要ないと
言うことですか？

>>365

ちょうどLeopardは64bit化レベルは
Windows95の32bit化レベルと考えてもらったらOKです。

Windows95と同じようなものか。確か95って32bit環境の中で無理やり16bitコードを
押し込んだようで、結構不安定だったよね。特にドライバ関係が。
そこら辺はLeopardは大丈夫なの？

レパードは不具合いろいろあるけど、別にドライバ周りででてるわけじゃないよ。
だいたい Windows と違って、Apple がほとんど自前でドライバかいてて、
対応ハードウェアもすくないのに、そういうところではエラーでないでしょう

あと、現状でレパードを普通に使っている人は全然 64 bit モードをつかってないと思うよ。まだ対応ソフトも全然でてないだろうし。

だから、64bit まわりが Leopard 大丈夫なのかどうなのか、というのは半年一年ぐらいして評判みてみないとどっちともいえないでしょう

煽りとマトモなレスとでループしている

//
ドライバの互換性

ユニバーサルOSのLeopardでは、新しいドライバやハードウェアを
揃える必要はありません。新しい64ビットアプリケーションを、
お手持ちのプリンタ、ストレージ装置、PCIカードと組み合わせて
そのまま使えます。
さらに嬉しいことに、新しい64ビット対応ドライバにアップグレード
すると、32ビットアプリケーションのスループットも向上します。
//
っていうappleのいいかたもヘンなんだけどね。
嬉しいならアップグレードするドライバを出せって感じ。

>>371
マイクロソフトなんかと比べるとAppleはお金掛けられないから、
スループットが重要なものを徐々に64bit対応ドライバに置き換えていくのかな？

ある程度の汎用ドライバ除いたら
本来OSメーカが作るもんじゃないしねぇ・・・

64bitドライバを強制的に作らせるMSとそれらには柔軟なApple。
普段切捨てとか言っているAppleにしては64bit化についてはMSと
対応が逆なのが面白い。

さて、WindowsとMacOS。どちら政策が先に64bitの世界に導いてくれるのか。
興味のわくところである。

>>374
サーバのマーケットが大きいから、やっぱWindowsじゃね？

結局、カーネルのソースを眺めるのが一番確実かな、と思ってきた。

そっか 64bit になるとメモリ空間が広大になるから、レイアウトに工夫をしたりもするのね。
仮想空間の話だから、実際にメモリを 4G 以上使うかどうかは関係ないわけだ。
どのぐらいパフォーマンスに差が出るのか、ちょっとやってみるかな。
あと、レイアウトが、カーネルの中よりむしろローダーに任されてる感じなのかな。

あと、64bit カーネルへの布石も、わずかながら見られたりして... 面白いね。

判った結果をしろうとにもわかるように噛み砕いておしえてください >>376

スレ読み返せよ

32bit OSとか64bit OSとかクロックじゃないんだから、パフォーマンス比較するのはナンセンスでしょう。
64bitモードで使えるレジスタが増えると言うのは多少影響あると思いますが64bitコードにした場合は
メモリバウンダリが8byteになってしまうため一般的なコードでは無駄が多いということでしょうか？
（Mac OS X Leopard は AMD64 abi-0.98.pdfに準拠）
つまりC2D以上のCPUを持つMacの場合、Leopardでは64bitカーネルがロードされています。

>>379
>つまりC2D以上のCPUを持つMacの場合、Leopardでは64bitカーネルがロードされています。
それってどうやって確認すればいいの？
もしそれが本当ならこのスレ自体の意味がなくなる事なのだが。

Pantherから始まって、Tigerでカーネルの必要個所の64bit化、
Leopardでほぼ全てのAPIが64bit化。その先（アプリ）は次回。

欲張って全て一気にとやろうとしないのがApple流でしょ。
OSXの64bit化だけど、徐々に段階を踏んでやってるよね。
Leopardでやっと64bitGUIアプリが動作するようになった。
多分OSX10.6でさらに次の段階に移行するんじゃないか？
OSX標準アプリの64bit化、64bit部分へのさらなる改良。
これからの方針を予想すると、多分32bitに依存するアプリを
徐々に移行させていくのだと思う。その先にあるのは、
将来的に完全な64bitOSへの道。

将来OSX上で動作するApple製アプリ郡さえ64bit化すれば、
Cocoaアプリとかってカーネルにそれほど依存してないみたいだし、
その気になれば完全な64bitカーネル化には苦労しないと思う。
今はその時を見越した準備期間的な実装。

その時が来るとしたら、32bit環境を棺桶に入れる段階に
なってからなんだろうなｗでもこうすることで、多くのユーザー
にとって64bitオンリー化が既定路線として、強制的に移行させる
ことが出来るのも事実（汗）
（Appleはそれを早期にやりそうだから怖いが･･･）

Appleって良いエンジニアが居てOSの中の方を美しくまとめてくれてる印象。
しかし、jobsさん以下経営陣が細かいテクノロジーの詳細には興味なさげ。

ソフトウエアの大切さは理解しているからエンジニアを褒めるし大衆にアピールして
くれるけれども、エンジニアほどは興味がないから本当に必要になる時までに徐々に
移行すればいいと思っていてそういう経営判断をしている。

まぁ、正しい選択だとは思うし、書いてて当たり前だと思ったんだけど、
だったら完全64bitなんて言わない方が…。

Appleがサーバ分野に行く気がなければこの先15年くらいは32bitのままでもいいじゃないの。

来年には完全64bitになって、CoreDuo機は切捨てになります。ｗ

>>382
>jobsさん以下経営陣が細かいテクノロジーの詳細には興味なさげ。

いや、オレは Jobs も相当テクノロジーの詳細には五月蝿い印象がある。
言い方悪いが、世の中にはエンジニアなんて掃いて捨てるほどいるが、
製品化にあたり、実装の仕方や採用するテクノロジーの取捨選択を行って
非常に上手く構築できるエンジニアはそういない。
（エンジニアなんて山ほどいる MS ですら Vista の難産を見ればわかる）

Jobs はそういうことが出来る人間を見分ける力があるのかもしれん。

>だったら完全64bitなんて言わない方が…。
BSD API も 64bit、Cocoa も 64bit、アプリケーションから見たら完全 64bit な
訳だが。

>Appleがサーバ分野に行く気がなければこの先15年くらいは32bitのままでもいいじゃないの。
MacOS の何がサーバー分野に足りないと？

> BSD API も 64bit、Cocoa も 64bit、アプリケーションから見たら完全 64bit な
> 訳だが。

↑これは、つまり
アプリケーションから見なかったら、完全な64bitではない。
という意味になります。
みなさん、気づきましたか？馬鹿ですね。

>>385
>MacOS の何がサーバー分野に足りないと？
営業力、体力。ミドルウェア。保守。

逆にさ、今後15年でサーバ分野でシェアを伸ばせると思う？
エッジ部分はほぼLinux。バックエンドはHP-UX/AIX/Solaris/(Linux)がいるわけだよ。
OSXにしたいと思わせるソリューションって何？WebObjectを使ってくれるSIerがどれだけ？
日本全国で4時間のSLAを引ける様になると思う？

他のOSがこのような不完全な64bitOSならめちゃくちゃ叩くんだろうが、
ここの人はボジティブだなｗ

>>388
ただのダブルスタンダードの二枚舌野郎だろ。ｗ

>>387
正論だと思うし、CEの経験者だから支持するけどさ。
マカには言っても通じないよ。マカの感覚じゃ業務用とコンシューマの
区別つかないみたいだし。

個人的には、自社のメンテ部隊が存在しない企業の製品なんか
恐ろしくて使う気になんかなれんけどな。

尚、東大のアレはリスクを承知で東大側が自前で面倒みてる
らしいな。呆れてしまうがｗ

>>389
いや、そうはっきり言わんでも

>>391
いあ、自覚がないマカに自覚させるためには必要だろｗ

ドザはしつこいな。
オレも一年前はバリバリのドザだったけど

>>393
マカもしつこいよ。
ちなみに、俺は元マカなんだよなｗ

アンタとはちょうど正反対になるな。

>>390
対価を払って面倒を見てもらうというのは大人になってからなんぼでもやればよく、
学生のうちにありがちなトラブルを経験させるのは親心。

ありがちなトラブルの原因を推測できる程度の経験がないともっともらしい理由をつけて
ベンダーに騙されるんじゃないの？と思います。
たまにすごい言い訳する人って居るじゃないですか…

>>395
いいかげんな屁理屈書いてんじゃないよ、このバカ。
その余計な経験に使った無駄な時間を他の有用なことに使ったほうがましだと
思わないのかね。コンピュータそのものを生業としない一般ユーザにとって
パソコンなんかただの道具であって、目的じゃねーんだよ。

>>394
dpmJe3XR0 は 10.2 までしか使っていないのに、全てを知っているかの様に語る
大嘘つきな訳だが何か？

Macが嫌いです。本当に嫌いです(´･ω･｀)
http://pc11.2ch.net/test/read.cgi/mac/1186817782/678-

>>387
>営業力、体力。ミドルウェア。保守。
それが 64bit 化とどんな関係が？

ドザはマトモなやり取りも出来なくて困る

>>395
パソコンのメンテと東大の学生用システムの維持管理を同じレベルだと
思ってるバカ発見。

>>390
>尚、東大のアレはリスクを承知で東大側が自前で面倒みてるらしいな。

あのシステムインテグレーションはNECがやってる訳だが、NECは無保証・無担保で
iMac や NetBoot 環境を入れてるとでも？
アホ丸出しもいい加減にしてくれ

導入の契約はしたが、保守契約はしてないって話なんじゃないのか？
まぁ、マカはアホだからそんな話は想像もできないんだろうけどな。

>>401
あのな、運用管理を東大ECCSが行うのと、
システムインテグレートが全く違う話だというのがわからんのか？

しかも今回も同じ MacOS+NetBoot環境だからな。
前回が成功したからこその話なのだが。

マカとかドザとか、おまえら、いつまでたっても飽きないねえw

んで結局64bitレジスタの恩恵をフルに受けられる64bitアプリは
現時点で自社他社含めてどの程度あるの？
マジでチェスだけなん？

>>404
過去レス位読め

>>404
32bitで十分。高速。
Appleは最高の選択をした。
完全に64bitにする意味なんて無い。
64bitなんてサーバじゃないと意味が無い。
でもサーバ市場に行くとは思えない。
AppleのWebでは64bitドライバにバージョンアップしたらスループットが上がるって書いてて
そんなドライバが現在存在していない。

それが今のところの総論。

突き詰めていくと、Leopard 以前に、なぜ最近は普通のユーザ向けの
CPU ですら 64bit 対応になっているのかという疑問が。

ここは中身がどんなものだったとしても
後付の最高の褒め言葉で受け入れるMac愛溢れるスレですね

>>407
散々言われてる事だが
もうCPUが手詰まりだからじゃね？

Windowsの世界では64bit化によって、メモリが8GB使えると喜んでいるユーザが
多いようだが、結局64bit化のメリットはメモリが大量に使える事ぐらいなのか。

>>396,399
コンピュータそのものを生業としない一般ユーザやパソコンのメンテの話なんてしてないんだけど。
なんでコンシューマと業務とをごっちゃにするんだよぅ。全然別の話でしょ。区別つかないの？

一般ユーザは管理者に文句言えばいいだけじゃん。
学生の時そうだったでしょ？社会に出てもそうして行くわけだし。

学内ネットワークのメンテって情報系の学生のいい教材なんだから自分らでメンテしたほうが
いいでしょ？という話なんだけどなぁ。
情報系の学科持ってて自己解決できない大学なんて存在価値無いと思わない？

>>410
エンコとかCGのレンダリングなんかは微妙に速くなる

それでも、ほとんどの人間には関係ないのに代わりはないけど・・・

64bitコンパイラでコンパイルすればあらゆるアプリが二倍高速に！
今時サーバ用途だろうとクライアント用途だろうと64bitにあらずばOSにあらず！
という誤解が解けたようで何よりです。

>>410
一般の人がインターネッツしたりメールしたり年賀状作ったり「パソコン」として使うには、Windows の 64bit 版はドライバやらなんやらの問題でメモリ以外はデメリットが多いのです。
なんで MS が Windows を 64bit と 32bit で別パッケージにしてるのか謎ですね。

あ、そうそう。
全然関係ないですが Safari for Windows って、Windows で初めてカラーマネージメントに対応したブラウザなんですって。
驚きですね。
いままで Windows を使ってた人って、Web ブラウザで表示してた画像の色が「間違ってる」って知らなかったようですね。

>>411
正当化に必死だな。ｗ
いつの間に>>395では全く言及していない、情報系の学科に限定した話になったんだろう。
しかも学生の話だと思っていたら、なぜか大学の存在価値にまで広がってるし。ｗｗ
さすがのすり変えだな、呆れるしかないよ。

互換性重視のクライアントOSと
サーバ・ワークステーション用のOSを分けるのはMSの伝統。
つうかこの流れで用途ごとにOSが分かれてるのを叩くってまったく理解できてない証拠だぞｗ

>>415
え？だって>>387,390ではコンシューマレベルの話してないじゃん。

>>416
あら、MacOS X もサーバとクライアントは別パッケージですよ。

ドザは 4GB を超えるメモリ空間を使う為には 32bit ドライバを捨てるしかなく
従来の 32bit ドライバを生かすには 4GB に縛られなければならない

MacOS X は 64bit クリーンな API と 4GB を超えるメモリ空間を持っていながら、
従来の 32bit ドライバも使える。
カーネルが 32bit （と言いながらも 64bit の互換モードで動くのだが）
なのは、いいとこ取りを実現する実装の結果

まあ、Macの場合は、
Leopardを使うためには、Tigerドライバを捨てるしかないわけだから
たいした違いはないんだけどなｗ

ハイパフォーマンスなエンプラ・サーバ周りを
切り捨ててしまったからこそ出来たんだよな。
サーバからゲーム機、携帯にまであらゆる分野に
足を引っ張られているWindowsにはとても選択し得なかったやり方だよ。

Tiger時代のドライバ、普通に使えてますが何か？

あらゆる分野で Windows が足を引っ張ってる



まで読んだ
ttp://www.page.sannet.ne.jp/mnagai/msj/msbuiltcars.htm

今までインチキ64bitOSなことを隠してきたのが偉い！

インチキとは失礼だな。高度な柔軟な政治判断に基づく臨機応変な実装と言ってくれ。

64bit になると無条件に早くなると思ってるドザは、やはり起動時間も倍になると
思っているのだろうか？

Vista は起動するまでに約10分、ログインして使えるようになるまで5分
ttp://www.computerworld.jp/news/plf/62250.html

>>426
ネガティブキャンペーン乙。恥じ晒してどうするの？ｗ

リンクの機種が不明だけど随分古くてメモリ不足のPCに無理してインストール
したんだろうな。最近の普及型なら50秒程度で起動するんだけどね。
http://pc.nikkeibp.co.jp/article/NPC/20061130/255530/?P=4

ちなみにこっちではLeopardの起動に5分程度かかってるけどな。ｗ
http://blog.so-net.ne.jp/syufunozakkityou/2007-10-31

おいらの Mac で Leopard の起動/自動ログイン/使えるようになるまでに 30 秒かからんけど？

Windows って、デスクトップが現れてからが長いじゃん。

マカは狂犬のように所かまわず噛み付いてくるね

反論出来なくなるとそれですか？

犬はドザチョンの貴重なタンパク源だそうだw

反論ていったいどこに論があるの？ｗ

MacBookCoreDuo 1.8GHz だけど2分もかからないけどな。
200万人の中には、ちょっと具合が悪くなったのも1台や2台はあるだろう。

でも、

>リンクの機種が不明だけど随分古くてメモリ不足のPCに無理してインストール
>したんだろうな。最近の普及型なら50秒程度で起動するんだけどね。

Vista×ワンセグ×新ボディ――富士通「FMV-BIBLO LOOX T50U/V」を試す
http://plusd.itmedia.co.jp/pcuser/articles/0703/22/news051_2.html
>電源オフの状態から起動すると完全に起動するのに10分程度かかってしまう

あれ？これって最近の普及型じゃないのかな？
レビュアーにしっかり書かれてるってことは不具合じゃなさそうだしw

そういうのは他所でやれと

Windowsってなんであんなに起動がおせえの？
いい加減イヤになるんだけど　マジで

>>435
煽り煽られも良いけど、せめて bit 数の絡む煽りにしてくれ、いちおうスレタイにしたがって。

>>377
>判った結果をしろうとにもわかるように噛み砕いておしえてください >>376

あくまでも自分が理解した（と思う）範囲だけども、
プロセスが 64bit のときは、デフォでカーネルとユーザーでアドレス空間の場所を分ける。
（ちなみに 64bit カーネルが鎮座する場所もすでに予定されているw）
で、さらにページテーブルのエントリをユーザーとカーネルで共有する。
すると、ユーザーモードからカーネルモードへスイッチするときにページテーブルを
再ロードせずに済む。
でも、これって結局 *BSD とか Linux がやってることと同じなようなw

いくつかシステムコールのベンチマークをしてみると、確かにこの仕組みがあると
1〜3割程度速くなる場合があった。　

ちなみに 32bit の場合は上記の仕組みはない。そのせいかパフォーマンス的にも
64bit で上記の仕組み off な場合ととほぼ同じ（= デフォの 64bit より1〜3割程度遅い）。
技術的には同じことが 32bit でも可能な筈だが、いろいろ問題があるのかもしれない。

ま、これって純粋に 64bit だから速いというより Mac OS X 上の 32bit/64bit の実装の
差の結果速くなるという感じもするが...
なお、パフォーマンスの差は、俺がやった素朴な特定のテストの範囲内だけの話なんで、
そこんとこよろしく。

通りすがりの者ですが>>437乙。

>>433
> 超低電圧版Celeron Mに512Mバイトのメインメモリ
だそうだよ。

>>426や>>433のように、ことさらに遅い機種をさも標準みたいに引き合いに出して、
OS批判を行なうのはバカのやる事。

>>440

これ以上32bitだということをいわれたくなくて話をそらしているだけなのでしょうね。

起動時間勝負？
おれのCore Duo（MacBook初期形Mem2GB）はLepardで1分かからないよ。
G4iBookでも1分くらいじゃないか？
こっちは933MGzでメモリ768MBだけど。

>427のリンク先のMacはなんか壊れてるねw

むぅ933MHzだね、まちがえたよ。

真の64bitだったら大々的に宣伝してるよ。
うやむやにしてる点で32bitだね、間違いない。

ブログの反応見てると例のプレゼン鵜呑みにして64bit化で圧倒的に高速化するのかと騙されちゃった人と
64bitレジスタ使った演算の効果なんてクライアントじゃ限定的だし
そもそも4GB以上メモリ積んだマシンなんて誰も使ってねーじゃんという比較的冷静な人で二分されてるね。
声のでかさは圧倒的に前者だけどｗ

まあ、Windowsのように全部64bitにして32bitドライバやDLLが動かなくなるよりも
32bitと64bitの混在可能にしたAppleのやり方のほうが、現実的だったのではないか。

今のところ、メモリが4GB以上積める事しか64bit化のメリットを感じられないようだし。

>>437
>技術的には同じことが 32bit でも可能な筈だが、いろいろ問題があるのかもしれない。
大人の事情とかも関係あるんですかね？
それか、ハード/ソフト両面の将来的なことも考えてなんでしょうかね。

>>442
ちょっと壊れ気味かもね。
どんなインストールの仕方したのか分かんないけど、とりあえずディスクユーティリティで修復した方がいい感じね。
ちなみに、メモリいっぱい積んでると電源投入直後のハードウエアチェックに時間がかかるので、起動時間は多少長くなります。

>>445
用途にもよるんだろうけど、MacPro で 9GB 積むとかなり快適ですよ。

現実的ということで話をするのなら、結局新しいOS用のドライバを使うわけで
以前のOS用の32bitドライバが動いてもあまり意味は無いのではないか？

つまり、Leopardで32bitドライバが動く！という事例がどういうときかを考えると
Leopard用に新しいドライバを作っておいて64bit版を出さないということは無いわけで
Tiger用32bitドライバを使う場合なわけだけど、通常はLeopard用ドライバを使うでしょ？ということ。

また、Windowsの話だが、64bit OSで32bitアプリ、32bit DLLは動く。

　　　　　　　　　　　＿　ーーー
　　　　　　　　,＞'´,: : ,: : : : : : : : :~＞ ､-'7　　　　 ＿_
　　 _, -'_＞'ヾ,,;;'~,／ ., : : : : : : ,: : : :.,: : /~`''''二-_＜~
-''~:::,／ ::::::::::::〉'~: ／ : : : : : :／. . ／M　'' :': : : : : :~＞＜
::,／:::::::::::::''／: :／.: : : : : ::／: : .イ: ／|.i　,　　　 '' ''大ー .`_.､
.ﾞ!,:::::::::::::::,.': :／: : : : : ::／' : ／./:／:;:;ｌ |　:|: : : . . .　 　`.、　 `ヽ
,　'、::::::::,',ﾝ'/ : : : :::／:;/: ／:;./／;:;:;:;|.:;:|　|i : : : : .|: . . 　 V
Vﾚ〉.::::/ﾍ;/: : : ;／:;:;:;/イ:;:;／';:;:;::;;:;:;|;:;:;| .|::|: : : : : |: ハ､　.|
　./ .'､::::,/: : .,イ:;:;:;:;':;:;:;:;:;':;:;:;:;:;::;;:;:;,/::;:;:| .|;:;|: : : : .|: : : |.V: :|
../ : :::`'/: ､ｲ　''':;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;:;|/:;:;:| : : : |: : : :|　|: :| MacProで9GB…
/: : ::::::;|:／.ｿ'　,,　　'''''''''''''''''''''''''':;:;:;:;:;:;:/;:;:;:.|: : : /: : : .|　 |: |　　このブルジョアめ！
: : ::::::/,|'＾`.-,､''.　　　　　　　　　`　::;:;:;:;:;:;:;:;.|: : /./ : : |　　|,'
: .:::::/|: ::::::::|::,乂　　　　,,,,,,_ 　　　　　 ''':;:;:;./|: //;|: : / 　　'
.::::,//|:.: ::::::|.i/　＼.　 'ｰ- .,,_｀ 丶,　　　,　./ |/ｲ;;;|: :/
::::// |:.: ::::::|:i　　　 ` ,､　　　 ~`〜 　　　ﾝ'ノ,'- ~.|:./
::/　 .|: : : :::||_,,,,／乙i　 `ミ, ,,,,,,,., ,- イ~ i:~:.|　　 |/
'　　 .|: : : ::::|､;;;;;;;;;;|~　　　（＼　// ,::::: :i i: i　　 .'
　,／.|: : : : :|､.､;;;;;;;|￣⌒＼|;;;;x.'/./::::: :| | :|
／　 |: : : : .|､ヽ ､;;;|　　　 /;;;;;;;,ﾞ|/::::: : :| |:.|　　　　←ドザ機で最大8GBしか使えないかがみん。
　　　|: : : : |;;ヽ.ヽ.､.|　　 /;;;;／イ :::: : / |:|

いまだに64bit対応アプリケーションソフトがチェスしかない状態ではなんとも言えないだろう。
結果的に良かったかどうかの判断は、今後の対応アプリ次第だな。
先行しているWindows用では順調に64bit版が揃ってきているからな。

カーネルが32bitというのは確実なようだ
エセ64bitだね。この過去を引きずった仕様が将来足を引っ張る。

http://d.hatena.ne.jp/NyaRuRu/20071114/p1
> ちょっと気になって調べてみたのですが，Leopard ではカーネル空間を 32-bit モードに据え置いたそうです．

>>448
Leopardoになったから新しいドライバが必要ってのは必須じゃないだろ
中には動かん物もあるかもしらんが、大抵のはTigerので動く

だが、現実的な話でいえば、
普通は新しいOS用に新しく作られたドライバを使うだろ？
それともお前、LeopardでTiger用ドライバ使ってんのか？
何のドライバだよ？

>>449
かがみん。ブルジョアでごめんｗ
http://itpro.nikkeibp.co.jp/article/USNEWS/20060525/238972/zu09.jpg

>>451
カーネルまで64bitにしたら32bitマシンが動かなくなるからそうしたのではないか？
しかもアプリ側からはカーネルなんて見えないし、カーネル自身互換モードで動かせば
問題はあまり無いのではないかと。

途中で送信しちまった・・・

ただ32bitから64bitに全面移行するとドライバ類は全部一から作り直さなきゃならん
これはMacもWinも一緒

今、64Vistaでも32bitアプリは動くが、それでも32Vista程は確実じゃない
そもそも64bitOSの上で動かすより、32bitOSの上でネイティブに動かす方がパフォーマンスが良いから
64bitOSで32bitアプリだけを走らせる意味がない・・・
64bitOSのパフォーマンス活かすなら64bitアプリも無いとダメだが
アプリに関しては64bitでコンパイルし直せば大概のアプリはそのまんま64bitアプリになる事はなるが
作る側も、今の64bitの普及度合いから考えても
既存のアプリが64bitになる必要性も無くてワザワザ作る必要を感じないから作らない

>>454
　　　　　　　 　 　 　 　 　 /￣ ＞―───―-
　　 　 　 　 　 　 , -ー─ |: : : : : : : : : : : : : : : : : : : ｀丶
　　 　 　 　 　 　 |: : : : : : l: : : : : : ヽ: : : : : : : : : : : : : : : ＼
.　　　　　　 　 　 |: : ／: :.:|: : | : : : : l＼ : ヽ: : : : : : : : :＼: :ヽ
　　　　　　　　　 j／ : /: :.|: : | : : : : |ー＼‐丶-: : : : :.ヽ: :＼ﾊ　┼
　　　　　　　 　 /: : : / : : |／|ｌ.: : : :.|　　 _＼ }＼: : : : : l: . : |:|
　　 　 　 　 　 /: : : / : : ∧ :八.: : :│　行う示�_ヽ: : : j＼: |:|　_人__
　　　　　　 　/: : : : | : : ,′'ｘ=ﾐ､ : : ｌ、　 |j:_ﾊ_j�W:.ﾍ : / : :j/:|　｀Y´+
　　　　 　 　 |: :/| :│ : |　/ｲﾉ'ﾊヽ :{ :＞弋_Yソ |│:.Vヽ: : :│　＋　かがみさんは安物PCで最大8GBなんですか。
　　　　 　 　 | :ハ: : ヽ:小'{iﾍ_Yｿfｊ⌒ヾ､ '' ￣　 ,| j: : :!　} : : |　　　
　　　　 　 　 ∨　ヽ: : ﾄ{ ハ　ゞ'´/tｰ'＾ヽ`ー‐ '´|/∨:|イ : :│　　　 私なんてOpteronを32個（64コア）搭載したサーバー機で
　　　　　　　　ヽ 　 ＼!/＼j__''_ノ　∨　 ｝ 　　　/ : : :.|│: :│　　　　メモリー容量は128Gバイトですの。
　　　　　　　　 　 　 　 |: :.:ﾉゝ,　__/⌒'＜＿　イ.: : : :.:|⊥:.:八
　　　　　　　　 　 　 　 |: :/: :j: : |/　ﾉ`ｰくヽ ∨: : : : : ﾘ'⌒＼丶
　　　　　　　　　　　 　 ∨: :/ : /　　￣ヽ_)_)‐': : : : :〃　　　 `､:＼
　　　　　　　　　　　　／ : / /7　　 Y　'´ ,ィ’ : /: :/　　　　 　 |: : :＼
　　　　 　 　 　 　 ／: : : / ∧{.　　 ﾉ　／/ : : /: :/　　　　　　│: : : :.ヽ
　　　　　　　　　 /: : : ／{ノ ヽ＼ｰ／｢　/! : :∧:/　　　　　　　ﾊ: : : : : :i
　 　 　 　 　 　 /: :.／ :厂＼　＼＼ヽ∨∧ / 〃　 　 　 　 　 {: ヽ.: : : :|

デモ機で自慢するなよ。

>>454
　　　　　　　　　　　　＿　　,─､
　　　 　 　 　 　 　 ／　ヽ-,　　 ヽ､‐､_
　　　　　　　　 　 /,　　,　,､ ,ﾍ　　　､　､ヽ
　　　　　　　　　//　　/├　Tヽ !　　!　＼ヽ
　　 　 　 　 　 // , 　 ＬL__　|.　Vl､＿j_　 ヽ|
　　　　　　　 / l　| 　 j !　 ｀　!.　「lヽ　j　 l　 l
　 　 　 　 　 l./|　|　 l'|.!　　　 ! 　!|　ヽﾄ　 ﾄ　l
　 　 　 　 　 |l |　 l　 |ﾋ≡ミ　　　ﾓ≡ﾐ,ヽ　|ヽ|
　　　　 　 　 　 l　 |　| ' 　 　 丶　　 '' '∧.│ l|
　　　　 　 　 　 ヽ├Ｎ､　　　ー‐'　　 ,ﾉヒl |
　　 　 　 　 　 　 〉Lヾ,|ﾆ＞, ､__　ィ１､┤┼､
　　　　　　　　　/　l　　Y　 │　　l　 ∀￣.l　l
　　　　 　 　 　 l　　l　/`＿,┤　 ト､　 l　 l　　l
　　　　　　　　 l　　 l_ '-´ﾌ　 l 　l　ヽヽ'　l　　 |
　　　　　　　 /　　 l　|　〈　　　Ｖ　　/　 Y　　　l　＞そんなもん個人で買えへんやろ。
　 　 　 　 　 l　　　|.│ 　 ＼　ヽ､〃　　 |l　　　|
　　　　　　 /　　　 |人　　　　＼ヽ 　 　 ﾉ|　　　l
　 　 　 　 /　　　　l|　ゝ　　　　 ヾヽ　　ﾊl　　 　 ヽ
　　 　 　 l　　　　　l　 l　 〇　　 　〇l　 l | 　 　 　 l
　　　　　|　　　　　|　/　　　　　　　　|　ﾊ|　　　　　l
　　　　│　　　　 l　l　　　　　　　　　| /　|　　　　　|
　 　 　 |　　　　　|　|　　 〇　　　 〇|/　│ 　 　 　 l
　　　　レ=二=､ l　 |　　　　　　　　　|　　 |l　／ニ､│
＿_(二＿(二＿)'＿|＿＿＿＿＿＿_|＿__lr二_´Ｙ´｀ュ_､＿＿＿＿

>>457
SAGEはその半分だね。
そういえば、こういう科学計算なんかに使うコンピュータのOSはどうなってるんだろ。
ttp://www.sagemath.org/sage.html

>>455
>カーネルまで64bitにしたら32bitマシンが動かなくなるからそうしたのではないか？
32bit CPU機では32bitカーネルで起動。
64bit CPU機では64bitカーネルと32bitカーネルを選択可
っていうのがよくあるUNIXのサポートだと思うけど。

>>460
ビジネス的にか技術的にかはしらんが
そんな言うほど簡単ならWinも64bit版と32bit版分けたりしなかったと思うぞ

>>456
完全に後ろ向きな意見だな。ｗ

64bit OSの用途は32bit OSでは賄えないアプリケーションのためにあるんだろ。具体的にはサーバ
アプリケーション、データベース(Oracle、SQL、DB2)、3D CAD（AutoCAD、MAYA、XSI等）あたりで
Windowsの64bit環境は着々と進んでいる。これら以外のパフォーマンスクリティカル用途ではない、
例えばOfficeやブラウザなんて32bit版が動けば十分。

http://www.3dvelocity.com/articles/win64compatibility/win64nativesoftlist.htm
http://wiki.mm2d.net/win64/index.php?64bit%A5%A2%A5%D7%A5%EA%A5%B1%A1%BC%A5%B7%A5%E7%A5%F3%BE%F0%CA%F3

>>461
両方のライブラリを入れるだけだろ？
LinuxでもSolarisでもAIXでもみんなそうしてる。

カーネルドライバだって、OSXの場合は自社マシンしかサポートする必要が無いんだからそれくらい
Appleが作ればいいじゃないか。
自社のハードウェアのドライバだったらIBMはともかくSunぐらいの規模でも出来てた話だぞ。

そもそも複数アーキテクチャサポートなんて昔からPPC/Intelバイナリを同梱してるMac(NeXT)じゃ
めずらしい話でもないだろ。

>>462
クライアントOSの話をしてるのにサーバの話してもなぁ・・・
何で都合良く、そうやってサーバとクライアントの話をすり替えるかな？

64Vistaがサーバに使われる訳じゃあるまい？
元々クライアントOSであるOSXにそこまでクリティカルなサーバアプリは要らんだろ
ならサーバ版のLeopardはどうなのよって話になったら、Appleも頑張れよとしか言いようはないが
ただ、サーバ分野に力入れてないメーカにそれ求めてもだし
普段俺らが使う分には全く関係ないしな・・・

クライアントOSとして使う上でカーネルまで64bitであるメリットって何よ？
３D関連とか映像編集とか位しかパッと思いつかんのだが・・・
そこら辺のアプリにしても、APIは64bit対応してるから64bitアプリとして作ってもOSXで何も問題無いわけだしなぁ

>>463
両方のライブラリいれるだけだろ？って言われりゃそうだが
その分開発コストも、その後のトラブル抱える可能性も2倍な訳で・・・

>カーネルドライバだって、OSXの場合は自社マシンしかサポートする必要が無いんだからそれくらい
>Appleが作ればいいじゃないか。
ドライバは今でもAppleが作ってるだろ

Appleもボランティアや研究機関じゃないからな・・・
費用対効果って言葉も大事なんじゃね？

結局多くの人が32bit専用Vistaに移行してる現実を考えると、
これで良かったんじゃないかね。向こうは動きもしないのだが。
64bit化の恩恵は今のLeopardでも十分に受けられるのに、
なにが不満なんだろね。

でも結局なんだかんだ言っても
完全64bit化したらしたでマンセーするんでしょ？

>>467
64bitが活かされて、パフォーマンスが向上する状況なら
喜んでマンセーするね
マンセーしない理由は無いしな

無理に64bit化して、パフォーマンス落ちたり不具合が起こるような状況だったら
不満言い続けるとは思うが・・・

long modeをサポートしてる時点で「64bit OS」なのは確定でしょ
Tigerもこれは同じだが

カーネル自体は32bitだから、64bitアプリケーションで
現在以上のパフォーマンス向上の余地があるとすれば
カーネルタスクの速度向上ぐらいか
client OSで恩恵を受けそうな場面はあまり想像できないけど...

>>464,>>468
本当に二枚舌のバカだな。ISVが64bitアプリケーションソフトを開発するのは、32bit版よりも
パフォーマンスが上がって、競合他社との差別化によるセールスポイントになるからだろ。
逆に遅くなったらどこも導入したりしないだろ、常考。

ISV...

QVC

>>470
K94i0d1x0も中途半端に訳分からない主張しないで、OS Xの64bit化自体が不要だぐらい言えば
いいのにな。ｗ

まぁMacに64bit市場は無いから仕方ない。例えばMAYAも64bit版はWindowsとLinux用だけで、
64bitアプリの面でOS Xがかなり遅れているのは明らかな事実。
今後はパフォーマンスクリティカルな市場では、64bit化が規定路線で避けられないのは間違い
ないから、結局>>450に戻る訳だ。ｗ

Photoshopの共同デザイナーScott Byerは木曜、彼のチームは必ずP
hotoshopの64-bitバージョンを開発するが、まもなく発売予定のCre
ative Suite 3.0（CS3）にこれを含めるのは現実的でない、と語った。

最新のPhotoshop CS3ベータが64-bitをサポートしていないことに
対するユーザーからの質問に答え、Byerは彼のオフィシャルブロ
グで、単に64-bitコンピューティングの恩恵の多くは、現世代のハ
ードウェアとソフトウェアではほとんど享受できない、と述べた。

Byerが言うには、ほとんどのPhotoshopユーザーは今でも、各プロ
グラム上で32-bitメモリアドレッシングしか対応していないオペレ
ーティングシステムを使用している。これにはアプリケーションに
3GBまでしかメモリを割り当てられない、Mac OS X Tigerを含む。
このような現状では、32-bitソフトウェア本来の4GBの壁を越えて
メモリアドレッシングができる、64-bit技術の根本的な長所を台無
しにしてしまうという。

「郵便受けに入れられた、64-bitの誇大広告をみんなチェックして
みよう。（64-bitアプリは）もっと大量のメモリをアドレスできる。
だいたいこれだけだ。64-bitアプリケーションは、メモリアクセス
が速くなったり、その他のアプリケーションのパフォーマンスを改
善したりするような鍵を、魔法みたいに手に入れるようなことはない。」

実際のところ、今日のコンピュータでは、コード -- 同じタスクを
実行しようとすると文字通り2倍のサイズになる -- がメモリサブシ
ステムにずっぽりはまりこみ、与えられた時間に処理できる情報量
が減ることで、むしろパフォーマンスの低下を招くだろうとByer
は付け加えた。現行のAMDとIntelのプロセッサは、ごく時たましか
64-bitコードを処理しておらず、ファイルのキャッシングでその利
点を相殺してしまうこともしばしばである。

彼は、64-bit要素を一部持つにもかかわらずTigerの根源的な32-bit
制限を批判し、特にPhotoshop CS3のMac用64-bit版の開発を否定
した。「アプリケーションが完全に64-bitであるために必要となる
多くのライブラリが、そろっていない。そのためMacintosh側に関
しては、答え（Photoshop CS3の64-bit版の可能性）はゼロだ。」

彼の会社のスタープログラムをアップデートして、4GB以上のメモ
リを活用することにはやぶさかではない、と述べながらも、64-bit
技術に費やす時間は、MacユーザーにとってはUniversal Binaryを
磨いて、前のバージョンからアップグレードを考えているアーティ
スト達がすぐに喜ぶであろう新機能を追加していくほうが有意義だ
ろうと、 Byerと言う。しかしながら、彼はもっと多くのコンピュ
ータがより多くのメモリ空間を使用し始めれば、64-bit版の開発は
いずれにしろ避けられないと約束した。

「問題は"いつやるか"だ。"やるかどうか"ではない。」

>>470
だからさofficeを64bit化して意味があるのか？
何でもかんでも64bit化すれば良いってもんじゃないって話だろ
逆に今64bit化が積極的に進められてるようなアプリ以外は
無理に64bit化してもオーバーヘッド起こってかえって遅くなるなんてのは常識

今64bitの恩恵が受けられるのは、３Dとか映像関連くらいだって言ってるだろ？
そこら辺の限られた用途のためだけに、普段使いのofficeとかのアプリが遅くなったら意味ないだろ？
そこら辺も含めて問題無い状況になったらマンセーするって話だ
二枚舌でも何でもない


>>473
まあ３Dとか64bit云々以前からMacは不毛だからなぁ・・・
ただチェスだけってのは間違いだ
一応、FCPなんかも64bit版としては売ってないが中の処理は64bitだ
必要に応じて他のアプリも64bit化してくだろうよ

先行すれば勝ちとかって単純な話だったら
今頃、WindowsがトップシェアにもiPodがトップシェアにならんかっただろうな・・・

今回のLeoのカーネルに不満を持つ人って、どういう考え方なのかな？
これが64bit化への最終型ってことなら確かに文句も出るだろうけど、
そうでない事は明らかな訳で。Leoは明らかに「移行期の暫定的な解」。

こういう段階的に進める戦略、悪くないと思うけどね。
結果として64アプリ実行環境の一般ユーザへの普及は
先行するWinより今後はずっと迅速に進む事になるだろうね。
なんと言ってもプリインストールのOSが64アプリ対応に
切り替わった訳だから。

>>476
64bit化するだけで普通は速くなるよ
遅くなる方が珍しい
爆速とまで行かないだけだよ

ハゲが詐欺まがいのイランプレゼンをするからこういうことになるんだよ
自重しろ

つーかKernelの64bit化とアプリケーションの64bit化は全く関係ないよ
アプリケーションが64bit化されるかどうかはAPIの提供次第。
Photoshopとかが64bit化できないのはCarbonが完全に64bit APIを提供してないから。

Appleがちゃんと情報提供してれば問題なかったのにね〜。
いつも都合の良いことだけ宣伝して、都合の悪いことはダンマリだから仕方ないか。

>>480
CS3はCocoaでスクラッチし直したんじゃなかったっけ？
まあCarbonは64bit化される事は無いんじゃね？
64bit使いたかったらCocoa使えって事だと思う

>>481
情報提供ってどのAPIが64bit化されるかなんてのは
WWDCで既に明らかにされてた訳だが...

>>475
結局Leopardはハイブリッドの中途半端なOSだってことだろ。ｗ

>>476
お前もう引込んでろヨ。全く理解していない。
だれが必要ないものまで64bit化しろって言ってるんだよ、ドアホ。
64bit OSが充分に動作するようなPCで32bit Officeの動作速度に不満があるわけ
ないだろ。0.1秒掛かっていた処理が0.11秒になったからなんだって言うんだよ？ｗ

どうでもいいけど、Office は 64 bit にする以前に、intel 化してほしいんだけど...

まあ来年一月にはでるけどさ。

Officeの64bit化は今のところ全く予定無いだろ。

>>480,481
32bit->64bit化したかったらデータ長の変更部分の修正や
パフォーマンスチューニングだけじゃなく
ライブラリとっかえろってめちゃくちゃ高いハードルだなｗ

64 bit ライブラリは Carbon の GUI 部分を除いて全部揃ってるよ。
問題は Adobe 系も Microsoft 系も Carbon だから、一筋縄では 64 bit にできない。

64 bit Carbon GUI も無かったわけではなくて、WWDC 2006 から一年間は存在して殆ど完成していて、実際に開発者には配られていたのに、WWDC 2007 でサポートしないという発表があって、わざわざ開発者版からは削除されたので、Apple 上層部の決断だったようだ。
http://www.carbondev.com/site/?page=64-bit+Carbon

まあ Leopard のあいだは Adobe / Microsoft と対決しようということだとおもう。
ppc 時代の intel 用 OS X と一緒で、Apple 内部では 64bit Carbon GUI はいちおうメンテナンスはしておくのだと思われるので、旗色が悪ければ 10.6 が出るときにまた 64 bit Carbon を配布すればいいだけの話だし。

どうなるかは今後の業界の勢力図によりけりですね。

>>488
へえ　こりゃ面白い話だ
Appleもまだまだ戦ってるってことだね
面白い

>>488
全部は揃ってない。代表的なのだとQuickTimeもまだ。
64bitアプリケーションからは超貧弱なObjCのQTKitしか使えない。
あとCarbonに近いけどATSUIなんかもNG。まあこれはCoreTextとかいうので
お茶を濁されたようだけど。

>>462
>>484
過去ログぐらい嫁よw
64bit 化＝高速化ではないことも、カーネル部分が 64bit モードの 32bit 互換モードであることの必然性も、全て既に書かれているのに、何そのボケたコメントは？

>>477
>今回のLeoのカーネルに不満を持つ人って、どういう考え方なのかな？
基本的に、無知な糞ドザが煽ってるだけかと

MacOS X ですでに Apache 2、MySQL 5、Postfix、Podcast Producer、QuickTime Streaming Server、Java VM on Intel あたりは 64bit 化されて動いている訳だが。

>>488
傑作なのはCocoaも64bit Carbon GUIを一部使っているので、現実には削除できず
製品版Leopardにも内緒で存在すること
64bit版Xcodeは存在しないはずの64bit Carbon GUIも使って動いている。

64 bit Carbon GUI をつかってるのはメニュー周りだけだと聞いたんだけど、
Xcode はそれ以外にも非公開 64bit Carbon GUI をつかってるんでしょうか？？？

ここまで読んでわかった事は、チェスは64bit化するメリットが十分にあったから
64bitバイナリがついてきたって事ですね。

>>494
そのとおりだ。
実際チェスを見てわかるとおり
メリットがあっただろ？

あの程度だがなｗ

単に64bitコンパイラでビルドしなおしただけだろｗ

チェスが64bit化されてるのは64bit版OpenGLの検証用でしょ。

Adobeひどいよ・・・

「郵便受けに入れられた、64-bitの誇大広告をみんなチェックして
みよう。（64-bitアプリは）もっと大量のメモリをアドレスできる。
だいたいこれだけだ。64-bitアプリケーションは、メモリアクセス
が速くなったり、その他のアプリケーションのパフォーマンスを改
善したりするような鍵を、魔法みたいに手に入れるようなことはない。」

>>498
Adobeは、独占状態で競争が無いから余裕ぶっこいているだけ。

>>491
お前もういいから引っ込んでろよ。
頭が弱い自覚のないやつは救いようがないな。

>>500
糞ドザの反論は相変わらず肝心な中身がないな

>490
それは意図的に取り除いたんだよ。
ATSUIはOS9からの遺産だし、QTもQuickDraw依存部分がある。
それら全部レガシー部分は移植しないという決断でしょ。
Quartzを利用することと、○○kit系、Core系を使いましょう
ってのがOSXのトレンドだからそれに沿った方針。

64bit対応するだけでライブラリ総とっかえ。
こりゃ開発者も裸足で逃げ出す罠。

>>502
今後QT APIが64bit化されずにラッパー経由でしかアクセスできなくなるなら
暴動ものだと思うよ。それほど現在のQTKitのAPIは貧弱で自由度も皆無。

64bitが主流になる頃にはQT API自体の64bit化が進んでる物と思いたい。

>>502
あ、ちなみにATSUIも部分的には64bit APIが提供されてるので
これもそのうち増えるのかなあとかは思ってたりするけど。

>>503
総とっかえなのは当たり前。ABIが違うんだから。
問題は32bit APIと同じインターフェースが
64bit APIにどれだけ提供されるかという点。

現状のOSXだと旧MacOS由来のAPIをできるだけ避けないと
64bit化に苦労する/そもそも64bit化が不可能になる。

>>502
そんな単純な話ではない。
CoreTextはATSUIの簡略化版で基本的な機能しか無く、ワープロ的な物は作れない。
QuickTimeのQuickDraw依存はQT7で払拭されている。
削除されたことになってる64bit Carbon GUIはレガシーな物ではなく、OSX10.2で
Quartz対応に新しく作った部分、古くからのCarbon由来APIは64bit化されてる。

まあとにかく完全 64bit ready という Apple の marketing-speak が言い過ぎなんだけども...

一応データを大量に扱う科学技術ソフトの GUI 部分は書けるようになったよということだと思う。10.6 では QtKit も CoreText も充実されるんでしょう。

OSXの64bit対応自体がmarketing-term

>>503
一瞬、納得しかけたが・・・ちょっと待て
64bitに対応させるのにライブラリ総取っ替えって当たり前じゃないか？

もはやドザが何を煽ろうとしてるのか
ドザ自身が分からなくなってきてるなｗ

流れが読めてないなら無理してレスつけんでも

「ライブラリを総とっかえ」という日本語が何をさすかで煽り側と煽られ側と流れが読めてない人とで話が通じてない気がする

んなもんAPI が全部 32 bit 版と 64 bit 版あったとしても、リンクするライブラリファイルの実体は違うんだからそれを総取っ換えといえなくはないけど、そんなことあたりまえなので、

たとえばある仕事をする API A と B があるんだけど、
64 bit では API B しかないから、API A つかってたひとは API B にかえなきゃいけないのかどうかとかそういう問題でしょう。
それの手間がとれぐらいかかるか、そもそも 32bit 版の段階で API A と API B をつかってるひとが何割ずつぐらいかとかそういう。

UBのフレームワークは見た目上の実体も一つだけどね。

ユニバーサルバイナリって実体はひとつに見えても
実はひとつのファイルに32bit版と64bit版の二つを
圧縮しているのと同じようなものらしいね。

だから、ファイルサイズはターゲットCPUが増えるごとに
倍増するし、128bit CPUが出た場合に
128bit CPU向けに再コンパイルが必要になる。

何を今更...
まあ圧縮すらしてないけど。
% lipo -create ppc_binary ppc64_binary i386_binary x86_64_binary -output univ_binary

>>514
同じようなもの「らしい」じゃなくて、単に同じ。
あと、圧縮してない。

また、最近のソフトは画像とかが多いから、
バイナリ自体のサイズは大したことがないので倍増してもあんまり関係ない
例:
Safari .... 56MB 中バイナリは 2.9 MB

Safariに限らず、国際化されたアプリは言語毎のファイルが大半だね。

特に Universal Binary である必要がないなら、
ttp://www.xslimmer.com/
ttp://www.macupdate.com/info.php/id/20404
こんなツールもある

もう8bitでいいじゃん

>>519
それでもVVindowsを凌駕しちゃうよ

Windows Vista 搭載機を量販店で買ったら、32bit 版しか売ってないって本当ですか？
MacOS X はもう 64bit クリーンだと言うのに、ビックリです。

64bit クリーンって何？

http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/64bitPorting.pdf

- 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.

クリーンか。
シャープのMZみたいなやつだな。

>>523
でも、実際はcleanじゃなかったと。

>>525
単に頭悪いのか？
64bit clean だぞ

実際Vista64bit版の恩恵にあずかっているのはホワイトボックスユーザーか
自作ヲタたちだけ。しかもドライバの互換性に苦しんでいる。

メーカー製PCは64bitをサポートするつもりはさらさら無い。

>>527
Leopardなんてそもそも、互換性が問題になるもならないも64bitのドライバ自体が・・・

って事なので比較は不適格。
64bitドライバへ移行がスムーズに出来てるならともかく。

このスレで4GB越えのメモリを搭載している人の割合・・・1%
このスレで4GB越えのアプリを使っている人の割合・・・0%

>>527
普通に製品リストにあるし、サポートされているけどな。嘘はいかんでしょう。

http://h50146.www5.hp.com/products/workstations/personal_ws/xw4400ct/specs/windows.html
http://configure.apj.dell.com/dellstore/config.aspx?c=jp&cs=jpbsd1&l=ja&oc=7072B109&s=bsd
http://www.express.nec.co.jp/workstation/products/50/54cb/index.html
http://www.fmworld.net/biz/celsius/products/200710/lineup/n460.html?fmwbfrom=celsius_top

まぁそれらは本当に働く64bitマシンというのがアップルとの違いか。

>>530
普及用の安物PCを前提にしていたわけであって、ワークステーションの事は
考えていなかったよ。しかしどれもMacProよりも性能の低いモデルばかりだな。
これでワークステーションと名乗っているのだから面白いな。
まあ、値段相応って奴なのか。

ちゃんとメモリ64Gとか128G載せられるXeonモデルも別にあるから心配するな。

>>532
3点。もう少し頑張りましょう。

　　　　　　　　　　　　　　　　　　　　|
　　　　　　　　　　　　　　　　　　　　|　自分たちが買えないワークステーションを自慢しているドザが荒らしている件について。
　　　　　　　　　　　　　　　　　　　　|
　　　　　　　　　　　　　＿＿__　　　.|　　　　　　　　　　　　　　　　　ミ /〉__人__
　　　　　　　　　／￣　　　　　　｀　 ､￣￣￣￣￣￣￣￣￣￣￣　 //　）　 （　ﾋﾟｼｯ￣￣￣￣
　　　　　　　,. ‐'　　　　　　　　　　　　` ｰ-､　　　　　人_　　　　　ミ//　　｀Ｖ´
　　　　　　/　　／ ／　　　 /　　　ｉ 　 　 　 ＼　　　｀Ｙ´　　　　　 //
　　　　　/　　/　/　 ／　／　　　　|　　 ＼　　',　 　_!_ 　 　 　　 //
　　　　　|　　|　 T ´厂 ｢`ﾒ　／　ｉ_｣_　　　 ｉ 　 | 　 　! 　 　 　　/,ｲ　　_!_
人 　　　|　　|　　|ｒ坏ﾃﾐﾘｉｲ/ ／ ｢ﾉ ｀ﾒ､　 | |　| 　 　 　 　 　_///　　　!
'Ｙ´　　　|　　|　　|　ﾄｒ:::ﾘ　 ∨　ｒﾃｉ{∨/　 / |/ﾘ　　　　　　 ///,ｲ
.　　　　/　　∧　ﾊ　ゝ‐'　　　　ﾊｒ:ﾘｲ/__ノ/　　　　　　　 ノ//.ﾉリ　　_!_
　＊　/　　/ .∧　 ヽ 　　　__ '　｀'´　ﾊ　　 ＼　　　　　　{〈/ﾚﾚﾍ}　　 !
　__／　　/　/ ∧ 　　',　{　　ﾉ　　　.ﾊ ＼ 　　＼ 　 　　 |　/ ` /
´　　　　/　/⌒ﾏｉ　　　',.　　　 _. ｨ　　＼　＼　　＼ 　 　|｀ ｰ-く　　　＊
　 　 　_＿/::::::::::::ｉ　ｉ　　ｉ`　ｆ´､::＞'⌒::＜ヽ　ヽ　　 ヽ ｒへ　＿/
-‐　 /::::::::::::::::::::ノ　 ｉ 　 |.＞ｒ‐ｒ|:::::レ-―┴'　 _＿__,ﾉ |　　　　 〉　*
.　　/:::,. ―‐' ´　-‐ '' 　 |::＼女|::/　　　　　,＜ 　（　　|　　　　 |＿_
／ {:::::|　　/´　　,. -―::く::＼ �X::|　　　　　｛:::::::＞､｀ｰ|　　　　 |､　　＼
　 /:::::ﾊ　 ｉ.　　（::::::―:::―::‐- !::∧　　　　　＼:::::―`ｰ|ﾉ|从 　 |__ヽ　　＼
. /:::::::::::ﾍ.　＼　＼:::::::::_:_:::／／＼＼　　　　　　￣￣　　 /　　|:::::::＞ ､　ｉ
/:::::::::::::::::∧　 ＼. ＼ー::‐:／ｉ!　　　`ｒ＼　　　　　￣　 ／　　 /:＊:::::::::::＼
::::::::_::_:::::::-:ｉ}　　 ヽ.　Ｖ／　 .|!　 ｉ.　 i!　 '＞､__＿＿／　　　　|:::::::::人:::::::::::＼

OCNアク禁されて悔しい。

ヌケマカはニセ64bitOSのMacOSをいつものペテンで買わされているわけだね。
まったく笑止千万だな。
まあ、騙されるアホマカが悪いんだけどね。

一般用途では64ビットOSの必要性はないね。

>>535
どっちが荒らしなんだか。ﾌﾟ

>>538
今のところはその通りなんだが、そうなるとOS Xの64bit部分はほとんどのユーザに
とって必要がないのに金を払っていることになる。
Windowsのように32bit版と64bit版を完全に別製品として、ユーザの選択に任せて
いればこういう問題も無いんだが、複数の版を同時に展開する能力がないのだろう。

>>539
>今のところはその通りなんだが、そうなるとOS Xの64bit部分はほとんどのユーザに
>とって必要がないのに金を払っていることになる。

値段はほぼ据え置きで 32bit と 64bit の両方（更には別のCPU）のバイナリも
付いてくるんだから、ちょっと違うような。そういう点ではある意味「おまけ」?

あと、Mac OS X はすべてのエディションが同じ価格に据え置きでございますw

ま、細かいこと言えば、32bit 版の値段に 64bit 版開発費用の回収分が含まれている
かもしれないのだし。ま、これは MS、Apple に限らないことだが。

『Vistaですべての機能を使うにはUltimate版をお使いください。』馬鹿げた仕様だこと。

ちなみに、最も普及しているHome Premiumでは64bit版ですら最大メモリが8GBに制限
されている。Leopardはそのような事はありませんから。

似非64bit かどうかはしらないけど、
とりあえず計算とかで 64 bit モードでコンパイルすると 3割増しぐらいのスピードになってるのは実感できるよ。
1時間かかる計算が40分になったら案外役に立ちます。

>>541
またうそをつく。
http://pc.watch.impress.co.jp/docs/2007/1127/hot517.htm
> Windows Vista Home Premium 4GB 16GB

> されている。Leopardはそのような事はありませんから。
Leopard自体には制限無くても、
ハードウェア的にスロットが無い・対応していないから
結局は同じことじゃん。MacProでさえこれ↓↓↓

http://www.apple.com/jp/macpro/specs.html
> 2枚のメモリライザカードに8つのFB-DIMMスロット
> （1枚のカードに4つのスロット）／最大16GBのメインメモリをサポート

なぜいきなりハードの話に...
まあMac Proも実は4GBx8で32GB積めるんだが

>>543
Basic と Premium とを勘違いしていたよ。orz…

しかし、ほとんどのマザーボードは8GBしか認識してくれないだろう。
>>543のリンク先にそう書いてある。

それ以上はXeonマシンでないと無理だという事がMacProで証明されている。
まあ、16GB以上のメモリをFB-DIMMで購入したら価格が凄い事になりそうだ。

とても個人では買えないな。

>>545
無知と勘違いを晒して恥をかく前に少しは推敲したらどうだろう？

最大メモリ搭載可能量は、使用されるチップセットの仕様によりメモリ種別とソケット数の上限が
決定される。MacProが証明しているとかは全く無くて、チップセットの仕様通り。
いまのところIntel製はXeon対象の5x000シリーズが8GBを越えるメモリをサポートしているだけ。
http://compare.intel.com/pcc/showchart.aspx?mmID=28047,24663,153,140,5723&familyID=9&culture=en-US

Appleのオナニーに振り回されて悲惨な事になっちゃったね・・・
64bit化の前にもっとやる事があっただろうに・・・

http://www.agenda.co.jp/press/ATN15MC1/DLcontents/ATN15MC1_20071210.pdf

株式会社アジェンダは12 月14 日（金）発売予定の弊社製品Macintosh 版年賀状ソフト「宛名
職人Ver.15 DVD 版」、「宛名職人Ver.15 アップグレードDVD 版」および「宛名職人Ver.15 ダ
ウンロード版」の発売日を12 月28 日（金）に再度、変更します。なお、製品内容に変更はござ
いません。

発売変更の理由
社員一同、「宛名職人」の15 年目の躍進に向けて取り組んで参りましたがユニバーサル
バイナリ化のプログラム設計に苦戦し、現段階でお客様に満足して提供いただける状況
に達していないため。

いやこれは単にそこの開発者が無能なだけじゃね？

>>542
そういえば Web ブラウザを再コンパイルして JavaScript のベンチのサイトを
使ってみたら、3割ぐらい速い結果が出た。ちょっとうれしい。

あと、 >>437 に書いてあるような理由で、ディスクの I/O なんかも速くなるかも。

>>548
同意。
64bit 化じゃなくて、エンディアン依存な処理をちゃんとできてないと推測。
バイナリデータの読み込みとか。

>>548
いやこれは、Appleの無節操なアーキテクチャの変更とまともな開発サポートもドキュメントもないこと
による零細ISVの被害の一例だな。こうやって撤退していくんだよ。ｗ

本来なら使い勝手を向上させる事にリソースを集中したいのに
いつまで経っても土台が液状化してグラグラ揺れていて
基礎工事にコストを費やさないといけないからね。

>>551-552はボーナスなしを食らったアジェン◯の無能開発者

>>547
12月28日に販売開始する年賀状ソフト・・・

>>547
> 発売変更の理由
> 社員一同、「宛名職人」の15 年目の躍進に向けて取り組んで参りましたがユニバーサル
> バイナリ化のプログラム設計に苦戦し、現段階でお客様に満足して提供いただける状況
> に達していないため。

>>548
>いやこれは単にそこの開発者が無能なだけじゃね？

日本語からして無能なわけだしな。
「提供いただける」ってなんて日本語？

>>550
違うでしょ。そんな事で発売を遅らせるのは流石におかしい
CFM CarbonからMach-O Carbonへの移行に手間取ったと想像

ソースコード自体はそんなに書き換えなくて良いけど
IDEを変えなきゃいけないから手間だけはかかるんだよね...

宛名アプリごときのUB化に苦戦だもんな・・・
これが3年も4年も前の話ならまだわからないでもないが・・・
Mac OS Xが登場してから、もう7年だぜ？

intel 変更で Xcode への変更を余儀なくされてからでももう丸二年たつよね。
きっとデスマーチなんだろうから二週間ぐらい予定を先延ばししてもどうしようもなかろうに ... プログラマの皆さんはご愁傷様です

>>549
つーか64bitで動かせるブラウザって具体的に何?
Mozilla系は無理だし、WebKitを使った自作のブラウザか何か?

シイラならソースが公開されてるから、再婚パイルできるんじゃね？

あ、Xで動かすならMozilla系でもまあアリか?

>>560
ああシイラがあったね
WebKitはデフォルトで64bit化されてるんだよな...流石に

/System/Library/Frameworks/WebKit.framework$ file WebKit
WebKit: Mach-O universal binary with 4 architectures
WebKit (for architecture ppc7400): Mach-O dynamically linked shared library ppc
WebKit (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64
WebKit (for architecture i386): Mach-O dynamically linked shared library i386
WebKit (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
/System/Library/Frameworks/WebKit.framework$

>>556
俺も CodeWarrior -> Xcode (同時に CFM -> Mach-O) やったよ。確かに楽じゃないが、
かといってリリースを送らせるほどかなあ。ってゆうか未だに CFM だったのか。

俺がやったときは、コードに関しては確か C++ の挙動の違いで少しハマッた気が。
あとバイナリデータの処理で少し。で、カスタムリソース用にバイトフリッパーを書いて...
一番厳しかったのは元々人が書いたコードだったことだけどw

>>559
ちなみに
Camino -> 64bit で消滅した Carbon の部分があるので、そこを書き換えないと駄目。
シイラ -> ほぼ Cocoa だけど（FSSpec とかもあったかな）、いろんなハックが入っている
せいで Leopard でコンパイルを通すのが一苦労。さすがあの作者さんのことだけはあるw

とりあえず実際にテストしたのは自前の WebKit ベースのなんちゃってブラウザ。

>>546
その程度の事ぐらい分かっているよ。ただドザ機では最大8GBしか扱えないのは
事実だろう。チップセットの影響で。それ以上のメモリを扱いたければXeonを
使えって事ぐらい。

それMacも同じじゃね。

>>566
おまえMacは特別だとでも思っているのか？なかみは台湾製のPCそのものだろ。
それにMac Proよりも高スペックのPCなんていくらでもあるんだぞ。

まったく、このスレもクソスレ化してきたな。

>>567
誰も、Macだけ特別と言っていないし。逆に安価で8GBの環境が手に入る
Windowsが羨ましい事もある。MacProはメモリが高いからね。

>>568
いくらでもMacPro以上のワークステーションがあるのはいいが、個人で
買える代物でないだろう。君はそんなに金持ちか？

>ただドザ機では最大8GBしか扱えないのは
>事実だろう。

>まったく、このスレもクソスレ化してきたな。
禿げ上がるほど同意

>>569
ま、少なくともクズMacProのようなペテン物は誰も買わない。

>>571
そういう者に限って、使っているのはCeleronマシンの32bitOSドザ。
まあ、貧乏人には買えないよな、Xeonマシンなんて。

つ　Dell鯖

ワークステーションを名乗っているマシンはどれもMacProと一緒で
BTOするととんでもない価格になる。

っていうかハードの話はスレ違いだから、もうやめにしないか。

>>569
Quad機ならMac ProよりもPCの方が安いだろ。ｗ

もうちょっとしたらMacでもPCでも今よりは安く大量にメモリ積めるようになるから
兄弟喧嘩するのやめよ☆

>>572
> まあ、貧乏人には買えないよな、Xeonマシンなんて。

Xeon搭載機なんて10万円程度からあるじゃん。
もう少し値段を調べてから発言したほうがいいぞ。

MacProの値段があれば、それと同等以上のマシン手に入るってｗ

64bitのメリットはまったく享受できずデメリット（開発者離れ、ソフトウェアの延期等）ばかりが強調される結果に終わってしまったな。

大容量メモリを搭載できないMac
http://pc.watch.impress.co.jp/docs/2007/1211/hot519.htm

最大の難点はメモリをたくさん搭載可能な製品がないことだ。
FB-DIMMをサポートしたMac Proは別として、現行のMacはモバイルアーキテクチャをベースにしているため、
メモリ搭載量の上限が4GB止まりとなる。4GB＝32bitということであり、
せっかくの64bit環境を生かし切れない印象だ。

>>578
ソフトが先かハードが先か、それだけの話
そうきっちりと足並みが揃うものでもないし、
単に時間の問題だよ。

Macは準備出来てるじゃん。

>>576
ドザ兄弟じゃないし
未だにBIOS積んでるようなPCもMacの兄弟じゃないw

メモリ2GBの MacBook Pro でも、数値計算するときに 64bitモードで使えば1.5倍はやくなる ... というのは利点ではありますよ。

まあ数値計算を個人のマシンでやってるようなひとは大学ぐらいしかいないでしょうけど ...

ユーザーのプログラムが使えるメモリは、32bit だと実際には OS の制限によって
2GB 前後（詳細は OS 毎に異なる）。下手すると 1.5GB ぐらいとか...
だから実メモリが 4GB 以下でも 64bit の意味はある。

>>582
> メモリ2GBの MacBook Pro でも、数値計算するときに 64bitモードで使えば1.5倍はやくなる ... というのは利点ではありますよ。

ちなみに、1.5倍も速くなるというのはどんなプログラムだろ。

>まあ数値計算を個人のマシンでやってるようなひとは大学ぐらいしかいないでしょうけど ...

昔は数値計算を計算機センターでやっているような人は大学に多かったわけだが...
今は個人のマシンでかなりできて、ベクトル演算もあるし、計算によっては GPU も使える。
ある意味すごい。強いて言えば電気代が心配（研究室で使えば無問題?）

>>578は、Macの欠点だけ指摘しているようだが。

　ソフトウェアの動作そのものには問題がなくても、64bit版はサポート対象外に
されていることも多い。この理由を端的に言えば、64bit版が普及していない、
ということに尽きる。量販店の店頭を見ても、Vista 64bit版が搭載されたPCなど1台も
置かれていない。普及していない環境をサポートするのはPCベンダにとっても負担だし、
ましてやソフトウェアの動作検証をしても報われない。というわけで64bit版の普及は
遅々として進まないというのが実情だ。

　実際、Microsoftの対応を見ても、どこまで本気で64bit環境への移行を進めようとしているのか
ハッキリとしない。Ultimateを除き、Vistaのパッケージに64bit版のメディアが同梱されていない
こともその表れだ。Microsoftのアプリケーションで64bit版への対応を謳うのはサーバーアプリケーションだけで、
Officeなどクライアントアプリケーションに64bit版は存在しない。手段を選ばなければ、
64bit版の価格を32bit版より少し低く設定するだけで移行するユーザーは増えると思うのだが、
そうした様子もない。どうもMicrosoftは Vistaへの移行を促すのに手一杯で、64bit環境への移行に
まで手が回らないようだ。

>>578
Macの64bit化が進まないって貶めるためにその記事貼るって思考回路はどうよ？
しかもMacProなら問題ないとも書いてあるし・・・

まあ、糞ドザがどんなに涙目で嘘を巻き散らかしても、MacOS X は全ての
PowerPC G5/Core2Duo/Xenon ユーザーが 64bitを享受できるのに、
Windows は 64bit 版というほとんど誰も使わないモノ
を無理矢理使うしかないのが現実。

>>587
予想されるドザのレス。

何言っているんだよ！！Leopardなんてカーネルが32bitの中途半端なOSじゃないかww
マカ涙目www

一足先に言っておいたぞ、ドザの諸君。

Vistaでは機能をフルに扱うのはUltimate版を購入しないとダメなんだよね。
XP Proでリモートデスクトップ使っているのだが、Home Premiumでは
クライアントでしか使用できないんだね。

Leopardではひとつのエディションでフル機能使えるのに…。
MSも変な機能の切り売りなんかしなければいいのに。

64bit版と32bit版とを分けたのも、一種の切り売りみたいなものだろう。

現行世代のモバイル向けMeromと次のPenrynでは
64モードの実効性能が低いから、
Mac Pro以外の今の機種で使う上では、
32ベースで最低限64対応のLeoのkernel／driverで
充分じゃないかと思うんだが

来年のNehalemで改善されるけど、まだ先の話だし、
ハイエンドからゆっくり浸透させる計画みたいだから
時間的にも余裕有るんじゃない？

その頃になると、10.6の足音が聞こえて来てる筈

68K＞PPC＞G4＞G5＞intel

ハードの準備が出来てからOSが対応してソフトが対応。

>>585
無駄に長々と引用する必要も無いし、常識として引用符ぐらいつけろよ初心者くん。

秘められた"真の革新"を暴く - the inner universe of Leopard
http://journal.mycom.co.jp/articles/2007/12/11/iul01/index.html

the inner universe of Leopard - 「rcの引退とlaunchdの強化」
http://journal.mycom.co.jp/articles/2007/12/11/iul01/index.html

>>578
ここは省略？

> 今、64bit環境への移行が着々と進んでいるのはMac
> OSの世界だ。最新のMac OS X Leopardではライブラ
> リである“Cocoa”も含め、OS全体が64bit化され、その
> 能力を持ったMac(Core 2 Duo搭載Mac)では自動的に
> 64bit環境が利用される。

無料のLinuxやSolarisの方が進んでるけどね。

>>592
結局反論できないんだ。MSの政策の愚かさに。

>>589
>64bit版と32bit版とを分けたのも、一種の切り売りみたいなものだろう。

それならまだ話はわかるが、Windows 64bit版を使ってみりゃわかるよ。
・64bit ドライバがないと 32bit アプリも動かない
・通常使用ではメイン環境ななる32bit アプリが遅くなる
・64bit アプリと 32bit アプリの両方があっても平行して動かない
ttp://ja.wikipedia.org/wiki/WOW64
この顕著な例として、Internet Explorerの振舞があげられる。32ビットの
ActiveXコンポーネントを検出すると、64ビット版Internet Explorerは処理
を中断して32ビット版Internet Explorerに処理を引き継ぐ。32ビットアプリ
ケーションと64ビットアプリケーションの間には、実行ファイル以外のコン
ポーネント群を互いに利用する事が出来ない深い溝がある。

要はどうしても64bitが必要という用途以外には使い物にならないんだよ

ええっと、Leopard も 64 bit アプリから 32 bit のプラグインは読み込めないんだけど。他人をけなすのもいいけど、そのときは自分がどうかをきちんと認識してください。

まあ基本的に Apple は、32bit 版と 64 bit 版を区別せず、すべてのバイナリ、plugin は universal で組むようにと推奨しているので、プラグインが全部 32 bit 版 64 bit 版そろってればいいわけだけどね。

それ以前に、64bit版では32bitのアプリが動かないから。デュアルBoot環境で
Windowsを使っているって事がバカらしくない？

わざわざ再起動しているんだよ。MacOSとWindowsならともかく同じWindows同士で。
Leopardなら少なくても64bitだの32bitとかの区別はユーザーが気にする必要がない分
現状ではまだましかも。

>>599
>それ以前に、64bit版では32bitのアプリが動かないから。
?

Vista のことはわかってないんですが、WOW64 って Classic みたいなかんじに、64 bit Windows 内で 32 bit Windows 用プログラムが動くのであって、再起動の必要はないんでしょ ???

>>528
>Leopardなんてそもそも、互換性が問題になるもならないも64bitのドライバ自体が・・・

ドザは頭が悪いから、64bit clean な MacOS X にはどうしても 64bit ドライバが
必須だと信じて疑わないらしい。MacOS X のドライバはちゃんと 64bit モードで
動くアプリでも動作するのに…

>>598
プラグインの話は Windows も一緒
プラグインが関係ないソフトも多い
アプリケーションローカルな話だろ

情報は出尽くして後はいつものMac親衛隊によるスレ嵐か

現実を認められないドザが来ちゃいました

>>602
>MacOS X のドライバはちゃんと 64bit モードで動くアプリでも動作するのに…

意味がわからん。
この文脈でドライバとアプリと64bitの関係は？

何故に自分で開発した訳でもない末端ユーザーのくせに双方は罵り合うのですか？
自分の好きなのを使えばいいじゃん。

>>599
WOW64で動かない32bitアプリの方が少ないだろ。ｗ

スレ前半は良スレだったのに、最近の劣化ぶりは見るに耐えん
最低限このスレ内の過去レスくらい目を通して欲しい

Winとの比較で煽り合いしたいだけなら、このスレでなく他のスレでやってくれ
Win板で"Mac"、新Mac板で"Win"で検索すれば、
相応しい釣り堀スレが沢山見つかるだろうに

窓遣いは Mac OS X をどう見るか【第19ラウンド】
http://pc11.2ch.net/test/read.cgi/win/1196539823/
とかな

>>606
>この文脈でドライバとアプリと64bitの関係は？
スレ前半を読み直せ

>>607
罵るから罵られる

ごめん、さんざん的外れなこと言ってたんだが、さっきようやく
誤解の根本的な原因がわかった。

Mac OS Xでは、カーネルとユーザープロセスが
同一の論理空間を共有しない！！！

これなら確かに32ビットカーネルで64ビットアプリケーションを動かせる。
カーネルやデバイスドライバーでDMAとかMMUとか小細工が必要なところは
あるんだろうけど、そのくらいは適当なサンクをかませればどうにでもなるだろうし。

>>612
今ごろ何言ってんだ？このバカ。

>>612
初心者は初心者スレへ

盛り上がっているところにすみませんが、Leopardでインターネットの
設定が出来ない。どこか分かりやすい所はないでしょうか？
教えて下さい。

>>615
アップルサポート

>>597
ブラウザなんて32bit版が問題なく動くのに何も困らないだろ。
ところでSafariはいつ64bi化されるんだっけ？

>>615
mixiでkusakabeさんに教わる。

結局は
レガシーな32bitを残したままの中途半端64bit Leopardがいいのか
レガシーフリーの64bit Windowsがいいのかってことですよね。
レガシーが必要な人は32bit Windowsってことで。

↑馬鹿発見。スレを最初から読み直せ。

>>612
とりあえずおまえがどのレスを書き込んだか列挙して取り消せ

まったく、前半のアカデミックな流れに対してこのクソスレ具合は一体何なんだ。
みんな書き込む前に、このスレの前半を読み直すんだ。

まあ、バカには分からないのだろうが、意味の分からない者はこのスレに来るな。

マカでみっくみくな流れ？

>>617
Safariが64bit化されて32bitプラグインが全滅したら、今度はどういう手のひら返しが
見られるんだろうな。ｗ

>>624
それを言ったらIEだって一緒だろう。
ttp://pc.watch.impress.co.jp/docs/2004/0528/ubiq65.htm

>>625
それぐらい知ってるし常識だろ、空気嫁というよりスレ嫁、低脳。

なんかすごいループしてるんですが、ここも凄い物スレみたいにペヤング漬けになってしまうんでしょうか。

一長一短あるから、どっちが先に普及するか、見物だね。比率でしか比べられないけど。

このスレのMacユーザは64bitには意味が無くて32bitで十分って思ってるんだろ。
俺は64bitが普及してくれた方が嬉しいけど。

>>629
どこをそう読むとそうなるんだ？

64bitその物は普及して欲しいが
今の普及してない状況でOSだけ64bitになっても意味ないって話だろ？
しかも、基本的には今のOSで十分64bitの恩恵が受けられるのに何が不満なんだ？
ってのがMacユーザの言い分

レガシーフリーじゃないMac

ドザは日本語すら読めないのはよくわかった

人間性を疑いたくなるひどい差別発言をあちこちに書き込むMacユーザー。
これが単発ならまだしも、日々繰り返しいろいろなIDで書き込まれている。

その一例がこれ。
どうしたら「障害者＝税金泥棒ニート」のような発想に至るのだろうか。

http://pc11.2ch.net/test/read.cgi/mac/1186334512/301

301 ：名称未設定：2007/09/13(木) 09:51:05 ID:e8RxPJAy0
　　　　　　　　　　　　　　　　　　　　　　 ||
　　　　　　　　　　　　　　　　　　　　　Λ||Λ
　　　　　　　　　　　　　　　　　　　　（ / ⌒ヽ
　　　　　　　　　　　　　　　　　　　　　| | 　　| ←車椅子ドザ＝朝鮮人
　　　　　　　　　　　　　　　　　　　　　∪ / ﾉ
　　　　　　　　　　　　　　　　　　　　　 | ｜|
　　　　　　　　　　　　　　　　　　　　　 ∪∪

　　　　　　　 ┌─────────
　 ∧＿∧　＜ 　さよなら障害者＝税金泥棒ニート
　（ 　　　,,）　└─────────
　（ ○ 　 ）　　∧ ∧　┌─────────
　 |　| 　 |_　 　(　　,,) ＜あ〜せいせいした
　（__(＿＿）　 /　　|　 └─────────
　　　　　　　 （＿__/

>捏造アスペル坊やの特徴
>・ 1 同じコピペを執拗に貼り続ける。自演のパターンが同じ。ワンパターン。基本的にage。
>・ 2 短時間に、ある意見に同調したレスを続けて書きこむので、いる、いない、自演がわかりやすい。
>　　　IDをコロコロ変える。携帯電話を使い自己擁護レスをつけまくる。そのため複数いるように見えるが「一人消えると全員消える」不思議な現象が起きる
>・ 3 間違いを指摘されるとなかったとしてシカト。厚顔。
>・ 4 しかしATi信者の間違いを指摘されるとどんなに些細でも執拗に繰り返し攻撃。コピペ。忘れない。粘着質。
>・ 5 RADEONに関するトラブル、その他不利なことは必死に擁護。必死になかったことにする。。そして几帳面に整理してコピペされると泣く。
>・ 6 自分の攻撃が破綻するとスレからいなくなる。
>・ 7 どういうわけか偉そう。自称天才。
>・ 8「妄想」「無知」「バカ」「真実」「証明」「挙証責任」を証明されると泣き喚く。
>・ 9 RADEONのことを「チートオン」「CHEATON」、ATiのことを「チーティーアイ」「CHEATY-EYE」と呼ばれるとまた必死で言い訳する。
>・10 体言止めのレスを書くことが多い。名詞で文章を終えるレスを連発。
>・11 単語を「」でくくって使うことができない。チョンなので日本語が読めない。
>・12 断定口調じゃなくても議論だと考えている。証拠もないのに断定する。自分勝手に妄想。
>・13 自分をアスペル坊やと呼ばれるのが嫌いで、他人ををアスペル坊やと呼ぶ事が多い。
>・14 何故か”アスペル”を使いたがる。 "アスペル"と呼ばれると非常に狼狽する。
>・15 相手の発言をコピペ改変だーとか言って泣き(この紹介も元はアスペル坊や)無駄にスレを消費
>・16 チートオンが故障した証拠を出されると捏造と言うが、　わりにGeforceの故障捏造画像は　　無条件に　　信用します
>・17 シリアルナンバーを出せといわれると逃げるかニセのナンバーを出す バレると逃亡

>>630
Macユーザの本音はこうだろ。
まともな64bitアプリが皆無で完全にWindowsに遅れをとっているのはうすうす感づいて
いる。しかし口が裂けてもそれを認めるようなことは言えないストレスから、>>597の
ような言いがかりつけるしかないんだゆ。だな。

もうねWindowsの完全勝利でいいし、マカーはバカでいいからさ
中身のある話をして欲しい。

キチガイマカー代表より。

なぜageるレスと基地外のレスは常に一致しているのか

じゃあ中身の有る話ということで、
Leopard のカーネルを語ろう

http://www.opensource.apple.com/darwinsource/10.5/xnu-1228/

Macに64bit用のアプリが無いのはLeopardが出たばかりだからしょうがないと思う。
しかし、Vista64bit版にそれ専用のアプリは出ているのか？主要なソフトは大抵
32bitだし。この数年でどれだけ64bitアプリが増えるかだと思うのだが。

hello, worldすら書けなさそうなのに
狂犬のようにvsしたがる奴ってなんなんだろうね。

LinuxでAMDの64bitのサーバ使ってるけど
苦労してコンパイルする割には32bitとさほど変わりないので結構ガッカリする

>>639
又いい加減な事を書いてやがる。OS XはTigerの時分から64bitネィティブOSだと誇大広告してただろ。ｗ
だいいち64bit Windows用アプリケーションは需要に応じてサーバアプリ、データベース、CAD、CG等と
ドライバも順調に揃ってきているし32bitアプリもほとんど問題なく動作する。
http://wiki.mm2d.net/win64/
http://www.3dvelocity.com/articles/win64compatibility/win64nativesoftlist.htm
http://www.forest.impress.co.jp/article/2006/02/02/64bitwin.html

>>642
良いネタ振りだw
http://www.forest.impress.co.jp/article/2006/02/02/64bitwin.html
>Windows XP x64の、64ビット版のソフト上では64ビット版のIMEしか利用できず、
>同様に32ビット版のソフト上では32ビット版のIMEしか利用できない。
>ソフトによって利用するIMEを手動で切り替える必要がある。
>「あいち」はこの切り替えを自動化してくれる。
Windowsには便利なソフトがあってうらやましいなあ。

いまどきXPの話か

>>643
しかも、解説の意味がぜんぜん違ってるしｗ
http://www.program-lab.jp/blog/progmemo/archives/2005/06/imeaueaoeiia.html

ようは32bit版しかないATOKを、64bitアプリでは(64bit版の)MS-IMEを使うのは仕方ないとしても
32bitアプリを使うときだけはATOKに切り替えたいという話だしｗ

> WindowsXP x64では、ATOKを使用できません。
> 正確には、32bitアプリケーション上では使用できますが、
> Explorerなど64btアプリケーションでは使用不可となります。
> それでも使おうと思うと、32bitアプリケーションではATOK、
> 64btアプリケーションではMS-IMEと、いちいちIMEを切り替えなければならず、
> その手間を考えるとほとんど使うのは無理だと同じに思えます。
>
> でも、やっぱりATOKのほうが使い勝手がいいし、2005にバージョンアップしてから
> ほとんど使っていない状態は勿体ないので、できるだけATOKを使いたい。

そんな自分のわがままを叶えるため、32bit/64bitアプリケーションを判別し、
自動的にIMEを切り替えてくれるアプリケーションを作成したときの作業メモ・・・

>>642
ずいぶん息巻いている様だが、Windows板ではVista64bitで動かないアプリや
ドライバが列挙されているぞ。
一度その手のスレを見てからここに来た方がいいのでは。

>>646
>>642のリンクにあるまとめWikiに全部集約されてるだろ。

>>647
で、君は実際見てきたのか？

IEは64bit版は使い物にならないし、Webでは当たり前のAdobe Flashは64bitには
対応してなくて、仕事では定番のMSOfficeですら64bit版が無い。

リンク先に列挙されているのはただのフリーソフトばかりじゃないか。

WinはSQL Server, IIS, .NETアプリが64bit化されてればさしあたりそれで十分。
デスクトップ用途では意味があるのはせいぜいエンコードくらいだろ。
それにしたってSIMD系の演算やマルチコアに対して最適化した方がよっぽど効果有りそうだし。
自分もコード書くけど自分の用途じゃ16bit->32bitの時と比べるとメリットはほぼないに等しいな。

てかこのスレって自分の体験として64bit化で
これだけメリットがあった、デメリットを被った、〜を待ち望むって話がほとんど出ないのなｗ
まあ1GB程度のメモリつんだマシンのブラウザで罵り合ってるだけじゃな〜んも関係ないしなｗ

SQLとかWebサーバをSIMDで高速化の効果ありとははつみみです

>>648
何回同じ事書けば気が済むんだよ。64bit版のブラウザやOfficeを使わなきゃならない理由を
挙げてみろ。32bit版で十分だろ、低脳。

もうお前は自分が何を主張してるのかも
分かんなくなってるみたいだな┐(ﾟ〜ﾟ)┌>>651

long long int: -9223372036854775808〜9223372036854775807
この数値ほどの規模の変数を一発で扱う計算を多用しているなら演算面で利点がある。
キャッシュメモリが4ではなく8個使えるのでこれによる高速化がいくらか望める。
メモリアドレスが64bitなので4GBの壁が取り除かれるので認識できるメモリ領域が広がる。

あんまり詳しくないけどこんな認識でいいのかな。

メモリのアドレスについては、アドレスそのものが倍の大きさになるので
それで圧迫されるとか書いてあった所も見かけたが、よくわからん。

>>651
なんだ、自ら32bitでいいです宣言か。>>651のような本当は64bitOSなんて
どうでもいいのですというような者はこのスレに来ないほうがいいよ。

いつまでもVista32bit版でも使っていなさい。

>キャッシュメモリが4ではなく8個使えるのでこれによる高速化がいくらか望める

???

LeopardのApacheって、64bitで動いてるのね。/usr/binにもちらほら。

それから、標準IMEのことえりは32bitだけど、64bit起動のXcodeで入力出来てる。

折角なので(657さんは知ってるかもだけど)追加しておくと、
これまで IME はすこしの部分が対象のソフトに plugin みたいなかたちで読み込まれていたので、そのままでは 64bit ソフトから読み込めなくて困ったことになる。
というわけで、Leopard になる際に、InputMethod Kit が出来て、
文字の変換の対象になるソフトに読み込まれる部分は全部 Apple にまかせて、
IME 作者側は IM Kit と通信しつつ変換するソフトを別に作るだけで良くなった。
IME と文字が入力されてるソフト側はプロセスを全く共有しなくなるので、
64 bit ソフトからも 32 bit IME がつかえるわけです

まあそのためには IM Kit に対応しないといけないけど。
とりあえずことえりはapple謹製だから ok。
さいきん egbridge も対応した。
ATOK は知りません、どうなんでしょう？

>>658
その設計変更のせいで、
IMのバグ（「はたけ」フリーズ）がシステム全体の安定性を損ねるという
最悪のデビューになってしまったのが……

IM Kit設計者はだいぶ怒られたに違いない。
まあ次回以降はちゃんと考慮されるだろうけど。

カーネルとユーザープロセスでアドレス空間共有しないとしたら、
システムコールとかDMAとかどうやってるの?
まさかいちいちコピーしてる?

>>660
基本からわかってない。

>>659
ところでシステムのハングがIM Kitのせい、というのは何故結論できるんだっけ?
例のバグでは実際には「ことえり」が暴走していたようだが（で、ことえりが暴走しないように
fix された模様）、IM Kit 導入前だったらことえりが暴走しても困らなかった?
以前の OS X でも、ことえりが暴走したときは結構ヒサンだったような記憶が。

>>662
>ことえりが暴走
しまった、話の流れからしていい表現じゃないね。実際に暴走してたのは確か LAServer
だった。いずれにせよ何からの IPC は以前から存在しているような。

>>662
>>663

2chソースなのでその辺は割引いてちょ。

--------------------
http://pc11.2ch.net/test/read.cgi/mac/1194178716/89

89 名前： 名称未設定 [sage] 投稿日： 2007/11/05(月) 13:28:48 ID:qpsVpFp50
LeopardでIMは独立したアプリで、１つのプロセスが全てのアプリの変換を行う様になった。
いつが無限ループに陥った場合、他のアプリに切り替えると、切り替えたアプリがIMに通信に行く。
IMは無限ループ中なので、返事が出来ず、そのアプリも沈黙。切り替えるたびに沈黙...
--------------------

この書き込みが本当なら、
IM Kitのクライアントサイドの設計ミスな気がする。
サーバプロセスが死んでる場合に備えて10秒ぐらいのタイムアウトを作っておけば
フリーズとまでは言われなかったんじゃなかろうかと

そういや知り合いのLeopardなマシンではたけ実験した時に
Kotoeri.appがあって驚いたな

>>662
いや、システムの構造はそんなに変わってない。
IMKit 以前の IME も、漢字の候補の選択、表示とか全部を対象のソフトのプロセス内でやってたらきりがないので、
相手ソフトに読み込まれる部分は最小限にとどまって、あとは IPC で裏のサーバと通信していてやってる。

裏の LAServer がコケたのは直接は IMKit と関係ないとおもう。
Tiger のときからうちではよく LAServer こけてたけど。なんか変な pdf ファイルをもってたせいで、Spotlight が検索用データを取りだそうと LAServer を呼び出すたびにコケてた。
まあ幸いはたけフリーズほどひどくなかったけど。

egbridge も最新版は egbridge.app だよ

悪いが、ここに書き込むドザはせめてスレを読み直して欲しい
そうすれば自分の書き込みがいかに的を外しているか分かるかと思う
嘘か誤解か分からないようなトボケた書き込みは煽る気すら失せる

ドザは 64bit / 32bit 2者択一だから、互換性を取りたければ狭いメモリ空間を
我慢しなければならないし、64bit を選んだら 64bit ドライバがない周辺機器や
アプリは使えない。
まずはその延長で MacOS X を語ってバカを晒すのはいい加減やめてくれ

まあ、叩かれるべきはダブルスタンダードだろうなｗ

>>658
>これまで IME はすこしの部分が対象のソフトに plugin みたいなかたちで読み込まれていたの>で、そのままでは 64bit ソフトから読み込めなくて困ったことになる。

ふと思ったが、別に IM のモジュールを Universal 化 (64bit も含む）してもいいような。違う?

IM （変換エンジン）部分も別プロセスにするというのは
- マシンの性能が上がったので別プロセスでも大丈夫になった
- 別プロセスにすることによる柔軟性（+ 強固性、のはずなのだが...）
とか?

例えば LAN 上の別のマシンで IM を走らせるなんてのもできるんじゃないだろうか。
IM Kit って DO 使ってるみたいだし。Bonjour でサーバをアナウンスして...
今の速くなったマシンでどれだけ嬉しいかはわからんが。
あ、今の実装がそうなってるかは知らないよ。単なる技術的可能性ね。

もうアホかと

>>667
>ドザは 64bit / 32bit 2者択一だから
??????

>>671
多分、32bitか64bitのどちらか一つしか選べないといっているのでは？
まあ、Vista64bit版でもある程度32bitアプリは動くようだ。WOW64という仕組みで。
ドライバはドザ曰くの64bit用が結構普及しているとか。どこまで本当かは分からないが。

あまり意味不明な事を書いているとまた変なドザが荒らしに来るのでWindowsの話は
あまりしないほうがいい。

>>669
プラグインはなるべく小さいほうがいい、というのは、プロセスを共有しているプラグイン内でエラーが起きると一瞬で本体を巻き込んで死亡するので。
だから、これまでも日本語 IM とかサイズのでかいやつは、プラグインはちいさくて、裏で別プロセスと通信してたわけです。
そういう意味では本質的に変わってません。

ただ、プラグイン部分内ですることはほとんどルーチンワーク (入力された文字を別プロセスの変換エンジンに送って、
結果を受けとってテキストボックスにいれる)なので、そこの部分の Apple によるサポートがすこし厚くなった、
ついでに 64 bit プロセスからでも 32 bit IM がつかえる、というそれだけです

>64bitアプリでは(64bit版の)MS-IMEを使うのは仕方ないとしても
>64bitアプリでは(64bit版の)MS-IMEを使うのは仕方ないとしても
>64bitアプリでは(64bit版の)MS-IMEを使うのは仕方ないとしても

ともかく MacOS では 64bit アプリ中でことえりも EGBRIDGE も普通に
使える。ATOK も Lepard IM 仕様に対応していれば問題ない。
64bit アプリであるかどうかは全く意識しなくて済む

64bit アプリだからこっちの IM、32bit アプリだからあっちの IM と
切り替わることに何の疑問も持たないドザの知能指数が疑問だ

おはやう

>>674
http://www.justsystems.com/jp/os/macosx/
ATOK はまだ Input Method Kit 対応でないから 64 bit ではつかえない。

64 bit 対応のためには IME に何らかの書き換えを必要とするという点では
Apple も Microsoft も一緒で、これに関しては JustSystems がわるい (というか体力あるんだから、そういう企業判断な)んでしょ。

64bit GUIアプリケーションと共にInput Method Kitも用意するのと
ヘンテコな状況放置プレイの間には大きな意識の差があるよ。
Input Method KitベースだとComponent書かなくて済むので、Input
Methodを作り易くしてる意味もある。

>>673
>プラグインはなるべく小さいほうがいい、というのは、プロセスを共有しているプラグイン内でエラーが起きると一瞬で本体を巻き込んで死亡するので。

なんだかマイクロカーネルの話を思い出すけど...
実際にはことえりの暴走でGUIが丸ごとハングしてしまったわけですが... あれ、ことえりだけを
殺してやると復活しますね。launchd のお陰もあるし。

そういや IM Kit の中の人も「IM のデバッグは2台のマシンを使おう」って言ってましたw

>>678
マイクロカーネルの話も結局は歴史的にこなれたモノリシックのカーネルの
座を奪う事は無かったから、どっちが優れてるとか無意味な議論になっちゃったけ
どね。
次はマイクロカーネルだって言ってた時代は懐かしい。

関数型言語対手続き型言語、RISC対CISC同様
結局双方の利点を取り入れたハイブリッドが生き残りやすいって話だね。
別に議論が無意味なわけではない。
こういうところの議論と呼ぶのがはばかられるような信者論争を除いてねｗ

>歴史的にこなれたモノリシックのカーネル
Windows も MacOS もどちらかと言えばマイクロカーネルですが。
一部OSサーバーがカーネル空間に取り込まれてるってのは実装上の問題にすぎない。

WindowsNTの出てきたときを思い出すね。
MSがマイクロカーネルだっていって、あんなのはマイクロカーネルじゃないって言われた。
そんで、4.0でディスプレイドライバを中に取り込んで改悪っていわれた。

MacはMachだけど実装は同じく妥協してる部分もあるね。
どこも現実解を求めるだけだけど。

>そんで、4.0でディスプレイドライバを中に取り込んで改悪っていわれた。
Vista はセキュリティ関係で、カーネルに取り込んだドライバのうち、一部を
ユーザーモードに戻しているらしいね

時代に合わせて柔軟な設計をしているということか

ま、そういう変更が出来る時点でモノリシックとは言わんわな

両者のいいところを取り込んだハイブリッドカーネル

NuKernel

そろそろ煽りネタも尽きたかなw

どうやらインテル上で 64bit のコードを実行すると
- 汎用レジスタの増加 -> パフォーマンス向上
- メモリ使用量の増加（64bit のポインタ等） -> パフォーマンス低下
でトータルとしてあまりメリットがないかも、という話の流れようだけど、だったら
- 64bit のレジスタにはアクセスできるが、依然 32bit モード（32bit アドレッシング）
があればいいはず。

が、インテルの 64bit (x64) はそういう設計にはなってないわけですよね?
G5 は 32bit モードでも 64bit のレジスタにアクセスできますよね、確か。
インテルの方はそういう設計にできなかったのか、しなかったのか。

あれ、カーネルはインテルの 64bit に対しては 32bit と 64bit を行ったり来たりする
んでしたっけ? ユーザープログラムでもそういうことをしたらどうなのかな（できるのかな）?

cpu のモードを切り替えるのは特権命令だから、ユーザープロセスにはできない。
32bit モードで 64bit レジスタは使えない(とおもう)。
というかそんなことができてそんなコードを書かれると、32 bit cpu での
32 bit mode で動かなくなるので、ますますややこしくなるよ。

あと、
> 汎用レジスタの増加 -> パフォーマンス向上
> メモリ使用量の増加（64bit のポインタ等） -> パフォーマンス低下
のふたつの「パフォーマンス」は別種のパフォーマンスだから、
どっちを追及したいかによって 64 bit にすることはもちろん意味が出てくる

PPC970用だと実際に32bit CPUで動かない32bitモードで動くプログラムが書けるんだが
ほとんど使ってる例は無いかな
まあABIが変わる(意図的に変えてる?)から64bitモードでコンパイルするのとあまり変わらんけど

ABI まで変わるんだっけ？
man 3 arch
とかすると、いっぱい cpu サポートしてるのがわかりますね。
hppa サポートとかまだ実際にカーネルに残ってるのかしらんけど。

>>689
>というかそんなことができてそんなコードを書かれると、32 bit cpu での
>32 bit mode で動かなくなるので、ますますややこしくなるよ。

Apple 的には Intel Mac の初代の方だけ切れば問題ないという説もw
（CoreDuo ユーザーの方にごめんなさい）

>>690
>PPC970用だと実際に32bit CPUで動かない32bitモードで動くプログラムが書けるんだが
ほとんど使ってる例は無いかな

この場合のメリットは平方根とか64bit整数の高速化とかでしょうから、
需要は比較的マイナーかもしれません。
PPC970 の Altivec のレジスタ幅が増えたりしてたならもっと違ったような気もしますが。


いずれにしても、OS 側の仕組みが整えば、普通のデベロッパ的には fat binary の
うち 32bit の種類が増えただけにならないですかね?
メリットデメリットはともかく技術的には。

太古の昔から複数アーキテクチャ対応だったからなあ

ビット幅が異なったりエンディアンが異なったり
ライブラリがころころ変わったり
苦労はマルチプラットフォーム並みで
売り上げは極小じゃやってられん罠

>>691
一応ppc970というarchが32bitでもPPC970専用のABIになっているようで
他のPowerPCでは起動しないようになってます。
ppc7400とかppc7450なんかは、そういう制限は無いんだけど。

いや、-mcpu=7450だとG3じゃ動かないでしょ。

74xx系のバイナリはG3でも動いた気がするんだなあ。確認はしてないけど。
AltiVecを使ってればillegal instructionで落ちるだろうけど。
つか-mcpuはMach-Oのarchとは関係ないよ。
-archでの指定の話。

いやあ、さすがパチもんMacは一味違うね。
バカ専用のMacにふさわしい欠陥だな。

「Leopard」、異なるボリュームへのファイル移動でバグ？
http://japan.cnet.com/news/ent/story/0,2000056022,20360536,00.htm

　　　　 ∧∧
　　　　(*ﾟ∀ﾟ)
　 　 〜(っ[どざ]っ 　あのなあ、ドザでいいやん。。。

>>698
10.5.1 で修正されてる。

>>700
　　　　 ∧∧
　　　　(*ﾟ∀ﾟ) 　　　　あのなあ、ドザってOSXのfixのピッチ
　 　 〜(っ[どざ]っ 　WindowsUpdate並に遅いと思ってるやん。。。

MacはTigerでさえSP11相当までいってるもんな。

そういう意味だろ？
>>701

　　　　 ∧∧
　　　　(*ﾟ∀ﾟ) 　　　　あのなあ、XPや２０００の
　 　 〜(っ[どざ]っ 　WindowsUpdateインド製やん。。。

>>701
つ 月一にスケジュール化している件＞更新

Macも更に普及したら、いきなりfixをリリースするのはできなくなるんじゃね？
事前発表無いと検証できないような

またMac親衛隊がスレ荒らしてるのか・・・

え？俺、アップルの宣伝信じて、マック買っちゃったんだけど嘘だったの？
前のマシンがAthlon64に32ビットのWindowsを走らせていたけれど、
Linux / Solaris / WindowsXP の64ビット版使った方が良かったかな。

お前は何使っても変わらんよ

>>704
タイムリーなことに、また更新だよ。今月二回目だってさ。

今月2度目のMac OS X用セキュリティアップデータが配布開始
http://journal.mycom.co.jp/news/2007/12/22/004/index.html

> 18日に配布開始された「Security Update 2007-009 1.0」は、
> 適用後にSafariで特定のWebサイトを表示するとクラッシュする問題が
> 報告されていた。

最近品質落ちてきたな。

>>708
>最近品質落ちてきたな。
このスレもな。

もう少しアカデミックな事を語ろうじゃないか。
カーネルが32bitでも64bitモードで動かせるとか何とか。

誰か親切に解説して
なんでそうなるの
違うアドレス空間だとしたらシステムコールやIOのオーバーヘッドは?

Macは俺のアイドルだもん。

>>711
答えは全て過去の書き込みにあり

例え：Vista64bit版はWOW64で64bit空間で32bitアプリを実行している。
x64には32bit互換モードが存在しているから64bit上でも32bitコードが
動くのである。
ttp://www.itmedia.co.jp/enterprise/articles/0507/26/news006.html

LinuxやWindowsで可能ならもちろんMacOSでも可能なはずだよね。

MacOSにはWOW64に相当するものがない。
作る技術力もない。

ふつうに Leopard で 32 bit アプリも 64 bit アプリも動くんですけど。

エミュレータ / virtualizer は Apple は昔からおてのものでしょ
ppc → intel の際の Rosetta,
OS 9 → OS X の際の Classic 環境、
ppc にしたときの 68k エミュレータ。
なんか OS のかなりの部分が 68 k のままだったし。

A/UX とかいって Mac 用ソフトがうごく Unix もつくってたし、
MAE とかいって他社製 Unix 上で System 7 を動かすソフトも売ってたべ。
ttp://homepage3.nifty.com/toshi3/mae.html

>>715
MSは無理やり64bit空間に32bit空間を作ったのがVistaのWOW64。
それに対して32bitと64bitをシームレスに動かせるようにしたのがLeopard。
MSにはこれらを作る技術力もないからWOW64なんておかしなものを作ったのだろう。

ってゆうか Leopard の 32bit/64bit の場合はいわゆるエミュレータでもバーチャライザでも
ないけどね。

ま、大人の都合による CPU やら OS やらの変更に何度も翻弄されて、
そのつどエンジニアが対応してきたということかとw

Wintel は、ずっと同じ系列の CPU で、起動時は至っては未だに 8086 に戻るわけで、
ある意味すごいよな。

大人の都合でもエミュレーションレイヤでも
アプリケーション側で互換性を解決しなければならない場合があるからなー

WOW64 については全く詳細をしらないんですが、ネットでちらほら読んだところでは、x86-64 上での WOW64 のやってることはレパードのカーネルがやってることとあんまり変わらないと思うんですが、どうなんでしょうか？

WOW64はカーネルが64bitで、完全に64bit OSの中に 互換性を保つ環境を作ったもの。
Leopardはカーネルが32bitで、使用できるメモリの範囲を64bitに拡張したもの。

根本的な違いがある。

Leopard は単にメモリ 64bit に拡張したのではなく、64bit コードもちゃんと動く。
完全な 64bit OS な訳だが。

>完全な 64bit OS な訳だが。

このスレの積み重ねを全て破壊する一言だなｗ

>>720
WOW64は単なるAPIブリッジ。
OSXその他の64bit OSは32bitコードを実行するのに
既存の32bit APIそのものを使ってる。
この点ではWindowsはちょっと特殊。IA-64の流れだろうかね。

ええと、Leopard は32bit ライブラリと64 bit ライブラリと両方積んでるのは知ってるんですが、
有る程度の部分は単にライブラリは別プロセスのサーバ(32 bit)と Mach で RPC してるだけですよね ... Window Server とか。
というわけで、WOW64 は 32bit API → 64 bit API とブリッジしてるけど、
Leopard は一部 64 bit API → 32 bit API へブリッジしてるのかなと思ったのですが ...

Windows 64bit板は 32bitアプリを切り捨てるなら
完全に64bit命令だけで動くことができるが、
Leopardは32bitコードをいつまでも引きずることになっている。

Leopard v.s. フル64bitOSの64bitアプリのベンチマーク対決ってどっかにないのかね。
公平になるようにどっちもgcc同士で。

>>724
だな・・・IA-64が有ったから嫌でも今のWOW６４みたいな作りにしなきゃならんかった
Core2出てから64bit化してればWinもMacと同じようなアプローチになったんだろうな
まあ、こればっかりは仕方ないといえば仕方ない

Winの64bitの実装の仕方で問題ないなら
IA-64ももっと売れてただろうし
IntelがわざわざCore2みたいな32bitと64bit両方のレジスタ持ったCPU作る必要も無かったと思う

>>723
カーネルに 32bit コード（しかも 64bit モードの互換モード）を含んでいるのは過去からの互換性のために取った手法の１つ。Leopard のAPI は 64bit 化され、64bit バイナリも問題なく動き、メモリ空間も 64bit になっている、完全 64bit OS な訳だが。

>>727
つーかIntelがobjective-C 2.0/objective-Cのネイティブコンパイラ早くだせ

>>729
「完全」の意味が違うんですよw
Windowsで言う完全は「強制」の意
32bit/64bitどちらでもユーザが都合の良い方を使える様、並立した環境を
提供したLeopardとは向いてる方向が全く違う。

さあ、文系頭がわらわらと沸いてまいりました

>>727
http://techreport.com/articles.x/12737/9
にWindows 64bit上でのLAMEのベンチマークがあるので手元で比較してみた。
ちなみにLeopardじゃなくてTigerですが。
環境はCore 2 Duo T7500 (2.2GHz), Tiger 10.4.11。
10分6秒のwavを用意して、CBR 128kbpsで5回エンコードしたところ、
64bitバイナリで平均36.0秒
32bitバイナリで平均41.1秒
だった。上のページにあるスコアはC2D E6400 (2.13GHz)で
64bit, MSVCで36.0秒
64bit iccで35.0秒
なので、まあコンパイラの差も加味して誤差範囲じゃないかな。

http://softlab.technion.ac.il/project/LAME/bin/のバイナリを使ったと思われるので、
http://softlab.technion.ac.il/project/LAME/src/から64bitのバイナリをコンパイルした。

>>711
最初からざっと見たけどちゃんと書いてないな。
ユーザーとカーネルは別空間だけど、ユーザーのほうから、
カーネル空間のup to 512MBまでをユーザー空間にマップできるんだよ。
たいがいの用はこれで間に合うでしょ?

>>734
逆じゃね?

>>733
64bit だと一割ぐらい速くなるという感じだね。
自分もやってみたがだいたいおんなじ感じだった。

>http://softlab.technion.ac.il/project/LAME/src/から64bitのバイナリをコンパイルした。

これ、ファイルの改行が全部 DOS だしw 最初変なエラーが出るから何かと思った。

nasm のファイルが入っていて XMM のレジスタをやたらいぢっているので、有効にして
32bit のバイナリを作り直してみたが（Leopard 上だと結構面倒）、
速度は元の 32bit と 64bit の間ぐらいだった。

そういえば、iTunes 内蔵のコンバータって、これに比べたら爆速だよね。
少なくともマルチスレッドが効いてるんだろうなあ。

ここまで書いてアレだが、OS 自体の話とはあまり関係ないかもw

Quartz (CoreGraphics) を調べてみたら座標（CGFloat) が 64bit だと double (64bit) なんだね。
32bit だと float (32bit) で。

これは float では画面全体を表現できないほどのワイド・高解像度のディスプレイが予定されて
いるに違いない!

というのは冗談にしても、画像をレンダリングするときとかにはそろそろ float だとしんどい?

>>736
iTunesが速いのは手抜きしてるからだよ

まあ、クズマカは品質とは縁遠いからなぁ。

ドザは煽り文句も三流

>>717
技術音痴は書き込みすんな

マックユーザー同士でもはずかしいよ
おまえは

>>741
ttp://ja.wikipedia.org/wiki/WOW64
技術音痴はお前だろう。さては成りすましドザか

<マカの痴呆の程度は宇宙一>

アポ製品購入は判断力の欠如から起こる。
アポ製品再購入は学習機能の欠如から起こる。
アポ製品再々購入は記憶力の欠如から起こる。
アポ製品再々々購入は痴呆から起こる。
それ以上購入する輩は死んでも直らない病気である。

Windowsはバカを育てる

>>742
被害妄想だな

ピュア64のWinはMS伝統のパフォーマンス重視
ハイブリッド64のLeoはAppleらしい移行期のソリューション

どっちもそれぞれ一長一短有って、単純に優劣はつかないと思うがね

どうでもいいけど、64bit Windows って家電量販店でどの程度売ってるの？

確かにどうでもいいな

　　　 　 　 　 　 　 ,,,,｡―'━━-＿:
　　 　 　 　 　 _／″ 　 　 　 　 　 `''i､
　 　 　 　 　 ,/゜　　　　　　　　　　　　｀'、
　　　　　　 ,i"　　　　　　　　　　　　　　 `i、
　　　　　 .,/　　　 、,,、　　　　　　　　　　 ﾞl、
　　　　 .,/｀　　　.,i´ .ﾟ!i､　　　　 ,r'ﾟ'・r,　　 ｀'i､
　　　　./　　　 ,,,il　●.,l“““““''l| ●.,l｡_　　 ｀'i､
　　　 .,|　　 .,-″`-,,,,r゜　　　　.ﾚ.″,i″｀'¬i､ .ﾞl,
　　　 ,lﾞ　 .j″　　　 : 　.r‐:ｗx,　.ﾞﾞ‐'゜ ._,,ｖ．　"'l,.ﾘ
　　　.Z　 ,「.rrrr-,｡,,: 　.|、　　.》 ..,,,,-･ﾟ゛,,,,,y-． ［.ﾞl
　　　.l　 ,lﾞ .ー'＝�＝� ."ﾍ,xxil} ｀,r‐'"ﾞﾞ＿,,,,,,,,,,,i| .ﾘ
　　　:|　.l′ ﾞ'''ll,＝-　　　 .ﾞl　　　　.'",,,,,ﾚ　　　 |　.l:　　　　　　
　　　:|　 ﾞl　　　.ﾞ"l━＝''''''''ﾞ“““““ﾞﾞﾞ~'k　　　　 l: : |
　　　.l、　l　　　　 `i,,　　　　　　　　_,,,,,,l,　　　　ｹ　］
　　　 ト　.|　　　　　 ﾞヽ、　　　　.,i'ﾟ~　　［　　　.,ト　.l 　色管理っ！色管理っ！あびゃぶああ！！
　　　 .ﾞl,　ﾞk　　　　　　 “'･'r---ﾆ---ｖ┘　　 .］　 ┃
　　　　.ﾋ　:l、 ._,ｗｗｗｗrr←―ｰ=-ｖ,,,,,,,,＿_, ,ド　 l!
　　　　 .'ｋ ﾞV'″　　　　　　　　　　　　　 : : .ﾞ~''y,,┘
　　　　　 ﾞ'┴.,,｡,,,,,,,,,,,_.,,｡,,,,,,,,,,,_.,,｡,,,,,,,,,,,_.,,｡,,,,,,, ,,r'

↑キチガイマカ

ドザはいつもコピペで逃げるからなぁ

age

-終了-

128bit FS「ZFS」のMac OS X Leopard用最新ビルドが公開
http://journal.mycom.co.jp/news/2008/01/11/008/index.html

>>19

コマネチっ！

保守age

LinuxのUbuntuで32bit版と64bit版を比べてみたけど、おおざっぱに後者の方が
前者の2倍メモリを食うねえ。
Leopardの場合、アプリは基本的に32bitなわけだけど、OSが64bit対応になったことが
メモリ使用量的には影響してるんだろうか。一応64bitのライブラリなんかもメモリには
ロードされてるのかな?

ちなみにhttp://www.apple.com/jp/macosx/techspecs/に書いてある最低メモリ量は
Panther -> 128MB Tiger -> 256MB Leopard -> 512MBとなっていた。
見事に倍々だがw おおざっぱにキリのいい数値を書いているというのもあるだろうね。
Panther -> Tigerはビット数の変化はなくても増えてる訳だから、これでOSのビット数
云々を語ることはできないけど。

>>756
Panther -> Tigerも増えてるんだけどねビット幅

64bitのライブラリが読まれるのは64bitアプリケーションを起動したときだけだが

それでは64bitドライバが動けない。

>>759
レパードは カーネル内 64 bit ドライバは無いから。
(とかいいはじめるとまたこのスレを1からやり直すことになりそう)

だいたい共有ライブラリを読むとかいうのはユーザースペースの話で、
ドライバが動ける動けないとは関係しようがない。
だから 64bit ドライバがあったとしても論理が通ってない。

>>760
徹底的なおバカなマカは全く理解できません。
それが、マカというものだ。
前人未踏のウルトラバカ。それがマカ。

>>761
ウルトラバカというよりは、究極の洗脳がなされていると考えるべきでは？

アップルから賜りし究極のOSであるOSXが地獄の汚物に等しき下賎なるWindows
ごときに劣る部分があるはずがないという妄想にとりつかれている上に、偉大なる
神アップルより賜りし技術は現代の人間ごときに理解できるものではなく、学者ご
ときクズが言う理論など聞くに値しないと考えているんだよ。

正常な人間であれば、現実社会で出来ないことがあることを理解できるけど、洗脳
されたマカにとってアップルは出来ないことなどありえない万能神と崇め奉ることが
当然のものであるから、そういう常識は理解できないんだよ。

>>762
その言葉、そのままVista64bitユーザーにも言えそうだな。

まあでも「ユーザースペース」はマズいわな

>>760 をかいたものですが、
なんでユーザースペースが悪いのかわからんのですが、
後学のためにおしえてください。

あとは僕はマカなんですが、なんで 761 , 762 という返答がついたのか
全く判らんのですが。僕はたんにテクニカルに正しいことを
書こうとつとめてるだけなんですけど。
馬鹿なせいで間違ったことも書いてると思いますが。

>>765
うんよく自分がバカって気がついたね
君が勉強したテクニカルはほとんど間違ってるよ
ユーザーランドに提供されるライブラリ（やAPIなど）とは別物
Leopardは（作れば）64bitデバイスドライバも動くんだ

Leopard での 64 bit ドライバってどうつくればいいんですか？
IOKit に入った段階で CPU が 32 bit モードなんじゃないかとおもうんですけど、
自前でCPUのモードを変更しないといけないのでは ...

>ユーザーランドに提供されるライブラリ（やAPIなど）とは別物
なにがユーザーランドのライブラリとは別物なんでしょう？

行間を読めない馬鹿ですいません。

>>767
ん？もしかして64bitモードからI/O Kitを利用できないとか思ってる？
それとも、I/O Kit使う = 32bitメモリ空間しか使えないと思ってるのかな？
自前でモード変更？？　必要ないなぁ。

ていうか単に煽りに突っかかってるだけかな？

いや、基本的にほんとに馬鹿なだけなので、すいません。
ADC の IOKit のあたりは読んでるつもりですが、実践が伴わないのでわかってません。

IOKit から 64 bit メモリ空間をアクセスできるのは判ってるつもりですが、
32bit I/O Kit ドライバと 64 bit I/O Kit ドライバというものが
別に存在して別個にカーネルが読み込んでくれるわけではないので、
なんにせよドライバ書く際は DMA するなら IODMACommand つかって、
そうしておけば 32 bit も 64 bit も関係ない、ということだと思いました。
だから I/O Kit の binary を ppc / i386 / x86_64 / ppc970 とかする必要がない、
と思っていましたが間違っている？

"64 bit ドライバ” という言葉で何を意味するかの齟齬なのかもしれませんが...

馬鹿なマカは引っこんどれ。
ますますドツボにハマるぞ。

>>769
>"64 bit ドライバ” という言葉で何を意味するかの齟齬なのかもしれませんが...

確かに、「64bit」も「ドライバ」もこのスレで何度も出てきるけど、どちらも未だにw
でそれを「I/O Kit が使えるかどうか」という表現で説明するとさらに倍。

I/O Kit といっても、カーネル内 I/O Kit の API も
ユーザースペースから I/O Kit と話す API もありますしね ...

用語の使い方がメチャクチャすぐる

どアホなクズマカは一言一句の言葉の意味すら理解できないようです。
まあ、それを理解する脳すらないのでしかたないようですが。

Machカーネル、BSDカーネルレイヤー、そしてIOKitドライバをもって
Darwinカーネルと呼ばれているが、デバイスドライバに関しては64bitの
場合でも32bit版IOKitドライバをそのまま利用するので書き換えをする必要が
無いらしい。

これは、Tigerの時から同じである。

>>774
・・・と、さっきまでコンビニで立ち読みしたエロ週刊誌の記事の
劣化コピーをリアル土方のドザ珍が焼酎の酔いの勢いを借りて
わめいております。

32bit版 IOKit ドライバというのと、64 bit 版 IOKit ドライバという区別がそもそも無いといったほうが正確だとおもいます
(煽りのひとが、64bitドライバが使えなくて32bit ドライバしかないだって？ぷぷぷとか返事するのが目に見えているので。)
単にひとつのドライバで、32bit cpu なら 32bit のメモリ空間を、
64bit cpu なら 64 bit のメモリ空間を扱えるようになっているということ、
そのあたりはカーネル内の IOKit クラス群で透過的に処理されているという
ことだと思います

つまり、32bitってことなんだね。

>>778
君の使ってるMeがね。

Meの使ってるレオポンが実は32bitだったなんてorz

>>780
16bitコード残ってるMe?
それともMe2007?

つまり、32bitコード残っているLeopardは32bit ということか

ところで、このスレでfat binaryのこと出てきた？
Darwin-deveで、G5導入のときにfat binary利用してG3/G4と
G5両方に対応させると言ってた。Intel発表後も同じこと言ってたな。

fat binaryをなんかすごいもののように勘違いしてそうだけど、
あれは単に、CPUごとにコンパイルしたものを一つのファイルにまとめただけ。

だから当然、32bitにしか対応していないfat binaryもあるし、
それを64bit対応にするのなら、最コンパイルしないといけない。

俺の友達のマカーは「Macは初代Macintoshから32bitだった（だからWindowsより
えらい）。」と力説しています。本当なのでしょうか。

表向き16bitCPUだった68Kに、32bitレジスタしか乗ってなかった事を言っているんだろうな。

>>785
MC68000は24bitアドレッシング。アドレス表現は32bitだが上位8bitは無視される。
初期のMacは最大RAM 4MB、仮想記憶も無いので32bit使うのは贅沢な位
古いToolboxでは、無視されるアドレスの上位8bitをフラグに使う物もあった。
MC68020と32Bit QuickDrawが乗ったSystem6以降は32bitアドレッシング

>>784
なにヴァカこいてるん？

各アーキテクチャーごとにコンパイルするのは当たり前

> 一つのファイルにまとめただけ。
「だけ」(笑)
OSサイドからアーキテクチャーに応じて透過的に利用できなかったら
一つのファイルにまとめても無意味なのだが。

> それを64bit対応にするのなら、最コンパイルしないといけない。
そんなこと出来ないだろ
最コンパイルなんてこと(笑)

>>786
その当時のPCのCPU8088も表向き16bitCPUだったけれど、
外部データバスなんか8bitだったしね。

>>788
>「だけ」(笑)
>OSサイドからアーキテクチャーに応じて透過的に利用できなかったら
>一つのファイルにまとめても無意味なのだが。
透過的に利用できる様にするなんて無視できるくらいの仕組みじゃん。
だから「だけ」って書いててもなんにも違和感がないがな。
じっさいそんなもんだし。

その程度の仕組みすら使えない糞OSにお布施払ってるドザって(笑)

>>791
なんでそこで「ドザ」って書くのか理解に苦しむ。

うれしいだろ(笑)

>>786
>>787
ということは俺の友達のマカーはホラ吹きというか嘘つきな訳ですね。
奴はそのことをたいへんに吹聴していて、最近になってやっと32bitになった
Windowsなんて糞だとバカにしまくっています。
困ったマカーなんですね。

それはまったく困ったマカーだな。
だいたい OS 9 以前から使っているマカーにロクなのはいない。
ドザの人もちゃんとネクストステッパー、その直系のOS X 使いと、
OS 9 以前からの馬鹿マカーの二種類を区別して煽ってくれよ。

と変なほうに話を振ってみますがどうでしょうか。

>>795
そいつはMacはIBM様のありがたいPOWERプロセッサ由来のPowerPCを搭載
したMacを崇め奉っていました。「Intelのようなバッタ屋が作ったCPUなんかに
負けるはずがない」と鼻先で笑っていました。彼にマイクロプロセッサの歴史を
いくらいっても聞く耳はありませんでした。でもここのところおとなしいようです。

>>795
確かに、ろくなマカーは居ないみたいだな。

>50 名前: 名称未設定 Mail: 投稿日: 2008/02/03(日) 04:31:31 ID: m6OMKFPx0
>俺、クリエイターとして20年Mac使ってるけど、ウィルスとか脆弱性なんて
>いっぺんも経験したことね〜よ。
>ドザはせっせとMicrosoftUpdateしてなｗ

>>796
じゃぁ君がここでマイクロプロセッサの歴史とやらを
騙ってください。

マカ珍のみなさん、Intelのプロセッサは速いでしょう。
使えるようになってよかったですね　(・ω・)ノ

もう悔し紛れにx86は造りが汚いとか意味のわかってない妄言をはかなくて
すみますしねｗ

ID:m6OMKFPx0
ttp://pc11.2ch.net/test/read.cgi/mac/1195043772/785,794,796,799
ttp://pc11.2ch.net/test/read.cgi/mac/1200575634/528,539
ttp://pc11.2ch.net/test/read.cgi/mac/1193652857/73
ttp://pc11.2ch.net/test/read.cgi/mac/1188141825/41
ttp://pc11.2ch.net/test/read.cgi/mac/1190641489/40
ttp://pc11.2ch.net/test/read.cgi/mac/1185455311/50
ttp://pc11.2ch.net/test/read.cgi/mac/1150166532/836
ttp://pc11.2ch.net/test/read.cgi/mac/1196946628/61
ttp://pc11.2ch.net/test/read.cgi/mac/1194246917/38

>>799
さっそく騙りだしたか(笑)
まあ君のPCでは起動時にウンコアーキテクチャが必要なんだろ。

>>795
私はOS Xが初めてだったんですが…

ID:m6OMKFPx0 のネタ振りにマジレスで返した ID:3n0Wr6Ld0
というとこまで読んだ

明らかに手慣れた手法を使ってくる釣り師にも、
うっかりマジレス返せる人が居る位の方が良スレの事が多いよ

804が既に串チェックされてた件について

つ、吊られないぞー(AA略

診断くん Ver 0.80a
疑惑 0%：proxy の兆候は全く見られません。

つか今時串とか使わんだろ、普通
信頼性が確認できない限り串の鯖缶に情報だだ漏れになるんだし

どこかで煽って誰かに串チェックされたって所でしょ

すまん。FatMac(512K)のころからのマカーで
MOしかなかったけどMathematicaがついてきたころからのネクストステッパーで
DOS/v ver. 4の頃からATと付き合ってるんですが、
どこに分類されればいいんでしょうか？

救いようのないパソコンオタク。

「おじいさん」でおk

いつの間にか汚いスレになったな。
そんなにドザPCが8GB以上使えない事が悔しいのか。
Vista64bit版も不具合が多いからな。

まるで、Vista64bitで8GB以上使えるという
事実を言われないように先手を打って不具合が多いと
デマ流しているように見える。

妄想と戦ってると疲れるでしょ、休みなさい

おまえら、Vista64でも8GB以上のハードディスク使えたじゃないか。うそつくなよ。

正直、確かにIntel使えて良かった。
MacBookの処理能力がメインのG5クアドと大差ないのに驚いた。

ありえません

たぶん大福でも大差ない作業してんだよ

残念ながらCore2Duo 2GHzなら単純なCPU比較で2.5GHz G5Quadと
同等性能みたいだな。
オレのG5 2.5Dualの倍早かったorz

新しいCPUが古いCPUより速いのは当たり前

>>818
>残念ながらCore2Duo 2GHzなら単純なCPU比較で2.5GHz G5Quadと
>同等性能みたいだな。

んなことはない

PPC信者ってまだ存在するんだな。
Intel Mac所有者が増えるにつれて、これまで
騙されていた事にみんな気付いたのかと思ったよ。
俺のまわりのマカは、以前はMacはハードもソフト
も段違いに高性能だと勧めていたが、今は大人しく
なってしまった。

PPC 信者も何も、POWER6 は欲しくても買えないからな

>>822
IBM System p ってそんなには高く無いから個人でも買えると思うけど。

>>823

IBM、「POWER6」と搭載サーバ「IBM System p 570」発表
http://www.itmedia.co.jp/news/articles/0705/22/news016.html

2007年05月23日
世界最速かつ省電力な次世代プロセッサー搭載のUNIXサーバー
日本IBMは本日、世界最高速4.7GHzの動作周波数を発揮する次世代
プロセッサー「POWER6」を初めて搭載したミッドレンジ・クラスの
UNIXサーバー新製品「IBM System p モデル570」を発表しました。
価格は12,280,380円（税込、最小構成価格）から、出荷開始日は
6月8日の予定です。

ちなみに最小構成は 1way なので意味無し

>>821

なんか一生懸命煽ってるつもりなのが痛々しいけどw
NetBurst と Phenom 比べて Intel 糞って騒いでる AMD厨みたい

>>824
高い方が好きなの？
POWER6が欲しいなら520でも550でもいいんじゃないの？
仕事で550を使ってるけどいいマシンだよ。

http://www-06.ibm.com/jp/press/2008/01/3002.html

>>826
うちがつかってるのは前の世代の5と5+。
6はもうすぐ納品。

やっぱり POWER6 といえば 4.7GHz じゃない？

Is 32 bits really better than 64?
ttp://gmplib.org/32vs64.html

何を言いたいのか分からんが
アルゴリズム的に64bit整数演算が可能な方が演算量が減る処理は速くなって当然だろう

その程度なら拡張命令で今までも速くできてたかな。

>>831
64bit乗算はSIMDじゃ無理だよ
つーかSIMDだと32bitすらままならない(SSE4.1で32bit同士の符号付き乗算がようやくサポートされた)

ハゲの32bit->64bitでアプリが2倍高速に！
とかいう失笑もののプレゼンを鵜呑みにして信じちゃってるおめでたい人意外は
クライアント、デスクトップ用途における64bit化の恩恵が意外と限定的で
特にマルチメディア系の操作はAltivec, SSE等の専用拡張命令の方が効果が大きいというのは大昔からの常識

そんなプレゼンは初耳だ。

64bit化なんて、手の指が5本から10本に増えるようなもんだ。
増えれば便利かもしれないが、実際には3本でも何とかなる。

いやパフォーマンス向上はおまけでメモリ空間が広がる方がメインだと思うんだが...

>>836
しかし，それだとMicrosoftみたいに頑張ってメモリ使用量増やさないといけないよな．
今のままだと普通のユーザは概ね4GBで足りてしまう．
Leopardになって若干確保されるメモリが減った気がするし．何やってんだAppleさんYO！

>>829
GMP で少し遊んでみたけど、同一マシン上で 32bit バイナリと 64bit バイナリを
走らせると後者の方が倍位速くなった。他の多倍長ライブラリでもそんな感じなのかな?
多倍長計算は暗号処理で使われるし、普通の人もそれなりに恩恵があるかと。

２ちゃんの鯖も一部６４bit化してたりする

おいおい、あんまり64bitを過小評価しているとVista64bitユーザーからも
批判が着そうだぞ。

まずは、iMacでメモリを8GBくらい載せられるようにしてほしい(´･ω･`)

まずはドザの脳味噌の容量をせめて4MBに増やして欲しい。

常識的に考えてMBPの上限を8GBが先だろう．
どうせ同じ世代のモバイルチップセット使うからiMac＝MBPだろうけど〜．

物理的にスロット増やすか4GBのモジュールが出るかじゃね

１０年後にはメモリ1TBが１万円切ったぞ。。。とか話してるのかなぁ・・・

どうでもいい話だがほとんどの民衆たちはメモリは2GB程度で十分だと
思っている。
8GBも何に使うんだ？

そういう人はMacBook使えばいいんじゃね。

2GBで足りる人はそれでいい。
でも俺は全然足りないなあ。
メモリが極端に高い訳でもないし、経済的な制約じゃないのがはがゆい。

>>848の気持ちも分からないでもないが現在最も売れているのがノート用と一体型。
Appleがそこに力を入れている気持ちもまた分かる。

ここからは私の持論だが、現在iMacはノート用アーキテクチャを採用している。
もうすぐQuadCPU搭載PCが主流になってくると現行のiMacとでは性能に差が出て
くる。現在のAppleではiMacにデスクトップ用のマザーボードは搭載する事は
難しいので、いわゆるミドルレンジのMacが必ず登場してくるだろう。

>>848
現行機種は4GBまで積めるはず。

>>849
盛り上がってるとこ悪いが，ノート用にもQuadCoreが出ますな．
iMac松にそれ載せたら隙間埋まっちゃうね．