【IA64】64bitプログラミング総合ｽﾚ【x86-64】2

1 ： ◆TimpoiKAMI ：2005/07/21(木) 14:26:37

ようやく64ビットを気軽に試せるようになったので、
せっかくだから
ナニヤラ目新しいことして遊ぼう藻前裸。

64ビット環境プログラミング全般の話題おkだけど、シェア事情により
x86-64(AMD64, EM64T)の話題が圧倒的に多くなる気配。
しかし、プラットフォーム・OS・言語問わずに逝こう。

前スレ
http://pc8.2ch.net/test/read.cgi/tech/1109121175/l50

2 ：デフォルトの名無しさん：2005/07/21(木) 14:30:01

２げと

3 ：デフォルトの名無しさん：2005/07/21(木) 14:34:35

>>前997
画像処理系か…確かにそうだね。データベースやエンコ以外
だとこの辺が筆頭か。

でもこれは論理アドレスより物理アドレスがほしいアプリじゃね？

4 ：デフォルトの名無しさん：2005/07/21(木) 14:35:22

>>1
スレたて乙

5 ： ◆TimpoiKAMI ：2005/07/21(木) 14:36:31

前スレ>990
64ビットでLoadされたら上位Qは無視もしくは不定で回るような
メカニズムになっていればちょっとは違ったかもしれんが

そのうち128ビットXMMがもの凄いスループットで回る日を夢見ることにしよう。

前スレ>992
Storeの琴は意図的に伏せてみたww

>>3
物理アドレスに関しては、もう4GB超の主記憶が積める時代になっちゃって
きていたというのもあるとおもう。

漏れ的には、ファイルことごとくmmapのような富豪プログラミングができるのが楽しげ。

6 ：デフォルトの名無しさん：2005/07/21(木) 14:41:49

＞富豪プログラミング
楽になるのはメリットのひとつだが、おれとしちゃ何か
ブレークスルーが欲しい。64bitマシンじゃなきゃ絶対
できなくて、尚且つ誰もが使いたくなるアプリや
プログラミングの新しい技法。

7 ：デフォルトの名無しさん：2005/07/21(木) 14:48:39

32bitマシンで絶対できないのはテラ級のメモリ搭載だから、
今後64bitマシンで果たしてそういうことをするときがくるのか。
それをして何か違う世界が開けないのか

8 ：デフォルトの名無しさん：2005/07/21(木) 14:51:21

普通に考えて自然言語処理とかのAI系だろうね
DB系の延長線上の技術が土台になるだろうけど

9 ：デフォルトの名無しさん：2005/07/21(木) 14:55:42

>>3
この辺見ると三次元CADはメモリ32GBですらローエンドらしいよ
http://pc8.2ch.net/test/read.cgi/os/1093549944/413

10 ：デフォルトの名無しさん：2005/07/21(木) 14:56:11

音声認識とかの精度もメモリの桁が上がれば使い物に
なるのだろうか？

11 ：デフォルトの名無しさん：2005/07/21(木) 14:59:11

>>10
音だけから分析するのには限界があるよ
人間はシチュエーションとか把握して意味から音を補完したりしてるから
コンピュータで真似しようとするとやっぱりAI系の技術に依存する
結局、意味まで把握する自然言語処理が進展しないと
音声認識やら機械翻訳やらのブレークスルーはない

12 ：デフォルトの名無しさん：2005/07/21(木) 15:06:16

自然言語の進展する余地はメモリ増大によってあるんかえ？

ときたまニュースで聞いたような専用のスーパーコンピュータ
使った主要７ヶ国語同時翻訳とかあった気がするけど、ああ
いうのが民生用に下りて来る土台になるのだろうか？

じっさいそのスパコンつかったのがどんくらいのレベルか
ぜんぜん知らんのだが。

13 ：デフォルトの名無しさん：2005/07/21(木) 15:09:26

>>12
最先端のスパコンがどれくらいのレベルかは知らないけど、
実装はぶっちゃけDBの延長線上だから
そういうのを実用的な速度で動かすには
物量作戦でオンメモリでさばける情報量が多いほど有利ではある。
まあ将棋とか囲碁とかも原理的には同じかな。

14 ：デフォルトの名無しさん：2005/07/21(木) 15:15:36

>>11
OCRなんかも似たような状況だね。

15 ：デフォルトの名無しさん：2005/07/21(木) 15:16:44

どうも巨大DBオンメモリが今後の鍵になりそうなﾖｶﾝ

でも「７ヶ国語同時翻訳」みないなニュースになるレベルは、
アルゴリズムからしてパソコンソフトと違うことは無いのか？

単に情報量とマシン性能の違いなんだろうか

16 ：デフォルトの名無しさん：2005/07/21(木) 15:16:52

>>3
物理シミュレーションとかの計算

17 ：デフォルトの名無しさん：2005/07/21(木) 15:20:32

>>15
翻訳は知らないけどチェスの世界王者に勝ったやつは
専用のコプロみたいなのを大量に並列で動かしてたはず。
そういうのがないと実用的な演算速度が得られないとすれば
メモリだけでなくCPUの方も超並列にする必要がある。
CELLなんかはそういう技術を民生化しようとする方向性ではないかと。

18 ：デフォルトの名無しさん：2005/07/21(木) 15:21:56

前スレの>>989へ
あの話は今64bit化で有効なアプリを作ると言う例のイベント前提の話だから
そんな空想の話してもしょうがないんですよ。
実装の話になると、物理メモリを無視できないでしょ？

19 ：デフォルトの名無しさん：2005/07/21(木) 15:52:00

>前スレ982
SSEは浮動小数点で遅いから当然ダメだけど
XMMXはMMXの１割引くらいの性能で普通に回るよ。速いこともあるし。

128bitが原理的に長すぎるというケースは除いて、
今後のCPUじゃXMMXが負けることはないと思うが、どうか。
そもそも、64bitに対応してないPenMで遅いのは構わないわけで。

20 ：デフォルトの名無しさん：2005/07/21(木) 15:53:50

物理計算、自然言語処理、巨大データベース

家庭用に普及させるロボットの頭脳になら無いだろうか？
そうなるとx64とかいう話にはならないかも知れないが、
頭脳はパソコンにあって胴体と無線通信しても面白いな

21 ：デフォルトの名無しさん：2005/07/21(木) 15:56:32

>>19
例えばブラウザ内で動く画像アプリをActiveXで実装したとする。
高速化のコードが32bitと64bitで共通に出来ないのは痛いんだ罠

22 ：デフォルトの名無しさん：2005/07/21(木) 16:05:51

>>21
命令が減る弊害か。同じコード書けばいいんだけど
実際やってみると面倒くさいんだ罠。

今日は人が多いな。

23 ：デフォルトの名無しさん：2005/07/21(木) 16:08:09

>>20
> 家庭用に普及させるロボットの頭脳になら無いだろうか？
最終的にはそういう方向が出てくるとは思う。
ASIMOに代表されるように日本人はロボット大好きだし。

でもあまりに先のこと過ぎて、
ここ数年のパソコンの動向とは直接関係ないかもしれない。
ただ徐々にそういう類の技術が民生に降りて来るだろうし、
それを受け入れる土台にはなると思う。

現状のGUIは10年前と比べても装飾が派手になっただけで
本質的な部分では何も変わってないけど、
性能の底上げで音楽や動画を扱うのが当たり前にはなった。
でもこれはマルチメディアのために性能が向上したというより、
性能が向上したからマルチメディアが使い物になったって感じ。

自然言語処理とかの分野もそんな感じで浸透するんじゃないかと。

24 ：デフォルトの名無しさん：2005/07/21(木) 16:19:23

64bit環境になるとやっぱり32bit演算の方が遅くなったりするの？

25 ：デフォルトの名無しさん：2005/07/21(木) 17:12:29

というより、MMXが無いとか、_asmが出来ないとか、別の意味で
当面64bitアプリの方が遅いﾖｶﾝ。32bitの演算自体は気にする
ほどの差は無いか、むしろ速いんじゃない？　特に掛け算割り算

あ、タコプログラムなら64bitにした方が速いってｗ

26 ：デフォルトの名無しさん：2005/07/21(木) 17:16:01

つーか、最近のコンパイラ優秀だから
普通の人が下手にアセンブリで書くよりずっとレベル高いコード吐くぞ？
可読性は確かに人手で書いたほうが上がるけど。

お前らいつの時代のコンパイラ使ってんだよ

27 ：デフォルトの名無しさん：2005/07/21(木) 17:17:36

ｺﾞﾒﾝ普通の人じゃないんだよｗ
使ってるのは最新コンパイラ　ｂｙ　最適化厨より

28 ：デフォルトの名無しさん：2005/07/21(木) 17:29:24

そこまでいかずとも、マトモな普通の人なら
使いどころをわきまえて高速化できると思う。

特にSIMDなら人間が直に書く表現力は強い。

29 ：デフォルトの名無しさん：2005/07/21(木) 17:36:07

でも普通の人じゃないオレでも最初に書いたSIMDは
Cの通常コード内の最適化に負けるよ。勝負はそこからだ！

30 ：デフォルトの名無しさん：2005/07/21(木) 17:53:09

そういえば俺も最初は負けたな。何でだろう。
コードを保存しておけばよかったよ。

31 ：前スレ990,992：2005/07/21(木) 18:59:58

