アカウント名:
パスワード:
95年くらいと言うと、CADの
Windowsで言えばWIN32 API時代からSYSTEMTIME構造体やFILETIME構造体が時刻の標準ですので、64ビット化するまでもなく2038年問題からの回避は十二分に可能かと思われます。
それぞれSYSTEMTIME構造体は最初から年月日時分秒を分けて格納する仕組みなので年のデータサイズ(WORD; 2バイト)で65535が最大値になります(従って仕様上の制限は65535/12/31 11:59:59.999 UTC)し、FILETIME構造体は1601/01/01を基準に100ナノ秒単位でDWORD 2つぶんで64ビット値(従って仕様上の制限は60056/5/28 5:36:10.9551615)です。
UNIX側でも同様のことがいえますが、回避策があっても使用せず手抜きをしているものが多いのも事実ですけど(話がズレ気味)。
既に定年…じゃないじゃないか。 下っ端どついてやらせるから関係ない。 つーか、30年以上使いそうなものも無いしなぁ。
Ultra2、Ultra60というSunのわーくすてーしょん。 ここ1ヶ月、アクセスもログインもしてないや。
# マックじゃないところがミソ。。。?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
初めての体験 (スコア:2, すばらしい洞察)
32bitで出来ることしか自分には出来ないです、、
Re:初めての体験 (スコア:3, すばらしい洞察)
飛び込む資格があるのなら、その64ビットがもたらしてくれる先進性を
出来る限り味わうべきだろう、たとえそれがつかの間の幸福であっても。
違うかい?
確かに、本格的にソフトウェア側が対応するまでは、
まだまだ時間があるだろう。80386が発表された頃だって、
そのパワーを十分に生かすOSやアプリケーションは、なかなか出なかった。
一般人がその環境を手軽に使えるようになったのはWindows95が発売されてから。
つまり、i80386が1985年に発表されてから10年もかかったんだ。
それに比べれば、発売されて数年で対応OSが使えるなんて幸せだよ。
Re:初めての体験 (スコア:1)
TomOne
Re:初めての体験 (スコア:1)
NiftyのFFMT(FTOWNS)で盛り上がって、
Xもまだ無くて、Lanカードも持っていないのに入れて
遊んでいました。
そのころに、TOWNS-OS上からダイアルアップで
知人の企業LAN経由でメールアカウントも貰ってWIDEに
つなげたのが私のインターネットデビュー?。
ちょっと脱線しましたが、ある意味386らしさが生きてた
マシンでしたよ。専用のWin3.1やWin95も有りましたしね。
Re:初めての体験 (スコア:0)
私も好きできたよ、TOWNS。いろいろと突っ込みどころは多かったけど。
Re:初めての体験 (スコア:0)
95年くらいと言うと、CADの
Re:初めての体験 (スコア:1)
16bitモードだけど32bit命令使った「要386以上」のソフトも多かった
Re:初めての体験 (スコア:0)
だからこそLinuxが生まれたとも言えるわけですが……
さて、AMD64(x86-64bit extented system)のために新しいソフトウェア潮流は生まれるのでしょうか。
Re:初めての体験 (スコア:1)
結構流行ってますよね。ドでかい容量のHDDを積んで、アニメなんか取り込んだりして。
あのテの巨大なデータを64Bitのポインタでビシバシ扱えるというのは
利点じゃないでしょうか。
メモリアクセスに64Bitのポインタがあれば、展開したデータが
軽く4GBを超えていても、無理に圧縮して32Bitでポイントできる範囲に
納める必要などありませんし。
16ビット機が出た頃、8ビットマシンと16ビットマシンを比較して、
16ビット機は倍ぐらい難解で操作が難しいかというと、そうでもなかったはずです。
それより、大きなデータを扱えるようになったというところが利点だった。
32ビットから64ビットへの変化も、同じようなものではないかと思います。
16Bitから32Bitへの変化では、メモリ保護と仮想マシンを提供する
システムの上でのマルチタスクという要素が大きな変化となったので、
コンピュータの利用形態が大きく変化することになりましたが、
今回はポインタがでかくなって大きなデータが扱えるようになるぐらいで、
ドラスティック(抜本的)な変化は見られないのではないかと思います。
Re:初めての体験 (スコア:1)
> 結構流行ってますよね。ドでかい容量のHDDを積んで、アニメなんか取り込んだりして。
> あのテの巨大なデータを64Bitのポインタでビシバシ扱えるというのは
> 利点じゃないでしょうか。
HDTVの解像度1920*1080ドットの動画で考えてみましょうか。
- 1ドットを表現するのに、RGBで3バイト使う。
- 1フレーム1920*1080ドットの圧縮処理のために、前後も含めて3フレーム分の情報を使う。
と仮定すると、1920*1080*3*3=18662400バイト(約17.8MB)。圧縮アルゴリズムの中でどれだけのメモリーを要求されるのかはわかりませんが、おそらく圧縮前のフレーム情報と合わせても4GBも要らないのではないでしょうか。
余ったメモリー一杯までフレームを先読みすることで、ディスクアクセスを減らして速度を稼ぐという手もありますが、そうするにしても、重要なのは搭載している物理メモリー量であって、64bit化による仮想メモリー空間の拡大はあまり貢献しないように感じられます。
ということで、
> 今回はポインタがでかくなって大きなデータが扱えるようになるぐらいで、
> ドラスティック(抜本的)な変化は見られないのではないかと思います。
動画圧縮に関しても、このご意見に同意します。
Re:初めての体験 (スコア:0)
またアセンブリ言語の経験がある方はわかると思いますが、一度メモリにアクセスする度にアドレス決めたりで数ステップ余分に処理を食います。さらにメモリとCPUの間にあるバスのクロックはご存知の通りCPUの動作クロックよりもかなり低い
Re:初めての体験 (スコア:1)
フツーのアクセスなら、動画(画像)なら通常RGBA=8:8:8:8の32bitでアクセスするから64bitは生きてこない。
同時に2dot分packed演算すれば64bitアクセスの意味が出るけど、packed演算ならMMXのほうがよりよい。
処理するデータが64bitなら、今まで32bitx2回(乗除算等もっと増える場合もある)で処理してたのが1回ですむから速くなるけど
そういう処理はあまり多くない。少なくとも動画圧縮・伸張に関しては変わらんと思う。
Re:初めての体験 (スコア:0)
# データバスはPentium辺りからすでに64bit以上だし
メモリコピーなんかはほとんどキャッシュで隠蔽されてしまうので
64bitにして目に見えて速くなることはないでしょう。
むしろポインタサイズが64b
Re:初めての体験 (スコア:1)
思いますが、巨大データを扱うプログラムの
開発効率は飛躍的に向上することになりますね。
効率が上がれば、コストがかからなくなり
それによりソフトウェアの値段が安くなります。
Re:初めての体験 (スコア:1)
> 16ビット機は倍ぐらい難解で操作が難しいかというと、そうでもなかったはずです。
i8086のセグメント機構はフラットメモリモデルな8ビットCPUに比べると10倍くらい難しいと思います。
i80286のプロテクトモードは更に難解ですた。
i80386になってフラットメモリモデルが使えるようになり,難解度は下がりました。
なお,32bitしか想定していないプログラムの移植は,地獄を見るでしょう。特にポインタとunsigned longを交換している………
Re:初めての体験 (スコア:1)
ポインタとint,longとintを交換するとまずいんだろうけど
おしえてエライひと
Re:初めての体験 (スコア:0)
な、なんだってーーー
も う だ め ぽ … …
Re:初めての体験 (スコア:0)
>結構流行ってますよね。ドでかい容量のHDDを積んで、アニメなんか取り込んだりして。
>あのテの巨大なデータを64Bitのポインタでビシバシ扱えるというのは
>利点じゃないでしょうか
技術発展にアングラは付きもの。と
Re:初めての体験 (スコア:0)
流行っているのは「最近」ではありません。
昔より一般化されたキャプチャ機材が出回ってはいますが、 その現象も最近と言うにはちょっと…
それに動画を扱うにしても、メモリ空間の増大そのものはさしてメリットになり得ません。付随して、それに
Re:初めての体験 (スコア:1)
私には16bitでも勿体無いかもしれません。
Re:初めての体験 (スコア:1)
Re:初めての体験 (スコア:2, 参考になる)
Windowsで言えばWIN32 API時代からSYSTEMTIME構造体やFILETIME構造体が時刻の標準ですので、64ビット化するまでもなく2038年問題からの回避は十二分に可能かと思われます。
それぞれSYSTEMTIME構造体は最初から年月日時分秒を分けて格納する仕組みなので年のデータサイズ(WORD; 2バイト)で65535が最大値になります(従って仕様上の制限は65535/12/31 11:59:59.999 UTC)し、FILETIME構造体は1601/01/01を基準に100ナノ秒単位でDWORD 2つぶんで64ビット値(従って仕様上の制限は60056/5/28 5:36:10.9551615)です。
UNIX側でも同様のことがいえますが、回避策があっても使用せず手抜きをしているものが多いのも事実ですけど(話がズレ気味)。
Re:初めての体験 (スコア:1, すばらしい洞察)
ソースが残っているか
リコンパイルできるか
テストできる環境が残ってるか
納品できるか
が問題だなぁ。
#あとお金もらえるか
Re:初めての体験 (スコア:0)
既に定年…じゃないじゃないか。
下っ端どついてやらせるから関係ない。
つーか、30年以上使いそうなものも無いしなぁ。
既に経験済み (スコア:1, すばらしい洞察)
Ultra2、Ultra60というSunのわーくすてーしょん。
ここ1ヶ月、アクセスもログインもしてないや。
# マックじゃないところがミソ。。。?
Re:今更経験予定 (スコア:0)
# 素直に余分に金出して普通のPC買っておけば、良かったかな。今更ながら。
# 同じ電気代払って面倒なメンテするなら、PCの方が(略)