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

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

理屈っぽい人,大募集!

1 : :2001/08/03(金) 05:34
ここの良いところは,すべての PC User が入り乱れているところ.
情報交換の場として,これほどおもしろいところはありません.
激しい議論は,素敵です.理屈っぽい人,大募集!

2 : :2001/08/03(金) 05:44
>>1
提案があります.
64~128 bit Processor の時代が来ると信じている人たちが少なくありません.
私は,かなり,疑問に思っています.32 bit は,バランスが良いのだと...

3 :名称未設定:2001/08/03(金) 05:56
>>2
おおお! 目のつけどころが...(← コマーシャルキャンセラー作動)ですね.

4 :名称未設定:2001/08/03(金) 06:01
待て待て。
まずなにをもって64bitと言うのかの定義から始めないと。

5 :1:2001/08/03(金) 06:03
>>2
あんたの主張の根拠は?

6 :2:2001/08/03(金) 06:13
>>4
1. register bit width
2. (1.) & bus bit width

7 :2:2001/08/03(金) 06:27
>>1
一言で言うと,コストアップです.
bit width が 2 倍になったからっといって,
すべてのパフォーマンスが 2 倍になるわけではありません.

8 :名称未設定:2001/08/03(金) 06:34
レジスタとバスの幅で判断するなら、今時32bitなCPUの方が少ないんじゃないの?

9 : :2001/08/03(金) 07:18
>>8
そ,そうなんですかぁー.
くわしい,おはなしをお聞かせ頂きたいでござそーろう.

10 :名称未設定:2001/08/03(金) 09:03
>>2
来るよ。メモリもHDDもどんどん容量が大きくなってるじゃん。
だから現在はファイルの大きさは64bitで表されてる。
メモリも近いうちにそうなるだろう。
もちろん、32bitOSでは一度に計算できないから、繰り上がり・繰り下がりを使って
計算してるけど、それじゃ効率悪いから移行していくだろうね。

もう一つはカレンダーの問題。
現在の時刻の内部表現は、1899年1月1日からの経過時間をミリ秒単位で表してるんだけど、
それだと近いうちに32bitの限界を越えてしまう。
だからもっと大きな数が扱える必要がある。
また、大きな数が使えれば、ミリ秒単位でなくもって小さい単位を使ってもいいわけだしね。
コンピュータの処理速度はどんどん上がってるんだから、ミリ秒より小さい単位の時間が扱える
必要性もどんどん増してくると思う。

11 :名称未設定:2001/08/03(金) 11:04
>現在の時刻の内部表現は、1899年1月1日からの経過時間をミリ秒単位で表してるんだけど、
>それだと近いうちに32bitの限界を越えてしまう。

>>10はかけ算はできるのか?
他の内容もめちゃめちゃだし。
夏休みの友は早いうちに終わらせとけよ。