>>得ろ屋ｸﾝ
スレ立て乙
で、まさかAltiVecみたいにユニットを全128ビットにでもしろと言うかね？(苦笑
どうせ現状整数も64ビット(×2)までの精度しか使わないんだからMMXニコイチ＋μOPs-fusionで当分は十分使える気もするけどね。
いっそ64ビット汎用ALUと兼用化してコア単体の縮小化を進め、マルチコアで性能稼ぐ手もアリじゃん？
いや、SSEを作った張本人のIntelがそんな路線の気がしてね。

32 ：デフォルトの名無しさん：2005/07/21(木) 19:06:43

＞何でだろう
コンパイラの最適化もCPUの通常コードの実行速度も
馬鹿じゃないってことだ罠。普通の人が素直に組んだ
くらいじゃまず勝てねーよ（変なストールありまくなの
も一因）

33 ：デフォルトの名無しさん：2005/07/21(木) 19:26:45

VecCやICCなら自動SIMD化使えるし組み込み関数が使えるじゃん。
SSEが使えない訳じゃあるまいし。
おﾌﾟやアスロン64でSSEﾌｭｰｼﾞｮﾝがサポートされるだけでも状況は変わるﾊｽﾞ
アスロン系のMMXはあの少ないレジスタで依存関係の引き延ばしをやらなきゃ
ならないから、ある意味使いにくい
SSEだとパイプラインの内部効率悪いしね

34 ：デフォルトの名無しさん：2005/07/21(木) 19:56:39

＞SSEが使えない訳じゃあるまいし。
＞SSEだとパイプラインの内部効率悪いしね

SSEを押してるのか逆なのかﾜｶﾝﾈ

35 ：デフォルトの名無しさん：2005/07/21(木) 21:00:21

>>1==得ろ屋ｸﾝ?

36 ：デフォルトの名無しさん：2005/07/22(金) 10:16:56

バードショップ

37 ：デフォルトの名無しさん：2005/07/22(金) 11:19:30

遅レスだが、スパコンの並列処理とCELLはまったく
思想が違う。

CELLは文字通り「ソフトウェアセル」という形で専用
の処理をさせるコードとデータをセルにして、７つの
SPEのいずれかを使って「専用に処理させる」もの。

SPEはオンダイのSRAMでコードとデータを処理する
から速度は速いしバスも占有しない。専用処理だから
コンテキストスイッチングもほとんど発生しない（という
より、そういう使い方は想定していない）のでレジスタ
を大量に持てる。単一目的のために効率を追求した
設計。

スパコンなんかの並列処理はバスを共有して汎用的
な処理を並列で動かすものでしょ。

38 ：デフォルトの名無しさん：2005/07/22(金) 11:25:27

>>37
スパコン汎用ではなくDeep Blueのカスタムチップを引き合いに出したものかと。

39 ：デフォルトの名無しさん：2005/07/22(金) 12:00:33

>>37
「スパコン」と一括りにするのはいかがなものか。いろんなタイプがあるべ。

40 ：デフォルトの名無しさん：2005/07/22(金) 15:02:53

>>37
おまえの御託よりもたるさんのHPのほうが使える。

41 ：デフォルトの名無しさん：2005/07/22(金) 16:27:04

直列でちょっぱやがベスト

42 ：デフォルトの名無しさん：2005/07/22(金) 16:29:46

並列を活かすのはそう組まんといけないからなあ…
速度目的と、どうしてもそうしないといけない場合は
仕方なしにやってるが

43 ：デフォルトの名無しさん：2005/07/22(金) 16:36:42

ILPよりはTLPのが幾分か楽なのも確かだ。

44 ：デフォルトの名無しさん：2005/07/22(金) 17:02:03

>>43
CPUはそうだろうけど、プログラマからは直列に組む方が楽だろ？

45 ：デフォルトの名無しさん：2005/07/22(金) 17:10:11

ILPが直列なわけないし
演算の畳み込みとか余分なこと考えなくちゃならないよりは、ループの中身を分割して並列処理させたほうが楽ぽ

本当に直列で組んでて性能が出てくれるのはPentium 4かな。
整数演算のレイテンシ0.5だし。
（もちろん落とし穴もあるが）

46 ：デフォルトの名無しさん：2005/07/22(金) 17:30:37

いやそうじゃなくて、直列に組んで速い方が嬉しいでしょ？

47 ：デフォルトの名無しさん：2005/07/22(金) 17:47:40

>>45
スーパースケーラとはとても言えないアーキ

48 ：デフォルトの名無しさん：2005/07/22(金) 17:50:49

もともと並列に計算可能な分野(分散処理向きなもの)を除けば、

アルゴリズムレベルでは直列に組んで
動作としては可能な限り並列になってくれる
とうれしい。

で、
アルゴリズム＝直列、インストラクション＝直列、実行＝並列、という思想がスーパースケーラで
アルゴリズム＝直列、インストラクション＝並列、実行＝並列、という思想がVLIW
なわけだが、現実はなかなか。

49 ：デフォルトの名無しさん：2005/07/22(金) 18:35:48

昔はスパコン=ベクトルプロセッサだったんだけどなぁ。

50 ：デフォルトの名無しさん：2005/07/22(金) 19:10:50

>>1
何、山田？

51 ：デフォルトの名無しさん：2005/07/22(金) 19:28:34

やはりご家庭用に64bitは需要が無いらしいな。
OSが3D-GUIになって立体テクスチャを山のように
使い始めるとかしなければ、消えちゃうんじゃないの？

52 ：デフォルトの名無しさん：2005/07/22(金) 19:46:43

まあ、それこそSIMDでやるべき領域なんだけどな。
うまくシフトやビット演算駆使してもSSEのがまだ速いという落ちになりそう。

でも近々アドレス空間は必要になるでしょ。もうPCでメインメモリ１GB、2GBとか普通なんだから。
それ以上の物理メモリ使うのにPAEだけは使いたくない。

53 ：デフォルトの名無しさん：2005/07/22(金) 20:13:40

もっと速い段階で64ビット化されてればなぁ。

メモリよりもファイルやファイルフォーマットの2GBや4GBの制限のほうが先にネックになったよね。
そういうプログラムやフォーマットが作られた時点で64ビットが普及していればなぁ・・・。

54 ：デフォルトの名無しさん：2005/07/22(金) 20:15:23

テスト環境として、qemuかbochsを用いて、ホストがWin2000かXPでゲストにXP x64 Editionを用意したいのですが、
初めて向けに一から設定を説明してあるサイトって在りますか？
あったら教えて。

55 ：デフォルトの名無しさん：2005/07/22(金) 20:30:30

情報は何ももってないんだが、
QEMUもbochsも、x64エミュレーションに対応してるんだね。今調べてはじめて知った。

56 ：デフォルトの名無しさん：2005/07/22(金) 20:36:20

>>53
ファイルサイズの限界はCPUのビット数とは関係ないけどな。
16ビットCPUだからといってファイルサイズが
64Kに制限されていたわけじゃないし。

57 ：デフォルトの名無しさん：2005/07/22(金) 20:50:20

＞でも近々アドレス空間は必要になるでしょ。
ほんとにそう思う？

グラフィックツール以外でこれだ、と思う用途がなさそうだし
それだって普通の人には32bit環境で十分だ。

おれにはSVHSの臭いがしてたまらないのよ。
メーカー製PCって256MB程度つんでるだけのが
まだまだ多い。

それじゃ使えないと騒ぐのはPC詳しい人間だけで、
WinXPも起動しないということは無い

まあPC供給元が64bitマシンしか作らなくなったら
徐々に変わっていくだろうけど。

58 ：デフォルトの名無しさん：2005/07/22(金) 20:50:30

関係あるよ。

CPUが32ビットだから、32ビットのAPIやフォーマットになってる。
もし64ビットだったら、64ビットのAPIやフォーマットになってたと思うな。

当時は
32ビットのCPUで、64ビットのAPIやフォーマットにすると、
オーバーヘッドが無視できなかったから。

59 ：デフォルトの名無しさん：2005/07/22(金) 20:57:46

現状64bitマシンで32bitマシンと物理メモリ量が違わないのが
問題だという人がいたけど、俺はもっと別の問題があると思う

それは、今のメモリ搭載量とバスの速度のバランスがそれなり
に取れているんじゃないかということ。

バスやCPUの動作速度が今のままメモリが数百倍積めるように
なっても、その分量全体にCPUがアクセスするのにそのまま
数百倍の時間がかかる。

これだとプログラムはしやすくなっても実質は遅い大容量デバイス
と変わらないんじゃないか

１GB走査するのに0.1秒だったら100GB走査するのに10秒だ。
リソースを豪華にしようとデータを搭載メモリに見合って豪華に
しても、プログラムの動作速度を決定する部分が一緒に100倍
にならないと活かしきれないと思う。

60 ：デフォルトの名無しさん：2005/07/22(金) 21:19:00

16bit->32bit
640KB->4GB
10MHz->3GHz
bus:?->800MHz
バランスよく進化したと思う

64bit、数百倍の搭載メモリが実現したとして、周囲の速度が
見合って上がるかな？

量子ｺﾝﾋﾟｭｰﾀ？？

61 ：デフォルトの名無しさん：2005/07/22(金) 22:01:54

>>58
APIはともかく、ファイルシステムが扱える最大ファイルサイズは、
歴史的にはCPUのアーキテクチャよりも、そのファイルシステムが
開発された頃の一般的なストレージデバイスのサイズとの関連の
方が大きいように見える。

16bit PC で使われてた FAT ファイルシステムは31ビット分くらいの
ファイルサイズに対応しているし、32bit PCで主に使われていた（いる）
NTFSは41ビット分くらいのファイルサイズにまで対応している。

64bit PCになったから、これを51ビット位まで拡張しようという動きも
無い様だし・・

62 ：デフォルトの名無しさん：2005/07/22(金) 22:21:28

64bitはでかいファイルを簡単にmmapして扱えるだけでもメリットあると思うけどな。
OSがタコでなければだけど。

63 ：デフォルトの名無しさん：2005/07/22(金) 22:40:14

mmapして何やりたいのか例をｷﾎﾞﾝ

64 ：デフォルトの名無しさん：2005/07/22(金) 22:42:10

>>59
現在の Intel式に FSB を通すと確かにそうなるけど、
AMD が SMP マシンでやってるみたいにプロセッサ
ごとにメモリバスが出てる方式なら、クロックを
変えずにメモリ帯域も増やせるのでは？
(SMP じゃなくて ccNUMA になるって話ね)
Rambus みたいにメモリバス幅を狭くして、チップ内の
マルチコアそれぞれからメモリバスを引き出すように
なるんじゃない？
メモリモジュール64個ってわけにはいかないから、
一つのモジュールから、複数のメモリバスを出すと。

65 ：デフォルトの名無しさん：2005/07/22(金) 23:01:01

>>64
もっとイメージ的な話で考えてます。あえて例を出すなら
現在のマシン：２Dテクスチャをリアルタイムでモーフィング：速度容量ともつりあってる

じゃあ64bitになった。テクスチャ３Dにしても容量的に現実の運用が可能に。
でもそれをCPUでグニグニしようとしたら上の例のようにリアルタイムで出来るのか？

速度もつりあって上がらないと駄目じゃないのってことです。

66 ：デフォルトの名無しさん：2005/07/23(土) 01:19:01

演算能力という意味では、今後はクロックの上昇率よりもコア数
の上昇率の方が比重が高いんじゃないの？メモリが64倍あっても、
コアが64個あって分割して処理すれば、O(N) 以下のアルゴリズム
は問題ない。

67 ：?デフォルトの名無しさん：2005/07/23(土) 07:58:47

>>63
データベース以外では画像処理関係でレイアウトスキャナーとか美味しそうだな。
同じような理由で高解像度のマッピングを多用するCGにもいいだろう。
個人的にイイと思うことは上のどれでもないが、そっちは教えない。

68 ：デフォルトの名無しさん：2005/07/23(土) 09:12:57

>>66
ますます並列プログラミングの時代かねえ
クロック100倍は非現実的だけど、コア64個はどうなんだろ？
民生機として考えると、ぴんとこないのは五十歩百歩…

69 ：デフォルトの名無しさん：2005/07/23(土) 10:13:17

っていうかマジでＭＭＸフッカツ希望

70 ：デフォルトの名無しさん：2005/07/23(土) 10:38:14

WOW64は完璧100％32bit互換モードと考えていいの？
32bitマシン上でのWOWはかなり動かなくなる16bitアプリ
あったけど。

今後WOW64が完璧に永久に32bitアプリを未来永劫保障
してくれるなら、32bitで十分なアプリを64bitにする気は
起きないんだが

ガソリンエンジンで十分な乗り物にジェットエンジン積もう
とは思わないのと同じ（今の64bitがジェットかは微妙だが）

71 ：デフォルトの名無しさん：2005/07/23(土) 10:53:36

Win32なドライバをインストールするようなものは駄目。

72 ：デフォルトの名無しさん：2005/07/23(土) 11:25:01

>>71
それ以外は注意する点なし？

73 ：デフォルトの名無しさん：2005/07/23(土) 11:37:32

>>68
将来的にはコア64個なら現実的だと思う（だいぶ先だが）。
ただ、そうなったときに、原理的に並列化できない（しにくい）タイプの
プログラムの性能が置いていかれる。
ちょっと悲しい。

74 ：デフォルトの名無しさん：2005/07/23(土) 11:47:32

＞原理的に並列化できない（しにくい）タイプ
そういうアプリって言い換えると32bitで十分じゃないか？

75 ：デフォルトの名無しさん：2005/07/23(土) 11:48:24

googleをローカルで動かす検索エンジンなんてどうかな。
ttp://www.yama.info.waseda.ac.jp/publications/gifimage/papers3/yamana-IPSJ8.pdf
ttp://www-db.stanford.edu/~backrub/google.html

76 ：デフォルトの名無しさん：2005/07/23(土) 12:17:48

>>74
そうかも知れないけど、コア数の話だから関係ないだろ。
・・・ってスレ違いってことか。ｽﾏｿ

77 ：デフォルトの名無しさん：2005/07/23(土) 12:35:03

>>74
スレッドによる並列化と64bit化の恩恵とはあまり関係が無いんじゃないか？

78 ：デフォルトの名無しさん：2005/07/23(土) 12:55:19

>>77
まあそれ言っちゃうと、x64でレジスタ倍増とかのうたい文句も
別の話になっちゃうしねえ。

スレッドというよりマルチコアとかでの並列プログラミングが
本格的に普及するのも64bitへの変更が皮切りになるんじゃ
ないか？

79 ：デフォルトの名無しさん：2005/07/23(土) 12:55:33

>>77
クロックが頭打ちだからこれからはコア数を増やすしかない状況を言ってると思う。
どうせ数年すればエントリーモデルですらデュアルコア64bitになってるだろうし。

80 ：デフォルトの名無しさん：2005/07/23(土) 13:13:05

64bit化ってだんだんに進むよね。
すでにデスクトップはほとんど64bitだけど、来年のYonahでも32bitだし。
32bitを切り捨てられる日は遠いなあ。

81 ：デフォルトの名無しさん：2005/07/23(土) 13:34:29

メモリアクセスって、2GB/secくらい?
したら、16GBメモリを積んだら、ゼロクリアするだけで8秒かかるのか・・・。

82 ：デフォルトの名無しさん：2005/07/23(土) 13:41:45

movntqとか使うと理論帯域に近いストアが出るべ。
DDR2なら3～4GB/secいけるだろう。

ただ、スピードより容量の進歩が速いので、
ゼロクリアの時間はだんだん長くなってきたねえ。

83 ：デフォルトの名無しさん：2005/07/23(土) 13:52:50

＞DDR2なら3～4GB/sec
このくらいのメモリの幅を使うアプリの起動時間だと、
どのくらいかかるんだろうね？　今でもアプリの起動時間って
めちゃくちゃ長いものもあるけど、64bitをフル活用するアプリ
だと起動時間数分とかにならね？ｗ

84 ：デフォルトの名無しさん：2005/07/23(土) 13:54:20

要は搭載メモリ幅に見合った速度がバス、CPUともに足りないだろ？

85 ：デフォルトの名無しさん：2005/07/23(土) 14:21:01

ノ　イ　マ　ン　型　終　わ　っ　た　な

86 ：デフォルトの名無しさん：2005/07/23(土) 14:50:43

>>85
ん？DSPみたいなデータ指向型プロセッサが台頭するとでも？

87 ：デフォルトの名無しさん：2005/07/23(土) 14:56:54

おれ、DSPのプログラムいくつかやった経験あるけど、
ちょっと使いにくいだけで基本はふつうのCPUと変わる
ところはなかったが…何が違うんだ？

88 ：デフォルトの名無しさん：2005/07/23(土) 15:00:13

>>72
16ビットアプリを内部的に使っているものも当然ダメ
(いまどきインストーラ以外には存在しないと思うけど)。
Ntナンタラカンタラみたいな非公開APIを使っているものは
仕様の違いで動作しない可能性がある。
Win16との互換性を捨てたためUSER/GDIハンドルが
65536個以上割り当てられる可能性ができた

パッと思いつくのはこんなところ

89 ：デフォルトの名無しさん：2005/07/23(土) 15:05:23

>>87
ノイマン型プロセッサは、命令を与えて動作するが、データ指向型プロセッサは
データそのものが命令になるというブツじゃなかったっけ？あまり詳しくないのでスマソ。

90 ：デフォルトの名無しさん：2005/07/23(土) 15:13:30

＞データそのものが命令になる
よくわからんです

アセンブラの表記は各社各チップで独特だったけど、基本は
命令＋オペランド、命令＋オペランド、命令＋オペランド…
でx86や68ｋなどと概念は同じだったと思う。

並列動作が見やすいように表記したりとかはあるけど、
些細なこと

91 ：デフォルトの名無しさん：2005/07/23(土) 15:14:59

>>88
さすがに16bitはもういいよなｗ
いろいろ参考になるthx

92 ：デフォルトの名無しさん：2005/07/23(土) 15:16:31

バッファオーバフロー型のワームがこれだけ世の中にあふれてるんだから
むしろデータとコードは厳密に分けようとするのがトレンドだと思ってたけど。
AMD64も全モデルNXビットサポートだったよね

93 ：デフォルトの名無しさん：2005/07/23(土) 15:17:29

>>80
はあ？
＞すでにデスクトップはほとんど64bit
いつの間に!?

94 ：デフォルトの名無しさん：2005/07/23(土) 15:47:00

データ指向型プロセッサってのは
DSPの一種で存在したってだけで
DSPのことではないんでは？

95 ：デフォルトの名無しさん：2005/07/23(土) 16:44:41

>>93
あなたがここで時代遅れの薀蓄披露して識者気取りになってる間に
確実に時代は移り変わってるんですよ。おじいちゃん

96 ：デフォルトの名無しさん：2005/07/23(土) 16:56:35

>>95
こんど量販店行って64bitマシンがいっぱい並んでるところを確かめてきまつ

97 ：デフォルトの名無しさん：2005/07/23(土) 17:01:22

EM64Tをサポートしてるかどうかなんて傍目の表示で分かるの?

98 ：デフォルトの名無しさん：2005/07/23(土) 17:06:32

インラインアセンブラのスレはどこですか？

99 ：デフォルトの名無しさん：2005/07/23(土) 17:06:42

店員に聞く

100 ：デフォルトの名無しさん：2005/07/23(土) 17:12:40

OSが64bitじゃないマシンを64bitマシンとして数えるのは
ちとなあ

101 ：デフォルトの名無しさん：2005/07/23(土) 17:23:51

>>81
バスが遅杉の初代Itanium使ったらﾜﾛﾀよ。

CPUが増えても速度上がらないし、
メモリが4枚束ねられてるのに、そこらのDDRと同じ速度。

102 ：デフォルトの名無しさん：2005/07/23(土) 17:25:46

386が98に搭載されはじめた頃も
「32bitマシンだよ」として売られていましたが。

ええ、バンドルされていたOSはN88BASICだけですよ。

103 ：デフォルトの名無しさん：2005/07/23(土) 17:33:23

>>102
いやそういう煽りがくるとは思ったけど。じゃなくて実質というか実感。

メーカー製のマシンでWin64積んでるのってNECとかにあったっけ？

win64アプリがどこのご家庭でも動くとかならんと、ほとんどという
実感にはならないっす

104 ：デフォルトの名無しさん：2005/07/23(土) 17:43:59

ナニいってんだこいつ
だったら最初からそう書け
自分の言葉足らずに対する他人の突っ込みを
煽りとかいってごまかしてんじゃねーよボケ

105 ：デフォルトの名無しさん：2005/07/23(土) 17:45:29

だいたい一体何様のつもりだ？
「俺様が64bitマシンだと感じるものが64bitマシンだ」ってか？
バカじゃねーの？

こういうのを煽りって言うんだよ。

106 ：デフォルトの名無しさん：2005/07/23(土) 17:48:23

だいたい80は(明記してないけどおそらく)CPUについて言ってるのに
いつの間にかWin64の話にすりかえられてるし

107 ：デフォルトの名無しさん：2005/07/23(土) 17:52:54

単に周りが見えない人なだけでしょ。そうでなきゃ軽々しく煽りとか言わないし。

108 ：デフォルトの名無しさん：2005/07/23(土) 18:10:33

怒らせてしまったらしい…ｽﾏﾇ

109 ：デフォルトの名無しさん：2005/07/23(土) 21:04:19

前スレはいいスレだったのに

110 ：デフォルトの名無しさん：2005/07/24(日) 08:22:35

愚露屋が絡むスレは荒れるな

111 ：デフォルトの名無しさん：2005/07/24(日) 12:38:27

そこでMMXネタですよ。

112 ：デフォルトの名無しさん：2005/07/24(日) 13:25:52

MMXが復活しない限り、64bit以降はありえないね。
俺が以降しないってことは・・・影響力も甚大だよ（ｗ

113 ：デフォルトの名無しさん：2005/07/24(日) 14:28:12

ｱｯｿ

114 ：デフォルトの名無しさん：2005/07/24(日) 14:35:00

>>113
何か勘違いしてないか。移行しないのは112だけじゃなくて
このスレの113以外全員だぞ？

115 ：デフォルトの名無しさん：2005/07/24(日) 14:47:25

メモリのチップの大きさって今よりぜんぜん小さく出来るのか？
何十ＧＢ積もうと思ったらその辺も解決しないとだめだろ

116 ：デフォルトの名無しさん：2005/07/24(日) 14:49:36

え、CPUとかの微細化とは違った問題がある？

117 ：デフォルトの名無しさん：2005/07/24(日) 14:55:33

出来るんなら無問題。マザボとかは総とっかえだろうが。
そういう規格でてるの？

118 ：116：2005/07/24(日) 15:07:06

ああ、小さいメモリを作ってたくさん載せて何十GBを実現するのね。
それだと難しいだろ。
今はあれが限界なわけで。MicroDIMMとかやたら高いし。

大きさ覚悟で大量に載せるしかないかと。
それでも値段は高いだろうし、いきなりメモリの量増やすのは不自然ぽ。

119 ：デフォルトの名無しさん：2005/07/24(日) 15:14:02

やっぱ限界なのか

120 ：デフォルトの名無しさん：2005/07/24(日) 15:30:09

ムーアの法則もどうやら終焉を迎えたようだし

121 ：デフォルトの名無しさん：2005/07/24(日) 15:49:57

>>120
いや、それはリーク電流でCPUのクロックが上がらなくなってることだろ？
元々の法則はトランジスタの集積度が18～24ヶ月で倍とかだから
一応今でも増え続けてるよ。

122 ：デフォルトの名無しさん：2005/07/24(日) 15:51:21

物理搭載も限界で速度も頭打ちか
頭だけ64bitを使えるようになってもなあ

123 ：デフォルトの名無しさん：2005/07/24(日) 15:54:11

x64はレジスタ倍増技術で、64bit化はオマケと思えばいいんじゃね。

124 ：デフォルトの名無しさん：2005/07/24(日) 16:23:38

レジスタ増えても大半のエンドユーザーには関係ないもんなあ…

125 ：デフォルトの名無しさん：2005/07/24(日) 16:29:20

16→32bit化を否定していた奴らを思い出す。

126 ：デフォルトの名無しさん：2005/07/24(日) 16:41:51

16→32のときはMMX禁止に相当するようなパフォーマンス低下の要因なんて
なかったし

127 ：デフォルトの名無しさん：2005/07/24(日) 16:44:55

16→32bitのときは速度も容量もまだまだ頭打ちではなかった

128 ：デフォルトの名無しさん：2005/07/24(日) 16:47:29

AMD64では32bitアプリもMMX、3DNow!を使わずにSSEの使用を
推奨しているけど、そこら辺はどうよ。

Intel知らんけど。

129 ：デフォルトの名無しさん：2005/07/24(日) 16:48:01

半導体の集積度は限界が見えてるんじゃなかったっけ？

130 ：デフォルトの名無しさん：2005/07/24(日) 16:51:44

淫テル、オワットル

131 ：デフォルトの名無しさん：2005/07/24(日) 16:54:58

i386も初期の奴はi286より遅かったんじゃなかったっけ？

132 ：デフォルトの名無しさん：2005/07/24(日) 16:55:53

AMDのXMMXはMMXと同等か速いの？　インテルのしか使ってないので知らんのだが

133 ：デフォルトの名無しさん：2005/07/24(日) 17:04:54

>>132
んなこたない。あからさまに遅くなる。レジスタ倍増したメリットもかたなし。
AMDのもMMXとXMMでユニット共用だ。

134 ：デフォルトの名無しさん：2005/07/24(日) 17:15:05

MMX→SSE2で遅くなるって言う人、どういうコードで遅くなるの？
よろしければそのコードの例を見せてよ。

135 ：デフォルトの名無しさん：2005/07/24(日) 17:16:34

淫テルがボロいからだろ。
x64コード走らせると遅くなりことが多いらしいぞｗ

136 ：デフォルトの名無しさん：2005/07/24(日) 17:17:26

×遅くなり
○遅くなる

137 ：デフォルトの名無しさん：2005/07/24(日) 17:19:08

ＭＭＸ最強杉

138 ：デフォルトの名無しさん：2005/07/24(日) 17:20:27

AMDの除算最強杉

139 ：デフォルトの名無しさん：2005/07/24(日) 17:47:19

>>134
コードじゃないけど、「SSE2 遅い」でググったらすぐにヒットする。

遅くなるって香具師の方がこのスレでも多い。

もちろんSSE2を活かせる場面も否定しないよ。速くなる状況に関しては使ってるから。

140 ：デフォルトの名無しさん：2005/07/24(日) 18:09:29

＞遅くなるって香具師の方がこのスレでも多い。

IDがでないこの板で、そんなこと言っても仕方がないですね。
実例を出す方が説得力ありますよ。

141 ：デフォルトの名無しさん：2005/07/24(日) 18:13:15

プログラムしたことあるやつかどうか疑ってしまう

142 ：デフォルトの名無しさん：2005/07/24(日) 18:22:52

http://pc8.2ch.net/test/read.cgi/tech/1105878545/l50
にお帰りください

143 ：デフォルトの名無しさん：2005/07/24(日) 19:32:15

>>138
詳しく

144 ：デフォルトの名無しさん：2005/07/24(日) 19:33:07

> 遅くなるって香具師の方がこのスレでも多い。

笑った
「スラドでこういう意見が多い」より酷い

145 ：デフォルトの名無しさん：2005/07/24(日) 19:53:13

出来たら速くなるコードを見せて欲しいもんだ

146 ：デフォルトの名無しさん：2005/07/24(日) 21:12:26

MMXとSSE2を比較してSSE2のほうが速かったよ。
コードはRSAのMD5を、MMXやSSE2を使うように書き換えただけのもの。

147 ：デフォルトの名無しさん：2005/07/24(日) 22:44:27

で、互いに具体的なコードは一切晒さず神学論争ですか

148 ：デフォルトの名無しさん：2005/07/24(日) 22:47:41

>>146
どんなケース？
１・mm0->xmm0　ほぼこれだけ
２・mm64bit幅からxmmの128bit全て使うようにした
３・SSE以降のMMX補完命令を使った。pmulhwとか
４・計算途中を浮動小数に変えてでも適用した

149 ：デフォルトの名無しさん：2005/07/24(日) 23:30:45

>>147
それが２ちゃんの醍醐味なんだよ（ｗ

150 ：146：2005/07/25(月) 00:16:19

>>148
2番です

MD5の計算は前後の依存が強いのでSIMD向きではないです。
本来ならマルチスレッドでやる複数のMD5の計算を、
まとめて1つのスレッドでやることで、SIMD化しています。

MD5の計算は32ビットなので、SSE2を使うと4本同時処理なわけですが、
すぐ前の計算結果を使った計算が多くてパイプラインがストールしまくるので、
4本を4組分、命令単位で交互に織り交ぜてやることでスループットを稼いでます。

それでもまだ若干パイプラインに隙間があるのだけど、
SSE2のレジスタの数が足りなくなってしまうので、
通常の整数レジスタを使った計算を4組分織り交ぜることで、
さらにスループットを稼ぎます。

こうして20本分を同時に計算することで、
MMXによって2本1組分に対して4倍の速度が稼げます。

151 ：146：2005/07/25(月) 00:22:11

あ、ごめん。
最後のところ、MMXだけ2本1組と比較したらダメだよね。
SSE2を使わない場合のピークは、
MMXを2本1組、通常の整数レジスタを1本7組の場合で、
SSE2を使えば、その約1.5倍くらいのスループットが出ました。

152 ：デフォルトの名無しさん：2005/07/25(月) 01:25:48

>>151
1.5倍か素晴らしい

md5のソース見てみたけど、ビット操作の鬼だな。SIMD化するの
大変だったでしょう。十分な手動パイプライニングの手間を惜しま
なければxmmxも効いてくるってことですね。

こっちはケース１・２では全滅。（画像変換処理）

153 ：デフォルトの名無しさん：2005/07/25(月) 10:26:19

P4の命令ﾚｲﾃﾝｼ/ｽﾙｰﾌﾟｯﾄ表をみると、MMX→SSE2化で効果ありそうだけど
逆にAthlon64だと効果ないっぽい。

2x2の行列の掛け算を148の(2)(3)でSSE2化しても、Opteronでは
まったく速くならないし遅くもならなかった。
まぁ、精度の関係でもうMMXは使っていないけどねー

154 ：デフォルトの名無しさん：2005/07/25(月) 10:54:34

>>153
SSE以降は、MMXでは精度が足りないようなところを補完する形で
使うとプログラムの全体的なアップにつながるね

155 ：デフォルトの名無しさん：2005/07/25(月) 13:54:43

Mathematica」がマルチコア対応、64bit環境をフルサポート
http://pcweb.mycom.co.jp/news/2005/07/25/100.html

64bit対応メリットは何かな？

156 ：デフォルトの名無しさん：2005/07/25(月) 14:25:23

>>155
大量のメモリが使える。つまり馬鹿でかい配列が使える。

157 ：デフォルトの名無しさん：2005/07/25(月) 14:36:39

マセマチ子さんは超巨大データを扱う需要はありそうだね。

158 ：デフォルトの名無しさん：2005/07/25(月) 17:22:11

>>156
64bitじゃないと確保できないサイズの配列って、どんな演算に使うの？

159 ：デフォルトの名無しさん：2005/07/25(月) 17:25:54

>>158
シミュレーション等ではいくらでも用途はある。

160 ：デフォルトの名無しさん：2005/07/25(月) 17:40:29

天気予報とか？

161 ：デフォルトの名無しさん：2005/07/25(月) 17:57:26

32bitでの、XMMがMMXより速い点。
・XMMはレジスタが広いので、同じ8個でもアンロールした効果が得られる。
・Pentium4ではL1からのLoadがMMXの倍の帯域。
・Pentium4ではMMXが弱い（レイテンシがXMMと同じ）ため、相対的に速い。

遅い点。
・使ってみるとわかるが、movdquがなぜかmovq*2より遅い。
・単純にレジスタが大きいから小回りが効かない。
・特定ユニットを使う命令が連続すると、命令が大きいため逆に並列実行を妨げる。
・Pen4以外では、内部でMMX*2に分解するのでデコーダの負担が少しある。
・psadbwは命令自体がMMX*2仕様なのでXMMで使うと余計な演算が必要になる。

162 ：デフォルトの名無しさん：2005/07/25(月) 18:00:05

>>151
1.5倍ということはPentium4だね（違ったら教えて）。
依存チェーンがきつい場合にSSE2は強いかも。

>>155
64bit*64bit=128bitの整数乗算ができるのが大きいと思う。

163 ：デフォルトの名無しさん：2005/07/25(月) 18:13:39

汎用の64bitレジスタより、mmの方が速い様な希ガス。
＠Athlon64 cgｺｱ

164 ：デフォルトの名無しさん：2005/07/25(月) 18:22:30

AthlonってMMXは汎用レジスタと違う実行ユニットなの？

165 ：デフォルトの名無しさん：2005/07/25(月) 19:30:23

>>163
それより古いC0コアのOpteronでは、mm(64bit)も汎用も変わんないよ。

x64のmasmってmmx命令にも対応しているのねｗ

166 ：デフォルトの名無しさん：2005/07/25(月) 19:44:40

>>165
そのmasm、ちょっと萌えるな。

167 ：デフォルトの名無しさん：2005/07/25(月) 20:04:46

>>165
うちのml64.exeは使えないぞ
↓というエラーが出る。

ml64.test.asm(5) : error A2222: x87 and MMX instructions disallowed; legacy FP state
not saved in Win64

168 ：デフォルトの名無しさん：2005/07/25(月) 20:19:06

psdkの人は残念。
vs2005 beta2のml64ならMMX対応。

169 ：デフォルトの名無しさん：2005/07/25(月) 21:06:51

MMレジスタを32本にしてF32vec2型とF64vec1型サポート汁

170 ：デフォルトの名無しさん：2005/07/25(月) 21:13:14

IA64なら汎用レジスタは128本だぞ

171 ：デフォルトの名無しさん：2005/07/25(月) 21:15:35

過去の資産をおろそかにするCPUは市場では歓迎されない

172 ：146：2005/07/25(月) 21:42:48

>>152
SIMD化は簡単でした。
分岐がなく、パックしてるデータ間は独立しているし、似たような演算ばかりなので。

MD5くらいだと、コンパイラのスケジューリングでも十分です。
他の人がアセンブラで実装したのと比べても遜色ないどころか、速いと思います。
アセンブラで書いてたらやってられないようなコードも楽勝なんで。

※ただし、コンパイルに異様に時間がかかりますが・・・。

>>162
Pentium4です。

ソースコードは非公開ですが、
http://www.geocities.jp/ny2scan/nyTripper.html
のnyTripperMD5bench10.zipで比較できます。
SSE2とMMXと整数レジスタの混合比を変えて総当たりして、
そのCPUでもっとも速い組み合わせを見つけ出します。

これの出力の
X-X-X
というが、
左から、SSE2、MMX、整数レジスタ(EAX等)の並列数です。
たとえば2-0-2の場合、SSE2で32bitx4 x2、整数レジスタで32bit x1で、9並列での計算になります。

>>170
128本を好き勝手に使えるわけじゃないから。

173 ：デフォルトの名無しさん：2005/07/25(月) 23:23:55

ってより…
メモリモデルのタイニー、スモール、コンパクト、ラージの話に近いんじゃないのかね。
あの時よりも、メモリの増大量が全く追いつかない訳だから、64bit化って意味だと時間は当然掛かるでしょ。
レジスタ数が増える分の向上はそれなりに大きいからx64化自体は急速に進むだろうけれども。

174 ：デフォルトの名無しさん：2005/07/25(月) 23:44:01

アドレス空間が広いのでファイルをマップするような場合はとても楽。
今の64bitを往時の32bitに例えると、今の32bitが往時はバンクメモリやらEMSやら。
データベースや全文検索など今後は個人や小規模オフィスでも需要が確実にある
応用に格段に有利だし、移行を進めるマーケットのパワーも往時より遥かに
強いので今更32bitにこだわるのはただのバカ。

>>173
レジスタ数なんて瑣末なことはほとんどx64の普及の要因とはなっていないよ。
そんなのは64bit化のついでに変わる様々なことのごく一端でしかない。

175 ：デフォルトの名無しさん：2005/07/25(月) 23:49:01

いくらメモリ空間が膨大にあっても、
ファイルを丸ごとメモリマップした場合、
プログラムからOSへヒントをちゃんと与える仕組みがあって、
適切にヒントを与えないと、かなりパフォーマンス的に厳しいものがある。

176 ：デフォルトの名無しさん：2005/07/25(月) 23:57:14

というのではわからない人もいるか。

実メモリの数倍のサイズのファイルを丸ごとメモリマップして、
先頭→末尾→先頭と、メモリを舐めた時に、何が起こるのか、
よく観察してみると、何が言いたいのかわかると思う。

177 ：デフォルトの名無しさん：2005/07/26(火) 01:34:25

>先頭→末尾→先頭と、メモリを舐めた時に
ライトするならヘッドが結構動くだろうけど、そもそもそういった使い方はしないんじゃないかな？
ディスクのいじめ方を知るにはいいと思うけど。

178 ：デフォルトの名無しさん：2005/07/26(火) 01:43:33

OS的には先読みするかと、どのページを残すかというアルゴリズムの問題だから
64bitだからといって大きく変わるわけではない。どうせ残せるページの数は実メモリ
のほうで決まるからね。OS的にはむしろ自由度が上がるという感じ。

179 ：デフォルトの名無しさん：2005/07/26(火) 01:47:53

いくらメモリが使えても、MMXが使えないんでは無意味。

180 ：デフォルトの名無しさん：2005/07/26(火) 02:04:45

>179
なるほど、んじゃ何使うね？

181 ：デフォルトの名無しさん：2005/07/26(火) 02:23:21

広い空間が不要でMMXが使いたいのなら32bitコード使ってりゃいいじゃん。

182 ：デフォルトの名無しさん：2005/07/26(火) 13:21:38

仕事で64bitに対応させざるを得ないこともあるんだろう。

183 ：デフォルトの名無しさん：2005/07/26(火) 13:36:06

仕事で金貰えるんならMMXが使えないくらい我慢しろ。

184 ：デフォルトの名無しさん：2005/07/26(火) 14:52:38

64ビットにしたら速くなるんでしょ?

というアホな客のために対応せざるをえないこともある。
んで、速くならなくて怒られる。
速くならないですよって最初に言ったじゃないですか、
とかいっても、それを信じないような客は覚えてないし、
責任も取らない。

185 ：デフォルトの名無しさん：2005/07/26(火) 15:13:29

ところで、64ビットではx87が一切使えないって話だけど、
超越関数はどうやって実現してるんだろ？
SSEにfsincosみたいのあったっけ？

186 ：デフォルトの名無しさん：2005/07/26(火) 15:36:14

おれはほんとに64bitが必要になるまで32bitで行く。
64bit演算が必要なくらいじゃロングモード使う必要ない。
32bit以上の計算がいるなら浮動小数で十分な場合が
ほとんどだし、__int64もある。
malloc(2GB)が必要にならない限り…

187 ：デフォルトの名無しさん：2005/07/26(火) 15:48:33

>>186
じゃ、このスレには用はないね。さようなら。

188 ：デフォルトの名無しさん：2005/07/26(火) 15:51:19

……あーすまん、それはウソだ。

189 ：デフォルトの名無しさん：2005/07/26(火) 15:57:35

>>185
某OS以外では使える

190 ：デフォルトの名無しさん：2005/07/26(火) 18:13:13

>>172
オレももういちどXMMのコード見直してみるか。
とはいえロングモードでインラインアセンブラは欲しい

191 ：デフォルトの名無しさん：2005/07/26(火) 18:17:29

>>185
そら反復法だべ

192 ：デフォルトの名無しさん：2005/07/26(火) 18:26:30

>>161
＞単純にレジスタが大きいから小回りが効かない。
これ、ネックになってる気がする。

193 ：デフォルトの名無しさん：2005/07/26(火) 18:45:43

>>191
64bitではプログラムで超越関数を実現してるのか。恐れ入った。
もうさ、それでは絶対にx87より速くなりっこないから。

194 ：デフォルトの名無しさん：2005/07/26(火) 18:50:56

>>193
そんなこたぁない。

195 ：デフォルトの名無しさん：2005/07/26(火) 18:51:56

RISC的な考え方なのかもしれない。

どうせ複雑な処理はマイクロコードで展開するわけで、
だったらコンパイラにやらせりゃいいじゃん、という。

196 ：デフォルトの名無しさん：2005/07/26(火) 19:03:43

32bitな某コンパイラも、超越関数はソフトウェアだな

197 ：デフォルトの名無しさん：2005/07/26(火) 19:58:27

なんで妙な勘違いするんだろうね。

198 ：デフォルトの名無しさん：2005/07/26(火) 20:05:42

一昔前のマイクロコードだと超越関数は反復(CORDICとかSTLとか)だったけど
精度保証がいらないなら級数展開が断然速いんじゃないかな。

64Bitの話題から脱線しまくっております。

199 ：デフォルトの名無しさん：2005/07/26(火) 20:14:02

>>196
詳しく。
MSCは直接x87を呼んでいるようだけど。

200 ：デフォルトの名無しさん：2005/07/26(火) 20:35:45

プログラミングって、インラインアセンブラがあるからこそ
高尚なものになりえてると思うんだ。

201 ：デフォルトの名無しさん：2005/07/26(火) 20:55:47

>>198
反復ってNewton法みたく収束反復のことでは?

202 ：デフォルトの名無しさん：2005/07/26(火) 23:29:41

>>200
ネタですか？

203 ：デフォルトの名無しさん：2005/07/27(水) 00:24:23

>>171
思うにハードが十分普及して枯れてきてからが、ハードの演算ユニット実装数に依存しない
APICアーキテクチャの本領発揮かと。

>>172
やっぱりnyTripperの人が来てたのか。MD5を並列とか言ってたからそんな気がしてた。
# てか俺もトリップ関連のソフト作ってるんだけどさ（ぼそ
そのうちPentium M最適化もおながいしますね。命令のレイテンシ短めだから、依存関係の
引き伸ばしはあんま必要なく、むしろレジスタを節約してL/S頻度を落としたほうがよさげでｓ。

で、そのPenM、たぶんクロックあたりのMMX性能は最強の部類に入るのにSSE2はサッパリ駄目ですな。
XMM μOPｓフュージョン実装待ちかな。

>>196
たしかPowerPC 970向けの最適化がそんな感じ。

ATL/WTLをWin64向けにビルドしても結構バグで落ちるらしいけど
大丈夫かいのう

204 ：デフォルトの名無しさん：2005/07/27(水) 00:25:52

淫乱アセンブラ使いたいならgccでいいじゃん

205 ：デフォルトの名無しさん：2005/07/27(水) 00:26:36

206 ：デフォルトの名無しさん：2005/07/27(水) 00:29:54

207 ：デフォルトの名無しさん：2005/07/27(水) 00:41:17

落ち着けよ

208 ：デフォルトの名無しさん：2005/07/27(水) 00:53:09

ごめん、なんかサーバの調子が悪くて連投になってもうた

209 ：デフォルトの名無しさん：2005/07/27(水) 01:07:44

>>199
ICCのP4向け最適化がそんな感じだったかと。

210 ：デフォルトの名無しさん：2005/07/27(水) 01:29:16

std::swap(p1, p2); で xchgに展開してくれるのが真の最適化コンパイラかと思う。
Intelコンパイラは酷すぎ。C++ライブラリクラスのメソッドのインライン化が全く利いてくれない。
SIMDだけなら最強だけど・・・

211 ：デフォルトの名無しさん：2005/07/27(水) 01:43:10

xchgってかなり遅いんじゃなかったっけ？普通のロード/ストアに比べて。
そもそもバスロックかかるし。

212 ：デフォルトの名無しさん：2005/07/27(水) 01:56:23

バスロックはかからないよ。

たいていはlock prefix付けてバスをロックして使うけどさ。

213 ：デフォルトの名無しさん：2005/07/27(水) 02:29:22

レジスタ値の交換には有効でしょ。

Pen4はメモリ－レジスタが半端なく時間かかる

214 ：デフォルトの名無しさん：2005/07/27(水) 03:14:43

>>212-213
えーと、インテルのマニュアルを読んだことはありますか？

215 ：デフォルトの名無しさん：2005/07/27(水) 03:16:19

というか、インラインアセンブラだの最適化だのほざいてるのって
結局この程度の連中が殆どなんだよね。

216 ：デフォルトの名無しさん：2005/07/27(水) 03:31:13

>>215
そういうお前は「この程度」以下なわけだな。

217 ：デフォルトの名無しさん：2005/07/27(水) 11:12:30

つーか210は突っ込み所満載だからネタだろ？

218 ：デフォルトの名無しさん：2005/07/27(水) 11:52:33

結局インラインアセンブラなんて使わずに、コンパイラに任せた方が大抵早くなるってこったなｗ
つーか、最近のコンパイラの最適化を侮っちゃいけない。
あれに勝てるアセンブリコード書ける人間なんてそういないんだし・・・
高速化のためにインラインアセンブラ使わせてくれってやつは、自分の実力把握してないんじゃね？

いや、別に馬鹿にしてるんじゃないよ。ただ何度も言うが最近のコンパイラに勝てる人間なんてそういないんだから…

219 ：デフォルトの名無しさん：2005/07/27(水) 12:01:33

xchg

デスティネーション・オペランド（第1 オペランド）の内容をソース・オペランド（第
2 オペランド）の内容と交換する。オペランドには、2 個の汎用レジスタまたは1 つの
レジスタと1 つのメモリ・ロケーションを使用できる。メモリ・オペランドが参照さ
れていると、LOCKプリフィックスの有無、あるいはIOPL の値に関係なく、プロセッ
サのロッキング・プロトコルが交換操作が持続している間自動的にインプリメントさ
れる

220 ：デフォルトの名無しさん：2005/07/27(水) 12:32:05

夏だな
うぜー

221 ：デフォルトの名無しさん：2005/07/27(水) 12:35:13

Athlon64だと、XCHGは16クロックもかかる。（L1ヒットで）

mov rax, a
mov rbx, b
mov b, rax
mov a, rbx
の方がずっと速いと思う。

222 ：デフォルトの名無しさん：2005/07/27(水) 12:37:25

>>218
コンパイラが吐かない命令を埋め込むときに使ったな。
ビットスキャン(場合によっては速い)とか
スピンロックとか。

あ。MMXモナー

223 ：デフォルトの名無しさん：2005/07/27(水) 13:41:05

MMX使ってる原始人はもうこのスレ来るなよ

224 ：デフォルトの名無しさん：2005/07/27(水) 14:00:03

Win64限定じゃあるまいし

225 ：デフォルトの名無しさん：2005/07/27(水) 16:07:07

>>210
レジスタが空いてないときに交換するなら便利かもしれんが、
そもそも自分でアセンブラ書くときにxchg使ったことないな。

>>213
Pen4ってLoadは普通に速いし、Storeはライトスルーだけど
その対策として384byteのストアバッファがあるから、交換目的には問題ないと思う。

226 ：デフォルトの名無しさん：2005/07/27(水) 23:53:10

>>221
レジスタ同士の値交換したい場合は？

まあ別に値さえ同じじゃなければ
xor *ax, *bx
xor *bx, *bx
xor *bx, *ax

でもいいんだけどさ。

227 ：デフォルトの名無しさん：2005/07/27(水) 23:53:53

こうや・・・間違えたorz

xor *ax, *bx
xor *bx, *ax
xor *ax, *bx

228 ：デフォルトの名無しさん：2005/07/27(水) 23:57:09

http://www.dd.iij4u.or.jp/~okuyamak/Information/xor_fixed_swapping.html

229 ：デフォルトの名無しさん：2005/07/28(木) 00:20:45

いまさら奥山教祖かよ、、、

230 ：デフォルトの名無しさん：2005/07/28(木) 00:52:50

少なくとも現代のCPUならテンポラリレジスタ使って普通に書いたほうが
ずっと速いぞ。64bitならレジスタも増えるし。

231 ：デフォルトの名無しさん：2005/07/28(木) 20:12:03

x86やx64のxchg命令は速度よりアトミックな交換ができるという点が重要なわけで

232 ：デフォルトの名無しさん：2005/07/29(金) 00:42:57

/O3や/Oxでコンパイルしてもstd::swapをわざわざ関数コールするICCのアホさ加減こそ突っ込みどころじゃなかろうかと

233 ：デフォルトの名無しさん：2005/07/29(金) 01:44:10

>>232
関数なんてコールしていないじゃないか。
嘘つき野郎

234 ：デフォルトの名無しさん：2005/07/30(土) 00:08:29

嘘も方便

235 ：デフォルトの名無しさん：2005/08/02(火) 12:45:15

、ｌ ∥＿＞:=‐ ￣￣「　ｌ| l　　 } ､　　ヽ　　んっ　んんっ…
ヽ　､i`─ '´　___　　　｜ｌl　⌒;　j　、　ヽ
　＼ヽ　r,ﾆ､‐‐'‐'　u　.ｌ　ｌl 　 '_ノ　　､　　ヽ　
　　｀＼"＼):､　　　｜ｌ|　　｀､　ヽ　､　　　ヽ
　　　　ヽ　ゞ'＾　　 !　lｌ　　　｀､　ヽ　　､　　ヽ
　　　　　丿　　.:::.　　｜ l|　　　　＼　ヽ、　､　　ヽ
　　　　丶､_　　　　 |　l|/ｌヽ　　　｀＞=‐- ミヽ　｀、
　　　　　｀⌒ヽ_　　|　ｌ| |　ﾊ　／´　　　　｀ヽ　　､
　　ﾁｭﾊﾟ　　/　　/.　｀´|　ｌ| | l / 〃　　　　　　　　｀、　､
　ﾁｭﾊﾟ　　/ 　　/ 　　 |　ｌ| | l' 〃　　　　　　　　
このレスを見た人はコピペでもいいので
10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ
出世しまくるわ体の悪い所全部治るわでえらい事です

236 ：デフォルトの名無しさん：2005/08/06(土) 19:35:56

32ビット実行形式から64ビットモジュールを呼び出す方法は存在しないのか?

237 ：デフォルトの名無しさん：2005/08/06(土) 19:42:45

ShellExecuteかsystemあたりでパラメータ渡して起動するだけなら原理上できそうだけど
それに何のメリットがあるのか

238 ：デフォルトの名無しさん：2005/08/06(土) 19:43:09

ないわきゃない。API呼び出しは結局すべて64bitのntdllに転送されてるんだから。
でも公開されてない。

239 ：デフォルトの名無しさん：2005/08/06(土) 19:48:18

out-of-process COMって手もあるね。結局はプロセス間通信だが。

240 ：デフォルトの名無しさん：2005/08/07(日) 02:58:35

まあ32bit/64bitの区切り単位がプロセスなんだからプロセス間通信になるのは
仕方ないよね。COMでも自前で適当なstubを書いてもいい。
そのあたりを自動生成するツールなんてもう誰か書いてそうな気もするけど、ないの?

241 ：デフォルトの名無しさん：2005/08/07(日) 03:04:01

で、その橋渡しをするのが怒涛熱湯ですよ

本屋を当たる限りWin64の情報が全く無いんだけど、全部CLRに移行させる気なのかね。
基本命令セットすら知らない。
mmintrin.hで書いたMMX向けコードをx64向けにコンパイルしたらｘ64汎用レジスタベースに展開されてしまった。
パックド演算特有の処理をどう展開するのかはまだ試してないが。

242 ：デフォルトの名無しさん：2005/08/07(日) 03:17:58

基本的には*mmintrin.hで書いておけばx86でもx64にもIA64にも対応する並列化コードが書けることだけはわかった。
それにしてもItaniumのコード素晴らしすぎる。惚れた！ここまでレジスタがリッチだとなんでもできんのね。
一般向けには売らないのかしら。。。

243 ：デフォルトの名無しさん：2005/08/07(日) 03:23:31

Intelは一般向けもIA64に移行させる夢を描いていましたが
市場にそっぽを向かれてAMD64で止めを刺されますた

244 ：デフォルトの名無しさん：2005/08/07(日) 03:36:43

唯一Powerに対抗できるプロセッサだし方向性が間違ってたわけじゃないとおもうけど
ダイナミックトランスレーションで「同クロックのNetBurst並みの性能」じゃちょっとどうしようもないかもね。
同クロックのPentium M並みならかなりイイが

245 ：デフォルトの名無しさん：2005/08/07(日) 03:37:29

>>242
つ ttp://page9.auctions.yahoo.co.jp/jp/auction/k23304285

いまんとこ5万円だ。

246 ：デフォルトの名無しさん：2005/08/07(日) 03:39:31

やっぱLinuxしかないのか。

247 ：デフォルトの名無しさん：2005/08/07(日) 03:52:57

単にOSなしってだけで、WindowsはMSDNでダウンロードすればいいんですよ。

248 ：デフォルトの名無しさん：2005/09/03(土) 02:16:52

64bitアプリ開発の参考になるサイトない？

249 ：デフォルトの名無しさん：2005/09/03(土) 06:28:41

OSは?

250 ：デフォルトの名無しさん：2005/09/03(土) 17:54:56

64bit版WinXP

251 ：249：2005/09/03(土) 20:59:01

>>250
ならば、マイクロソフトのサイトやMSDNを見たほうが早いよ。

252 ：デフォルトの名無しさん：2005/09/04(日) 01:49:31

開発環境の設定の仕方とか載ってるかな？
このサイトを参考にして設定したんだけど、複雑になってしまい環境を変更が簡単にできない…

http://www.02.246.ne.jp/~torutk/cxx/vc/vctoolkit2003.html
http://pcweb.mycom.co.jp/special/2005/compiler/009.html

今のところ支障はないみたいだけど…もっと簡単な設定方法ないかな？

253 ：デフォルトの名無しさん：2005/09/04(日) 01:57:32

簡単に設定したければ VisualStudio 2005 の発売を待つ。かな。

254 ：デフォルトの名無しさん：2005/09/05(月) 03:00:08

「はじめて読む486」みたいな良い本で、
最近の pent3～pent4・amd64 までサポート
しているような書籍ってないですかね？

255 ：デフォルトの名無しさん：2005/09/05(月) 13:18:09

>>254
そんな都合の良い本は売ってない。
書籍メーカーも儲けないといけないので、全部別冊で出してるよ。

256 ：デフォルトの名無しさん：2005/09/05(月) 14:01:50

ttp://www.tkool.org/punge/sinsa/No2.zip
ここにひとつのゲームがある。
このゲームは既存に存在するゲームへのアンチテーゼ。
何から何まで説明され、ユーザーが考える余地のないゲームが
多く存在する昨今、今回は「逆にまったく説明しない」または
「教えようとしない」コンセプトで作ってある。

なんだコレ？で終わる人間も居るだろうし
意味を探る人間も居る。
何かを感じないのも、何かを感じるのもどっちも間違いではなく、正解でもない。

枷を嵌め、尚もその枷を越える「チカラ」を手に入れるべき人類。
それは創作のみならず。
人類の飛翔は今の腐った思考で今を生きている、漠然と生きている
そんな人間達に一喝を入れるべきがあたしの作る「ゲーム」だ。
上記に何も感じなければ間違いではないと言ってるが
個人的には「この意味」を理解できない奴は何を作っても無駄だ。

あたしが目指す「ゲームの最終地点」は
「プログラム上のみならず現実世界ですらそのゲームを髣髴させる事」にあり。
世界を超えるデバイスとなるゲームを作る。
それがあたしの希望であり、全ての人類への警鐘となる。

目覚めよ、人間たち

257 ：デフォルトの名無しさん：2005/09/05(月) 16:18:53

>>256
もう夏は終わりだよ。

258 ：デフォルトの名無しさん：2005/09/15(木) 14:33:35

32bitの演算も高速化されるのでしょうか？

259 ：デフォルトの名無しさん：2005/09/15(木) 15:35:03

>>258
ほとんど変わらん。

260 ：デフォルトの名無しさん：2005/09/15(木) 15:35:35

されないのがふつー

261 ：デフォルトの名無しさん：2005/09/15(木) 16:30:02

32bitの演算は技術的には通常のまま
ただし、64bitと32bitの変換が入るので、オーバーヘッドは微々たる物だが、あるといえばある。
基本的に32bitの処理は32bitOSにやらせるのが一番。

ま、カーネルチューニングもされてるので、多少高速化されてるんだけどね。
ただ、ドライバのチューニングは逆に遅れてるので、結局総合的に見て、同じか判らない程度劣ってるんじゃないかな。

262 ：デフォルトの名無しさん：2005/09/15(木) 16:44:20

>>261
32ビットの演算で、64ビットと32ビットの変換のオーバーヘッドがかかる
32ビットの演算が、32ビットOSと64ビットOSで速度が違う

この2つのことについて、もう少し詳しく教えてください。

私はてっきり、オーバーヘッドなし、速度の違いなし、だと思っていたのですが・・・。

263 ：デフォルトの名無しさん：2005/09/15(木) 16:49:09

>>262
ただの32bit懐古厨なので放置推奨

264 ：デフォルトの名無しさん：2005/09/15(木) 16:50:18

>>262
オーバーヘッドってのはOS呼ぶときにの話でしょ。
そんなの微々たるものだし、そもそも計算ネックのアプリケーションでは
無視できる程度だよ。

265 ：デフォルトの名無しさん：2005/09/15(木) 19:02:47

amd64/EM64Tで、64ビットOS上で64ビットアプリで32ビット計算をする
話なら、レジスタ数や関数コールの違いで速くなるんじゃないかね。

266 ：262：2005/09/15(木) 21:25:20

>>264
OSを呼ぶと変換が生じるのでオーバーヘッドがあるのはわかるのですが・・

>>261には、32ビットの演算に変換が生じてオーバーヘッドがかかり、
32ビットの演算なら32ビットのOSのほうが速いと書いてあるので、
なんか自分の知っているのと違うなぁ、と思いまして。

267 ：デフォルトの名無しさん：2005/09/15(木) 22:43:31

>>266
>>261は気にするな。ｗ

268 ：262：2005/09/16(金) 00:02:31

>>261は釣りか、さもなくば真性の馬鹿だったんですね。

今夜は安心して眠れそうです。

269 ：デフォルトの名無しさん：2005/09/16(金) 00:33:18

真性のバカに一票

270 ：デフォルトの名無しさん：2005/09/16(金) 01:42:42

プレス子の実装だと、多少はあるんじゃねーのか。
あと、アーキそのものが違うからなんとも言えないがIA32＞IA64上のIA32EL

271 ：デフォルトの名無しさん：2005/09/16(金) 22:42:46

かつてのAlphaみたいにクロックの差で補うつもりだったんだろう
でもどうしても一番金の掛けられるIA32の進化には勝てない

272 ：デフォルトの名無しさん：2005/09/17(土) 02:49:12

>>258
「32bitの演算」に限定すれば同じ
「32bitのデータの処理」辺りまで広げれば違いがある可能性がある
けど一般論は無理だろう　具体的かつ定量的に検討しないと

273 ：デフォルトの名無しさん：2005/09/17(土) 02:51:41

16bit32bitになったときに、とても高速になった気がしたのですが、
今回はあまりそんな気がしないのが何故？

274 ：デフォルトの名無しさん：2005/09/17(土) 03:16:08

>>273
どうせ32bitの初めて買ったCPUが486とかPentiumとか、そういうオチなんだろ。

275 ：デフォルトの名無しさん：2005/09/17(土) 03:21:33

アドレス空間も整数の幅も 32bit で十分なアプリが殆どだから
64bit 幅のデータ転送が結構大変だったから
>>273 が Pentium を使ってるから

どれ?

276 ：デフォルトの名無しさん：2005/09/17(土) 03:46:22

16ビットの時にhugeポインタを使いまくってたから、に一票。

277 ：デフォルトの名無しさん：2005/09/17(土) 04:11:29

>>275
64ビット幅のデータバスなんて初代Pentiumでも実装してたぞ。
Pen4はコア内では最大256ビットじゃなかったかな。上り下り計で。

278 ：デフォルトの名無しさん：2005/09/17(土) 05:06:10

>>273
１６ビットＣＰＵは２８６で２０ＭＨｚくらいまででキャッシュメモリなし
３２ビットＣＰＵは３８６以降で３３ＭＨｚくらいからで命令もキャッシュメモリも追加された
ビット幅に関係なく３２ビットが早い。

４８６　１００ＭＨｚでメモリも８０Ｍバイト載ってると仮定する。
Windows３．１　ＤＯＳの１６ビットファイルアクセス、ＤＯＳのディスクキャッシュ
　　　　　　　　　そしてシングルタスクなので遅く感じる

Windows９５　　大量のディスクキャッシュを使い３２ビットファイルアクセス
　　　　　　　　　マルチタスクになり３．１アプリがエラー出しまくり
　　　　　　　　　そしてＯＳの３２ビット化が進み、ボトルネック解消で高速化
　　　　　　　　　（メモリアクセスは３２ビット必要だから）
　　　　　　　　　さらにマルチタスクで早く感じる。実際レスポンス、描画がめちゃはやになった。

メモリは２０ＭＢくらい以上でWindows９５の方がはやくなるが、それ以下では３．１が早い。
当時１６ＭＢ～３２ＭＢが普通だったし。

279 ：デフォルトの名無しさん：2005/09/17(土) 05:27:43

適当すぎ。
286は5～１2MHz
386は16～33MHz
ちなみに、486は20～100MHｚな。

280 ：デフォルトの名無しさん：2005/09/17(土) 05:53:01

386でL1キャッシュが載ったのは、サードパーティ発売分だけだろ。
Intel(c)謹製にはなかったのでは？

281 ：デフォルトの名無しさん：2005/09/17(土) 05:56:10

あ、サードパーティ≠セカンドソースな。

で、386、486と模造品を作られるのに業を煮やしたIntelは、586として
発売予定だったCPUをPentium(c)として登録商標化し、他のメーカーが
使えなくした。

282 ：デフォルトの名無しさん：2005/09/17(土) 08:40:41

全角英数ウソ書きすぎ

283 ：デフォルトの名無しさん：2005/09/17(土) 08:52:36

>>278
2chデビューしたてで、何でも書いてみたかったのか。
どの板でもそうだが、嘘を書くと、激しくバッシングされるぞ。特にIDの出る板は気をつけな。

284 ：デフォルトの名無しさん：2005/09/17(土) 09:02:13

>>279
あれ、386のクロック下限 > 286のクロック上限だっけ? 逆じゃない?
少なくとも80286の16MHzはあったと思う。
PC-9801で80386載せたやつが出始めのとき、EPSONはそれより速い80286搭載の
互換機を出して「大差ないから速い方がいいでしょ」みたいな広告打ってた
記憶があるんだけど。

285 ：デフォルトの名無しさん：2005/09/17(土) 09:15:48

Intel製でなくても良いのなら、286相当で20MHzというのもあったな。
確かAMD製だったか？

286 ：デフォルトの名無しさん：2005/09/17(土) 09:18:28

俺のおぼろげな記憶だと、
386は16MHzから、286は16MHzまでだったんじゃないかな。
もしかしたら、286は12MHzまで(>>279の通り)かも。

で、エプソンに使われていた286の20MHzとかは
Intel製じゃなくて、AMDとかのセカンドソース。
これは、「命令互換」じゃなくて、中身の回路もIntelと同じもの。

287 ：286：2005/09/17(土) 09:21:40

つーか糞かぶりやん。
やっぱ286は中途半端で使い物にならんな。

288 ：デフォルトの名無しさん：2005/09/17(土) 09:32:56

http://ja.wikipedia.org/wiki/Intel_80286

289 ：デフォルトの名無しさん：2005/09/17(土) 09:40:16

16bit→32bit の時は速度よりも忌まわしい「セグメント：オフセット」の壁から解放されて
メモリがフラットに使えることが一番嬉しかった。

32bit→64bit では特殊な用途でもない限り、１つのアプリでそこまで大量のメモリを
必要とすることは当分ないだろうからなぁ・・・

290 ：278：2005/09/17(土) 13:03:27

そうそう。あったねコプロ。
コプロなしとかもあって遅かったね。
FAくらいまで２８６だと思ってたけど違ったね。
当時は詳細なデータが雑誌に載ってたんだけどNECは公開してないし分からないね。

>>282-283
君もなかなかの能無しぶりだね。
特に>>283

確か２８６と４８６で周波数あたりの処理速度を測ってみると３倍だか１０倍だかあったんだよ。
動かすものによるけどね。
もう１０年以上前のことで資料なしでしゃべってる人間をうそつき呼ばわりするのもどうかと思うよ。
探してもろくなの出てこんかったけど。

http://www.amy.hi-ho.ne.jp/nakajima-jr/com/pc-9801/fa.htm
PC-9801FA2 458,000円
FAの搭載している CPUは intel 486SX (16MHz) で、キャッシュメモリ 8kB内蔵です。
キャッシュメモリを内蔵したため、従来の 386より高速な処理を実現しています。

＞しかし、当時、価格の安い PC/AT互換機では、i486DX 25MHzが主流となっており、
このころDOS/Vのほうが激安撃早ってうわさにはなってた。

PC-9801シリーズの系統（デスクトップ）
http://d.hatena.ne.jp/keyword/PC-9801?kid=92322

ＰＣ－９８０１ＲＡ２１/５１
http://www.pc-9800.net/db1/data/pc-9801ra.htm
CPU i386DX(20MHz)

PC-9800シリーズ
http://ja.wikipedia.org/wiki/PC-9800%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA

291 ：デフォルトの名無しさん：2005/09/17(土) 13:10:45

>>290

ちょっと待て。

＞確か２８６と４８６で周波数あたりの処理速度を測ってみると３倍だか１０倍だかあったんだよ。
＞動かすものによるけどね。

俺はこの意見に一度でも反対したか？L1を載せて、486がそれまでのCPUよりも
馬鹿っ速くなったのは、当然知っている。というか、EPSONの486-25MHzを載せた
98互換マシンを持ってたわけだが。後から486DX2が発売され、それも買って差し
換えたよ。

それを、俺がまるで知らなかったような書き方をされるのは、頭にくるな。
お前もうちょっと人の書き込みをよく読むようにした方がいいよ。自分に都合のいい
部分しか目に入らないとは、やっぱり馬鹿だと言われかねないぞ。

292 ：デフォルトの名無しさん：2005/09/17(土) 13:13:17

昔話もちょっとは面白いけど、続けるならそういうスレ行ってやってくれない？

293 ：デフォルトの名無しさん：2005/09/17(土) 13:14:46

Windows3.1をシングルタスクとか言ってる時点でバカ確定ですが

294 ：デフォルトの名無しさん：2005/09/17(土) 13:43:38

>>293
ノンプリエンティブマルチタスクはマルチタスクなんかじゃない
漏れは職場でUNIXはMM（マルチユーザーマルチタスク）、
WindowsはSS（シングルユーザーシングルタスク）と習った。

状況が変わったのはWindowsNTと９５の登場でだ。

http://www.intera.ne.jp/~friends/toku/pcwin95.html
一世代前のWindows3.1はマルチタスクといってもウィンドウが
有効（アクティブ）になっているソフトだけが動作していて、
他のウィンドウは停止状態になっていましたので疑似マルチタスクと呼ばれています。　

切り替えだけならDOSだって特殊なソフトで複数切り替えられた。
ただ裏のやつを保存しそこなうから結局使うのやめたが。

ちなみにWindowsは２．０から使ってる。

295 ：デフォルトの名無しさん：2005/09/17(土) 13:53:18

>>294
一つのアプリがハングしたら、全部のアプリがアウトだったからなぁ。
とても仕事には使えなかった。

296 ：デフォルトの名無しさん：2005/09/17(土) 14:13:35

ぶっちゃけ>>294の職場の話なぞ聞いてはいない

297 ：デフォルトの名無しさん：2005/09/17(土) 14:15:47

>>296
ぶっちゃけお前には言っていない。失せろ。

298 ：デフォルトの名無しさん：2005/09/17(土) 14:16:27

>>296
はいはい。
レベルが低いとは言え、２００人ものプログラマを抱える部署で言われてたのを
馬鹿の一言で済ませるわけですか。

ばかっちゃあ馬鹿ですが、あんたに言われたくないってこった。

299 ：デフォルトの名無しさん：2005/09/17(土) 14:20:07

>>298
>馬鹿の一言で済ませるわけですか。
もちろん済ませる。

>ばかっちゃあ馬鹿ですが、あんたに言われたくないってこった。
言わなくたって事実だしな。自覚があるのはいいことだ。

300 ：デフォルトの名無しさん：2005/09/17(土) 14:21:52

ここは16bitスレですか？　いいかげんにしましょうよ。

301 ：デフォルトの名無しさん：2005/09/17(土) 14:23:52

>>300
８ビット脳が１６ビットを語るとこうなると言う見本。

302 ：デフォルトの名無しさん：2005/09/17(土) 14:24:00

マ板逝け！！

303 ：デフォルトの名無しさん：2005/09/17(土) 14:24:56

でもまあ2.0はさらっと触って華麗にスルーが基本だったよね。
「２．０から使ってる。」ってのは当時の判断能力を疑われても
仕方がない。

304 ：デフォルトの名無しさん：2005/09/17(土) 14:28:14

>>303
日立のシステムで日立の人が入れたんですよ。
判断したのは日立です。
つーか２．０しか動かないような古い端末だし。
基本ホスト端末だし。

いや最初オペレーターだったから使うだけだったんだよね。
あのころはオペレーターっていう採用枠があって良かったよ。

305 ：デフォルトの名無しさん：2005/09/17(土) 14:30:16

>>304
だからここは昔話をする板じゃありませんから。うぜーんだよジジイ。

306 ：デフォルトの名無しさん：2005/09/17(土) 14:34:53

>>298と>>304を見比べると面白いな
「２００人ものプログラマ」と「オペレーターっていう採用枠」とやらの接点が分からんｗ
要は昔話してるじじいは当時下っ端の下っ端だったってことでOK？

307 ：デフォルトの名無しさん：2005/09/17(土) 14:37:56

>>305
そんなこと言ってるとここゴミばっかりにするけど？
Windows２．０みたいに華麗にスルーすればいいのに、

君の判断能力を疑うよ。

つーか君には６４ビットなんて無駄だから他のスレに行けよ。

>>306
新卒から下っ端じゃないなんてたいそうなエリートさんですね。
事件現場に居合わせた警察官僚はホントにじゃまばっかしくさって役にたたなかったよ。
事件が見えてないんだから。

308 ：デフォルトの名無しさん：2005/09/17(土) 14:39:18

　 /＼＿＿_／＼
／　／　　　ヽ ::: ＼
|　（●）,　、（●）、　| 　　／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　ま～たはじまった
|　　　,;‐＝‐ヽ　 .:::::| 　　＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼

309 ：デフォルトの名無しさん：2005/09/17(土) 14:41:43

>>307
これだから脳の硬直化したロートルプログラマは困るねえ。

310 ：デフォルトの名無しさん：2005/09/17(土) 14:42:19

じじいの出口
つttp://bubble4.2ch.net/i4004/

311 ：デフォルトの名無しさん：2005/09/17(土) 14:42:45

>>309 が柔軟な解決を見せてくれるそうですね。

・・・・無理だと思うけどね。

312 ：デフォルトの名無しさん：2005/09/17(土) 14:43:29

>>310
ナイス。

313 ：デフォルトの名無しさん：2005/09/17(土) 14:47:49

>>310
悪いけど昔のPCには興味ないよ
Pen４よりPen３がいいとは思うけど、Pen３よりPenMがいいからね。

314 ：デフォルトの名無しさん：2005/09/17(土) 14:52:10

>>313
詭弁じいさんは会社の中でも浮いた存在だろ。リストラはまだなの？

315 ：デフォルトの名無しさん：2005/09/17(土) 14:53:54

これからはインテルよりAMDの時代かな。
ほんとのマルチコアが普及したらどうか分からないけど、
IA６４とかいらね。

IA６４が必要になるのってどんな？

316 ：デフォルトの名無しさん：2005/09/17(土) 14:53:57

>>313
なに言ってるんだ？Pen3の話題なんかほとんどでねぇよ。
ここなんかお前にぴったりだ。じじいらしく引っ込んでろ。
【Win1.0】幻のOSを語ろう【Win2.0】
ttp://bubble4.2ch.net/test/read.cgi/i4004/1090495552/

>>314
ヒント：こんな時間に2ch

317 ：デフォルトの名無しさん：2005/09/17(土) 14:54:25

>>314
オマエも早く就職しろよ

318 ：デフォルトの名無しさん：2005/09/17(土) 14:55:23

>>316 >>317
土曜日も仕事の弱小会社に勤めてるのか。まあ精一杯仕事してくれたまえ。

319 ：デフォルトの名無しさん：2005/09/17(土) 14:59:39

>>318
馬鹿？

320 ：デフォルトの名無しさん：2005/09/17(土) 15:00:47

>>319
（　´∀｀）オマエモナー

321 ：デフォルトの名無しさん：2005/09/17(土) 15:05:19

２チャンネルの良心、モララーデビュー！ 2000/04/10 モララー誕生スレ
1 名前：名無しさん投稿日： 2000/04/10(月) 00:35

　 Λ＿Λ 　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）＜　やめてやれよ！
　（　　　　）　＼＿＿＿＿＿＿＿＿＿＿＿＿
　｜｜　|
　（_＿）＿）

でもそれ以前に使ってたけどな。

322 ：デフォルトの名無しさん：2005/09/17(土) 19:01:21

> 確か２８６と４８６で周波数あたりの処理速度を測ってみると３倍だか１０倍だかあったんだよ。
> 動かすものによるけどね。

くわしく。

286が2クロックで実行する命令を、
486は1クロックで実行しているので
概ね2倍になるはず。

ZOBのcpubenchでは、
286の10MHzのスコアは5.69。1MHzあたり0.569ポイント
486DX2の66MHzのスコアは84.26。1MHzあたり1.277ポイント
その差は2.24倍。

323 ：デフォルトの名無しさん：2005/09/17(土) 19:37:02

プログラムサイズがキャッシュに収まる場合に１０倍差が出た。
まんでるぶろなんとかだったかも。
２８６ではじわじわ描画されるのに、キャッシュ搭載だと一瞬でなんども描画したと思う。
周波数も違ったけどね。
あ、小数演算とか割り算多用したかも。

確かキャッシュを有効にするドライバが必要で、OnとOffで全然違ったような気も。
ライトキャッシュのOnOffだったかな？
でもBIOSでライトキャッシュ切り替えても体感速度変わらないよね？

＞286が2クロックで実行する命令を、
＞486は1クロックで実行しているので
＞概ね2倍になるはず。

とはいえ、メモリアクセスが遅いので、２８６は待ち時間が多いんですよ。

＞286の10MHzのスコアは5.69。1MHzあたり0.569ポイント
＞486DX2の66MHzのスコアは84.26。1MHzあたり1.277ポイント

これ参考にするとクロックあたりでの計算しなかったかも。
でもいろいろ条件変えて実験したんだけどな。

324 ：デフォルトの名無しさん：2005/09/17(土) 20:06:10

全角厨は馬鹿。

325 ：デフォルトの名無しさん：2005/09/17(土) 20:28:08

てかさ、いいかげん過去の記憶だけで物言うのやめてくんないかな。

326 ：デフォルトの名無しさん：2005/09/17(土) 20:28:33

>>323
CPUBENCHはキャッシュに収まるくらい小さいよ。
浮動小数点演算は286はソフトウェアでゴリゴリやるけど、486はハードウェアで計算するよ。
キャッシュをドライバで云々するのは偽486だよ。

286の10MHzはメモリアクセスノーウェイトだよ。
286でも486でも、メインメモリは同じ80nsのDRAMだよ。

327 ：デフォルトの名無しさん：2005/09/17(土) 20:33:02

そろそろ64bitの話もしよーや。

328 ：デフォルトの名無しさん：2005/09/17(土) 20:33:11

186→286の高速化はクロック上昇
286→386の高速化はパイプライン採用
386→486の高速化はマイクロコードのハードワイヤード化

だったような希ガス。いい加減な記憶で書いてるから
はずれてるかもしれん。

329 ：デフォルトの名無しさん：2005/09/17(土) 20:38:18

16bitCPUスレ立ててそこでやれ！

330 ：デフォルトの名無しさん：2005/09/17(土) 20:43:38

やれやれだぜ

331 ：デフォルトの名無しさん：2005/09/17(土) 21:21:24

>>329
関連あるからいいだろ。
多ビット化は高速化に寄与するかって命題なんだよ。

>>326
＞キャッシュをドライバで云々するのは偽486だよ。

そうそう。偽４８６だよ。
いや、インテルだったとは思うけどO/Cだったような。
いや、４８６SXとは書いてあったけどIntelだったかな？？・・

>>325
２８６とか４８６のパソコンなんてもう持ってないし。

>>330
まったくだ。

332 ：デフォルトの名無しさん：2005/09/17(土) 21:30:24

いい加減すれ違いの懐古厨はｶｴﾚ

333 ：デフォルトの名無しさん：2005/09/17(土) 21:51:51

>>332
オマエも無駄な発言してないで６４ビットについて語れ

334 ：デフォルトの名無しさん：2005/09/17(土) 21:53:21

おいおい相手してもらえちゃってるから、喜んでるじゃねぇか。
全角厨はそっとしといてやれ。かわいそうな人なんだから。

335 ：デフォルトの名無しさん：2005/09/17(土) 21:59:37

どうせ昔話をするならWindows 2000 for Alphaの話でもしようぜ。

336 ：デフォルトの名無しさん：2005/09/17(土) 22:11:44

>>335
ああ、いいな。
いい感じだ。
WindowsNTなのにAlphaサーバーでツールが動かないんだよ。
パソコンで作ったソフトも動かないんだ。
エンディアン違うからそのままコンパイルじゃうまくいかないんだ。
でもあれが激早だったんだよな。

337 ：デフォルトの名無しさん：2005/09/17(土) 23:41:00

>>336
そんなあなたにFX!32

338 ：デフォルトの名無しさん：2005/09/17(土) 23:53:42

スゲー流れw
適当にしか見てないけど >>278 と >>294 は一瞬でバカ丸出し確定。

339 ：デフォルトの名無しさん：2005/09/18(日) 00:03:13

いっその事Windows2000RC2の話しようぜ！
うちじゃ現役で動いてるよ！

340 ：デフォルトの名無しさん：2005/09/18(日) 00:25:31

>>339
通報しますた。

341 ：デフォルトの名無しさん：2005/09/18(日) 00:38:18

>>336

> エンディアン違うからそのままコンパイルじゃうまくいかないんだ。

alphaはlittle endianだから、x86と同じだよ。
っていうか、Windows NTが移植されたプラットフォームは全て
little endian。

342 ：デフォルトの名無しさん：2005/09/18(日) 00:43:11

で、結局64ビットになっても処理速度の点での恩恵は64ビットの演算を行わない限りあまり恩恵はないということでいいの

343 ：デフォルトの名無しさん：2005/09/18(日) 00:45:22

>>342
（´・ω・）ｶﾜｲｿｽ

344 ：デフォルトの名無しさん：2005/09/18(日) 00:46:49

>>342
それと64bitの（リニア）アドレス空間が要るかどうか。

345 ：デフォルトの名無しさん：2005/09/18(日) 01:00:36

64ビットのアドレス空間があればさ、全部のファイルをメモリマップしてもいいね。

悲惨なことになりそうだが。

346 ：デフォルトの名無しさん：2005/09/18(日) 01:11:59

ファイルシステムキャッシュの事じゃなくて？

347 ：デフォルトの名無しさん：2005/09/18(日) 03:26:05

残念ながら64ビットのアドレス空間丸々使えるわけじゃないから
全部マッピングは無理っぽい

348 ：デフォルトの名無しさん：2005/09/18(日) 06:04:40

2G程度の搭載メモリでは64ビットにしてもほとんど意味ない

349 ：デフォルトの名無しさん：2005/09/18(日) 07:08:43

またその話かよ

350 ：デフォルトの名無しさん：2005/09/18(日) 07:43:25

ロートルは黙ってろって言ったのに。

351 ：デフォルトの名無しさん：2005/09/18(日) 07:49:23

64ビットのアドレス空間、今のところ一番ニーズがあるのはデータベース分野か。
他に単一java VMでいくつもサブシステムが動くとか、.
NETでAppDomainを大量に使うとかいった分野の需要はありそう。

352 ：デフォルトの名無しさん：2005/09/18(日) 08:16:17

>>350
くそ野郎が発言するなボケ
てめーは親父狩りでもやってろ

353 ：デフォルトの名無しさん：2005/09/18(日) 08:20:59

>>352
ファビョッた(^ω^)なにこいつ・・・・

354 ：デフォルトの名無しさん：2005/09/18(日) 08:29:58

>>353
ロートルがなにか言ってるよ

355 ：デフォルトの名無しさん：2005/09/18(日) 08:30:32

>>353
いちいち反応したがるのはなんで？

356 ：デフォルトの名無しさん：2005/09/18(日) 08:31:25

>>353
しかもブサイクな鼻つけやがって
貴様はブタか

357 ：デフォルトの名無しさん：2005/09/18(日) 08:32:10

ロートルは黙れ。

358 ：デフォルトの名無しさん：2005/09/18(日) 08:32:32

>>357
そーだそーだかせいそーだ

359 ：デフォルトの名無しさん：2005/09/18(日) 08:50:13

>>347
物理メモリへのアクセスが正味64bit分出ていないって話だろ?
マッピングには影響ない。

360 ：デフォルトの名無しさん：2005/09/18(日) 13:19:54

変な馴れ合い喧嘩やめれ

361 ：デフォルトの名無しさん：2005/09/18(日) 13:53:12

実際４GB以上のメモリをつみたくなる様な状況ってどんな？

362 ：デフォルトの名無しさん：2005/09/18(日) 13:59:42

DB丸ごとオンメモリ

363 ：デフォルトの名無しさん：2005/09/18(日) 14:19:36

>>362
４Gで十分なDBもどうかと。
更新も不安だし。

364 ：デフォルトの名無しさん：2005/09/18(日) 14:25:48

意味不明

365 ：デフォルトの名無しさん：2005/09/18(日) 18:29:55

>>361
数値計算などで倍精度実数の３次元配列を確保しようとする場合
4GBのメモリで確保できる配列の数は
100*100*100 で 536個
200*200*200 で 67個
500*500*500 で 4個
800*800*800 で 1個
四倍精度や複素数にすると更に半分になる。

366 ：デフォルトの名無しさん：2005/09/18(日) 18:44:49

>>365
あーなんか少なく感じますねｗ

367 ：デフォルトの名無しさん：2005/09/18(日) 20:50:16

OSのGUIが3D化して、３次元テクスチャ使いまくりになれば意味も出てくるな。
実搭載メモリが何十GBとかにならんと駄目だろうが。

368 ：デフォルトの名無しさん：2005/09/18(日) 22:47:38

昨今のコンピュータはメモリアクセスより
計算の方が圧倒的に速いんだし
ベタな3Dテクスチャを使うなんて今後とも無さそうだが。

369 ：デフォルトの名無しさん：2005/09/18(日) 23:40:29

>>359
物理アドレスが64ビットよりもずっと少ないだけでなく、
論理アドレスも64ビットよりも少ないというのを、
どこかで見かけたんだけどなぁ。

仮に64ビットフルに使えたとして、
今みたいに1ページ4KBのままでは、2^52ページにもなって、
1ページに1ビットのフラグ持たせたら、フラグだけで512TBですよ。

370 ：デフォルトの名無しさん：2005/09/19(月) 00:19:16

>>369
2Mbyteのどでかページも使えるので心配するな。ｗ
あと論理アドレスを制限するのは基本的にはOSだと思う。

371 ：デフォルトの名無しさん：2005/09/19(月) 02:03:00

３次元テクスチャの話だけど、
電子地図帳Ｚの３Ｄのリアルモードみたいのを
建物の細かい構造、看板、電柱などたくさんのオブジェクト配置して
超リアルな街並みが再現できるかも。

ＢｏｏｍＴｏｗｎみたいなのって、こんなにメモリ食う構造だったんだな。

372 ：デフォルトの名無しさん：2005/09/19(月) 02:50:26

メモリーが増えても出入り口の幅はほとんど変わらないから
有り難味が少ないなぁ．．．

373 ：デフォルトの名無しさん：2005/09/19(月) 03:07:55

早くメモリ安くなんないかね

374 ：デフォルトの名無しさん：2005/09/19(月) 03:15:35

フラッシュメモリなんて16Gbitチップ登場だよね。
DRAMもそのくらいに集積度上がって欲しいなぁ。

375 ：デフォルトの名無しさん：2005/09/19(月) 03:24:26

真面目な話、x86の64bit化のメリットは、以下の３点だよ。
・１プロセスが32bitを超えるアドレス空間を扱える
・全プロセス合計で4Gを超える物理メモリを扱える
・レジスタ増加

理屈ではわかっていても、意外に(普通の)開発者から軽視されるのが真ん中の項目。
ちょっと考えると、サーバー用途以外ではあまり意味がなさそうにも思えるかもしれないけど
デスクトップで複数のタスクを動作させる、という事を抜きにしても
(これ自体も、マルチコア等でもっと一般的に行われるようになるかもしれないけど)
例えばRAMディスクにたっぷりと割り当てても他のプロセスへの影響が無くなるわけだし
単純にディスクキャッシュで扱えるメモリが増える、という意味でも
効果が期待できる場合もあるよ。

376 ：デフォルトの名無しさん：2005/09/19(月) 03:32:59

真ん中はPAE使えやボケ

377 ：デフォルトの名無しさん：2005/09/19(月) 03:39:10

PAEを有効利用できるデスクトップ版Windowsがあれば、ね。

378 ：デフォルトの名無しさん：2005/09/19(月) 03:57:02

サーバでも 1 と 3 のが重要度高いな

379 ：デフォルトの名無しさん：2005/09/19(月) 04:58:01

まあ、個人向けのパソコンではマザーボードの仕様上2Gから4G程度しか詰めないから、アプリも出てこないと言うことなのか。
それとも、データベースや科学計算のような特殊な分野以外に64ビットマシンは必要とされていないということなのか？

380 ：デフォルトの名無しさん：2005/09/19(月) 05:08:14

>>375
４GB以上のディスクキャッシュはありがたいかもしれない。
電気は無駄に使うことになるし、リフレッシュのためにメモリが遅くなりそうだけど、
読み込みが減らせるからディスクアクセスが更新とか書き込みを
効率よくできるかもしれない。
断片化の発生を抑えた書き込みもできるかもしれない。

でもUPSが必須だな。

381 ：デフォルトの名無しさん：2005/09/19(月) 05:16:53

あ、でも、DBとかはセキュリティの関係で読み込みのみってこたないな。
ノーツのDBも、開いただけでログ残ってたし。
「やべー。覗き見したらばればれやん」て思った。
覗き見するときはちゃんとその人のPCでその人のID使ってやらないとな。

382 ：デフォルトの名無しさん：2005/09/19(月) 05:18:22

>>370
1ページ2MBでも1TBになるので、泣けてくる。ビットマップはやばい。

本当はAMDの資料を見ないといけないのだけど、
とりあえず
http://hp.vector.co.jp/authors/VA003988/asm2.htm
を見ると、1プロセスで使えるのは48ビット分の空間のようです。

>>372
メモリアクセスのコストが無視できなくなってきてるよね。

PC3200のメモリがデュアルチャネルであっても、
64GBのメモリを舐めるのに10秒以上かかると思う。

メモリのどこにあるかわかっていても、
キャッシュにヒットしなければ、とても長い長い時間がかかる。

もしQWORD単位で64GB分をランダムに読むと、15分くらいかかると思う。

383 ：デフォルトの名無しさん：2005/09/19(月) 05:42:03

>>378
32ビットの1プロセス2GB以内という制限は、けっこうキツいよね。

たとえば、1000クライアントを捌くサーバプロセスは、1クライアントあたり2MBしかメモリを使えない。
プロセスを分割したところで、プロセス間でメモリ共有を使って情報を交換するので、結局は同じことになる。

だから、とっとと64ビットになってほしいが、既存のDLLが32ビット・・・orz

>>379
AlphaやItanium2が、PCサーバ分野で鳴かず飛ばずだったのが、物語ってると思う。
32ビットではできないことをやろうとしたら、x86とバイナリ互換がないことは、
大した問題ではないと思う。不可能なのと、やればできるの違いは大きいから。
それなのに・・・ということは、32ビットではできないことをやる必要があんまりなかったんだね。

384 ：デフォルトの名無しさん：2005/09/19(月) 05:42:17

>>379
メモリが積めないからアプリが出ないというより
一般向けに64bit環境が普及していないから需要が少ないという事でしょう。

ワープロと表計算くらいの用途なら64bitマシンどころか
16bit CPUと数MBのRAMしかないPCの時代でも出来たんだし
やってることの本質はたいして変わってない。

でも64bit CPUと64bit対応のOSを積んだマシンが普通に出回り始めれば
アプリの方もそれに合わせてくるだろうし
いずれはみんな、64bitな環境に移行するんだろうけど。

385 ：デフォルトの名無しさん：2005/09/19(月) 05:56:24

>>384
６４モードで今までのソフトは動くの？

リブートが必要ならデスクトップで使われることはないよね
ＯＳも二ついるだろうし。

386 ：デフォルトの名無しさん：2005/09/19(月) 06:08:11

64ビット空間というのは広大な空間だな。
32ビット空間は4GBで、PAEを使っても36GBなので、意外に早く
限界が来たけど。

387 ：デフォルトの名無しさん：2005/09/19(月) 06:11:44

>>385
その昔 Windows はリアルモードとプロテクトモードの切り替えを
I/O 経由で CPU にリセット信号を送ることによって実現してた。
ありえないと思うが、必要とあればそれも選択肢かと。`

