5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

64bitのオペレーティングシステム

1 :Der Angriff:2001/05/10(木) 22:42
64bitに触れたこともありません。
誰か詳しい方、64bitと32bit双方のOSレベルでの根本的違いを説明して
下さい。

また、どこかのサイトで128bitのOSについても、ちょっとだけ触れてましたね。

2 :名無しさん@お腹いっぱい。:2001/05/10(木) 22:46
Tru64 はやいよ。

3 :CCルリたん。:2001/05/10(木) 22:58
Solaris2.7以降はHardwareが64bit対応していたら、カーネルが
64bitになるみたいですね。

ip_filterがgccでmake出来なくて癪だ。

Tru64は、5時間ぐらい使って、FreeBSD4.2Rに変えました。
Tru64はXの解像度どうやって変えるのだ?1024x768は狭い。

4 :名無しさん@お腹いっぱい。:2001/05/11(金) 00:26
I/Oの幅とアドレス空間

5 :名無しさん:2001/05/11(金) 09:00
以前、PCをオシロ代わりに使おうとしたが、
まったく帯域不足のオシロであまり役に立たなかった。
その時、これが64bit MPU/OSなら楽勝なのに…と思ったよ。

6 :aki:2001/05/12(土) 06:01
ゼミのCPUサーバをSolaris8 64bitsにしたら、
GbEカードのドライバが出て無くて、
仕方ないので100のありふれたカードをさして使ってる。

鬱だ。

7 :名無しさん@お腹いっぱい。:2001/05/12(土) 06:16
データバスは128bitほどあっていいが
アドレスバスは64bitもあれば十分すぎるかと。

8 :名無しさん:2001/05/12(土) 09:03
Z80設計者:アドレスバスは16bitもあれば十分すぎるかと。
i8086設計者:アドレスバスは20bitもあれば十分すぎるかと。
i80386設計者:アドレスバスは32bitもあれば十分すぎるかと。
>>7のドキュソ:アドレスバスは64bitもあれば十分すぎるかと。

歴史は繰り返す

9 :名無しさん@お腹いっぱい。:2001/05/12(土) 10:08
>>4
I/O の幅は、変わらないのが多いよ。
今までの I/O を動かさなきゃイケないわけだし。
符号拡張するだけとかね。