12 ::2001/08/03(金) 12:23
>>10
> 1899年1月1日からの経過時間をミリ秒単位で表してるんだけど、
計算してみ(w それだと32bit超えてるから。

1970年1月1日から、2039年の1月(だっけかな?)が、
UNIX epochの32bitで表せる時間の幅だったと思うよ。

と思ったらがいしゅつだった。鬱。

# それより、9月9日問題は大丈夫なのか?

13 :名称未設定:2001/08/03(金) 12:25
え?ここってもっともらしい嘘書くスレじゃなかったの?
他の奴らマジで書いてるの?

14 :名称未設定:2001/08/03(金) 12:26
ちなみに、>>10 で日付け計算以外の嘘に気付いた奴いるか?

15 ::2001/08/03(金) 12:34
>>13-14
ごめん。ちゃんと読んでなかったのかも。
よくわかったから、漏れは鬱氏するさ。

16 :名称未設定:2001/08/03(金) 12:37
>>10 がいってることはネタだね.
しかし,いいところをついている.
register はデータだけを扱うものではないと言う点だ.
Processor にとって, adress と data がそろわないと困ったことになる

17 :名称未設定:2001/08/03(金) 13:53
・32 bit (integer/unsigned):2^32=4294967296:
0< range < 4294967296

・32 bit (integer/signed):2^31=2147483648:
-2147483648< range < 2147483648

・fraction:FPU (floating point unit) の役割

18 :名称未設定:2001/08/03(金) 15:01
さて,>>10 の嘘をリストアップしてみましょう.

>メモリもHDDもどんどん容量が大きくなってるじゃん。
>だから現在はファイルの大きさは64bitで表されてる。
processor 直接のデータの取り引き相手は memory であって hard disk ではない.

>ミリ秒単位で表してるんだけど、
1年を mili second に換算して表すようなことはやっていないはず.
だいいち,PC の内部時計の精度はそんなに高くない.

>コンピュータの処理速度はどんどん上がってるんだから、
>ミリ秒より小さい単位の時間が扱える必要性もどんどん増してくると思う。
これに関しては FEP の役割であって,64bit の必要性とは無関係.

19 :名称未設定:2001/08/03(金) 17:20
さて、>>18 の嘘をリストアップしてみましょう。

>processor 直接のデータの取り引き相手は memory であって hard disk ではない.
ファイルを読み書きする時は当然ディスクと取り引きする。

>1年を mili second に換算して表すようなことはやっていないはず.
>だいいち,PC の内部時計の精度はそんなに高くない.
精度はともかく、してるのは間違いない。
ただし、32bitではなく64bit。>>10 の嘘は32bitと言ってたことであって、
ミリ秒に嘘はない。

>これに関しては FEP の役割であって,64bit の必要性とは無関係.
まず、FEP(フロントエンドプロセッサ)は無関係。
それと、処理速度が上がれば精度も高くなり、今まで使えなかったミリ秒以下の計測も
できるようになる。ミリ秒以下の時間単位を年単位の時間とシームレスに扱おうとすれば、
つまり、数年間をミリ秒以下の精度で表そうとすれば、大きな数字を扱う必要が出て来る。
処理速度と扱える数値の桁数は無関係ではない。

20 :名称未設定:2001/08/03(金) 17:23
>>10 のどこが嘘かって言うと、32bitOSでは32bit以上の計算が一度にできないと言ってるところ。
ほんとに誰も気付かないのか?

21 :>>20:2001/08/03(金) 17:56
・・・・自作自演ご苦労さん

22 :名称未設定:2001/08/03(金) 18:27
>>21
ほんとに気付かなかったの?ねえ?常識だよ。
バッカでぇ。

23 :18:2001/08/03(金) 18:40
嘘と間違いがごちゃ混ぜになって,頭くらくら.
でも,おもしろかったりして...
・訂正:× FEP → 〇 FPU

24 :1:2001/08/04(土) 06:52
つぶやき...

もう,2ch やめたい.なんだか,しらけてしまった.
みんな,良くあきないものだね.馬鹿,アホと罵りあう無限ループを...
でも,なにか,書き込んでいないと...く,苦しぃー.
だ,だんなー. ね,ねたをー.

25 ::2001/08/06(月) 10:06
この板はいつだってしらけてるよw

>>24
WebObjectsを買うのはどうよ?
OSX持ってるなら、体験版導入するとか。

26 :名称未設定:2001/08/06(月) 13:16
>>1
厨房にはまだわからんだろうが
世の中、理屈通りには逝かないことを知れ。

27 :これこれ:2001/08/06(月) 16:33
待て待て待て待て!
なぜそのように言い争うのだ。
象さんにあやまりなさい。


                 / ̄ ̄ ̄ ̄ ̄\
                  | パオーン      |
                 \__  __/
      / ̄ ̄ ̄ ̄ ̄ ̄\   //
     J|     (⌒ ●  ●⌒)
        |      )    | ≡|  (
        |        ヽ   | ≡| ノ
        |         /≡/ヽ
        | ≡|----| ≡|  ̄| ≡|        ◎ (((◎
      ( mn)   ( mn)  ( nm)      ソ` ソノノ'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^:
ぞうもすみません。

28 :名称未設定:2001/08/06(月) 16:38
幺夂            
小ニ

29 :kitchen:2001/08/06(月) 18:27
>>25
はー ぁぁぁ...
毛色が変わったスレッドが一つぐらいあってもよさそうだと,
考えたものの,みごとに,もくろみがはずれてしまって...
OS X の Developer Tool には,期待していたのに,いざとなると,
もつれた毛糸玉のようで,どこから手をつけたものやら...
>>26
はー ぁぁぁ..
>>27
あははは.
エレファント...いや,エレガントに行きたいものです.
にやりと笑える,煽りや叩きが,できるようになりたいなぁ...

30 : :2001/08/06(月) 18:43
なぞなぞです.
”HD の最外周部分は線速度が速いので,内周部と比べて読み書きが速い.”
これが,正しいかどうかを考えてみてください.

31 :名称未設定:2001/08/06(月) 18:58
>>30
わかりました。答えは「象さん」ですね?

32 :名称未設定:2001/08/06(月) 19:06
>>30
ttp://www.watch.impress.co.jp/pc/docs/article/20001027/key141.htm
ダメ?(なぞなぞとして答えられんかった)

33 :dA/dt:2001/08/07(火) 04:02
ささやかな実験をやりました.
[条件]
・HDD:Seagate Barracuda {7200rpm, 30GB, 8.2ms(seek time), 2MB(buffer)}
・Disk Cache:1.28MB (← MemoryControlPanel によるもの,VM:Off)
・Partition:{2GB X 7(#0~#6), 14.42GB X 1:(#7)} (← すべて HFS format)
・どのパーティションも空っぽの状態です.
・Software:Norton System Info v.3.0  (←なんとかの一つ覚え.許してけろ.)
[測定結果]
・Over all:
{#5 < #4 < #0 < #2 < #3 < #1 < #7< #6}
・Random Write (MB/sec):
{#2 < #7 < #4 < #6 < #1 < #5 < #0 < #3}:
(11.668)(11.672)(11.717)(11.766)(11.774)(11.809)(11.813)(11.925)
・Random Read (MB/sec):
{#7 < #1 < #4 < #2 < #6 < #3 < #0 < #5}:
(7.999)(8.107)(8.116)(8.188)(8.193)(8.199)(8.217)(8.231)
・64KB Sequential Write:
{#6 < #4 < #7 < #5 < #3 < #2 < #1 < #0}:
(14.494)(14.502)(14.504)(14.510)(14.530)(14.537)(14.545)(14.547)
・64KB Sequential Read:
{#2 < #3 < #4 < #5 < #1 < #0 < #7 < #6}:
(13.366)(13.377)(13.389)(13.478)(13.499)(13.507)(13.568)(13.699)
・Sequential R/W については,他にもデータがありますが,省略.
[結論]
測定条件によって,変わること,変わること!
ひとつだけ言えることは,”最外周は必ずしも最高速ではない ”ということ.

34 :名称未設定:2001/08/07(火) 07:45
思うほどムラはないもんだね。

35 : :2001/08/17(金) 23:44
>>33 のデータをとるために,HDD のフォーマットしなおししたりしたのに...
みんな,つめたすぎるよ.

36 :名称未設定:2001/08/17(金) 23:51
>>33 >>35
お、見逃してて気づかんカターヨ。
数字でこの差なら、触ってるときは違いがワカランね。
昔々のHDDだと、体感で違ったような記憶があるけど
その辺がカバーされるほど速くなったのかね。

37 :名称未設定:2001/08/18(土) 00:08
正直に言います。長いの読み飛ばしました。

38 : :2001/08/18(土) 04:06
正直,このスレッド,放棄するつもりでした.
書き込みたくなるスレッドがなくなってしまったので,あえて復活させました.
ところで,Altivec に詳しい方おられませんか?
僕は,疑問に思っています.
高クロックの PPC 750 なら,下克上もありえるのではないかと...

PPC 750 は,もともと,PPC 603e ベースのプロセッサだと聞きます.
つまり,低発熱,低コスト指向のプロセッサ.
でも,それが PPC 604e をぶっちっぎってしまったのですから,大変でした.
それならば,PPC 604e ベースのプロセッサというアプローチもありなのでは?

39 :名称未設定:2001/08/18(土) 20:17
1GHzとか出て欲しくないなぁ…
以前、クロックが2倍になったら買い換えると誓っちゃったんだけど考えてみたらお金がない。
自分にウソをついてしまう(w

40 : :2001/08/18(土) 21:27
>>39
良いものは欲しいけれど,金がない...よくあることです.
PPC 750 なら,IBM が開発に成功しているらしいです.
最大の興味はこの点です. つまり...
PPC 750(1GHz 以上) と PPC 7450(0.5GHz 程度) と勝負させたら,
どうなるかってこと.(もちろん,コスト,発熱量も評価の対象.)

41 :名称未設定:2001/08/18(土) 21:31
衝撃の事実!
スペイン人がインカ帝国を滅亡させたのはマカの手助けがあったため
http://www.bionasa.co.jp/home/maca/qanda.htm

42 :名称未設定:2001/08/18(土) 21:32
マカの効能
http://www.bionasa.co.jp/home/maca/sawayaka9904.htm

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

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

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