388 ：デフォルトの名無しさん：2005/09/19(月) 06:15:54

>>386
そんなに使うのにワークステーション利用しないの？

389 ：デフォルトの名無しさん：2005/09/19(月) 06:19:35

>>385
WinXP x64 Editionの場合は16bitコードを含むものや一部の特殊なソフトを除けば
32bitアプリもそのまま動く。

390 ：デフォルトの名無しさん：2005/09/19(月) 06:37:39

>>387
それは286の話だね。386は自由にリアルモードとプロテクトモードの間を
行き来できるようになったので、関係ない。

391 ：デフォルトの名無しさん：2005/09/19(月) 07:00:10

>>389
いいですねえ。

http://pc.watch.impress.co.jp/docs/2004/0213/hot302.htm
＞Pentium Proの時代に導入されたPAE(Physical Address Extension)、
＞Pentium IIIで導入されたPSE-36(Page Size Extension)などだ。
＞これらの機能を利用するとメモリアクセスにオーバーヘッドが生じる
でもやっぱりオーバーヘッドはあるんでしょうね。

AMD64って実装はフル64じゃなかったよなーって思ったんですが、資料ないですか？

http://www.debian.org/ports/amd64/index.ja.html
＞プロセス当たり最大 512GiB の仮想アドレス空間 (従来は 2GiB)
これが関係あるのかな？