10 :名無しさん@お腹いっぱい。:2001/05/12(土) 10:17
>>1
例えば、PA-RISC の世界なんだけど。
IO_EIR (I/O Extertnal Interrupt Register っていう、
システム上のモジュール(CPU, メモリコントローラ, I/O ...)
それぞれに識別子をつけて、CPU に「どのモジュールからの割り込みか?」って
識別する機能があるのね。
これが 32 -> 64 bits のレジスタなら、単純に倍の(1モジュール/1bit の割り当て)
モジュール(I/O) を取り扱う事が出来る。
psw(Processor Status Word) の w-bit で 32/64 を切り替えるんだけど
良く間違えた。PA-RISC は左から 0, 1, ... 63 bit って並ぶんだけど
32 bitだと 0 bitめを表すのに、64 bitだと 32bitめだからね。

11 :名無しさん@お腹いっぱい。:2001/05/12(土) 10:19
IA-64 の世界は、やっぱ >>4 が書いてるメモリ空間かな。
4GB と 16He リニアに使えるのとでは違うよね。

12 :名無しさん@お腹いっぱい。:2001/05/12(土) 10:25
>>2
DEC アルファの 64bit って、
データ長は、64bit で、アドレッシングは Virtual Addressing で
実は 32bit っていう、インチキ 64bit じゃなかったっけ?

13 :名無しさん@お腹いっぱい。:2001/05/12(土) 11:34
16Heって何の単位ですか

14 :名無しさん@お腹いっぱい。:2001/05/12(土) 11:54
ヘリウム原子16個分

15 :名無しさん@お腹いっぱい。:2001/05/12(土) 11:54
ところで4004ってアドレス空間どれくらいだったの

16 :名無しさん@お腹いっぱい。:2001/05/12(土) 18:08
>>12
だかーら、DIGITAL -> Tru64 になったのだと思われ。

17 :7のドキュソ:2001/05/12(土) 23:15
>>8
繰り返すっていっても
Z80とi8086はともかく
i80386はまだ足りてるじゃん。
64bitあれば18エクサbyteだぞ?

ネット上(この言葉が何を指すのかは知らんが)の
すべての情報ですらまだ1エクサ達してないのだろう?

十分すぎると思うのだが……

18 :名無しさん@お腹いっぱい。:2001/05/13(日) 00:10


          || ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄||
          ||  BSD馬鹿は     Λ_Λ  いいですね。
          ||   放置!  \ (゚ー゚*)
          ||________⊂⊂ |
  ∧ ∧    ∧ ∧    ∧ ∧    | ̄ ̄ ̄ ̄|
  (  ∧ ∧ (   ∧ ∧ (  ∧ ∧ |      |
〜(_(  ∧ ∧ __(  ∧ ∧__(   ∧ ∧ ̄ ̄ ̄
  〜(_(  ∧ ∧_(  ∧ ∧_(   ∧ ∧  は〜い、先生。
    〜(_(   ,,)〜(_(   ,,)〜(_(   ,,)
      〜(___ノ  〜(___ノ   〜(___ノ




19 :名無しさん@お腹いっぱい。:2001/05/13(日) 00:21
>>17
だから今の時点ではたりるさぁ

20 :19:2001/05/13(日) 00:23
ま、増え方が段違いだから足りなくなるとは思えないけどね
でも、広大な無限の領域と思われた4GBが物によっては足りてないからなあ

21 :7のドキュソ:2001/05/13(日) 00:45
>>19
一応先のことも考えてるつもり

>>20
まあ4GBは使い切れるだろうが
その42億倍を使いきれるか?

22 :???????????????B:2001/05/13(日) 01:02
>>7のドキュソ
例えば、画像ファイルはどうだろう。テレビ局が20あるとして、
24時間分全てを録画していくとしよう。何年分記録できるのだろう。
誰か試算してー



23 :名無しさん@お腹いっぱい。:2001/05/13(日) 02:13
>>22
仮に1局を1時間1GBだとしたら100年ぐらいかな。
RAMに記録する必要もないが。

24 :23:2001/05/13(日) 04:45
ここはUNIX板だしRAMっていうよりコアっていったほうがいいのか?

25 :名無しさん@お腹いっぱい。:2001/05/15(火) 08:26
へ?

26 :sage:2001/05/16(水) 05:12
わかっているとは思うが、
Pentium Pro 以降は 4G より大きい物理メモリを
扱えるようにはなってるぞ。PAE や PSE-63 を使えば 64G まで逝ける。
MMU 使ってリニアにアクセスできる仮想空間は 4G だが。

27 :名無しさん@お腹いっぱい。:2001/05/16(水) 06:22
>>26
よく知らないんだけど、昔のセグメントやページングのような仕組み?

28 :1:2001/05/16(水) 07:37
1

29 :26:2001/05/16(水) 15:10
>>27
PAE はページテーブルを2段から3段にして
扱える物理アドレスを拡張する。Pentium Pro 以降。
PSE はページサイズを大きくして (4KB→4MB) 物理アドレスを拡張する。
こっちは Xeon 以降。

いずれにせよ、MMU を使うかぎりリニアに使える仮想空間は4G。
もちろん MS-DOS リアルモード時代みたいに手動で切り替えれば、
アクセスできる空間は増やすことはできるけど、
いまさらそんなことしたくないよな。

で、>>1 の話に戻ると、UNIXにおいて 64 ビットというと
やはりこの仮想アドレス空間が広大なる、
というのが一番大きいのではないか。月並みの結論だが。
それ以外では根本的な違いというのはあまりないような
気がする。

30 :名無しさん@お腹いっぱい。:2001/05/16(水) 19:39
IPaddrだって 128bitになるのに、64bitじゃ...


31 :26:2001/05/16(水) 22:22
>>30
アドレス空間が大きければいいってものでもないんだ。
今度はページテーブルが巨大になってメモリを圧迫する。

32 :26:2001/05/16(水) 22:23
>>30
アドレス空間が大きければいいってものでもないんだ。
今度はページテーブルが巨大になってメモリを圧迫する。

33 :名無しさん@お腹いっぱい。:2001/05/16(水) 23:09
TLB miss fault も頻繁に起きそうだしね。<ページテーブル

34 :名無しさん@Emacs:2001/05/17(木) 00:40
>>3

/etc/dt/config/Xserversの最後の方を、

:0 Local local@console /usr/bin/X11/X :0 -screen 1280x1024 -vclass TrueColor

とかにする。

もし/etc/dt/config/
がなかったら、
/usr/dt/configをコピーしてつかう。



35 :名無しさん@お腹いっぱい。:2001/05/17(木) 02:29
>>32
pagetableが巨大になってもいいようにGDT,LDTと2段階になっている
pagetableをswapoutできないOSは滅んでいい。いや滅ぶべきだ。

36 :名無しさん@お腹いっぱい。:2001/05/17(木) 02:30
>>35
Linuxは滅ぶべきだと逝っているのか?
今時FreeBSDだってkernelをswapoutできる筈だがな

37 :名無しさん@お腹いっぱい。:2001/05/17(木) 02:31
>>36
FreeBSDもLinuxもkernel、pagetable、ldtをswapoutできない。
よって滅んでよし。

38 :名無しさん@お腹いっぱい。:2001/05/17(木) 02:36
>>35
今出来ない事は別にできる必要はないと強がりを言うUNIX厨房が
騒ぐから、この話題はやめやめ。誰だってkernelのその点では
Win2000に負けている事を素直に認めてあとを追いかけているし、
あえてそのモードを切り離したエディションもM$は出しているしさ。

滅ぶべきはUNIX厨房だけ

39 :名無しさん@お腹いっぱい。:2001/05/17(木) 04:00
仮に 1KB / 1ns でアクセスできたとして、
64bit だと 200 日ぐらい?
メモリチェックするだけでも大変だ。

40 :CCルリたん。:2001/05/17(木) 22:59
>>32

Thank you!。だがしかしもうTru64が無い。FreeBSDにしててファイル
サーバにしてしまった。今更OSは変えられない。


41 :名無しさん@お腹いっぱい。:2001/05/17(木) 23:25
>>38
NTはスワップアウトできるんだ!初めて知ったよ。
だけど実際に外に出されるケースってあるのかな?
pagetableよりもアクセス頻度の高いデータってそんなにないような・・

42 :名無しさん@お腹いっぱい。:2001/05/17(木) 23:48
>> 35

GDT, LDT ってのは page table じゃなくて descriptor table でしょ.
こいつは paging じゃなくて segmentation のための仕組みなので, ふつー,
UNIX/WinNT/Win2000 的には無用の長物に近いでしょ.
(x86 の場合仕方なしに使う必要があるけど)

>> 37, 38

WinNT も最初の設計時にはカーネルは non-pageable だったんだけど, Mach
の偉い人に指摘されてから直したんでしょ.
BSD 系の VM の場合, プロセスが swapout されている時には pagetable は
swapout されるんじゃなくて解放されるので, 当然実メモリ中には常駐しなく
なるっす. それどころか pagetable を swap に書き込む必要性さえないのだ.
とゆうわけで, それほど馬鹿にするもんでもないのでは?


43 :名無しさん@お腹いっぱい。:2001/05/17(木) 23:53
普段これといって優位性を見出せないWindowsユーザーが
騒いでるだけだって。ちょっとかわいそう。


44 :名無しさん@お腹いっぱい。:2001/05/18(金) 01:07
>43
煽りなんていりません

45 :名無しさん@お腹いっぱい。:2001/05/19(土) 00:19
>>42
loadable moduleによってrebootの危機に晒されている

46 :名無しさん@お腹いっぱい。:2001/05/19(土) 10:33
>>42
pagetable開放されるんだあ。でもなんかそれovercommitに弱そうな
気がするんだが気のせいかなあ。あとプロセスのメモリ空間が
全部Swapoutされないとpagetableは開放されないはずだよね、
となるとほとんど開放されることはないような気もするなあ。

47 :名無しさん@お腹いっぱい。:2001/05/19(土) 11:57
> pagetable開放されるんだあ。でもなんかそれovercommitに弱そうな
> 気がするんだが気のせいかなあ。

それは完全に気のせい. 確かに現在の 4.4BSD 系 VM には overcommit 問題
があるけど, この page table 解放の仕組みは, overcommit とは全く関係ない.

> あとプロセスのメモリ空間が 全部Swapoutされないとpagetableは開放され
> ないはずだよね、

いやいや, それだけじゃなくて, ある page table が使われなくなっただけで
起きる. せっかくソースが公開されているんだから, pmap.c の中の
pmap_remove(9) を読んでみたり, また pmap_remove(9) が呼ばれるタイミング
を調べてみたりすれば確認できるよ.
この自分の目で調査できるって点が,ソースのある OS の嬉しいところだよね.
Windows 系の OS でこれができる人って相当限られている上に, 守秘義務の関
係でその結果をここで書くことも難しいんじゃないかな.

> となるとほとんど開放されることはないような気もするなあ。

"ps axl" で表示した結果, STAT フィールドに W フラグが表示されている
プロセスは swap out されているから, 全 page table が解放されてる.
少なくとも, うちの環境では, それなりの数が表示されてるよ.
しかも, それだけじゃないのは上に書いた通り.

Windows NT/2000/XP の場合も, swap out されている時だけじゃなくて,
通常の paging 時にも page table 自体が page out されるのかな?
38 の書き込みを見ると, paga table が pageable な製品と, そうでない製品
があるみたいだけど, ここら辺の情報ってどこを見れば分かるの?


48 :名無しさん@お腹いっぱい。:2001/05/19(土) 15:03
まとめると
WinNT kernelも page out化
*BSD(区別しないでいいのか?) page tableは swap outされたら消える
Linux シラネーヨ
か?

でも page tableってそんなでかいのか?
所詮 working setに比例した大きさだと思うが。


49 :名無しさん@お腹いっぱい。:2001/05/19(土) 16:23
32bitだとそんなに気にすることない大きさだけど
やっぱ64bitになると馬鹿にならない大きさだよね。
やっぱできないより、出来たほうがいいべ。

50 :名無しさん@お腹いっぱい。:2001/05/22(火) 22:43
>>1
あまり詳しくないけど、偏見交じりの相違点となると

・ネイティブで扱える整数値の範囲が違う(32bit int と 64bit int)

これがすべての立脚点だと自分では思うす。

 バス幅、メモリ空間の大きさが異なるのは自明の話だけど、Epoch time をあらわ
すデータ長(32bit から 64bitへ)とかファイルオフセットの大きさ(2^64 - 1
バイトまで扱える)とかも広くなります。あたりまえだけど、mmap()した後のオフ
セット値もでかくとれますな。

 プロセッサや OS によっては 32bit OS でも Over 2GB とか扱えるけど、やっ
ぱりどっか無理はあります。つーか美しくない。



15 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)