演算は６４でI/O幅が３２＋７ってことかな？

IA-32e: AMD64クローン技術
http://www.septor.net/archives/77181736.html

392 ：デフォルトの名無しさん：2005/09/19(月) 08:32:22

>>385
64bit モードで 32bit プログラムを動かす手続きも x86-64 の仕様に含まれてた気がする
thunk layer だっけ?
当然、ライブラリやらドライバーやらはデータモデルを合わせてあげなきゃダメだけど。

393 ：デフォルトの名無しさん：2005/09/19(月) 08:43:43

とっくに64bit化してるSPARCだって64bit Solarisの元で32bit用バイナリを実行
できるんで、それより後にやっとこさ64bit化したx86-64でできなきゃ嘘でしょう。

394 ：デフォルトの名無しさん：2005/09/19(月) 08:44:01

>>391
リンク先記事だけど、PAE は Solaris や Linux, FreeBSD でも使えるのに、
と思ったら元麻布か。

395 ：デフォルトの名無しさん：2005/09/19(月) 09:51:44

>>385
その話は、あまりにレベルが低すぎないか?
プログラマの発言とは思えない。

396 ：デフォルトの名無しさん：2005/09/19(月) 10:28:25

>>395
そうかい？
使ってみないと分からないと思うけど。

397 ：デフォルトの名無しさん：2005/09/19(月) 10:46:24

>>395
確か１６→３２のときは１６ビットアプリでも
コンパイラも３２対応製品に付属のでコンパイルしないとバグが出たと思う。
MSに問い合わせてもそういわれたし。
ということはベンダー提供のアップデートが必要になるってことだと思う。

398 ：デフォルトの名無しさん：2005/09/19(月) 10:51:32

>>397
push sp した時のpushされる値の違いとかか？

399 ：デフォルトの名無しさん：2005/09/19(月) 11:30:17

>>398
違うような

スタック破壊の実行時検出に関する研究動向
http://64.233.179.104/search?q=cache:efIaZVO9K8AJ:www.mtl.t.u-tokyo.ac.jp/~toyoshim/pub/smashed-stack-detection.pdf+windows+16+32+%22push+sp%22+&hl=ja

400 ：デフォルトの名無しさん：2005/09/19(月) 12:35:59

>>399
0DIVエラートラップ時に積む値まで違っていたのか。初めて知った。
俺がx86使い始めたのは386が一番最初だったから知らなかった。

401 ：デフォルトの名無しさん：2005/09/19(月) 12:37:26

まあでも俺の言い訳は言い訳にならないよな。Intel発行のデベロッパー
マニュアルを見れば、ちゃんと互換性の注意点とか書いてあるからな。

402 ：デフォルトの名無しさん：2005/09/19(月) 21:38:40

>>396-397
ちょっとWindows板とか自作PC板とかの64ビットスレを見てきなよ。

403 ：デフォルトの名無しさん：2005/09/19(月) 22:34:03

え～っと、、、
Windowsの最大の利点の１つは過去の資産との互換性でありまして
昔のプログラムを動かすのに一々リコンパイルが必要ならここまでの
シェアはっていうかぐぐればすぐに・・・

404 ：デフォルトの名無しさん：2005/09/20(火) 00:00:41

push spとか0divの動作が変わったのは286が出た時だろ

405 ：デフォルトの名無しさん：2005/09/20(火) 02:02:36

PAEって16ビット時代で言うところのFARみたいなものかと
思ってたけど違うの?

406 ：デフォルトの名無しさん：2005/09/20(火) 02:08:31

http://www.microsoft.com/japan/whdc/system/platform/server/pae/default.mspx

ほれ

407 ：デフォルトの名無しさん：2005/09/20(火) 02:08:37

>>405
違う

408 ：デフォルトの名無しさん：2005/09/21(水) 01:48:32

おまいらついにVMwareが64bitゲストをサポートしましたよ

ttp://slashdot.jp/article.pl?sid=05/09/19/2220211&topic=104&mode=thread&threshold=-1

409 ：mokorikomo KHP222009212068.ppp-bb.dion.ne.jp：2005/09/23(金) 18:12:10

webprog

410 ：デフォルトの名無しさん：2005/09/25(日) 14:05:33

64bitプログラミングしてみたいんですが、
VC++　2005　express edition beta 2 で出来ますか？

411 ：デフォルトの名無しさん：2005/09/25(日) 17:36:52

Expressは64bitコードを生成できない

412 ：デフォルトの名無しさん：2005/09/25(日) 18:32:51

マジで？どのコンパイラなら64bitコード吐いてくれますか？

413 ：デフォルトの名無しさん：2005/09/25(日) 18:51:57

gcc

414 ：デフォルトの名無しさん：2005/09/25(日) 19:05:15

PathScale

415 ：デフォルトの名無しさん：2005/09/25(日) 19:33:48

>>412
Plartform SDKにコンパイラが入ってる

416 ：デフォルトの名無しさん：2005/09/25(日) 22:44:21

gccかぁ。Cygwinでやる場合Cygwinも64bit版じゃなきゃだめでしょうか。

417 ：デフォルトの名無しさん：2005/09/25(日) 22:57:26

>>416
Cygwin64/mingw64はまだじゃないかな。gccは当面はLinux等だね。

418 ：デフォルトの名無しさん：2005/10/01(土) 10:52:05

>>341
亀レスですまんが、たまにはPPC版NTのことも思い出してあげてください

419 ：デフォルトの名無しさん：2005/10/01(土) 10:53:50

PPCゎbi-endianじゃないっけ？

420 ：デフォルトの名無しさん：2005/10/01(土) 11:27:37

>>418-419
PPCはリトルエンディアンとビッグエンディアンを初期化時に選択できて
Windows NTが使っているのはリトルエンディアンモード

421 ：デフォルトの名無しさん：2005/10/01(土) 11:53:32

>>418
PowerPCにはWindows CEがあるじゃないか。

まだサポートされてたよな？

422 ：デフォルトの名無しさん：2005/10/02(日) 12:32:21

>>418
でもって、WinCE でもやっぱり little endian しかサポートされてないん
じゃなかったっけ。違った?

423 ：デフォルトの名無しさん：2005/10/02(日) 13:19:43

あぁendianの差が移植の最大の障害になってたのかWindowsは。
てことはx86系のUnixとかLinuxはendianの関係で余計なオーバーヘッド
背負ってるのかな。使ったことないからわからないけど。

424 ：デフォルトの名無しさん：2005/10/02(日) 13:26:23

>>423
そんなことはない。Microsoftの技術が稚拙なだけ。

425 ：デフォルトの名無しさん：2005/10/02(日) 13:43:25

そうだよなぁ。LHAなんてbig endianのだけど
別にパフォーマンスで特に問題なんてないよなぁ。

まあWindowsはクライアント以外には用のないOSだから
需要の点で移植が進まなかったんだろうけど。
需要があるんなら金の力でなんとかしただろうし。

426 ：デフォルトの名無しさん：2005/10/02(日) 13:48:04

あぁｺﾞﾒｿ勘違いだ。LHAはlittle endianだ。

427 ：デフォルトの名無しさん：2005/10/02(日) 13:50:20

TCP/IPのヘッダなんかはbigだよね。
効率悪いからlittleに変えようなんて話、出てこないよな。ｗ

428 ：デフォルトの名無しさん：2005/10/02(日) 13:58:35

ヘッダとかアクセス頻度が低いものならほとんど何の影響もないよね。

えらい昔68000でZ80のエミュレータを書いた時はエンディアンの違いがウザくて
閉口したもんだったけど。
アレがなけりゃ三割ぐらい性能アップしてたかも。

429 ：デフォルトの名無しさん：2005/10/02(日) 14:10:32

そこでBSWAP命令ですよ。

430 ：デフォルトの名無しさん：2005/10/02(日) 14:50:38

>>423
Linuxはもともと386用のカーネルだったわけですが。
つか、まともなコードなら両方対応できるようにマクロ切ってあるはず。

それはそうとPPCのVPERMユニットってあまりにリッチなんだが
あれはエンディアンの変換用にあるんじゃないかって思った。

431 ：デフォルトの名無しさん：2005/10/02(日) 15:21:00

やっぱりインラインアセンブラがないとダメですね

432 ：デフォルトの名無しさん：2005/10/02(日) 15:33:15

単純にMMX/SSE使うだけなら昔ならともかく今は組み込み関数が使えるから必要ないといえば必要ない。

433 ：デフォルトの名無しさん：2005/10/02(日) 15:48:31

PC用のソフトではがんばってインラインアセンブラで最適化しても
CPUが変わるとかえって遅くなったりしちゃうし。

434 ：デフォルトの名無しさん：2005/10/02(日) 18:24:32

インラインアセンブラで書くよりも、
組み込み関数を使って書いたほうが、

・書くのが楽。書いたものを変更するのも楽。
・コンパイラの最適化は、そんなに悪くない

性能的には
SIMD使わない << インラインアセンブラで下手に書く < 組み込み関数でSIMDを使う < インラインアセンブラで上手に書く
だと思う。

自分の技量と使える時間に相談して、選べばいいと思うよ。

今のコンパイラはサポートしてなかったりするけど、
CPU別の最適化や、CPUのアーキテクチャが変ってMMXがなくなっても、SSE2を使うコードに変えてくれる
とかの将来性がある。

435 ：デフォルトの名無しさん：2005/10/02(日) 18:40:25

MMX→SSE2はほとんど負担ねーと思うぞ。一度に2倍のデータを使うように改造するだけで殆ど事足りる。

436 ：デフォルトの名無しさん：2005/10/03(月) 21:13:36

>>434
インラインアセンブラで下手に書く　＜　SIMD使わない

437 ：デフォルトの名無しさん：2005/10/04(火) 04:04:41

まあ、SIMD使えば同時に扱うデータ量が倍になるし、下手なスケジューリングしても
アウトオブオーダ実行もあるから、SIMD不使用のコードより多少は速いってことはあるんじゃねーの？
整数の場合はAMD64で汎用ALU使ったほうが速そうだけど。

どのみちインラインアセンブラは使えなくなるんだし、*mmintrinで書いておけば、
各CPU向けに特化したスケジューリングはコンパイラがやってくれるから手間が省けるし、
来るマルチコア・メニィコアにうまくタスクを割り当てることに時間を割くほうが有意義だと俺は思ふ。

438 ：デフォルトの名無しさん：2005/10/08(土) 13:22:31

> どのみちインラインアセンブラは使えなくなるんだし

Intel コンパイラや mingw の EM64T/AMD64 版がでたら、まず間違いなく
インラインサポートするでしょ? 使えなくなるっていうのは言い過ぎだと
思う。
.NET を普及させたいからネイティブコンパイラの方で手を抜いてたなんて
いった政治的理由だったりすると嫌だな。

439 ：デフォルトの名無しさん：2005/10/08(土) 14:04:15

＞インラインアセンブラは使えなくなるんだし

マイケルソフトの糞コンパイラだけの話だろ。

440 ：デフォルトの名無しさん：2005/10/08(土) 14:37:38

ICCのEM64T対応版はもう出てたと思うがなｗｗ

441 ：デフォルトの名無しさん：2005/10/08(土) 16:40:25

まあ最近インラインアセンブラなんて使ってない俺にとってはどうでもいい話だがな。

442 ：デフォルトの名無しさん：2005/10/08(土) 17:28:32

>>438
gcc-x86_64-linux-elf ならすでに asm ふつうに使えてる

443 ：デフォルトの名無しさん：2005/10/08(土) 22:52:00

EM64T版ICCもインラインアセンブラは使えないよ。

444 ：デフォルトの名無しさん：2005/10/09(日) 00:14:31

UNIX版iccの方はgcc互換にするって建前があるので、
使えるようにするんじゃねえ?

445 ：デフォルトの名無しさん：2005/10/09(日) 00:35:00

>>443
インラインASM禁止はIntelが言い出したことじゃねーのかと思っている。

>>444
AMD独自拡張のニーモニックが含まれてるとエラー吐くのもIntelクォリティ

446 ：デフォルトの名無しさん：2005/10/09(日) 01:00:49

まあそりゃインテルのコンパイラだし

447 ：デフォルトの名無しさん：2005/10/09(日) 02:46:27

AMD64のCPUは高速なかわりにアセンブラプログラムを直接実行できない
無理にアセンブラを使おうとすると「互換モード」で実行されるので実行速度が非情に遅くなる

もう時代遅れのアセンブラは必要ないのですよ

448 ：デフォルトの名無しさん：2005/10/09(日) 02:56:39

アセンブラプログラムってなんだそれｗｗ

449 ：デフォルトの名無しさん：2005/10/09(日) 03:15:42

いやー、AMD64に限らず、CPUが直接実行できるのは機械語だけだし。

・・・・ということを言っているわけではなさそうだな。

450 ：デフォルトの名無しさん：2005/10/09(日) 08:47:09

「互換モード」でアセンブラプログラムを実行できるAMD64最強w

451 ：デフォルトの名無しさん：2005/10/09(日) 12:49:34

>>447
うわー電波

452 ：デフォルトの名無しさん：2005/10/09(日) 12:53:20

>>447
>>アセンブラプログラム
きっとアセンブラ自体のことだなｗｗ
きっとアセンブルする時に動作劇重になるんだろうと、
ウルトラ良心的解釈でもしてみる。

んなわけねーだろ。電波。

453 ：デフォルトの名無しさん：2005/10/09(日) 20:13:37

アセンブラで書いたコードをアセンブラでアセンブルして
アセンブればアセンブるときアセンブろう

454 ：デフォルトの名無しさん：2005/10/16(日) 00:21:24

>>453
そんなにアセンブらないこと。

455 ：デフォルトの名無しさん：2005/10/16(日) 18:17:30

　　　　　　∧＿∧ 　トンファーキ～ック！
　　　　　_（　 ´Д｀）
　　　／　　　　　　）　　　　　ﾄﾞｺﾞｫｫｫ　＿　　／
∩ 　/　,ｲ　、　　ﾉ/　　　　∧ ∧―＝￣　｀ヽ,　＿
| |　/　/　|　　　（〈　∵. ・（　　〈＿_　>　　゛　、＿
| | ｜ |　ヽ　　ｰ＝-￣￣＝_、　　（／　,　´ノ　＼
| | ｜ |　　　｀iー＿＿＝―＿　;,　／　／／←>>454
| |ﾆ(!、)　　　=＿二＿＿￣_=;,　／　／　,'
∪　　　　　/　 /　　　　　　　／　／| 　|
　　　　　／　 /　　　　　　　!､＿／ / 　〉
　　　／＿/　　　　　　　　　　　　 |_／
　　　ヽ､＿ヽ

456 ：デフォルトの名無しさん：2005/10/21(金) 11:47:48

64bit期待age

457 ：デフォルトの名無しさん：2005/10/21(金) 14:20:38

つくったよ

458 ：デフォルトの名無しさん：2005/10/24(月) 17:15:18

なにを？

459 ：デフォルトの名無しさん：2005/10/25(火) 00:33:32

よくわからないけど、たぶん中村さんの発明じゃないの？

460 ：デフォルトの名無しさん：2005/10/31(月) 21:46:11

大賞の賞金100万円らしいが、何か考えてる香具師いるか？

Windows XP Professional x64 Editionソフトウェアコンテスト
ttp://win64xp.impress.co.jp/

461 ：デフォルトの名無しさん：2005/10/31(月) 22:41:55

メモリorメモリ空間をむっちゃ使う類以外ので何かあるかなあ・・・

462 ：デフォルトの名無しさん：2005/11/01(火) 01:38:12

諦めてる。

463 ：デフォルトの名無しさん：2005/11/01(火) 01:40:08

レジスタをむっちゃ使う用途とか。

464 ：デフォルトの名無しさん：2005/11/01(火) 01:50:48

PowerPCでいいだろそんなの。

465 ：デフォルトの名無しさん：2005/11/01(火) 11:48:09

32ビットのDLLを64ビットのEXEから使うための何か。
32ビットのドライバを64ビットのWindowsで使うための何か。

そういうものを作ったら、ものすごく喜ばれるのではないかと。

466 ：デフォルトの名無しさん：2005/11/01(火) 16:14:39

既にあるんだけど・・・

467 ：デフォルトの名無しさん：2005/11/02(水) 06:48:48

>>466
まじですか?

それは何ですか?

468 ：デフォルトの名無しさん：2005/11/02(水) 08:54:28

ただの感違いでしょ

469 ：デフォルトの名無しさん：2005/11/02(水) 13:51:46

out-of-process COM とかかな。

470 ：デフォルトの名無しさん：2005/11/02(水) 17:01:19

64bit版のIEで32bit版のplug-inというかActiveXコントロールが使えるとかでないと
意味がない。
out-of-processサーバーでできるとか言われても
新規にプログラムを書く必要があるなら最初から64bit版書けば済むわけで

471 ：デフォルトの名無しさん：2005/11/03(木) 11:17:06

なんだかんだ言いながら、32bitに依存しまくったプログラムばかりだったということだ。

472 ：デフォルトの名無しさん：2005/11/03(木) 12:58:21

ソースがなくて、既存バイナリをそのまま使わないといけない、という話だよ。

473 ：デフォルトの名無しさん：2005/11/03(木) 13:05:31

そーっす。

474 ：デフォルトの名無しさん：2005/11/03(木) 19:42:00

Windowsで遊びに使えて、4GB超のメモリを使えるLispインタプリタみたいなのを
作りたいんだが、intとポインタが64bitなコードを吐くコンパイラはもうありますか？

475 ：デフォルトの名無しさん：2005/11/03(木) 19:49:44

もうあります。

476 ：デフォルトの名無しさん：2005/11/03(木) 21:19:19

>>474
いざとなれば#define int boost::int64_tという手もあるｗ。

477 ：デフォルトの名無しさん：2005/11/03(木) 22:14:28

4GB超のメモリを贅沢に使い潰して、マルチプロセッサでＧＣと本来の処理を並行させたり
したいわけだが。intだけ64bitになってもなぁ・・・。情報thx.

478 ：デフォルトの名無しさん：2005/11/03(木) 22:21:05

>>477
Win64用のコンパイラなら、ポインタ64bitは当然。>>476はその上でintも64bitに
する方法を書いてくださっているのだ。

479 ：デフォルトの名無しさん：2005/11/03(木) 22:25:34

ありがとうございます。精進いたします。

480 ：デフォルトの名無しさん：2005/11/03(木) 23:04:18

4GB分のGCにかかる時間を想像してみたよ

481 ：デフォルトの名無しさん：2005/11/04(金) 13:57:03

GCって出番があるのかな。

確保したいメモリ容量分の、連続した空き領域が存在しない確率は、かなり低くなると思う。
4GBのメモリに対して、数百MBのメモリを連続して確保したりするなら、別だけど・・・。

482 ：デフォルトの名無しさん：2005/11/04(金) 13:59:44

マークするだけで５分とかかかりそう

483 ：デフォルトの名無しさん：2005/11/04(金) 15:12:22

GCが新しいボトルネックということですね

484 ：デフォルトの名無しさん：2005/11/04(金) 22:39:48

GBオーダー時代のGC手法
というのでペーパーかけそうだ

485 ：デフォルトの名無しさん：2005/11/05(土) 20:30:26

4GB超のメモリ空間で動作するOSを考えると、ＧＣからは決して逃げられないと思うのだが。
各アプリがメモリを食い散らかして、freeせずにexit、という事象に対する耐久性は、メモリ量
向上ゆえに上がるかもしれないが、いずれ、ごみ集めが必要になる事態は避けられまい。
まして、連続稼動するアプリケーションサーバならなおさらである。

486 ：デフォルトの名無しさん：2005/11/05(土) 20:39:10

>>485
ヘボイ根拠だね。

487 ：デフォルトの名無しさん：2005/11/05(土) 20:41:48

その「4GB超のメモリ空間で動作するOS」とやらは
メモリ管理もろくに出来ない代物なのか？

488 ：デフォルトの名無しさん：2005/11/05(土) 21:19:17

>>487
そうなんですよ。

489 ：デフォルトの名無しさん：2005/11/05(土) 21:29:21

>>485
大体のOSはメモリがどのプロセスに属しているかという情報を管理していて、
プロセスが終了するときにはそのプロセスに属するメモリを丸ごと解放するようになっている。

490 ：デフォルトの名無しさん：2005/11/06(日) 00:46:45

>>489
ブッブー。
メモリへの参照を外す、ですね。
もう少し勉強しましょう。

491 ：デフォルトの名無しさん：2005/11/06(日) 00:48:22

そうそう。他のプロセスに悪さしないように、プロセスって概念があるのだからね。
OSがそこんところうまくやってくれてるんだよ。普通は。普通でないことが
しばしば起こる場合もあるが。

492 ：デフォルトの名無しさん：2005/11/06(日) 00:50:07

>>490
だからそれはOSや処理系依存なんだって。もう少し勉強しましょう。
同じUNIX系でもAIXとLinuxは驚くほど仕組みが違う。

493 ：デフォルトの名無しさん：2005/11/06(日) 00:54:07

>>492
で、で、でた、後だしジャンケン。
一部の実装を持ち出して云々されても・・・

494 ：デフォルトの名無しさん：2005/11/06(日) 00:57:59

これだからJava厨は・・・

495 ：デフォルトの名無しさん：2005/11/06(日) 02:01:15

よーわからんが
とりあえずだ。
頭の悪い俺にわかるように教えて欲しい。

環境はWindowsXPとLinuxとする。
アプリでmalloc()した領域をアプリ終了時にfree()しなかったら、まずいのか？

496 ：デフォルトの名無しさん：2005/11/06(日) 02:11:50

全然まずくない。

サーバープログラムでメモリのフラグメントが気になるケースはあるが
よほど無駄な使われ方(4K内に1byteだけ頻繁にアクセスする等)でない限り
ページングによりある程度カバーできる。

というより、64bitだと「アドレス空間が足りない」という事態がまず起こらないので
ほぼページングによる「あまり使われていない領域のスワップアウト」で事足りる。

497 ：デフォルトの名無しさん：2005/11/06(日) 04:31:27

AMD廚ウザイな。氏ねよ。
実際のプログラミング話が出て来ない所を見るとOpteron持ってないのか？

64bitプログラミングできるOSと言語ってどれが最強？
malloc(4GB)できるのある？

498 ：デフォルトの名無しさん：2005/11/06(日) 08:12:12

>>497
Win64ならできるみたい。

#define _HEAP_MAXREQ 0xFFFFFFFFFFFFFFE0

499 ：デフォルトの名無しさん：2005/11/06(日) 11:19:55

64bitプログラミングできる環境の例

Xeon
ttp://www.hpc.co.jp/B-Xeon/XeonPaxvilleDP.html
Itanium2
ttp://www.hpc.co.jp/B-IA642/IA642-T4.html
Opteron
ttp://www.jcsn.co.jp/products/spec/vin_opt_3u_wua.html

どれが「最強」かは各自の用途と財布の中身で変わってくる。

500 ：デフォルトの名無しさん：2005/11/06(日) 13:51:13

このスレは重複しているので削除依頼だしておきます。

501 ：デフォルトの名無しさん：2005/11/06(日) 14:15:31

> malloc(4GB)できるのある？

64 bit OSでそれができなかったら意味ないだろ。

502 ：デフォルトの名無しさん：2005/11/06(日) 14:31:57

>>497の前半の無意味な煽りと後半の救いようのない教えてクンぶりから
推定(精神)年齢は12～14歳。

503 ：デフォルトの名無しさん：2005/11/06(日) 15:42:27

>>485
それはプロセス内でGCするのではなく、
OSがプロセスに貸し出した物理ページをGCするということ?
物理ページが連続していなくてもいいと思うのだけど。

unix系の人の書いたコードは酷いのが時々あるね。
mallocしたのをfreeしないとか、
複数のスレッドから呼ばれることを考えてないライブラリとか。

マルチスレッドにせずに、シングルスレッドのプロセスをポコポコとforkしまくって、
1つずつのプロセスが短時間で終了することで、
リソースの管理をOSがやっているのだからアプリはやるのは二重管理で無駄
というスタイルは、ちょっとねぇ。

504 ：デフォルトの名無しさん：2005/11/06(日) 15:55:04

パタヘネ？ヘネパタ？どっちだか忘れたけど簡単な方に、
ページングの仕組みとその利用方法が載ってるから、厨房は一度読むべきだな。

505 ：デフォルトの名無しさん：2005/11/06(日) 16:09:46

>>503
> マルチスレッドにせずに、シングルスレッドのプロセスをポコポコとforkしまくって

そのせいで、Apache2はめっちゃ苦労してたな

506 ：デフォルトの名無しさん：2005/11/06(日) 17:37:09

>>503
> unix系の人の書いたコードは酷いのが時々あるね。

よく理解もせずに、適当なこといいなさんな。

507 ：デフォルトの名無しさん：2005/11/06(日) 17:40:57

ページング使っているのに何でGCが必要なんだよ。
アホじゃん。

508 ：デフォルトの名無しさん：2005/11/06(日) 18:15:26

ページングとGCは別物で同居可能だと思うが？

509 ：デフォルトの名無しさん：2005/11/06(日) 18:20:40

階層の違う話をいっしょくたに混同してないか？
どの技術も（場合によっては）必要だと思うが。

510 ：デフォルトの名無しさん：2005/11/06(日) 19:20:50

共有メモリって参照カウント方式でGCされるやん。

511 ：デフォルトの名無しさん：2005/11/06(日) 19:24:34

>>510
ここは理解不足を誇らしげに発表するスレですか？

512 ：デフォルトの名無しさん：2005/11/06(日) 19:26:10

>>511
残念だがお前の理解が不足しているんだな

513 ：デフォルトの名無しさん：2005/11/06(日) 19:35:16

OSメモリ管理ではページングがあるから、ガベージコレクションは
必要ないでしょ。
ユーザプログラム上での話ならGCの必要不必要はプログラマ次第。

514 ：デフォルトの名無しさん：2005/11/06(日) 19:39:49

GCってプロセスが死ぬまでの話ね。了解？

515 ：デフォルトの名無しさん：2005/11/06(日) 19:57:37

>477が話の始まり。
>485でOSのメモリ管理の話が出てきた。

で、今に至る。

516 ：デフォルトの名無しさん：2005/11/06(日) 20:10:06

Java厨とは、分かってないのに分かったつもりになって
ぐだぐだと知ってる単語を並べるものだから。

517 ：デフォルトの名無しさん：2005/11/06(日) 20:28:11

>>512
精一杯の皮肉乙
恥の上塗りですね

518 ：デフォルトの名無しさん：2005/11/06(日) 20:32:31

そこで初めて読む486ですよｗ

519 ：デフォルトの名無しさん：2005/11/06(日) 22:20:47

>>506
freeせずにexitは、unix文化ですよ。

520 ：デフォルトの名無しさん：2005/11/06(日) 22:25:54

GCするのなんて、
8ビットのパソコンのBASIC
組み込みを考えていたJava
ヒープの速度がネックになるほどメモリ確保・解放をしまくるJava
くらいでしょ。

実際、Javaはすごかったよ。
プロファイラで見ると、信じられないくらいの回数、オブジェクトの生成・解放をやってる。
よくもまぁ、そんなにやっても、速度が出るなぁと感心したよ。

521 ：デフォルトの名無しさん：2005/11/06(日) 22:32:35

.NET CLR も仲間に入れてやれよ。

522 ：デフォルトの名無しさん：2005/11/06(日) 22:34:32

UNIX使ってる人はメモリ確保するまでは慎重にやって
その後はぞんざいに扱う人が多い気がする。

523 ：デフォルトの名無しさん：2005/11/06(日) 22:54:32

DOSや組み込みでプログラミングしてた人の方が
メモリは慎重に扱うかもしれない？
UNIXはカーネルハッカーとアプリケーションプログラマで
メモリに対する意識はかなり違いそう。

524 ：デフォルトの名無しさん：2005/11/07(月) 00:03:18

>>519
>freeせずにexitは、unix文化ですよ。

そうそう。で、どこが酷いのだろうね？
ユーザレベルでの、ママゴトみたいな解放処理を省いただけで。

525 ：デフォルトの名無しさん：2005/11/07(月) 00:16:05

まさか
GC：言語処理系のための不要なメモリ回収の仕組み
としか考えられないのかな？

526 ：デフォルトの名無しさん：2005/11/07(月) 00:32:08

さすがにそこまで頭悪いとは思わんが

527 ：デフォルトの名無しさん：2005/11/07(月) 00:36:42

はいはいわろすわろす

528 ：デフォルトの名無しさん：2005/11/07(月) 00:38:13

>>525
は？こいつ何言ってんの？
頭おかしいんじゃね？
バーカバーカ

529 ：デフォルトの名無しさん：2005/11/07(月) 01:23:31

もうちょっと気の利いた煽りを入れてくれよ。
そんなんじゃ見てる方が恥ずかしくなってくるわ。

530 ：デフォルトの名無しさん：2005/11/07(月) 10:19:08

はいはいわろすわろす

531 ：デフォルトの名無しさん：2005/11/07(月) 20:27:09

>>524
短時間で終了するプロセスをポコポコとforkするunix文化なら、問題にはならないかもしれない。

長時間動き続けるプロセスの場合、
もう使っていないメモリを掴んだままになるので、
リソースがもったいない。

532 ：デフォルトの名無しさん：2005/11/07(月) 20:30:51

たとえば、関数が100個あり、
それぞれの関数が内部ワーク用として、それぞれ1MBのメモリをローカルに使うとする。

関数100個を順番に呼び出していく場合、
ちゃんとfreeするようになっていれば、全体で1MBのメモリで済む。
freeしない場合、全体で100MBのメモリが必要になる。

メモリを1GB搭載したPCで、上記プログラムを20個走らせた場合、どうなるか考えてみてよ。

533 ：デフォルトの名無しさん：2005/11/07(月) 21:02:18

相変わらず話の噛み合わないスレだな

534 ：デフォルトの名無しさん：2005/11/07(月) 22:04:43

で、おまいら結局何GBまでメモリ積んで走らせたことあるんですか？
構成込みで情報ｷﾎﾞﾝﾇ

535 ：デフォルトの名無しさん：2005/11/07(月) 23:08:27

>>532
順番に呼び出していくのなら仮想記憶があれば大丈夫じゃないか？

536 ：デフォルトの名無しさん：2005/11/08(火) 00:28:57

>>535
いちいちスワップアウトしちゃうじゃんという話では？

537 ：デフォルトの名無しさん：2005/11/08(火) 03:24:28

malloc/free のナイーブな管理で安心しちゃ駄目だよ。

俺なら、長時間の稼働が求められるときは、
最初にガバっと確保したメモリを自前で管理する。

皆はどうしてるの？

538 ：デフォルトの名無しさん：2005/11/08(火) 03:50:02

こまめに確保

539 ：デフォルトの名無しさん：2005/11/08(火) 07:17:32

こまめに自前でHDDに入れたり、メモリに出したりしてる。
OSなんて信用しねぇ！

540 ：デフォルトの名無しさん：2005/11/08(火) 09:25:31

ときどき虫が湧くな

541 ：デフォルトの名無しさん：2005/11/08(火) 14:18:03

>>536
どうせされる時はされるだろ

542 ：デフォルトの名無しさん：2005/11/08(火) 20:40:50

>>541
いちいちされるように作ることはないのでは？

543 ：デフォルトの名無しさん：2005/11/08(火) 22:57:44

>>518
その前にはじめての8086。な，いいからオレの言うこと聞いとけ。

544 ：デフォルトの名無しさん：2005/11/08(火) 23:07:55

eaxとかの32ビットレジスタ載ってないじゃん

545 ：デフォルトの名無しさん：2005/11/08(火) 23:19:04

>>543
釣りか？
セグメント関連とか今では忘れたほうがいい話が多すぎるだろ。

546 ：デフォルトの名無しさん：2005/11/08(火) 23:30:19

>>545
オマエはプログラミング言語は得意みたいだが
自然言語はかなり不得意みたいだなw

547 ：デフォルトの名無しさん：2005/11/09(水) 09:09:49

>>546
ここはそんな人ばっかりです

548 ：デフォルトの名無しさん：2005/11/09(水) 09:50:06

はいはいわろすわろす

549 ：デフォルトの名無しさん：2005/11/10(木) 00:35:57

>>537
そういう人がいるのだけど、
やっていることがCランタイムライブラリのヒープ以下だったりする。

550 ：デフォルトの名無しさん：2005/11/10(木) 00:39:54

>>541
そこで>>532の例ですよ。

もし物理メモリが1GB余っている場合、
スワップされるのは、
ちゃんとfreeしていた場合1000個以上同時。
ちゃんとfreeしない場合10個以上同時。

されるときはされるが、
されるまでの処理能力が違う。

551 ：デフォルトの名無しさん：2005/11/10(木) 00:48:48

つまり、あなたはfreeを呼ぶ度にメモリをOSに返す、
つまりfreeの度にカーネルモードに移行するという非常にコストのかかる処理を行う、

そんな糞ライブラリを常用していると言うことですか？

552 ：デフォルトの名無しさん：2005/11/10(木) 00:56:57

ちなみに、普通のメモリ管理の実装では
freeを呼んでもOSにメモリブロックを返したりはしないよ。
少なくとも、毎回必ず返すなどというバカな実装はあり得ない。

で、OSから見たら、メモリは「プロセスに割り当てたか否か」でしか区別しないから
「ライブラリが管理している(free済み)」「アプリケーションが管理している(未free)」の違いはない。
アプリケーションが管理していても、使っていれば(アクセスがあれば)別だけど
そんな領域は、そもそもfree出来ないわけだし。

553 ：デフォルトの名無しさん：2005/11/10(木) 01:07:17

Windows の DLL って扱い違わなかったっけ

554 ：デフォルトの名無しさん：2005/11/10(木) 06:49:40

普通のプログラマが、>>532みたいな「バカみたいな無駄」を平気で残していると考えるのは、Java厨だけ。
もちろん、普通の「Javaプログラマ」も、>>532みたいなやり方が異常だということはよく分かっている。
分からないから、「Java厨」と呼ばれる。

555 ：デフォルトの名無しさん：2005/11/10(木) 12:53:03

Javaについては↓の記事が興味深い。（別に信者でも布教活動でもないぞ）
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml

556 ：デフォルトの名無しさん：2005/11/10(木) 20:09:05

>>551-552

void* p ;
for(int i=0; i<100; i++) {
p = malloc(1MB) ;
free(p) ;
}

と

void* p ;
for(int i=0; i<100; i++) {
p = malloc(1MB) ;
}

の違いの話をしているのですが。

557 ：デフォルトの名無しさん：2005/11/10(木) 20:39:28

Windowsの方が仮想メモリシステムをアプリケーション側から細かく制御できるんだっけ

558 ：ものは言いよう：2005/11/10(木) 21:01:29

Windowsの方が仮想メモリシステムをアプリケーション側から細かく制御しなくてはなりません

559 ：デフォルトの名無しさん：2005/11/10(木) 22:29:55

>>556
その、メモリリークのバグ入り糞プログラムと
64bitに何の関係があるのですか？

まさかとは思うけど、64bit==デュアルコアとか思ってないですよね？

560 ：デフォルトの名無しさん：2005/11/10(木) 22:33:46

もう一つ。

Javaにおいても、大きなバッファ等をローカル変数に割り当てたままで
別のメソッドを呼び出す事が、当然出来ますが
このバッファがGCにより回収されると思っていますか？

>>532の「freeせずに別の関数を呼びだす」とは、↑と同じことですが
GCがあれば、このような事が起きなくなるとでも思っていますか？

561 ：デフォルトの名無しさん：2005/11/10(木) 22:47:42

>>560
回収されるんじゃない？

562 ：デフォルトの名無しさん：2005/11/10(木) 22:51:38

>>561
メソッド呼び出しから戻った後、実行可能性のある部分がそのローカル変数を
参照していたら当然GCされない。（逆は必ずしも真ではないことに注意）

563 ：デフォルトの名無しさん：2005/11/10(木) 22:53:47

資源を大切にね！

564 ：デフォルトの名無しさん：2005/11/10(木) 22:57:29

>>562
そりゃぁ、それを回収したら GC じゃなくて・・・なんて言うの（ｗ？
556の下のほうのように参照が無くなれローカル変数だって回収されるでしょ。

565 ：デフォルトの名無しさん：2005/11/10(木) 23:02:50

>>564
それをGC様が判断できるかという問題になるな。
ローカル変数の入ってるスタックフレームが開放されるまではGCの対象に
ならないと考えるほうが（プログラマとしては）安全側の配慮だと思う。

566 ：デフォルトの名無しさん：2005/11/10(木) 23:04:34

もちろん >>556 の下の場合のようにローカル変数（この場合はp）を上書き
していれば、最新のもの以外は確実にGCの対象になる。

567 ：デフォルトの名無しさん：2005/11/10(木) 23:16:42

そ。
何のためにわざわざnullを代入するか、ってことだよ。

まあ、実際には、ローカル変数に対してnullを代入するケースは少ないけど
何らかの(ローカルを含む)変数が指している領域は
GCの対象にはならないわけ。
だから、Javaでも>>532は当然起こる。

>>556でfreeを入れると何が違うかといえば
ライブラリが別のところからのmalloc呼び出しに対して再利用可能にすること。
これはJavaにおいて、nullを代入してGC可能であることを明示するのとまったく同じ。

だから、>>532のケースを「GCがあれば」と論じるのは妥当ではない。

568 ：デフォルトの名無しさん：2005/11/10(木) 23:19:45

一応。
「null入れときゃいいじゃん」という理論には
「freeすればいいじゃん」という言葉が返りますので。

569 ：デフォルトの名無しさん：2005/11/10(木) 23:25:52

俺、GCのソースコード読んで理解したんだけど、すごいよ。
おまえらの無駄さが笑える程しっかりやってる。
それ以来、GCに頼れるところは頼りまくりまクリスティーヌ。

570 ：デフォルトの名無しさん：2005/11/10(木) 23:34:56

まあ一口にGCと言っても、
実装は山ほどあるわけで。

571 ：デフォルトの名無しさん：2005/11/10(木) 23:51:52

>>568
参照を消すことは比較的安全だけど、実体を消すことはそうではないことが多い。
同じだと思うのは極めてナンセンス。

572 ：デフォルトの名無しさん：2005/11/10(木) 23:53:52

>>571
参照を消す＝その先の実態も消える。

573 ：デフォルトの名無しさん：2005/11/10(木) 23:57:35

「参照にnullを代入して『GC対象であること』を明確にする」のと
「メモリブロックをfreeして再利用可能にする」のは別ですか。
そうですか。

574 ：デフォルトの名無しさん：2005/11/11(金) 00:00:42

>>573
他からも参照されてる可能性を考えれば、別に決まってるじゃん。

575 ：デフォルトの名無しさん：2005/11/11(金) 00:05:45

ローカル変数の話をしているのに
他からも参照ですかそうですか。

576 ：デフォルトの名無しさん：2005/11/11(金) 00:06:29

ローカル変数っていうか、ローカルで用いるバッファだな。>>532のような。

577 ：デフォルトの名無しさん：2005/11/11(金) 00:09:46

だから、何が争点になっているのかを明確にしてくれよ。

578 ：デフォルトの名無しさん：2005/11/11(金) 00:13:28

なんだ、論点もわからず揚げ足取りしてたのか

579 ：デフォルトの名無しさん：2005/11/11(金) 00:29:37

もはや64bitプログラミングと何ら関係ない論争になっている点について

ていうかそんなにGCの話がしたけりゃ、GCスレ立ててそっちでやってくれよ。

580 ：デフォルトの名無しさん：2005/11/11(金) 00:33:27

OSレベルのメモリ管理の話をしてるとき（だよね）に「Java厨」とか無意味な呪文を
唱えてGC原理主義者を召還するからじゃないのか？

581 ：デフォルトの名無しさん：2005/11/11(金) 00:34:23

>>485-577のまとめ

Java厨「マルチコアなら別プロセッサでGC走らせれば・・・」
Java厨「4GB超のメモリ空間で動作するOSを考えると、ＧＣからは決して逃げられない」
他「はあ？(あのー、64bitプログラミングとの関係は？)」
Java厨「OSもメモリの使い回しができるし、アプリケーションサーバー(←おいおい)にも」
他「あのね、ページングとか仮想記憶とか知ってる？足りなければスワップすればいいし」
Java厨「GCがあれば、スワップ減らせるでしょ」
他「はあ？」
Java厨「freeしないで1Mのバッファを100個使うプロセスだと・・・」
他「freeしないプロセスと比べてどうすんの。だいたい、GCがあるからといって、ローカルで使っているバッファの・・・」
(このあたりが>>532 >>560とかその辺)
他「ローカル変数に代入されているものは、GCされるとは限らないよ」
他「null代入とfreeは(メモリを再利用可能にすると意味で)同じ事だよ」

ここに>>571が登場。
Java厨２「(最後のレスだけを読んで)参照を消すのと実体を消すのは違うだろ」
Java厨２「他から参照されてる可能性を考えれば」
Java厨２「何が争点になっているのかを明確にしてくれよ」

582 ：デフォルトの名無しさん：2005/11/11(金) 00:37:14

>>580
ごめん。まとめてたらモロに。。。ほんとごめん。

というか>>485とか>>532とか、それ以外の言葉が浮かばないんだもん。
(「Java使い」は「Java厨」とは違うよ)

583 ：デフォルトの名無しさん：2005/11/11(金) 00:39:52

だからOS側の管理の話とプロセス内のヒープの管理の話をごっちゃにしてるんだろ？
GC云々ってのは（普通は）後者の話でしょ？

584 ：デフォルトの名無しさん：2005/11/11(金) 01:56:33

結論としては、Java最強、ということで。

585 ：デフォルトの名無しさん：2005/11/11(金) 02:09:25

おまえら.NET CLRは無視ですかそうですか。

586 ：デフォルトの名無しさん：2005/11/11(金) 02:11:15

別に無視じゃないが、パフォーマンスはネイティブの１／３でメモリ使用量は数倍ってイメージ。

587 ：デフォルトの名無しさん：2005/11/11(金) 02:22:23

64bitマンセーって逝ってる香具師とJavaマンセーって逝ってる香具師は同じ痛さを感じるのは気のせいだろうか(w
現状では32bitでC使ってるソフトが最速だ。

588 ：デフォルトの名無しさん：2005/11/11(金) 02:43:32

>>587
正しいがつまらん。

589 ：デフォルトの名無しさん：2005/11/11(金) 08:13:24

Javaはいつ標準化されんの？後出しのC#はECMA標準規格が存在するけど。

590 ：デフォルトの名無しさん：2005/11/11(金) 10:47:26

jabaは字実上の標順だからｗ
ECNAに票準してもらってるC$と比べないでほしいねｗ

591 ：デフォルトの名無しさん：2005/11/11(金) 11:20:29

>>590
>>590

592 ：デフォルトの名無しさん：2005/11/11(金) 11:24:15

>>590
ﾜﾛﾀ

593 ：デフォルトの名無しさん：2005/11/11(金) 21:09:53

64bitのCLRって32bitのより速いん？

594 ：556：2005/11/11(金) 23:50:51

unix文化だとmallocしてもfreeしない
というのはJava登場以前からある話です。

595 ：デフォルトの名無しさん：2005/11/11(金) 23:55:03

>>594
異文化に対する偏見だ。必要ならやるし必要なければやらないだけ。

596 ：デフォルトの名無しさん：2005/11/12(土) 00:46:57

>>594
それ何て文化？

597 ：デフォルトの名無しさん：2005/11/12(土) 01:03:53

Javaは配列の添え字がint固定だね。
java.nioのByteBufferもintでしか範囲指定できないし。
Javaアプリケーションは64bitアドレスをリニアに扱えないってことか。

598 ：デフォルトの名無しさん：2005/11/12(土) 01:16:17

>>597
intは符号付きしかないから、現在の仕様では2G要素（事実上2Gバイトか？）が
一つのオブジェクトの大きさとしては限界になりそうだね。超でかいファイルを
一気にマップしてランダムアクセスなんてやるときは、マップし直したりする手間が
入りそうだな。

599 ：デフォルトの名無しさん：2005/11/12(土) 02:21:07

リニアな配列でデータ扱う必要があるケースって稀だと思うが。

600 ：デフォルトの名無しさん：2005/11/12(土) 02:55:07

>>594
「unix文化」と言い切るからには、そういうやり方をしているプログラムを複数挙げてくれよ。
もちろん、おまえの言うように
「10-100M単位で確保」「複数同時に動かす可能性もある」もので
「使い捨てでない」「実際に実用的な」ものを、な。

当然だが、「exit前のfree」問題の話じゃないぞ。
「使い捨てバッファ」を「ひたすら確保だけして解放しない」プログラムを、な。

「unix文化」は、昔から、ソースからコンパイルするのが当然だから
「それが普通」なら、ソースコードがいくつでもあるはずだよな。

601 ：デフォルトの名無しさん：2005/11/12(土) 03:13:51

例えばファイルを処理するのに
ちまちま一行ずつ読んだりブロックで読んだりせず
statでサイズを取ってmallocし、まとめて一気に読み込む、みたいなやり方は確かにある。

けど、これをサーバー(daemon)でやるわけないし
多数のファイルを扱うプログラムが、
ファイル毎に別のバッファを確保するようなやり方になっているとは
とても思えないが。

602 ：デフォルトの名無しさん：2005/11/12(土) 08:21:37

Javaは32bit時代のプログラミング言語なんだよね
64bitのパワーを生かすならJavaは選択肢から外すことになる

603 ：デフォルトの名無しさん：2005/11/12(土) 08:23:20

601
> ちまちま一行ずつ読んだりブロックで読んだりせず
> statでサイズを取ってmallocし、まとめて一気に読み込む

mmap使うだろそれ

600
>「使い捨てバッファ」を「ひたすら確保だけして解放しない」プログラム

昔のgnuのgrepなんかがそうだった気がするyo
いまはどうだか知らんが

604 ：デフォルトの名無しさん：2005/11/12(土) 08:25:00

そういう用途だったら今ならmmapするのが多いとは思う。
statでサイズが取れるってことはnonseekable streamを相手にしなくてよいわけ
だから。

605 ：デフォルトの名無しさん：2005/11/12(土) 08:38:47

で、何GBというサイズのファイルをmmapしたいときに、64 bit OS の出
番ですよ！！！11！

606 ：デフォルトの名無しさん：2005/11/12(土) 09:32:51

>>602
64bitのパワーってなんですか？

607 ：デフォルトの名無しさん：2005/11/12(土) 09:45:29

>>606
> >>602
> 64bitのパワーってなんですか？

こと、x86-64に限って言えば、メモリ空間が32bit(4GB)を超えること。
汎用レジスタが64bitに拡張されているため、42億を超える整数を
扱えること。

決して、命令を64bit毎にフェッチするから速い、VLIWだ、なんてことはない。

608 ：デフォルトの名無しさん：2005/11/12(土) 09:53:21

> 64bitのパワーってなんですか？
すごい消費電力

609 ：デフォルトの名無しさん：2005/11/12(土) 10:51:25

>>604
たとえば、CIFSをマウントしてもmmapは無理だよね。
多くのソフトは、mmap不可なときへの対応も必要だよね。

# 可能なとき、mmapするのには異論ないよ。

610 ：デフォルトの名無しさん：2005/11/12(土) 11:57:32

>598
> intは符号付きしかないから、現在の仕様では2G要素（事実上2Gバイトか？）が
細かい話だけど、Javaのlong配列だと8バイト×2G要素=16GBになる。

611 ：デフォルトの名無しさん：2005/11/12(土) 12:16:24

>>610
今のJavaVMで2G以上の大きさの配列ってnewできる？

612 ：デフォルトの名無しさん：2005/11/12(土) 12:18:28

>>605
Javaってさ、4GB超えるサイズのmmapってできるのかなあ
できないんじゃ・・・ちょっと・・・

613 ：デフォルトの名無しさん：2005/11/12(土) 14:44:09

>>608
つ[座布団]

614 ：デフォルトの名無しさん：2005/11/12(土) 21:30:13

>>605
まさしくその通り。
でないと昔のEMSを彷彿とさせるような切り替えをプログラマがやらなきゃいけない。

615 ：デフォルトの名無しさん：2005/11/12(土) 22:21:38

>612
FileCnannel.map()の引数は64ビットになってるから、実装次第かと。
64ビットOS上で動作するJVMなら大丈夫なのでは。

616 ：デフォルトの名無しさん：2005/11/12(土) 22:43:57

>>615
いや、だからmapし直さないとファイル全体をアクセスできないって話でしょ。
ByteBufferのほうは2Gまでしかシークできないから。

617 ：デフォルトの名無しさん：2005/11/13(日) 00:34:44

>>609
OSによるでしょ。
Windowsはリモートのファイルをメモリマップできるよ。
原理上、ローカルのファイルのメモリマップとの相違点に要注意だけど。

64ビットならファイルをメモリマップで、というのは乱暴すぎるよ。
OSのVMはそんなに賢くないし、ましてやエスパーでもないので、
もう参照しない場所までマップしたまま放置しておくのは良くない。

618 ：デフォルトの名無しさん：2005/11/13(日) 02:30:59

> Windowsはリモートのファイルをメモリマップできるよ。

UNIX もできる。
Windows って Windows NT の頃にリモートだと駄目だという説明を
読んだような記憶があるんだけど (でもうろ覚えなので間違いかも)、
今は直ってたのか、知らなかった…

> OSのVMはそんなに賢くないし、ましてやエスパーでもないので、
> もう参照しない場所までマップしたまま放置しておくのは良くない。

64bit 機なら、あまり神経質に mmap(2)/munmap(2) する必要もないのでは？
確かにカーネルメモリをちょっと無駄使いすることになるけど、
たとえばシーケンシャルアクセスなら、madvise(,, MADV_SEQUENTIAL)
しておけば実メモリの方は、VM が適宜解放してくれるし。

アクセスパターンが複雑で VM では判断できないが、アプリだと判断できて、
かつ主記憶を溢れる可能性があるならば、アプリが munmap(2) した方が
勿論いいけど。

結局場合によりけりかな。

619 ：デフォルトの名無しさん：2005/11/13(日) 06:07:41

>>602
最悪の場合でもVMで動いてるJavaや.NETはVM上で32bitモードとか64bitモードとか
モードを分ければすむことじゃないか？
コンパイラのオプションを指定するのと同じように起動時に指定させればいいように
VMを作ればいいだけじゃん

620 ：デフォルトの名無しさん：2005/11/13(日) 07:28:09

単に >>602 が口からでまかせ言ってるだけなんだから、
真に受けるだけ損。
sparc 版は 32bit と 64bit の両方のバイナリが用意されてる。
ttp://java.sun.com/j2se/1.4.2/download.html

あるいは >>602 は x86 版で 32bit バイナリしかないと言いたい
のかもしれないが、x86_64 版は BEA などが出しているから、
そちらを使えば良い。s
Sun は Opteron に本腰を入れてるから、そのうち Sun からも
出るんじゃないの?

621 ：デフォルトの名無しさん：2005/11/13(日) 08:24:08

Javaで
long[] long_array = new long [ 2*1024*1024*1024/*2G個*/ ];
はできますか？

622 ：デフォルトの名無しさん：2005/11/13(日) 09:07:29

>>617
> 64ビットならファイルをメモリマップで、というのは乱暴すぎるよ。
> OSのVMはそんなに賢くないし、ましてやエスパーでもないので、
> もう参照しない場所までマップしたまま放置しておくのは良くない。

普通のページングと同様に参照しなければ実メモリはそのうち別のプロセスに
使われるので全然問題ありませんが。
そりゃ、プログラマがアクセス特性をきっちり把握してれば陽に制御した方がVM
任せよりはよくなることが多いだろうけどさ。

623 ：デフォルトの名無しさん：2005/11/13(日) 09:11:38

Javaは賢いから大丈夫ですよ（苦笑）

624 ：デフォルトの名無しさん：2005/11/13(日) 11:49:38

64bit版のJava VMではIntが64bitになったりしないの？
64bit版のVM使ったことないからわからない
誰か教えて

625 ：デフォルトの名無しさん：2005/11/13(日) 13:00:50

Javaの言語仕様が変わらない限り32bitのまま。

626 ：デフォルトの名無しさん：2005/11/13(日) 13:08:22

JavaとゆうかJVMが32bitしか考えてないからな

627 ：デフォルトの名無しさん：2005/11/13(日) 13:08:43

>624
VMの仕様上intは32bit固定になってる。配列の確保時のサイズ指定や、
配列アクセス時のインデックスも32bit固定なので、64bit対応にするためには
VMに新しい命令を追加するしかない。

628 ：デフォルトの名無しさん：2005/11/13(日) 13:12:16

>>620
Sun からも出てるよ。
・Solaris x64 Platform - J2SE(TM) Development Kit 5.0 Update 5
・Linux AMD64 Platform - J2SE(TM) Development Kit 5.0 Update 5
・Windows AMD64 Platform - J2SE(TM) Development Kit 5.0 Update 5

629 ：デフォルトの名無しさん：2005/11/13(日) 13:19:59

Java Plug-inﾏﾀﾞｰ? (AAry

630 ：デフォルトの名無しさん：2005/11/13(日) 18:50:24

longが64bitなわけで。
C言語でint=64bitな処理系って見たこと無いな。

byte=8bit
char=8bit or 16bit
short=16bit
int=32bit
long=32bit or 64bit
long long=64bit

だろ大抵。

631 ：デフォルトの名無しさん：2005/11/13(日) 18:58:33

自分の世界だけで語らんでくれたまえ厨房

632 ：デフォルトの名無しさん：2005/11/13(日) 19:03:27

>>630 みたいなバカが死滅するまでプログラマーは低賃金長時間労働者の
ままなんだろうな・・・

633 ：デフォルトの名無しさん：2005/11/13(日) 19:09:12

純粋にわからん。int＝64bitな処理系ってあんの？
shortやlongって何ビットなんだ？

634 ：デフォルトの名無しさん：2005/11/13(日) 19:13:07

JBossのようにひとつのVMでマイクロカーネルモデルをやってるようなアプリが64it化で使いやすくなるかな。

635 ：デフォルトの名無しさん：2005/11/13(日) 19:16:07

>>634
知ったかすんな。いい子ぶりやがって。

636 ：デフォルトの名無しさん：2005/11/13(日) 19:18:46

>>634
おめーが発してる単語一つ一つにどれだけの人がかかわって
苦労したのかわかってんのかよ。
JBoss, VM, カーネル、マイクロカーネル、カーネルモデル、アプリ、64bit化。
おまえが発するには荷が重すぎる。

637 ：デフォルトの名無しさん：2005/11/13(日) 19:19:24

どういうたたかれかただよ

638 ：デフォルトの名無しさん：2005/11/13(日) 19:24:24

>>633
ILP64でぐぐれ。

639 ：デフォルトの名無しさん：2005/11/13(日) 19:37:49

>>634
>>636
>>637
ワロータ

640 ：デフォルトの名無しさん：2005/11/13(日) 20:38:00

ILP64 採用してるのって、昔の CRAY ぐらいでしょ。
ほぼ全ての 64bit OS は 630 の言う通りで、
LP64 (UNIX 系) か LLP64 (Windows 系) の筈。

641 ：デフォルトの名無しさん：2005/11/13(日) 20:43:28

>>640
今は亡きAlphaがILP64じゃなかったっけ？

642 ：デフォルトの名無しさん：2005/11/13(日) 21:17:07

>>622
別プロセスに使われるまでが、問題なのです。
やってみればわかるけど、全体のパフォーマンスが落ちます。

643 ：デフォルトの名無しさん：2005/11/13(日) 21:22:59

いや、Alpha は LP64 (UNIX) か LLP64 (VMS) だよ。ILP64 じゃない。
ttp://h30097.www3.hp.com/dtk/Compaq_C_Compiler/doc/lrm/DOCU0006.HTM#sizes_sec

あと、来年の10月27日までは新規納入のための受注を受け付けてる
ので、まだ死んでない。死にかけだけど。

644 ：デフォルトの名無しさん：2005/11/13(日) 21:49:23

>>642
やったことあるけど落ちないよ。

645 ：デフォルトの名無しさん：2005/11/13(日) 22:42:32

Java最強ってことでFA?

646 ：デフォルトの名無しさん：2005/11/13(日) 23:04:36

一時バッファの終了処理はおおざっぱにvectorとか、boost.scoped_arrayとか使う、
OSが勝手に確保するような特殊なのは関数内クラスで終了処理する。
C言語できちんと書くのは面倒、結論 C++ を使え。

647 ：デフォルトの名無しさん：2005/11/13(日) 23:04:52

最強厨はJavaでも使っておとなしくしてなさい、ってことで。

648 ：デフォルトの名無しさん：2005/11/13(日) 23:31:23

Javaはポインタ使わないからC言語ほど32bit→64bitの考慮の必要はないね

649 ：デフォルトの名無しさん：2005/11/13(日) 23:49:14

議論を蒸し返すのも嫌なので上に頷いておく。

650 ：デフォルトの名無しさん：2005/11/14(月) 09:18:57

>>644
メモリが余りまくってるからじゃないか?

651 ：デフォルトの名無しさん：2005/11/14(月) 09:47:30

今からこのスレは貧乏スペック自慢スレになりますた

652 ：デフォルトの名無しさん：2005/11/14(月) 12:18:16

Javaなら64bitのこと考えなくていいから、むしろ32bitの速いCPUで十分な罠。

653 ：デフォルトの名無しさん：2005/11/15(火) 10:14:31

>>634
>>636
>>637

ﾜﾛｽ。>>636の叩き方は愛があるな

654 ：デフォルトの名無しさん：2005/12/14(水) 18:15:03

655 ：デフォルトの名無しさん：2006/01/07(土) 20:58:14

見事な廃れっぷりだな。64bitはまだ先ってことでFA

656 ：デフォルトの名無しさん：2006/01/07(土) 21:32:28

Vistaで半ば強制移行。

657 ：デフォルトの名無しさん：2006/01/07(土) 21:44:58

結局 x86-64 に軍配？
って、 x86-64 ってのは正式名称？

658 ：デフォルトの名無しさん：2006/01/07(土) 22:05:17

初期にAMD64と言われていたものを広く浸透させるために
会社の名前を取って一般名称にしたとかなんじゃ。
インテルの力でEM64Tの呼称が浸透する可能性もなきにしもあらず。

659 ：デフォルトの名無しさん：2006/01/07(土) 22:07:05

マイケルソフトは x64 と四㌦ね

660 ：デフォルトの名無しさん：2006/01/07(土) 22:09:22

>>658
http://ja.wikipedia.org/wiki/X86-64
どうやら逆らし。

MSはx64で統一するつもりらし。

661 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/01/08(日) 00:27:10

Intelにとっては主役は飽くまでIA64(IPF)だからね。

662 ：デフォルトの名無しさん：2006/01/08(日) 00:30:31

>>661
そこは笑うところですか？

663 ：デフォルトの名無しさん：2006/01/08(日) 00:34:17

そんなことより、もともと Intel が進めていた
x86 互換の 64bit 拡張と、AMD64 との間の違いを知りたい。

664 ：デフォルトの名無しさん：2006/01/08(日) 00:35:13

まぁインテルの現状を見る限り大したことはしてなかったと思う

665 ：デフォルトの名無しさん：2006/01/08(日) 01:16:20

AMD64(以下A）とEM64T（以下E）の違い
1.LAHF/SAHF命令のサポート
　　A：全モード
　　E：64ビットモードを除く
2.CMPXCHG16Bのサポート
　　A：未サポート
　　E：64ビットモード
3.FFXSRフラグのサポート
　　A：64ビットモード
　　E：未サポート
4.No-Execute Enableフラグのサポート
　　A：64ビットモード
　　E：未サポート
5.SYSCALLとSYSRET
　　A：全モード
　　E：64ビットモードのみ
6.SYSENTERとSYSEXIT
　　A：レガシーモードのみ
　　E：全モード

666 ：デフォルトの名無しさん：2006/01/08(日) 01:27:20

>>665 え？ AMD64 と EM64T の間に違いがあったのか。
ってことは、マイクロソフトがいう x64 ってのは
実は異なる二つのアーキテクチャの総称？？？

667 ：デフォルトの名無しさん：2006/01/08(日) 01:42:49

>>666
386 と 486 程度の違いだから、同じアーキテクチャと言ってよいと思う。
それに一口にEM64Tと言ってもプロセッサモデルによって多少の違いはあったりするし。

668 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/01/08(日) 01:43:24

>>665
Prescottの現行ステッピングではAMD64は全部サポートしてるような。。。

669 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/01/08(日) 01:44:44

>>666
MS謹製のx64 Assemblerでは互換性の無い命令は使えないようにしてたハズ。。。

670 ：デフォルトの名無しさん：2006/01/08(日) 03:43:00

>>668
最初から全部サポートしていればなぁ。
サポートしていないCPUが存在すれば、使えないわけで。

ちゃんとインテルに情報開示しなかったAMDが悪いよ。
今まで散々、互換プロセッサで商売してきたのにさ。

671 ：デフォルトの名無しさん：2006/01/08(日) 03:45:27

>>670
ちゃんと開示してるよ。

672 ：デフォルトの名無しさん：2006/01/08(日) 08:03:38

>>671
ほんと?

俺が読んだ記事では、
AMDの資料に問題があり、インテルがAMDと同じように実装できなかった
ということになっていたが。

なんでも、AMDの資料には、AMDのCPUの実態とは違うことが書いてあったらしい。

673 ：デフォルトの名無しさん：2006/01/08(日) 08:08:11

結局 Microsoft は無難な共通点だけを使うってことかな。
で、それを x64 って呼ぶよってことじゃないか？

674 ：デフォルトの名無しさん：2006/01/08(日) 13:20:09

きちんとオリジナルを調べる責任は常にコピーする側にあると思うが。

675 ：デフォルトの名無しさん：2006/01/08(日) 15:12:35

AMDの初期のdocに書きそこねがあったんでしょ
intelも意地張らずにすり合わせしとけばよかったのに、と思う

676 ：デフォルトの名無しさん：2006/01/08(日) 17:01:03

ダンプに関数パラメータ情報が無いという素敵なx64のABIを策定した奴を100回ﾇｯｺﾛｼﾀｲ。

677 ：デフォルトの名無しさん：2006/01/08(日) 21:27:22

レジスタ渡しで、スタックに引数を積まない、のかもな。

>>675
AMDのCPUに対して、ドキュメント通りの実装ではないのでエラッタだ、
AMDのほうが修正すべきだと要求するのが本来の筋だと思うんだな。

インテルは度量が大きいから、
しかたねーな、こっちが合せてやるよ、
ってことになったのだと思われ。

678 ：デフォルトの名無しさん：2006/01/08(日) 21:29:09

>>677
エラッタってのは具体的に何の話？
少なくとも>>665に書いてる話は最初からドキュメントされているが。

679 ：デフォルトの名無しさん：2006/01/08(日) 23:29:06

The AMD x86-64 Architecture Programmers Overview
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/x86-64_overview.pdf
ページ88
LAHFはINVALID IN 64-BIT MODE (invalid-opcode exception)と書かれている。

680 ：デフォルトの名無しさん：2006/01/09(月) 00:11:12

どっちにしても実チップが存在したのだから、それに合わせるのが「互換チップ」の
基本だわな。インテルはそういうことに慣れていなかっただけだろう。

681 ：デフォルトの名無しさん：2006/01/09(月) 00:23:10

>>679
あのさ、LAHFもSAHFも代替可能な古い命令だぞ？
そこまで目くじら立てる理由がわからん。
文章では64bitモードで使えないと書いておいて、後からx87との互換性かなんかで
横槍入って一応使えるようにしておいたってだけだろうが。
SSEを推進しているIntelがそれを実装していなかったとしても何も問題ないし、
OSベンダーやソフトハウスが最大公約数としてのx64を考えているのなら賢明だってだけじゃんか。

x64互換としてのAMD64とEM64Tと考えれば何も問題はない。

682 ：デフォルトの名無しさん：2006/01/09(月) 00:38:16

実際、AMD64とEM64Tで「互換性がなくて困る」って話は聞かないもんな。

683 ：デフォルトの名無しさん：2006/01/09(月) 00:47:04

> 目くじら立てる

そう、 >>665 にある命令で、差異があることで本当に困るものって無いんだよね
それを吟味せずにピーピー騒いでるのは滑稽。

あ・・CMPXCHG16Bってどうだろ。

684 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/01/09(月) 01:32:58

そもそもx86-64の設計に横槍入れてたMSがx64アプリではx87をサポートしないんじゃなかったっけ。
AMDとしては3DNOW!なんかの資産のあるFP/MMレジスタベースを生かしたほうが有利だっただろうけど
結局XMMレジスタを生かすことになったってのは、ある意味Intelの思惑がかなった形だわな。

まぁMSはコンパイラが象徴するように「80bit浮動小数なんていらねーよ」って態度貫いてきたからね。
それよかXMMレジスタベースで高精度浮動小数サポートしてほしくね？

685 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/01/09(月) 01:36:11

x64アセンブラの本とかって出版されてる？
製本されたリファレンス欲しい。
なぜか無駄にItaniumのアセンブラ本持ってたりするがｗ

686 ：デフォルトの名無しさん：2006/01/09(月) 07:34:21

NX(Intelの呼び名ではXD)ビットはさすがにサポートの有無を判別して動作してるな。

687 ：デフォルトの名無しさん：2006/01/09(月) 17:53:33

インテルが度量が大きいというのはどういう視点で見るとそうなるんだろう

688 ：デフォルトの名無しさん：2006/01/09(月) 20:13:55

資本力が大きいですし・・・

689 ：デフォルトの名無しさん：2006/01/09(月) 21:25:51

Itaniumは結局消えるのかな。
あまりマトモに扱われているという話を聞かない。

690 ：デフォルトの名無しさん：2006/01/10(火) 00:49:39

>>682-683
ピーピー騒いでいるのは、
何がなんでもインテルを叩きたいAMD厨
なんですよ。

691 ：デフォルトの名無しさん：2006/01/10(火) 01:51:31

マカーじゃないかな？
真の64bitはmacだけ、ということにしたいわけだし。

692 ：デフォルトの名無しさん：2006/01/10(火) 01:53:47

>>691
もうすぐ仲間になるんだから、仲良くやりましょうよ。ｗ

693 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/01/10(火) 01:54:37

まぁ無理やり付け足した感もないところが綺麗だわな。
もともと32bitのPPCは「64bit CPUの32bitバージョン」ということらしいし。

694 ：デフォルトの名無しさん：2006/01/10(火) 03:25:28

>>692
これまでのマカーから行動から予想するに
AMDを叩きだすだろうな

695 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/01/10(火) 03:51:27

>>694
それなんてMacオタ氏？

696 ：デフォルトの名無しさん：2006/01/10(火) 19:20:36

AMD厨はマカーよりもたちがわるい。

697 ：デフォルトの名無しさん：2006/01/10(火) 20:50:03

厨はとにかくたちがわるい

698 ：デフォルトの名無しさん：2006/01/11(水) 15:22:32

Win64(x64)の仕様ではx87レジスタは使用してはいけないという話だが
SDKのmathライブラリ内でx87命令が使われている。どういうことか？

699 ：デフォルトの名無しさん：2006/01/11(水) 16:09:46

>>698
user-modeではx87レジスタは使用可だよ。
kernel-では使っていけないという話なのに・・・

700 ：デフォルトの名無しさん：2006/01/11(水) 16:52:27

ユーザーモードで利用可じゃないとそもそもx87使った32bitアプリを
動かせないんじゃないの？いや、よく知らないけど。

701 ：698：2006/01/11(水) 17:24:19

>>699
レスどうも。
自分でも調べてみたのですがそのようですね。

702 ：デフォルトの名無しさん：2006/01/11(水) 18:54:13

>>700
まあ仮想PCみたいに変換噛ませば不可能じゃないんじゃない？
パフォーマンス落ちるだろうけど。

703 ：デフォルトの名無しさん：2006/01/12(木) 00:25:23

とにかくAMD厨はたちがわるい

704 ：デフォルトの名無しさん：2006/01/12(木) 00:27:37

そろそろ鬱陶しいな

705 ：デフォルトの名無しさん：2006/01/12(木) 01:23:27

>>700
32ビットアプリの話ではなく、64ビットアプリの話ですよ。

706 ：デフォルトの名無しさん：2006/01/12(木) 13:23:13

厨うざい

>>705
拡張精度が扱えるのはFPUだけではない?
なので「非推奨」ということで。

707 ：デフォルトの名無しさん：2006/01/12(木) 14:22:47

>>705
Longモード（要するに64bitのOSが乗っかってる状態）だと、32bitと64bitのプロセスが
混在する中でマルチタスキングしないといけない。
最低限FP/MMレジスタの退避をサポートする必要があるわけで、64bitでも
結果的に「使える」という話。

だからFP/MMがレジスタ拡張されるわけでもなく、消されるわけでもなく、
残ってるのはそのため。

MMXはともかく、x87の場合「スタック」として扱うから論理レジスタ本数増やしても
パフォーマンスの向上しえないしね

708 ：デフォルトの名無しさん：2006/01/12(木) 14:47:29

>>707
＞SDKのmathライブラリ内でx87命令が使われている。

とあるが、パフォーマンスの向上しえないのになぜMSは使っているのか。
手抜き？

709 ：デフォルトの名無しさん：2006/01/12(木) 15:30:20

作ったやつしか知らないよ。

710 ：デフォルトの名無しさん：2006/01/13(金) 22:53:50

53bitの精度を出すには53bitの演算じゃ手間がかかるってことさ

711 ：デフォルトの名無しさん：2006/01/15(日) 03:25:16

X64対応のXeonでx87命令使うとめっさ遅い気がする。
ia32 同クロックのXeon上で同じ32bitバイナリを
動かしたときの３倍は遅い。
何か下方修正があった？

712 ：デフォルトの名無しさん：2006/01/15(日) 10:21:56

SIMD 命令を使えって言う神様のお告げじゃないのか。

713 ：デフォルトの名無しさん：2006/01/15(日) 17:04:48

Intel MKLのem64t版でもx87使っててめっさ遅いルーチンがあるのさ。

714 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/01/15(日) 18:36:18

80bit精度使ってるからじゃなくて？

715 ：デフォルトの名無しさん：2006/01/15(日) 19:55:39

x87使うのはもち80bit精度のため。
OpteronはSSE2よりx87使って書いた方が
速いことも多いんだけどなぁ。

716 ：デフォルトの名無しさん：2006/01/15(日) 23:02:18

結局>>711の遅い原因は何であるっぽいの？

内部80bitだからって32bitでは遅くならないが。
（メモリ転送や平方根、除算などを除いて）

717 ：デフォルトの名無しさん：2006/01/16(月) 00:25:13

なぜOpteronには4倍精度がないのだ。

718 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/02/08(水) 22:23:20

ICC9の64bit向けコンパイラってコア別最適化がWとPしかサポートされてないんだが
Wって32bitと同じくWillametteだとしたら暗にSSE3未サポートの初期AMD64向けの最適化オプションだよな。
Prescottコア以降でしかEM64T使えないし。

Woodcrest（MeromベースXeon）？まさかね。

719 ：デフォルトの名無しさん：2006/02/18(土) 18:32:23

TextSSを64bit版でコンパイルして欲しい

720 ：デフォルトの名無しさん：2006/02/18(土) 18:40:56

６４bitでネイティブ動作する2chブラウザをつくろう

721 ：デフォルトの名無しさん：2006/02/19(日) 20:34:00

>>707
> MMXはともかく、x87の場合「スタック」として扱うから論理レジスタ本数増やしても
> パフォーマンスの向上しえないしね

FXCH命令のレイテンシ、知ってる？

722 ：デフォルトの名無しさん：2006/02/19(日) 22:52:28

命令数の問題じゃないんか？

723 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/02/20(月) 03:34:40

P6以降のCPUでfxchって実行自体されない気が。

724 ：デフォルトの名無しさん：2006/02/20(月) 05:54:06

リネーミングになるからじゃんじゃか使えという話をみたような。

725 ：デフォルトの名無しさん：2006/02/20(月) 13:22:01

そしてデコーダは燃え上がる。

726 ：デフォルトの名無しさん：2006/04/05(水) 21:02:01

http://www.forest.impress.co.jp/article/2006/03/24/64bitcon_result.html
結局こういうのがじゅしょうするわけか。
まあ、他に作りようがないけどなあ。
ある状況下で少し速くなるとか作りやすいとかの変化でしかないもんな。

727 ：デフォルトの名無しさん：2006/04/09(日) 21:21:42

うーわ、ものごっつつまんね。

728 ：デフォルトの名無しさん：2006/04/12(水) 01:18:37

age

729 ：デフォルトの名無しさん：2006/04/22(土) 11:29:26

だから64bitなんざSVHSだって言ってんだろ。

730 ：デフォルトの名無しさん：2006/06/08(木) 01:16:06

731 ：デフォルトの名無しさん：2006/06/08(木) 16:28:57

で、64bit環境でアセンブラいじってるヤシはおらんのか。

732 ：デフォルトの名無しさん：2006/06/09(金) 00:03:18

つ[ http://user64.psychedance.com/2005/09/mty20050910_x64.html ]

733 ：デフォルトの名無しさん：2006/07/18(火) 21:17:33

Core2の64bit性能がイマイチということだが、
このスレの過疎っぷりを見ると問題なさそうだな。

734 ：デフォルトの名無しさん：2006/07/18(火) 22:13:16

そのせいでMSがvista 64bitをプッシュしなくなっちゃった！

サーバサイドではプッシュしまくりだがね。

735 ：デフォルトの名無しさん：2006/07/18(火) 22:34:58

簡単な(初心者でもできる)プログラミング教えてください！！

736 ：デフォルトの名無しさん：2006/07/18(火) 23:31:39

>>735
無い。
なんだかんだ言ってどれも平等に難しい。

737 ：デフォルトの名無しさん：2006/07/23(日) 01:40:41

64bit Windowsは窓使いの憂鬱が対応するまで移行できん……。

738 ：デフォルトの名無しさん：2006/07/23(日) 02:12:56

なんのためにソースが公開されてるんだとか言ってみる
64bitならコンパイラも含めて無料で手に入るし

739 ：デフォルトの名無しさん：2006/08/11(金) 01:03:54

x64のMS Access ODBC Driver ってあるの？

740 ：デフォルトの名無しさん：2006/08/11(金) 01:10:19

VC8 MFCソリューションから使用できる
COMコンポーネントのFlexGridを
誰か知りませんか。
MSFlexGrid6.0 はx86しか対応してないし・・・
昔作成したプロジェクトをx64対応させなあかん
のやけど、Grid系は.Net Framworkコンポネーントでしか
見つからんし

741 ：デフォルトの名無しさん：2006/09/20(水) 12:17:28

さしあたり、Vistaの64bit版が出たらだね。
アセンブラで増えたレジスタの効果を確かめるのと、
対応コンパイラでどれだけ高速化するかがネタになる。

742 ：デフォルトの名無しさん：2006/09/20(水) 21:55:58

XP x64ではできない画期的な何かがVista x64にはあるんですか?

743 ：デフォルトの名無しさん：2006/09/20(水) 22:10:10

XPx64は誰にでもお勧めできる代物じゃないからね。
64ビットプラットフォームとしてVistaに期待できるでしょ。

744 ：デフォルトの名無しさん：2006/09/20(水) 22:19:20

まだ最終製品でないから断言はできないがVista x64も誰にでもお勧めできるかは微妙だよ
http://itpro.nikkeibp.co.jp/article/COLUMN/20060911/247700/
「4Gバイトを越えるメモリーが必要だとか，特殊なアプリケーションが必要だとか，そういった
特別な用途がなければ，x64版のWindows Vistaを無視するのが無難だ。」

745 ：デフォルトの名無しさん：2006/09/25(月) 11:23:08

>>744
改善されるのを願うしかないなあ。
64bitモードでアセンブラをいじるという用途のために、
次は64bitOSを選ぼうと思っていたんだが。

746 ：デフォルトの名無しさん：2006/09/25(月) 12:02:51

16→32bitの時のような待望感が32→64bitではないね

747 ：デフォルトの名無しさん：2006/09/25(月) 12:09:32

逆に、128bit化する必要は当分ないというのはあるかも。
ビット数を倍にすると扱える数は2倍でなく2乗になるからな。
完成形の64bitを早く定着させてほしいものだ。

748 ：デフォルトの名無しさん：2006/09/25(月) 12:12:13

128bitの型の名前は一般名称として定着しているのはありますか？
byte 8bit
short 16bitのように。

749 ：デフォルトの名無しさん：2006/09/25(月) 12:21:47

QWORD

750 ：デフォルトの名無しさん：2006/09/25(月) 12:35:11

byte 8bit
word 16bit
dword 32bit
qword 64bit
tbyte 80bit

PUNPCKLQDQとかのニーモニックからすると
128bitはdqword？

751 ：デフォルトの名無しさん：2006/09/25(月) 12:39:01

128bitのデータって一般的なのは IPv6 のアドレスくらいかな。
（もちろん１「ワード」として扱える必要は特に無いだろうけど）

752 ：デフォルトの名無しさん：2006/09/25(月) 12:58:37

>>751 IPv6、なるほど。

753 ：デフォルトの名無しさん：2006/09/25(月) 13:03:41

IEEE754rが広がってきたとして、
浮動小数点はやっぱり
float 32
double 64
quad 128 でしょうか？

754 ：デフォルトの名無しさん：2006/09/25(月) 14:12:08

UUID (GUID)も128bitある。

755 ：デフォルトの名無しさん：2006/09/25(月) 14:24:16

128bit型は、だいぶ使い道あるし、大事じゃん。
64bit型はそうでもなかったけどさ。

756 ：デフォルトの名無しさん：2006/09/26(火) 09:16:36

short 16bit
int 32bit
long 64bit
long long 128bit
こんな処理系も出てくるかな。

757 ：デフォルトの名無しさん：2006/09/26(火) 10:34:28

very long とか longer の方が面白い。ｗ

758 ：デフォルトの名無しさん：2006/09/26(火) 11:13:11

longestを出してしまったらそこで終わりだ。
人間、向上し続けることが大事だ。

759 ：デフォルトの名無しさん：2006/09/26(火) 11:36:12

longer than longer 256bit
longer than logner than longer 512bit
　　　　　　　・
　　　　　　　・
　　　　　　　・

760 ：デフォルトの名無しさん：2006/09/26(火) 12:41:11

きりが無いから
signed{32} x;
unsigned{128} y;
みたいな表記がいいな。

761 ：デフォルトの名無しさん：2006/09/26(火) 12:45:35

例えばint128を組み込み型としておいて、
typedef int128 longer;
とか、やっぱり typedefっぽく
ユーザーが型宣言というか型定義っぽくなるのかなと思う？

762 ：デフォルトの名無しさん：2006/09/26(火) 17:58:55

C99的には当然、int128_tとuint128_tとして提供されるんだろう。

763 ：デフォルトの名無しさん：2006/09/26(火) 18:32:43

みんな独自定義して
short, int, longのような共通とかないんだろうと思っちゃう…

764 ：デフォルトの名無しさん：2006/09/26(火) 20:27:21

wow64で動いている32bitアプリから64bitのDLLを呼び出す場合ってDCOM使わんと駄目？

765 ：デフォルトの名無しさん：2006/09/26(火) 21:42:54

Microsoftがいやがるような裏技はあると思うぞ
少なくともwow64.dll wow64win.dll wow64cpu.dllの3つはマップされてるんだから

766 ：デフォルトの名無しさん：2006/09/27(水) 00:28:01

逆に比べれば簡単だろうな

767 ：デフォルトの名無しさん：2006/09/28(木) 22:27:54

なんでWin16/32のときのようなサンクを用意しなかったんだろう？

768 ：デフォルトの名無しさん：2006/09/29(金) 23:33:52

IA-64版と機能差を付けたくなかったんだろう

769 ：デフォルトの名無しさん：2006/10/01(日) 09:53:55

Vistaインストールしたので64bitのプログラムを
作ってみたいのですが、いいコンパイラはありますか？
Borland C++ Compilerをずっと使っていましたが、
どうやら64bit版はないようで・・・

770 ：デフォルトの名無しさん：2006/10/01(日) 10:10:03

>>769
とりあえずPlatform SDKをインストールすればVC++の64bit版コンパイラも付いてくるはずだぞ。

771 ：デフォルトの名無しさん：2006/10/01(日) 17:46:52

>>769
ActiveBasicww

772 ：デフォルトの名無しさん：2006/10/01(日) 17:53:55

>>770
VisualStudio2005 TeamSuiteはインストールしていますが、
さらにPlatformSDKも入れる必要がありますか？

>>771
とりあえずC++のが欲しいんですよｗ

773 ：デフォルトの名無しさん：2006/10/01(日) 18:03:04

>>772
Visual Studioを持っているなら、それが使えるはずだ。
俺持っていないから詳しくは知らないけど。

774 ：デフォルトの名無しさん：2006/10/02(月) 01:45:51

だめだorz
コンパイルしても動かないorz

775 ：デフォルトの名無しさん：2006/10/02(月) 05:55:07

Borland C++は64ビット対応してないの?

776 ：デフォルトの名無しさん：2006/10/02(月) 06:35:35

してない

777 ：デフォルトの名無しさん：2006/10/02(月) 07:09:07

>>774
まさかこんなメッセージが出てないよな？
...は有効なWin32アプリケーションでありません。

778 ：デフォルトの名無しさん：2006/10/07(土) 16:50:19

TeamSuiteを入れる人間の質問とは思えないんだが…

779 ：デフォルトの名無しさん：2006/10/07(土) 20:41:17

割れ物注意ｗ

780 ：デフォルトの名無しさん：2006/10/10(火) 02:30:57

VS2005で、純粋仮想関数を使った基本クラスをライブラリ（libファイル）に
し、その派生クラスと仮想関数をmainのあるところで書いてコンパイルしよ
うとすると、リンクエラーでリンクできません。解決方法はありますか？

781 ：デフォルトの名無しさん：2006/10/10(火) 07:32:18

>>780
それは普通は問題ないはずだけどな。
64bitコンパイラだけで起きる現象なら何かあるかもしれないが、
32bitでコンパイルしても同じ現象が出るようなら単なるコーディングミスだと思う。
答えが欲しいなら再現性のあるコードをアップしてみて。

782 ：デフォルトの名無しさん：2006/10/15(日) 00:19:06

ここで質問していいのかどうかよくわかりませんが、教えてください。
１テラバイトくらいのメモリを必要とするアプリを開発＆実行させたいのですが、
WindowsXP64bit版でVisual Studio 2005を使って開発したアプリは、1テラバイト
のメモリ空間を利用できますか？

783 ：デフォルトの名無しさん：2006/10/15(日) 00:37:19

メモリ空間は8TBのはず

784 ：デフォルトの名無しさん：2006/10/15(日) 00:40:15

>783
ありがとうございます。
そうすると、500GBのHDDを20台くらい使えば、8TB使うアプリを
ページングしながら動かすことはできますかね？

785 ：デフォルトの名無しさん：2006/10/15(日) 02:37:10

物理メモリを8TB積め

786 ：デフォルトの名無しさん：2006/10/15(日) 04:23:03

現在の６４ビットのPCサーバーで１６GBから６４GBくらいが最大搭載容量だからつらそ。

787 ：デフォルトの名無しさん：2006/10/15(日) 08:57:13

>786
ありがとうございます。
PCは64GB程度のメモリ搭載を想定しています。そこにページング用のHDDを
沢山乗せて、64bitのOSを使って数テラバイトのメモリ空間を使うアプリ
を動かしたいのです。現時点で、そういうことは可能でしょうか？
OSはwin,linuxなど何でもOKです。

788 ：デフォルトの名無しさん：2006/10/15(日) 09:24:44

動いても凄い遅そうだな。

789 ：デフォルトの名無しさん：2006/10/15(日) 12:16:38

一体何の処理をするんだ？

790 ：デフォルトの名無しさん：2006/10/15(日) 12:37:12

脳内だけで、釣りだろ。

791 ：デフォルトの名無しさん：2006/10/15(日) 18:23:01

>789
ええっと、ある種のシミュレーションです。
>790
釣りではありません。実際にやりたいのです。

792 ：デフォルトの名無しさん：2006/10/15(日) 18:28:26

クラスタとかとまた違うのか？
まあPCの性能限界に挑戦とかなら興味ないしどうでもいいけど。

793 ：デフォルトの名無しさん：2006/10/15(日) 18:46:23

>>791
本当に物理的に8TBもの場所にアクセスが必要なの？
必要なところだけポインタであれするとかできないのか。

本当に必要なら、どんなシミュレーションか気になるね。

794 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/10/15(日) 18:50:53

リニアアドレッシングさえ考えなければ32bitでも不可能じゃないと思う。

795 ：デフォルトの名無しさん：2006/10/15(日) 19:29:32

大規模って言うか壮大な計画がなら、豊富な資金を用意して、
ハード面は業者任せ（比較的安い価格で組む特注ハード）？だと思おうけどさ。
たいていは、数人のハッカー企業か大学の研究室で、予算ないんだろうな。
もし本当にやるつもりなら、人柱でヨロシク。
性能比較をHPで公開してよ。結果楽しみ…

796 ：デフォルトの名無しさん：2006/10/17(火) 23:43:02

できるものならクラスタリングした方が、、、

797 ：デフォルトの名無しさん：2006/10/18(水) 09:56:19

障害時の被害が凄そうなシステムだ

798 ：デフォルトの名無しさん：2006/10/18(水) 11:58:37

>>794

それを言ったら64bitのアドレッシング全否定じゃん
16bitだって可能

799 ：デフォルトの名無しさん：2006/10/18(水) 12:34:25

実際に搭載される物理メモリが増えたときの性能的利点のために今から64bitで作っておく
というのが多いんじゃないかな。

800 ：デフォルトの名無しさん：2006/10/18(水) 12:47:52

>>799 それを本腰で使うのはいつからだ？素人は黙ってろ。

801 ：デフォルトの名無しさん：2006/10/18(水) 12:49:13

>>800
馬鹿は黙っててくれ

802 ：デフォルトの名無しさん：2006/10/21(土) 05:15:26

ランダムアクセスの場合、ディスクはメモリの100万倍くらい遅いので、
64GBしかメモリがないのに、8TBあるつもりでアクセスしたら、
64GBあるつもりの場合の128倍じゃなくて128*100万=1億倍くらい遅く
なりそうだが、それでもいいんだろうか。

問題を分割して、メモリ64GBのマシンを128台用意して解いた方が
いいんじゃねえ？

803 ：デフォルトの名無しさん：2006/10/21(土) 05:43:11

スラッシングというやつだな。
アクセスを局所化しないで物理メモリより大きな仮想メモリを使うのは馬鹿

804 ：デフォルトの名無しさん：2006/10/21(土) 07:53:50

馬鹿にも使える64ビット電卓

805 ：デフォルトの名無しさん：2006/10/21(土) 08:50:34

スラッシングの意味違わない？

806 ：デフォルトの名無しさん：2006/10/21(土) 10:51:15

>>782
OSは何でもいいというんだからSolarisでもいいんだろう。
これ買え。1TB載るそうだから。
http://jp.sun.com/products/servers/highend/sunfire_e25k

807 ：デフォルトの名無しさん：2006/10/21(土) 13:05:36

>>802
アクセスパターン次第。完全にランダムなアクセスでない限りそういう単純計算の
程度よりは速くなるように設計されている。「100万倍遅い」というのも誰に聞いたか
知らんが不正確。とりあえずもうちょっと勉強しなさい。

>>806
物理メモリを1TB載せたいなんて話は誰もしてないと思う。

808 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/10/21(土) 15:53:50

アクセス速度と信頼性両立するならRAID0+RAID1でどーよ

809 ：デフォルトの名無しさん：2006/10/21(土) 20:38:25

>>807
でも素直にできるだけ物理メモリが沢山載るマシンを買った方が
賢いと思うぞ。

810 ：デフォルトの名無しさん：2006/10/21(土) 21:37:36

金があればそうだがTB越えだとメモリだけで億いくぜ。

811 ：デフォルトの名無しさん：2006/10/21(土) 22:08:50

>>809
賢いかどうかは微妙

812 ：デフォルトの名無しさん：2006/10/25(水) 11:28:02

782の本人ですけれど、
みなさんありがとうございます。
いろいろ参考になりました。Sunの1TBマシンは値段いくらかしりませんが
高くて買えないと思います。大規模なクラスタも予算、設置場所の点で
難しいです。ですので、64GBﾒﾓﾘくらいのSMPの8CPUくらいのマシン１台を
考えています。メモリアクセスは、ほとんどの場合ランダムではなく、
連続的に読み書きする場合が多いです。そいうい条件でも
ページングの影響でとても遅くなりますか？
たとえばdouble型8byteで1T個の配列を確保して合計8TB。
その1T個の配列を
for(i=1;i<1e12;i++){

813 ：デフォルトの名無しさん：2006/10/25(水) 11:29:37

すみません、手が滑って、途中で書き込んでしまいました。
続きです。
なんていう風にループで回すと、どれくらいの計算時間になりますかね？

814 ：デフォルトの名無しさん：2006/10/25(水) 11:38:41

ＰＣの寿命が先に尽きる希ガス

815 ：デフォルトの名無しさん：2006/10/25(水) 12:07:38

>>813
自分でやってみれ。いきなり１TBでテストする必要は無いんだぜ。
小規模なテストモデルを考えて、自前のPCで動かしてみれ。
問題を分割出来ていないのが問題化と。

816 ：デフォルトの名無しさん：2006/10/25(水) 14:31:30

>>812
100MBずつにループを分解してやれば、
32bitCPUのWinXPマシン＋大容量HDDで
できるんじゃないの？

817 ：デフォルトの名無しさん：2006/10/26(木) 00:10:21

それ以前にループにフロート使っちゃダメだろ

818 ：デフォルトの名無しさん：2006/10/26(木) 00:54:35

あ、気づかなかったｗ
1e12は整数の1000000000000のことだと思ったけど、
これは32bit整数じゃ表せない大きさだ。
floatではなおさらダメだがdoubleならできなくはない。

819 ：デフォルトの名無しさん：2006/10/26(木) 04:03:45

整数に収まるかどうかは問題ではない
i++で下位ビットが欠ける数値はカウンターには使えないだろ

820 ：デフォルトの名無しさん：2006/10/26(木) 04:35:59

それはi+=1.0とかにすればいいじゃん。
まあ、整数使え。

821 ：デフォルトの名無しさん：2006/10/26(木) 05:03:39

だから桁が増えるとi+=1.0が欠けると

822 ：デフォルトの名無しさん：2006/10/26(木) 05:53:39

>>821
doubleで1e12なら欠けない。
doubleは絶対値が2^53以下の整数を厳密に扱える。

823 ：デフォルトの名無しさん：2006/10/26(木) 06:07:35

せっかくの64bit CPUなんだから64bit整数使えばいいじゃない(ﾏﾘｰ
64bit CPUじゃなくても64bit整数は使えるけど無理やりスレタイに関連付けてみた

824 ：デフォルトの名無しさん：2006/10/30(月) 23:41:04

先日x64版Linuxに意味も無く移行した
自前のソースが全然コンパイルできなくて唖然とした
低スキルの素人プログラマだから自業自得なんだけど
閑話休題
おまえら！x86とx86_64でソース互換性を保ったままコーディングする方法について詳しく解説してる本とかサイト知ってたら教えてください
あ、言語はCです

825 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/10/30(月) 23:44:41

#include <emmintrin.h>

826 ：デフォルトの名無しさん：2006/10/30(月) 23:56:53

asmを使わない

827 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/10/31(火) 00:00:20

型の大きさの表現に即値は使わない

例：　sizeof (int *)

828 ：デフォルトの名無しさん：2006/10/31(火) 00:16:19

>>824
キャストは使わないｗ

829 ：デフォルトの名無しさん：2006/10/31(火) 01:09:04

ポインタ型を整数型にキャストするときにはintptr_t/uintptr_t。

830 ：824：2006/10/31(火) 02:32:09

>>825-829
みなさんの仰られていることでぐぐったらやるべきことが見えてきた気がします
あれこれ調べながら小さいものから書き直してみようと思います
曖昧な質問なのにアドバイスありがとうございました

831 ：デフォルトの名無しさん：2006/10/31(火) 04:23:05

とりあえずここ一通り目を通しとけ。
http://docs.sun.com/source/806-4836/conv_v9.html
http://docs.sun.com/app/docs/doc/819-0389?l=ja

Win64でもtypedef名等が違うだけで、基本的な考え方は同じ。

832 ：824：2006/10/31(火) 21:46:28

>>831
ありがとうございます
わかりやすくまとまっていてとても勉強になります
>>ALL
とりあえずmalloc()でsegmentation faultが出なくなりました！
この調子でマイペースに楽しみながらデバグしていこうと思います
本当にありがとうございました

833 ：デフォルトの名無しさん：2006/11/26(日) 02:14:35

Insure++やDevPartnerなど、ランタイムエラーを捉えるツールで、X86-64
のWindowsXP64ビットで使えるものってありますか？

834 ：デフォルトの名無しさん：2006/12/13(水) 01:20:52

ＦＦＦＴＰの６４ビット版つくってください

835 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/12/13(水) 01:26:19

あるじゃねーかｗｗｗｗｗ

836 ：デフォルトの名無しさん：2006/12/13(水) 01:35:42

MS-DOSの64bit版つくってください

837 ：デフォルトの名無しさん：2006/12/13(水) 01:44:55

64bitでネイティブ動作するテキスト置換ソフトは何を使ってる？

838 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/12/13(水) 02:12:02

テキスト置換なんか強いて64ビットでやる必要ねーだろ

839 ：デフォルトの名無しさん：2006/12/13(水) 02:15:10

64bitにすればなんでも速くなるとでも思ってるの？

840 ：デフォルトの名無しさん：2006/12/13(水) 13:12:51

おうよ！

841 ：デフォルトの名無しさん：2006/12/13(水) 13:13:37

数値が２倍なんだから２倍速くなければ公取が動きますよ

842 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/12/13(水) 21:46:27

あふぉや
SSE2のpcmpeqb使って並列比較したほうがまだマシ

843 ：デフォルトの名無しさん：2006/12/13(水) 22:34:13

>>835
あったっけ？＜ＦＦＦＴＰ６４ビット

844 ：デフォルトの名無しさん：2006/12/13(水) 22:43:54

メモリ帯域は変わらないよね？
全部64bitにすると全部32bitの場合の半分の個数しかデータ送れないんじゃないの？

あんまり詳しくないけど。
誰か教えて。

845 ：844：2006/12/14(木) 14:16:29

むむ。誰からも返事が無い。
自分の疑問は合ってるのかな。

846 ：デフォルトの名無しさん：2006/12/14(木) 16:58:05

>>844
64bit精度が必要なところ以外では
今まで通り32bit変数を使うから、
そういう心配はいらないのだ。

847 ：デフォルトの名無しさん：2006/12/14(木) 16:59:56

　　　　　　　　　　 ∩＿
　　　　　　　　　　〈〈〈　ヽ
　　　　　　　　　　〈⊃　　}
　　 ∩＿＿＿∩　 |　　 |
　　 | ノ　　　　　ヽ !　　 !
　　/　　●　　　● |　　/
　 |　　　　( _●_)　ミ／＜こいつ最高にアホ
　彡､　　　|∪|　　／
/　＿＿　ヽノ　/
(＿＿＿）　　　/

848 ：デフォルトの名無しさん：2006/12/14(木) 17:10:52

>>847
AAに同感するとは思わなかったが、同感だ。

849 ：デフォルトの名無しさん：2006/12/14(木) 17:33:15

俺も知らんけど、アホとか言ってないで説明できないの？

850 ：デフォルトの名無しさん：2006/12/14(木) 17:44:40

847がそうなのはわかったが、アホなのは844なのか846なのかはっきりしる。

851 ：デフォルトの名無しさん：2006/12/14(木) 19:29:54

どう考えても846

852 ：デフォルトの名無しさん：2006/12/14(木) 20:40:12

で、どうなの？

853 ：デフォルトの名無しさん：2006/12/14(木) 20:50:59

広い範囲のメモリをバンバン読み書きするタイプの処理の場合、
844の心配は現実になるよ

整数なら範囲がわかっていれば32bitにすることもできるけど
ポインタはそうはいかないんだよねえ

854 ：デフォルトの名無しさん：2006/12/14(木) 21:11:53

>>843
ソース公開されているんだから、自分で64ビット対応の修正すれば作れるのでは？

855 ：デフォルトの名無しさん：2006/12/14(木) 21:12:29

ポインタだけでキャッシュに収まらないほどの量になるの？

856 ：・∀・）っ-{}@{}@{}@ ◆DanGorION6 ：2006/12/14(木) 22:06:46

収まるか収まらないかの問題じゃない。
転送帯域が同じなのにデータサイズが増えるならそれだけでスループット落ちる。

あとは命令サイズの問題か。
imm64とかをうかつに使うと命令フェッチ帯域圧迫されるしREX使えばそれだけで命令長1バイト増える。
Core 2 Duoは4命令同時デコードに対して16byte/clkの命令フェッチ帯域しかないから32bitのほうが速いことも多いよ。

857 ：844：2006/12/15(金) 12:34:25

なるほど。みなさんありがとうございます。

858 ：デフォルトの名無しさん：2006/12/15(金) 21:13:10

>>856
理論的にはそうだが、自分で試した上での発言か?

859 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/12/15(金) 22:42:25

Pentium 4だと、レジスタ増えてるのにスループット全く変わらなかった。
SIMD演算ユニットの割にロード・ストアのスループットが良すぎるから
レジスタ数の増加程度で性能は伸びない。

従来型アーキテクチャだとデコード前の命令長の影響はもろに受けるからね。
Core 2 Duoで4 IPCが3 IPC前後に落ちる現象も知ってる。

ロード・ストアの頻度の多いプログラムでレジスタの増分性能が改善されたり、
あと4GB以上のメモリ空間が必要な処理なら十分性能出せるんじゃないかと。

つかね、ただパフォーマンスを上げるだけなら、現状、SIMD使った方がいい。

860 ：デフォルトの名無しさん：2006/12/15(金) 23:39:55

別に排他的なもんじゃあるまい＞SIMDと64bit

861 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/12/16(土) 00:44:16

そうだけど、別にSSEが128bitから256bitになるわけじゃないだろ？

64ビットは32bitが2個分だから性能が上がる、とか言う前に、まずSIMD使えって言いたいの。
SIMD命令なら各要素ごとにラップアラウンドしたり飽和処理したりするのが簡単にできるわけで。

現状、SIMDを多用するときは、汎用レジスタセットはデータのアドレス計算やループカウント、
あと細かいスカラの演算くらいにしか使わないんだよね。
汎用←→XMMレジスタ間の転送はmovd(32bit)やpinsrw/pextrw(16bit)くらいだし。

強いて言えばIA32→x64でレジスタ数の増加くらいの恩恵はあるけど、REXプレフィックスは
命令サイズを増大させるので、先に指摘した問題がある。
あと、レジスタが増えた分だけ待避・復帰処理の時間が増える。

862 ：デフォルトの名無しさん：2006/12/16(土) 00:54:02

つか、64bitの利点はデータの幅じゃなくてアドレスの幅だべさ。
64bit整数なんて32bit環境でも普通に使えるべ。

863 ：デフォルトの名無しさん：2006/12/16(土) 07:34:10

SIMDを多用して速度が向上するような処理は
REXプレフィックスの足かせよりレジスタ数増加の恩恵の方が大きいと思う。

864 ：デフォルトの名無しさん：2006/12/16(土) 12:07:32

long long intを32bit環境でやると、遅いと言うより使いづらい。
配列なんて確保したら、殆どの場合セグメントフォルトだし

865 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/12/16(土) 13:39:46

まあ、Athlon64なんかは64bit ALU×3、64bit SIMD ALU×2（128bitは64bit2回に分割実行）
だから、それほど性能良くない。
Core 2なんかは64bit ALU ×3、128bit SIMD ALU×3だから、大量データ処理には
完全にSIMDのほうが優位。

866 ：デフォルトの名無しさん：2006/12/16(土) 13:41:47

>>864
なんでやねん

867 ：デフォルトの名無しさん：2006/12/16(土) 13:49:48

>>865
ダンゴリオンさんは、いろいろ書いてくれてるけど知識だけじゃなくて、
SIMD使ってとりわけ速くなる様なコーディング経験があったってことなん？

868 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/12/16(土) 14:10:11

いちおう有るには有る。64bitのほうはまだ世に出してないが
Core 2のSIMD整数モンスターぶりがよくわかるのは個人で出してる

869 ：デフォルトの名無しさん：2006/12/16(土) 17:31:28

>>868
それ見たい。

870 ：・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 ：2006/12/16(土) 18:13:12

おいらのサイト
ttp://tripper.kousaku.in/

John the Ripperのビルドなら自分で試してみるのも良いかなと

871 ：869：2006/12/16(土) 18:48:53

>>870
ありがとう。すごいなぁ。

872 ：867：2006/12/16(土) 20:23:29

>>870
ちらっと拝見しましたよ。NANDとNORを追加とかアセンブラ書きの人の言やねw

873 ：デフォルトの名無しさん：2006/12/30(土) 21:34:35

>>824
遅レスだが、この人に聞けばいいヒントが見つかるかもしれない
ttp://pc9.2ch.net/test/read.cgi/notepc/1160039483/404

874 ：デフォルトの名無しさん：2007/01/29(月) 00:26:58

>>854
作者に無断で改変して配布するわけには　いかんだろ

875 ：デフォルトの名無しさん：2007/01/29(月) 00:43:44

>>874
フリーソフトなのにそんな変なライセンスなの？

876 ：デフォルトの名無しさん：2007/01/29(月) 00:44:04

別に修正ＢＳＤライセンスなんだからいいんでねーの。

877 ：デフォルトの名無しさん：2007/01/29(月) 11:09:28

俗に言う64bitCPUというのは何をもって64bitなのですか？
CPUからにょろっとでてる配線の数が64本だから？
ポインターの大きさが８バイトだから？

878 ：￣￣￣￣￣∨￣￣￣￣￣￣：2007/01/29(月) 11:35:01

　┌┐.┌i　　 ┌┐　　__　┌┐　　| | [][]
　｜└[][]L.ﾛﾛ |　[][]　|　| ﾛﾛ |.[][] l└─┐
　｜┌┤.r‐┘│┌┘ | └┐└─┐l￣￣
　└┘..凵　　 └┘　　!　l￣__l￣￣.┘　　ﾞ!!
　　　　　　　　　　　 └┘
　　　　　　　　　　　　 ∧＿∧　　　　!
　　　　　　　　　　　　（　＾∀＾）
　　　　(　　;;　　　　　⊂　　　）⊃
　　　(　(　　;(　;;　;　０爻爻爻０

879 ：デフォルトの名無しさん：2007/01/29(月) 14:24:39

汎用レジスタのサイズじゃね？

880 ：デフォルトの名無しさん：2007/01/29(月) 19:56:50

バス幅が64bitとか、
32bitが2つで64bit級とか。

881 ：デフォルトの名無しさん：2007/01/29(月) 20:08:47

サターンを彷彿とさせるなぁ

882 ：デフォルトの名無しさん：2007/01/29(月) 20:18:59

64bit Windowsのユーザーアドレス空間が
0x10000 - 0x0000 07FF FFFE FFFF x64
0x10000 - 0x0000 06FB FFFE FFFF itanium
こうなってるとか見たことがある。
CPUとしては倍の16TBくらいなのかな？

883 ：デフォルトの名無しさん：2007/02/01(木) 01:53:56

バス幅が64ビットというと。
Pentium以後のIntelCPU全て、ソケ5・7系以後とか、
PowerPC601以後のPowerPCの大半が該当するな。

なんと、PC用CPUは、10年以上前から64ビットばかりだったって事になってしまう。

32ビットが2つで64ビット級...ならば。
CoreDuo、 Core2Duo、 PenttiumDあたりは64ビットってことか
Athlon64 x2は128ビット級ってわけか?

884 ：デフォルトの名無しさん：2007/02/01(木) 01:55:36

32bitからいきなり64bitなんてやりすぎだろ。まずは40bitくらいを目指すべきではないのか？

885 ：デフォルトの名無しさん：2007/02/01(木) 02:29:02

アドレスバスとデータバスを混ぜるのは良くないですよ。

886 ：デフォルトの名無しさん：2007/02/01(木) 07:06:43

>>884
現時点では48bitくらいしか使われてなくて残りは予約されてなかったっけ?

887 ：デフォルトの名無しさん：2007/02/01(木) 12:38:02

今のプログラムはいわゆるタイニーメモリモデルだから
スモールメモリモデルにすれば8GB
ラージメモリモデルなら1024GBまでいけるな。

888 ：デフォルトの名無しさん：2007/02/01(木) 13:29:08

ナツカシス

889 ：デフォルトの名無しさん：2007/02/08(木) 14:08:53

このスレをざっと見てみたけど
float と double は32ビットから64ビットに移行しても
メモリ中に占めるサイズは変わらないってことですよね？

890 ：デフォルトの名無しさん：2007/02/08(木) 21:53:33

流石にそれが変わったら大騒ぎｗ

891 ：デフォルトの名無しさん：2007/02/09(金) 06:40:20

>>889
浮動小数点演算の場合はIEEE 754という縛りがあるんで、
単純にCPUの処理ビット幅が増えたからといってそのまま大きくするわけにもいかない。

892 ：デフォルトの名無しさん：2007/02/09(金) 18:16:13

>>890-891
ありがとうございます。

893 ：デフォルトの名無しさん：2007/02/09(金) 20:31:04

レジスタ幅(内部計算精度)がx87は80bitで、x86-64はSSE 64bitという違いがあるな。

894 ：デフォルトの名無しさん：2007/02/09(金) 22:20:57

>>893
確かにx86-64だと80bit精度にはならないが、
それだとCで同じコードを書いても結果が異なるということになる。
元からdoubleは内部も64bitじゃなかったっけ？

895 ：デフォルトの名無しさん：2007/02/09(金) 22:27:15

中間結果の精度が高いために結果が異なる場合がある。
もっとも64bitでなくても今はSSEのほうが速いので、いずれx87は廃れる運命だろう。

896 ：デフォルトの名無しさん：2007/02/09(金) 22:52:49

結果が異なってもいい規格なのか。どうも。
まあ、今どきレジスタがスタック形式はないよな。

897 ：デフォルトの名無しさん：2007/02/09(金) 22:55:48

浮動小数点は、定数のたたみ込み具合で値が変わるという話があったな。

898 ：デフォルトの名無しさん：2007/02/10(土) 21:31:52

Javaで問題になったねえ・・・どう決着したんだっけ

899 ：デフォルトの名無しさん：2007/02/11(日) 01:06:55

つ http://www.shudo.net/publications/NASDA-200212/

900 ：デフォルトの名無しさん：2007/03/05(月) 13:12:19

WindowsXP x64 で正常動作する2chブラウザつくってください

ちなみにVC6で書かれている２ｃｈブラウザ（ソースつき）
Ya2b
(Yet Another 2ch Browser)
http://www.geocities.co.jp/SiliconValley-Sunnyvale/1375/

ギコブラウザ（ソースあり）
http://gicko999.hp.infoseek.co.jp/

901 ：デフォルトの名無しさん：2007/03/05(月) 13:13:40

x86版はXP x64で正常動作しないの？

902 ：デフォルトの名無しさん：2007/03/05(月) 13:16:09

>900それくらい自分でやれよ

903 ：デフォルトの名無しさん：2007/03/05(月) 17:02:23

つ V2C

904 ：デフォルトの名無しさん：2007/03/07(水) 00:24:05

>>901
win32api つかってるからアウト
delphiで書かれたモノはアウト
まぁjava(v2c)もいいけど
x64対応があってもイイわな

905 ：デフォルトの名無しさん：2007/03/07(水) 00:30:55

win32apiを使ってることはx64 Editionで動かない理由にはならないだろ。
Delphiで書かれたWin32用アプリってx64 Editionで動かないの？
何か大きな勘違いをしてないか？

906 ：デフォルトの名無しさん：2007/03/07(水) 00:32:30

2chブラウザは大量メモリが必要なわけでもなく、高速な処理が必用なわけでもない。
64bit化することに全く意味がない。

907 ：デフォルトの名無しさん：2007/03/07(水) 00:38:35

きっと64bit化しないと64bit OSで動かない（または遅くなる）と思ってるんでしょ

908 ：デフォルトの名無しさん：2007/03/07(水) 00:38:47

OKわかった。とりあえず開発機材よこせ。

909 ：デフォルトの名無しさん：2007/03/07(水) 00:43:29

自作板の64bit版2chブラウザスレ、厨房大杉でﾜﾛｽ

910 ：デフォルトの名無しさん：2007/03/07(水) 01:18:14

過去ログ検索だったら分からんでもないが
それでも個人用途なら64bitは要らんだろうなあ

911 ：デフォルトの名無しさん：2007/03/07(水) 01:33:06

オンメモリに2chの過去ログ全部のてみせます！
推奨メモリ・２５６GB

912 ：デフォルトの名無しさん：2007/03/07(水) 01:35:30

発端が>>900だからなぁ、とてもそういうものを望んでるとは思えん。

913 ：デフォルトの名無しさん：2007/03/07(水) 01:42:54

winの64bit版は32bitアプリ動かないのか

914 ：デフォルトの名無しさん：2007/03/07(水) 01:51:45

まさか

915 ：デフォルトの名無しさん：2007/03/07(水) 01:55:08

夜釣りご苦労様です。

916 ：デフォルトの名無しさん：2007/03/07(水) 01:57:10

６４ｂｉｔて死滅しちゃうの？

917 ：デフォルトの名無しさん：2007/03/07(水) 02:00:18

32bitからいきなり64bitなんて無茶するからだよ。
とりあえず34bitくらいから順に上げていくのが良いのではないか？

918 ：デフォルトの名無しさん：2007/03/07(水) 02:03:08

何をどうしたらそういう発言ができるのかわからん

919 ：デフォルトの名無しさん：2007/03/07(水) 02:03:31

あれあれ？いいんですか？
セグメントモデル復活させますよ？

920 ：デフォルトの名無しさん：2007/03/07(水) 02:06:43

IA-64では復活したと聞いた

921 ：デフォルトの名無しさん：2007/03/07(水) 02:08:30

そもそも多重仮想記憶やPAEはセグメントと言えないこともないな

922 ：デフォルトの名無しさん：2007/03/07(水) 02:09:14

祝！FARポインタ(16+32bit)復活。

923 ：デフォルトの名無しさん：2007/03/07(水) 02:10:22

これからやるなら64bit+64bitにしてください

924 ：デフォルトの名無しさん：2007/03/07(水) 05:08:25

IA-64のポインタは一種のFARポインタだよ。
Win16の時代と違ってコンパイラが完璧に隠蔽してるだけで
参考:
http://msdn.microsoft.com/msdnmag/issues/1100/hood/

925 ：デフォルトの名無しさん：2007/03/07(水) 18:02:37

>>924
セグメントレジスタというより基底レジスタに近い感じだな。
41bit/1命令 x 3命令 + 5bit ということは命令として直に指定できる値が限られるわけだ。
IBM S/360のアセンブリに似ている・・・

926 ：・∀・）っ-{}@{}@{}@：2007/03/07(水) 21:11:34

RISCなどの固定長命令型アーキはみんなそうだよ

927 ：デフォルトの名無しさん：2007/03/07(水) 23:05:26

むしろx86が特殊
「特殊」なもののシェアが大きすぎてそっちが標準的に見えてしまうけど
http://blogs.msdn.com/oldnewthing/archive/2004/09/14/229387.aspx

928 ：デフォルトの名無しさん：2007/03/07(水) 23:28:57

x64の直値代入だと命令長が80bitさすがに弊害が見える。
  0004e 48 b9 00 e8 76
    48 17 00 00 00   mov     rcx, 100000000000  ; 000000174876e800H
  00058 48 03 c1     add     rax, rcx

929 ：デフォルトの名無しさん：2007/03/07(水) 23:32:58

IA-64は2バンドル使って64bit即値代入してるな

930 ：デフォルトの名無しさん：2007/03/08(木) 00:16:43

>>928
多少の非効率は押してでもx86からの以降のしやすさを狙ったのがx64だからね

931 ：デフォルトの名無しさん：2007/03/09(金) 02:20:59

>>913
win32apiで組んだものは動かないのが多いよ
WoWはアテにならない

932 ：デフォルトの名無しさん：2007/03/09(金) 02:21:29

またテキトーなことを

933 ：・∀・）っ-○◎●：2007/03/09(金) 02:22:33

乞食がこっちのスレに戻ってきたか

934 ：デフォルトの名無しさん：2007/03/09(金) 02:45:12

x64で動かすためにはポータブルメソッドで書き直さないとダメだろう