トップページ⇒tech
1001コメント278KB

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

レス数が1000を超えています。これ以上書き込みはできません。
0001 ◆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
0002デフォルトの名無しさん2005/07/21(木) 14:30:01
２げと
0003デフォルトの名無しさん2005/07/21(木) 14:34:35
>>前997
画像処理系か…確かにそうだね。データベースやエンコ以外
だとこの辺が筆頭か。

でもこれは論理アドレスより物理アドレスがほしいアプリじゃね？
0004デフォルトの名無しさん2005/07/21(木) 14:35:22
>>1
スレたて乙
0005 ◆TimpoiKAMI 2005/07/21(木) 14:36:31
前スレ>990
64ビットでLoadされたら上位Qは無視もしくは不定で回るような
メカニズムになっていればちょっとは違ったかもしれんが

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

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

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

漏れ的には、ファイルことごとくmmapのような富豪プログラミングができるのが楽しげ。
0006デフォルトの名無しさん2005/07/21(木) 14:41:49
＞富豪プログラミング
楽になるのはメリットのひとつだが、おれとしちゃ何か
ブレークスルーが欲しい。64bitマシンじゃなきゃ絶対
できなくて、尚且つ誰もが使いたくなるアプリや
プログラミングの新しい技法。
0007デフォルトの名無しさん2005/07/21(木) 14:48:39
32bitマシンで絶対できないのはテラ級のメモリ搭載だから、
今後64bitマシンで果たしてそういうことをするときがくるのか。
それをして何か違う世界が開けないのか
0008デフォルトの名無しさん2005/07/21(木) 14:51:21
普通に考えて自然言語処理とかのAI系だろうね
DB系の延長線上の技術が土台になるだろうけど
0009デフォルトの名無しさん2005/07/21(木) 14:55:42
>>3
この辺見ると三次元CADはメモリ32GBですらローエンドらしいよ
http://pc8.2ch.net/test/read.cgi/os/1093549944/413
0010デフォルトの名無しさん2005/07/21(木) 14:56:11
音声認識とかの精度もメモリの桁が上がれば使い物に
なるのだろうか？
0011デフォルトの名無しさん2005/07/21(木) 14:59:11
>>10
音だけから分析するのには限界があるよ
人間はシチュエーションとか把握して意味から音を補完したりしてるから
コンピュータで真似しようとするとやっぱりAI系の技術に依存する
結局、意味まで把握する自然言語処理が進展しないと
音声認識やら機械翻訳やらのブレークスルーはない
0012デフォルトの名無しさん2005/07/21(木) 15:06:16
自然言語の進展する余地はメモリ増大によってあるんかえ？

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

じっさいそのスパコンつかったのがどんくらいのレベルか
ぜんぜん知らんのだが。
0013デフォルトの名無しさん2005/07/21(木) 15:09:26
>>12
最先端のスパコンがどれくらいのレベルかは知らないけど、
実装はぶっちゃけDBの延長線上だから
そういうのを実用的な速度で動かすには
物量作戦でオンメモリでさばける情報量が多いほど有利ではある。
まあ将棋とか囲碁とかも原理的には同じかな。
0014デフォルトの名無しさん2005/07/21(木) 15:15:36
>>11
OCRなんかも似たような状況だね。
0015デフォルトの名無しさん2005/07/21(木) 15:16:44
どうも巨大DBオンメモリが今後の鍵になりそうなﾖｶﾝ

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

単に情報量とマシン性能の違いなんだろうか
0016デフォルトの名無しさん2005/07/21(木) 15:16:52
>>3
物理シミュレーションとかの計算
0017デフォルトの名無しさん2005/07/21(木) 15:20:32
>>15
翻訳は知らないけどチェスの世界王者に勝ったやつは
専用のコプロみたいなのを大量に並列で動かしてたはず。
そういうのがないと実用的な演算速度が得られないとすれば
メモリだけでなくCPUの方も超並列にする必要がある。
CELLなんかはそういう技術を民生化しようとする方向性ではないかと。
0018デフォルトの名無しさん2005/07/21(木) 15:21:56
前スレの>>989へ
あの話は今64bit化で有効なアプリを作ると言う例のイベント前提の話だから
そんな空想の話してもしょうがないんですよ。
実装の話になると、物理メモリを無視できないでしょ？
0019デフォルトの名無しさん2005/07/21(木) 15:52:00
>前スレ982
SSEは浮動小数点で遅いから当然ダメだけど
XMMXはMMXの１割引くらいの性能で普通に回るよ。速いこともあるし。

128bitが原理的に長すぎるというケースは除いて、
今後のCPUじゃXMMXが負けることはないと思うが、どうか。
そもそも、64bitに対応してないPenMで遅いのは構わないわけで。
0020デフォルトの名無しさん2005/07/21(木) 15:53:50
物理計算、自然言語処理、巨大データベース

家庭用に普及させるロボットの頭脳になら無いだろうか？
そうなるとx64とかいう話にはならないかも知れないが、
頭脳はパソコンにあって胴体と無線通信しても面白いな
0021デフォルトの名無しさん2005/07/21(木) 15:56:32
>>19
例えばブラウザ内で動く画像アプリをActiveXで実装したとする。
高速化のコードが32bitと64bitで共通に出来ないのは痛いんだ罠
0022デフォルトの名無しさん2005/07/21(木) 16:05:51
>>21
命令が減る弊害か。同じコード書けばいいんだけど
実際やってみると面倒くさいんだ罠。

今日は人が多いな。
0023デフォルトの名無しさん2005/07/21(木) 16:08:09
>>20
> 家庭用に普及させるロボットの頭脳になら無いだろうか？
最終的にはそういう方向が出てくるとは思う。
ASIMOに代表されるように日本人はロボット大好きだし。

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

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

自然言語処理とかの分野もそんな感じで浸透するんじゃないかと。
0024デフォルトの名無しさん2005/07/21(木) 16:19:23
64bit環境になるとやっぱり32bit演算の方が遅くなったりするの？
0025デフォルトの名無しさん2005/07/21(木) 17:12:29
というより、MMXが無いとか、_asmが出来ないとか、別の意味で
当面64bitアプリの方が遅いﾖｶﾝ。32bitの演算自体は気にする
ほどの差は無いか、むしろ速いんじゃない？　特に掛け算割り算

あ、タコプログラムなら64bitにした方が速いってｗ
0026デフォルトの名無しさん2005/07/21(木) 17:16:01
つーか、最近のコンパイラ優秀だから
普通の人が下手にアセンブリで書くよりずっとレベル高いコード吐くぞ？
可読性は確かに人手で書いたほうが上がるけど。

お前らいつの時代のコンパイラ使ってんだよ
0027デフォルトの名無しさん2005/07/21(木) 17:17:36
ｺﾞﾒﾝ普通の人じゃないんだよｗ
使ってるのは最新コンパイラ　ｂｙ　最適化厨より
0028デフォルトの名無しさん2005/07/21(木) 17:29:24
そこまでいかずとも、マトモな普通の人なら
使いどころをわきまえて高速化できると思う。

特にSIMDなら人間が直に書く表現力は強い。
0029デフォルトの名無しさん2005/07/21(木) 17:36:07
でも普通の人じゃないオレでも最初に書いたSIMDは
Cの通常コード内の最適化に負けるよ。勝負はそこからだ！
0030デフォルトの名無しさん2005/07/21(木) 17:53:09
そういえば俺も最初は負けたな。何でだろう。
コードを保存しておけばよかったよ。
0031前スレ990,9922005/07/21(木) 18:59:58
>>得ろ屋ｸﾝ
スレ立て乙
で、まさかAltiVecみたいにユニットを全128ビットにでもしろと言うかね？(苦笑
どうせ現状整数も64ビット(×2)までの精度しか使わないんだからMMXニコイチ＋μOPs-fusionで当分は十分使える気もするけどね。
いっそ64ビット汎用ALUと兼用化してコア単体の縮小化を進め、マルチコアで性能稼ぐ手もアリじゃん？
いや、SSEを作った張本人のIntelがそんな路線の気がしてね。
0032デフォルトの名無しさん2005/07/21(木) 19:06:43
＞何でだろう
コンパイラの最適化もCPUの通常コードの実行速度も
馬鹿じゃないってことだ罠。普通の人が素直に組んだ
くらいじゃまず勝てねーよ（変なストールありまくなの
も一因）
0033デフォルトの名無しさん2005/07/21(木) 19:26:45
VecCやICCなら自動SIMD化使えるし組み込み関数が使えるじゃん。
SSEが使えない訳じゃあるまいし。
おﾌﾟやアスロン64でSSEﾌｭｰｼﾞｮﾝがサポートされるだけでも状況は変わるﾊｽﾞ
アスロン系のMMXはあの少ないレジスタで依存関係の引き延ばしをやらなきゃ
ならないから、ある意味使いにくい
SSEだとパイプラインの内部効率悪いしね
0034デフォルトの名無しさん2005/07/21(木) 19:56:39
＞SSEが使えない訳じゃあるまいし。
＞SSEだとパイプラインの内部効率悪いしね

SSEを押してるのか逆なのかﾜｶﾝﾈ
0035デフォルトの名無しさん2005/07/21(木) 21:00:21
>>1==得ろ屋ｸﾝ?
0036デフォルトの名無しさん2005/07/22(金) 10:16:56
バードショップ
0037デフォルトの名無しさん2005/07/22(金) 11:19:30
遅レスだが、スパコンの並列処理とCELLはまったく
思想が違う。

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

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

スパコンなんかの並列処理はバスを共有して汎用的
な処理を並列で動かすものでしょ。
0038デフォルトの名無しさん2005/07/22(金) 11:25:27
>>37
スパコン汎用ではなくDeep Blueのカスタムチップを引き合いに出したものかと。
0039デフォルトの名無しさん2005/07/22(金) 12:00:33
>>37
「スパコン」と一括りにするのはいかがなものか。いろんなタイプがあるべ。
0040デフォルトの名無しさん2005/07/22(金) 15:02:53
>>37
おまえの御託よりもたるさんのHPのほうが使える。
0041デフォルトの名無しさん2005/07/22(金) 16:27:04
直列でちょっぱやがベスト
0042デフォルトの名無しさん2005/07/22(金) 16:29:46
並列を活かすのはそう組まんといけないからなあ…
速度目的と、どうしてもそうしないといけない場合は
仕方なしにやってるが
0043デフォルトの名無しさん2005/07/22(金) 16:36:42
ILPよりはTLPのが幾分か楽なのも確かだ。
0044デフォルトの名無しさん2005/07/22(金) 17:02:03
>>43
CPUはそうだろうけど、プログラマからは直列に組む方が楽だろ？
0045デフォルトの名無しさん2005/07/22(金) 17:10:11
ILPが直列なわけないし
演算の畳み込みとか余分なこと考えなくちゃならないよりは、ループの中身を分割して並列処理させたほうが楽ぽ

本当に直列で組んでて性能が出てくれるのはPentium 4かな。
整数演算のレイテンシ0.5だし。
（もちろん落とし穴もあるが）
0046デフォルトの名無しさん2005/07/22(金) 17:30:37
いやそうじゃなくて、直列に組んで速い方が嬉しいでしょ？
0047デフォルトの名無しさん2005/07/22(金) 17:47:40
>>45
スーパースケーラとはとても言えないアーキ
0048デフォルトの名無しさん2005/07/22(金) 17:50:49
もともと並列に計算可能な分野(分散処理向きなもの)を除けば、

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

で、
アルゴリズム＝直列、インストラクション＝直列、実行＝並列、という思想がスーパースケーラで
アルゴリズム＝直列、インストラクション＝並列、実行＝並列、という思想がVLIW
なわけだが、現実はなかなか。
0049デフォルトの名無しさん2005/07/22(金) 18:35:48
昔はスパコン=ベクトルプロセッサだったんだけどなぁ。

0050デフォルトの名無しさん2005/07/22(金) 19:10:50
>>1
何、山田？
0051デフォルトの名無しさん2005/07/22(金) 19:28:34
やはりご家庭用に64bitは需要が無いらしいな。
OSが3D-GUIになって立体テクスチャを山のように
使い始めるとかしなければ、消えちゃうんじゃないの？
0052デフォルトの名無しさん2005/07/22(金) 19:46:43
まあ、それこそSIMDでやるべき領域なんだけどな。
うまくシフトやビット演算駆使してもSSEのがまだ速いという落ちになりそう。

でも近々アドレス空間は必要になるでしょ。もうPCでメインメモリ１GB、2GBとか普通なんだから。
それ以上の物理メモリ使うのにPAEだけは使いたくない。
0053デフォルトの名無しさん2005/07/22(金) 20:13:40
もっと速い段階で64ビット化されてればなぁ。

メモリよりもファイルやファイルフォーマットの2GBや4GBの制限のほうが先にネックになったよね。
そういうプログラムやフォーマットが作られた時点で64ビットが普及していればなぁ・・・。
0054デフォルトの名無しさん2005/07/22(金) 20:15:23
テスト環境として、qemuかbochsを用いて、ホストがWin2000かXPでゲストにXP x64 Editionを用意したいのですが、
初めて向けに一から設定を説明してあるサイトって在りますか？
あったら教えて。
0055デフォルトの名無しさん2005/07/22(金) 20:30:30
情報は何ももってないんだが、
QEMUもbochsも、x64エミュレーションに対応してるんだね。今調べてはじめて知った。

0056デフォルトの名無しさん2005/07/22(金) 20:36:20
>>53
ファイルサイズの限界はCPUのビット数とは関係ないけどな。
16ビットCPUだからといってファイルサイズが
64Kに制限されていたわけじゃないし。
0057デフォルトの名無しさん2005/07/22(金) 20:50:20
＞でも近々アドレス空間は必要になるでしょ。
ほんとにそう思う？

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

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

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

まあPC供給元が64bitマシンしか作らなくなったら
徐々に変わっていくだろうけど。
0058デフォルトの名無しさん2005/07/22(金) 20:50:30
関係あるよ。

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

当時は
32ビットのCPUで、64ビットのAPIやフォーマットにすると、
オーバーヘッドが無視できなかったから。
0059デフォルトの名無しさん2005/07/22(金) 20:57:46
現状64bitマシンで32bitマシンと物理メモリ量が違わないのが
問題だという人がいたけど、俺はもっと別の問題があると思う

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

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

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

１GB走査するのに0.1秒だったら100GB走査するのに10秒だ。
リソースを豪華にしようとデータを搭載メモリに見合って豪華に
しても、プログラムの動作速度を決定する部分が一緒に100倍
にならないと活かしきれないと思う。
0060デフォルトの名無しさん2005/07/22(金) 21:19:00
16bit->32bit
640KB->4GB
10MHz->3GHz
bus:?->800MHz
バランスよく進化したと思う

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

量子ｺﾝﾋﾟｭｰﾀ？？
0061デフォルトの名無しさん2005/07/22(金) 22:01:54
>>58
APIはともかく、ファイルシステムが扱える最大ファイルサイズは、
歴史的にはCPUのアーキテクチャよりも、そのファイルシステムが
開発された頃の一般的なストレージデバイスのサイズとの関連の
方が大きいように見える。

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

64bit PCになったから、これを51ビット位まで拡張しようという動きも
無い様だし・・
0062デフォルトの名無しさん2005/07/22(金) 22:21:28
64bitはでかいファイルを簡単にmmapして扱えるだけでもメリットあると思うけどな。
OSがタコでなければだけど。
0063デフォルトの名無しさん2005/07/22(金) 22:40:14
mmapして何やりたいのか例をｷﾎﾞﾝ
0064デフォルトの名無しさん2005/07/22(金) 22:42:10
>>59
現在の Intel式に FSB を通すと確かにそうなるけど、
AMD が SMP マシンでやってるみたいにプロセッサ
ごとにメモリバスが出てる方式なら、クロックを
変えずにメモリ帯域も増やせるのでは？
(SMP じゃなくて ccNUMA になるって話ね)
Rambus みたいにメモリバス幅を狭くして、チップ内の
マルチコアそれぞれからメモリバスを引き出すように
なるんじゃない？
メモリモジュール64個ってわけにはいかないから、
一つのモジュールから、複数のメモリバスを出すと。
0065デフォルトの名無しさん2005/07/22(金) 23:01:01
>>64
もっとイメージ的な話で考えてます。あえて例を出すなら
現在のマシン：２Dテクスチャをリアルタイムでモーフィング：速度容量ともつりあってる

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

速度もつりあって上がらないと駄目じゃないのってことです。
0066デフォルトの名無しさん2005/07/23(土) 01:19:01
演算能力という意味では、今後はクロックの上昇率よりもコア数
の上昇率の方が比重が高いんじゃないの？ メモリが64倍あっても、
コアが64個あって分割して処理すれば、O(N) 以下のアルゴリズム
は問題ない。
0067?デフォルトの名無しさん2005/07/23(土) 07:58:47
>>63
データベース以外では画像処理関係でレイアウトスキャナーとか美味しそうだな。
同じような理由で高解像度のマッピングを多用するCGにもいいだろう。
個人的にイイと思うことは上のどれでもないが、そっちは教えない。

0068デフォルトの名無しさん2005/07/23(土) 09:12:57
>>66
ますます並列プログラミングの時代かねえ
クロック100倍は非現実的だけど、コア64個はどうなんだろ？
民生機として考えると、ぴんとこないのは五十歩百歩…
0069デフォルトの名無しさん2005/07/23(土) 10:13:17
っていうかマジでＭＭＸフッカツ希望
0070デフォルトの名無しさん2005/07/23(土) 10:38:14
WOW64は完璧100％32bit互換モードと考えていいの？
32bitマシン上でのWOWはかなり動かなくなる16bitアプリ
あったけど。

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

ガソリンエンジンで十分な乗り物にジェットエンジン積もう
とは思わないのと同じ（今の64bitがジェットかは微妙だが）
0071デフォルトの名無しさん2005/07/23(土) 10:53:36
Win32なドライバをインストールするようなものは駄目。
0072デフォルトの名無しさん2005/07/23(土) 11:25:01
>>71
それ以外は注意する点なし？
0073デフォルトの名無しさん2005/07/23(土) 11:37:32
>>68
将来的にはコア64個なら現実的だと思う（だいぶ先だが）。
ただ、そうなったときに、原理的に並列化できない（しにくい）タイプの
プログラムの性能が置いていかれる。
ちょっと悲しい。
0074デフォルトの名無しさん2005/07/23(土) 11:47:32
＞原理的に並列化できない（しにくい）タイプ
そういうアプリって言い換えると32bitで十分じゃないか？
0075デフォルトの名無しさん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
0076デフォルトの名無しさん2005/07/23(土) 12:17:48
>>74
そうかも知れないけど、コア数の話だから関係ないだろ。
・・・ってスレ違いってことか。ｽﾏｿ
0077デフォルトの名無しさん2005/07/23(土) 12:35:03
>>74
スレッドによる並列化と64bit化の恩恵とはあまり関係が無いんじゃないか？
0078デフォルトの名無しさん2005/07/23(土) 12:55:19
>>77
まあそれ言っちゃうと、x64でレジスタ倍増とかのうたい文句も
別の話になっちゃうしねえ。

スレッドというよりマルチコアとかでの並列プログラミングが
本格的に普及するのも64bitへの変更が皮切りになるんじゃ
ないか？
0079デフォルトの名無しさん2005/07/23(土) 12:55:33
>>77
クロックが頭打ちだからこれからはコア数を増やすしかない状況を言ってると思う。
どうせ数年すればエントリーモデルですらデュアルコア64bitになってるだろうし。
0080デフォルトの名無しさん2005/07/23(土) 13:13:05
64bit化ってだんだんに進むよね。
すでにデスクトップはほとんど64bitだけど、来年のYonahでも32bitだし。
32bitを切り捨てられる日は遠いなあ。
0081デフォルトの名無しさん2005/07/23(土) 13:34:29
メモリアクセスって、2GB/secくらい?
したら、16GBメモリを積んだら、ゼロクリアするだけで8秒かかるのか・・・。
0082デフォルトの名無しさん2005/07/23(土) 13:41:45
movntqとか使うと理論帯域に近いストアが出るべ。
DDR2なら3～4GB/secいけるだろう。

ただ、スピードより容量の進歩が速いので、
ゼロクリアの時間はだんだん長くなってきたねえ。
0083デフォルトの名無しさん2005/07/23(土) 13:52:50
＞DDR2なら3～4GB/sec
このくらいのメモリの幅を使うアプリの起動時間だと、
どのくらいかかるんだろうね？　今でもアプリの起動時間って
めちゃくちゃ長いものもあるけど、64bitをフル活用するアプリ
だと起動時間数分とかにならね？ｗ
0084デフォルトの名無しさん2005/07/23(土) 13:54:20
要は搭載メモリ幅に見合った速度がバス、CPUともに足りないだろ？
0085デフォルトの名無しさん2005/07/23(土) 14:21:01


ノ　イ　マ　ン　型　終　わ　っ　た　な

0086デフォルトの名無しさん2005/07/23(土) 14:50:43
>>85
ん？DSPみたいなデータ指向型プロセッサが台頭するとでも？
0087デフォルトの名無しさん2005/07/23(土) 14:56:54
おれ、DSPのプログラムいくつかやった経験あるけど、
ちょっと使いにくいだけで基本はふつうのCPUと変わる
ところはなかったが…何が違うんだ？
0088デフォルトの名無しさん2005/07/23(土) 15:00:13
>>72
16ビットアプリを内部的に使っているものも当然ダメ
(いまどきインストーラ以外には存在しないと思うけど)。
Ntナンタラカンタラみたいな非公開APIを使っているものは
仕様の違いで動作しない可能性がある。
Win16との互換性を捨てたためUSER/GDIハンドルが
65536個以上割り当てられる可能性ができた

パッと思いつくのはこんなところ
0089デフォルトの名無しさん2005/07/23(土) 15:05:23
>>87
ノイマン型プロセッサは、命令を与えて動作するが、データ指向型プロセッサは
データそのものが命令になるというブツじゃなかったっけ？あまり詳しくないのでスマソ。
0090デフォルトの名無しさん2005/07/23(土) 15:13:30
＞データそのものが命令になる
よくわからんです

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

並列動作が見やすいように表記したりとかはあるけど、
些細なこと
0091デフォルトの名無しさん2005/07/23(土) 15:14:59
>>88
さすがに16bitはもういいよなｗ
いろいろ参考になるthx
0092デフォルトの名無しさん2005/07/23(土) 15:16:31
バッファオーバフロー型のワームがこれだけ世の中にあふれてるんだから
むしろデータとコードは厳密に分けようとするのがトレンドだと思ってたけど。
AMD64も全モデルNXビットサポートだったよね
0093デフォルトの名無しさん2005/07/23(土) 15:17:29
>>80
はあ？
＞すでにデスクトップはほとんど64bit
いつの間に!?
0094デフォルトの名無しさん2005/07/23(土) 15:47:00
データ指向型プロセッサってのは
DSPの一種で存在したってだけで
DSPのことではないんでは？
0095デフォルトの名無しさん2005/07/23(土) 16:44:41
>>93
あなたがここで時代遅れの薀蓄披露して識者気取りになってる間に
確実に時代は移り変わってるんですよ。おじいちゃん
0096デフォルトの名無しさん2005/07/23(土) 16:56:35
>>95
こんど量販店行って64bitマシンがいっぱい並んでるところを確かめてきまつ
0097デフォルトの名無しさん2005/07/23(土) 17:01:22
EM64Tをサポートしてるかどうかなんて傍目の表示で分かるの?
0098デフォルトの名無しさん2005/07/23(土) 17:06:32
インラインアセンブラのスレはどこですか？
0099デフォルトの名無しさん2005/07/23(土) 17:06:42
店員に聞く
0100デフォルトの名無しさん2005/07/23(土) 17:12:40
OSが64bitじゃないマシンを64bitマシンとして数えるのは
ちとなあ
0101デフォルトの名無しさん2005/07/23(土) 17:23:51
>>81
バスが遅杉の初代Itanium使ったらﾜﾛﾀよ。

CPUが増えても速度上がらないし、
メモリが4枚束ねられてるのに、そこらのDDRと同じ速度。
0102デフォルトの名無しさん2005/07/23(土) 17:25:46
386が98に搭載されはじめた頃も
「32bitマシンだよ」として売られていましたが。

ええ、バンドルされていたOSはN88BASICだけですよ。
0103デフォルトの名無しさん2005/07/23(土) 17:33:23
>>102
いやそういう煽りがくるとは思ったけど。じゃなくて実質というか実感。

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

win64アプリがどこのご家庭でも動くとかならんと、ほとんどという
実感にはならないっす
0104デフォルトの名無しさん2005/07/23(土) 17:43:59
ナニいってんだこいつ
だったら最初からそう書け
自分の言葉足らずに対する他人の突っ込みを
煽りとかいってごまかしてんじゃねーよボケ
0105デフォルトの名無しさん2005/07/23(土) 17:45:29
だいたい一体何様のつもりだ？
「俺様が64bitマシンだと感じるものが64bitマシンだ」ってか？
バカじゃねーの？

こういうのを煽りって言うんだよ。
0106デフォルトの名無しさん2005/07/23(土) 17:48:23
だいたい80は(明記してないけどおそらく)CPUについて言ってるのに
いつの間にかWin64の話にすりかえられてるし
0107デフォルトの名無しさん2005/07/23(土) 17:52:54
単に周りが見えない人なだけでしょ。そうでなきゃ軽々しく煽りとか言わないし。
0108デフォルトの名無しさん2005/07/23(土) 18:10:33
怒らせてしまったらしい…ｽﾏﾇ
0109デフォルトの名無しさん2005/07/23(土) 21:04:19
前スレはいいスレだったのに
0110デフォルトの名無しさん2005/07/24(日) 08:22:35
愚露屋が絡むスレは荒れるな
0111デフォルトの名無しさん2005/07/24(日) 12:38:27
そこでMMXネタですよ。
0112デフォルトの名無しさん2005/07/24(日) 13:25:52
MMXが復活しない限り、64bit以降はありえないね。
俺が以降しないってことは・・・影響力も甚大だよ（ｗ
0113デフォルトの名無しさん2005/07/24(日) 14:28:12
ｱｯｿ
0114デフォルトの名無しさん2005/07/24(日) 14:35:00
>>113
何か勘違いしてないか。移行しないのは112だけじゃなくて
このスレの113以外全員だぞ？
0115デフォルトの名無しさん2005/07/24(日) 14:47:25
メモリのチップの大きさって今よりぜんぜん小さく出来るのか？
何十ＧＢ積もうと思ったらその辺も解決しないとだめだろ
0116デフォルトの名無しさん2005/07/24(日) 14:49:36
え、CPUとかの微細化とは違った問題がある？
0117デフォルトの名無しさん2005/07/24(日) 14:55:33
出来るんなら無問題。マザボとかは総とっかえだろうが。
そういう規格でてるの？
01181162005/07/24(日) 15:07:06
ああ、小さいメモリを作ってたくさん載せて何十GBを実現するのね。
それだと難しいだろ。
今はあれが限界なわけで。MicroDIMMとかやたら高いし。

大きさ覚悟で大量に載せるしかないかと。
それでも値段は高いだろうし、いきなりメモリの量増やすのは不自然ぽ。
0119デフォルトの名無しさん2005/07/24(日) 15:14:02
やっぱ限界なのか
0120デフォルトの名無しさん2005/07/24(日) 15:30:09
ムーアの法則もどうやら終焉を迎えたようだし
0121デフォルトの名無しさん2005/07/24(日) 15:49:57
>>120
いや、それはリーク電流でCPUのクロックが上がらなくなってることだろ？
元々の法則はトランジスタの集積度が18～24ヶ月で倍とかだから
一応今でも増え続けてるよ。
0122デフォルトの名無しさん2005/07/24(日) 15:51:21
物理搭載も限界で速度も頭打ちか
頭だけ64bitを使えるようになってもなあ
0123デフォルトの名無しさん2005/07/24(日) 15:54:11
x64はレジスタ倍増技術で、64bit化はオマケと思えばいいんじゃね。
0124デフォルトの名無しさん2005/07/24(日) 16:23:38
レジスタ増えても大半のエンドユーザーには関係ないもんなあ…
0125デフォルトの名無しさん2005/07/24(日) 16:29:20
16→32bit化を否定していた奴らを思い出す。
0126デフォルトの名無しさん2005/07/24(日) 16:41:51
16→32のときはMMX禁止に相当するようなパフォーマンス低下の要因なんて
なかったし
0127デフォルトの名無しさん2005/07/24(日) 16:44:55
16→32bitのときは速度も容量もまだまだ頭打ちではなかった
0128デフォルトの名無しさん2005/07/24(日) 16:47:29
AMD64では32bitアプリもMMX、3DNow!を使わずにSSEの使用を
推奨しているけど、そこら辺はどうよ。

Intel知らんけど。
0129デフォルトの名無しさん2005/07/24(日) 16:48:01
半導体の集積度は限界が見えてるんじゃなかったっけ？
0130デフォルトの名無しさん2005/07/24(日) 16:51:44
淫テル、オワットル
0131デフォルトの名無しさん2005/07/24(日) 16:54:58
i386も初期の奴はi286より遅かったんじゃなかったっけ？
0132デフォルトの名無しさん2005/07/24(日) 16:55:53
AMDのXMMXはMMXと同等か速いの？　インテルのしか使ってないので知らんのだが
0133デフォルトの名無しさん2005/07/24(日) 17:04:54
>>132
んなこたない。あからさまに遅くなる。レジスタ倍増したメリットもかたなし。
AMDのもMMXとXMMでユニット共用だ。
0134デフォルトの名無しさん2005/07/24(日) 17:15:05
MMX→SSE2で遅くなるって言う人、どういうコードで遅くなるの？
よろしければそのコードの例を見せてよ。
0135デフォルトの名無しさん2005/07/24(日) 17:16:34
淫テルがボロいからだろ。
x64コード走らせると遅くなりことが多いらしいぞｗ
0136デフォルトの名無しさん2005/07/24(日) 17:17:26
×遅くなり
○遅くなる
0137デフォルトの名無しさん2005/07/24(日) 17:19:08
ＭＭＸ最強杉
0138デフォルトの名無しさん2005/07/24(日) 17:20:27
AMDの除算最強杉
0139デフォルトの名無しさん2005/07/24(日) 17:47:19
>>134
コードじゃないけど、「SSE2 遅い」でググったらすぐにヒットする。

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

もちろんSSE2を活かせる場面も否定しないよ。速くなる状況に関しては使ってるから。
0140デフォルトの名無しさん2005/07/24(日) 18:09:29
＞遅くなるって香具師の方がこのスレでも多い。

IDがでないこの板で、そんなこと言っても仕方がないですね。
実例を出す方が説得力ありますよ。
0141デフォルトの名無しさん2005/07/24(日) 18:13:15
プログラムしたことあるやつかどうか疑ってしまう
0142デフォルトの名無しさん2005/07/24(日) 18:22:52
http://pc8.2ch.net/test/read.cgi/tech/1105878545/l50
にお帰りください
0143デフォルトの名無しさん2005/07/24(日) 19:32:15
>>138
詳しく
0144デフォルトの名無しさん2005/07/24(日) 19:33:07
> 遅くなるって香具師の方がこのスレでも多い。

笑った
「スラドでこういう意見が多い」より酷い
0145デフォルトの名無しさん2005/07/24(日) 19:53:13
出来たら速くなるコードを見せて欲しいもんだ
0146デフォルトの名無しさん2005/07/24(日) 21:12:26
MMXとSSE2を比較してSSE2のほうが速かったよ。
コードはRSAのMD5を、MMXやSSE2を使うように書き換えただけのもの。
0147デフォルトの名無しさん2005/07/24(日) 22:44:27
で、互いに具体的なコードは一切晒さず神学論争ですか
0148デフォルトの名無しさん2005/07/24(日) 22:47:41
>>146
どんなケース？
１・mm0->xmm0　ほぼこれだけ
２・mm64bit幅からxmmの128bit全て使うようにした
３・SSE以降のMMX補完命令を使った。pmulhwとか
４・計算途中を浮動小数に変えてでも適用した
0149デフォルトの名無しさん2005/07/24(日) 23:30:45
>>147
それが２ちゃんの醍醐味なんだよ（ｗ
01501462005/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倍の速度が稼げます。
01511462005/07/25(月) 00:22:11
あ、ごめん。
最後のところ、MMXだけ2本1組と比較したらダメだよね。
SSE2を使わない場合のピークは、
MMXを2本1組、通常の整数レジスタを1本7組の場合で、
SSE2を使えば、その約1.5倍くらいのスループットが出ました。
0152デフォルトの名無しさん2005/07/25(月) 01:25:48
>>151
1.5倍か素晴らしい

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

こっちはケース１・２では全滅。（画像変換処理）
0153デフォルトの名無しさん2005/07/25(月) 10:26:19
P4の命令ﾚｲﾃﾝｼ/ｽﾙｰﾌﾟｯﾄ表をみると、MMX→SSE2化で効果ありそうだけど
逆にAthlon64だと効果ないっぽい。

2x2の行列の掛け算を148の(2)(3)でSSE2化しても、Opteronでは
まったく速くならないし遅くもならなかった。
まぁ、精度の関係でもうMMXは使っていないけどねー
0154デフォルトの名無しさん2005/07/25(月) 10:54:34
>>153
SSE以降は、MMXでは精度が足りないようなところを補完する形で
使うとプログラムの全体的なアップにつながるね
0155デフォルトの名無しさん2005/07/25(月) 13:54:43
Mathematica」がマルチコア対応、64bit環境をフルサポート
http://pcweb.mycom.co.jp/news/2005/07/25/100.html

64bit対応メリットは何かな？
0156デフォルトの名無しさん2005/07/25(月) 14:25:23
>>155
大量のメモリが使える。つまり馬鹿でかい配列が使える。
0157デフォルトの名無しさん2005/07/25(月) 14:36:39
マセマチ子さんは超巨大データを扱う需要はありそうだね。
0158デフォルトの名無しさん2005/07/25(月) 17:22:11
>>156
64bitじゃないと確保できないサイズの配列って、どんな演算に使うの？
0159デフォルトの名無しさん2005/07/25(月) 17:25:54
>>158
シミュレーション等ではいくらでも用途はある。
0160デフォルトの名無しさん2005/07/25(月) 17:40:29
天気予報とか？
0161デフォルトの名無しさん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で使うと余計な演算が必要になる。
0162デフォルトの名無しさん2005/07/25(月) 18:00:05
>>151
1.5倍ということはPentium4だね（違ったら教えて）。
依存チェーンがきつい場合にSSE2は強いかも。

>>155
64bit*64bit=128bitの整数乗算ができるのが大きいと思う。
0163デフォルトの名無しさん2005/07/25(月) 18:13:39
汎用の64bitレジスタより、mmの方が速い様な希ガス。
＠Athlon64 cgｺｱ
0164デフォルトの名無しさん2005/07/25(月) 18:22:30
AthlonってMMXは汎用レジスタと違う実行ユニットなの？
0165デフォルトの名無しさん2005/07/25(月) 19:30:23
>>163
それより古いC0コアのOpteronでは、mm(64bit)も汎用も変わんないよ。

x64のmasmってmmx命令にも対応しているのねｗ
0166デフォルトの名無しさん2005/07/25(月) 19:44:40
>>165
そのmasm、ちょっと萌えるな。
0167デフォルトの名無しさん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
0168デフォルトの名無しさん2005/07/25(月) 20:19:06
psdkの人は残念。
vs2005 beta2のml64ならMMX対応。
0169デフォルトの名無しさん2005/07/25(月) 21:06:51
MMレジスタを32本にしてF32vec2型とF64vec1型サポート汁
0170デフォルトの名無しさん2005/07/25(月) 21:13:14
IA64なら汎用レジスタは128本だぞ
0171デフォルトの名無しさん2005/07/25(月) 21:15:35
過去の資産をおろそかにするCPUは市場では歓迎されない
01721462005/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本を好き勝手に使えるわけじゃないから。
0173デフォルトの名無しさん2005/07/25(月) 23:23:55
ってより…
メモリモデルのタイニー、スモール、コンパクト、ラージの話に近いんじゃないのかね。
あの時よりも、メモリの増大量が全く追いつかない訳だから、64bit化って意味だと時間は当然掛かるでしょ。
レジスタ数が増える分の向上はそれなりに大きいからx64化自体は急速に進むだろうけれども。
0174デフォルトの名無しさん2005/07/25(月) 23:44:01
アドレス空間が広いのでファイルをマップするような場合はとても楽。
今の64bitを往時の32bitに例えると、今の32bitが往時はバンクメモリやらEMSやら。
データベースや全文検索など今後は個人や小規模オフィスでも需要が確実にある
応用に格段に有利だし、移行を進めるマーケットのパワーも往時より遥かに
強いので今更32bitにこだわるのはただのバカ。

>>173
レジスタ数なんて瑣末なことはほとんどx64の普及の要因とはなっていないよ。
そんなのは64bit化のついでに変わる様々なことのごく一端でしかない。
0175デフォルトの名無しさん2005/07/25(月) 23:49:01
いくらメモリ空間が膨大にあっても、
ファイルを丸ごとメモリマップした場合、
プログラムからOSへヒントをちゃんと与える仕組みがあって、
適切にヒントを与えないと、かなりパフォーマンス的に厳しいものがある。
0176デフォルトの名無しさん2005/07/25(月) 23:57:14
というのではわからない人もいるか。

実メモリの数倍のサイズのファイルを丸ごとメモリマップして、
先頭→末尾→先頭と、メモリを舐めた時に、何が起こるのか、
よく観察してみると、何が言いたいのかわかると思う。
0177デフォルトの名無しさん2005/07/26(火) 01:34:25
>先頭→末尾→先頭と、メモリを舐めた時に
ライトするならヘッドが結構動くだろうけど、そもそもそういった使い方はしないんじゃないかな？
ディスクのいじめ方を知るにはいいと思うけど。
0178デフォルトの名無しさん2005/07/26(火) 01:43:33
OS的には先読みするかと、どのページを残すかというアルゴリズムの問題だから
64bitだからといって大きく変わるわけではない。どうせ残せるページの数は実メモリ
のほうで決まるからね。OS的にはむしろ自由度が上がるという感じ。
0179デフォルトの名無しさん2005/07/26(火) 01:47:53
いくらメモリが使えても、MMXが使えないんでは無意味。
0180デフォルトの名無しさん2005/07/26(火) 02:04:45
>179
なるほど、んじゃ何使うね？
0181デフォルトの名無しさん2005/07/26(火) 02:23:21
広い空間が不要でMMXが使いたいのなら32bitコード使ってりゃいいじゃん。
0182デフォルトの名無しさん2005/07/26(火) 13:21:38
仕事で64bitに対応させざるを得ないこともあるんだろう。
0183デフォルトの名無しさん2005/07/26(火) 13:36:06
仕事で金貰えるんならMMXが使えないくらい我慢しろ。
0184デフォルトの名無しさん2005/07/26(火) 14:52:38
64ビットにしたら速くなるんでしょ?

というアホな客のために対応せざるをえないこともある。
んで、速くならなくて怒られる。
速くならないですよって最初に言ったじゃないですか、
とかいっても、それを信じないような客は覚えてないし、
責任も取らない。
0185デフォルトの名無しさん2005/07/26(火) 15:13:29
ところで、64ビットではx87が一切使えないって話だけど、
超越関数はどうやって実現してるんだろ？
SSEにfsincosみたいのあったっけ？
0186デフォルトの名無しさん2005/07/26(火) 15:36:14
おれはほんとに64bitが必要になるまで32bitで行く。
64bit演算が必要なくらいじゃロングモード使う必要ない。
32bit以上の計算がいるなら浮動小数で十分な場合が
ほとんどだし、__int64もある。
malloc(2GB)が必要にならない限り…
0187デフォルトの名無しさん2005/07/26(火) 15:48:33
>>186
じゃ、このスレには用はないね。さようなら。
0188デフォルトの名無しさん2005/07/26(火) 15:51:19
……あーすまん、それはウソだ。
0189デフォルトの名無しさん2005/07/26(火) 15:57:35
>>185
某OS以外では使える
0190デフォルトの名無しさん2005/07/26(火) 18:13:13
>>172
オレももういちどXMMのコード見直してみるか。
とはいえロングモードでインラインアセンブラは欲しい
0191デフォルトの名無しさん2005/07/26(火) 18:17:29
>>185
そら反復法だべ
0192デフォルトの名無しさん2005/07/26(火) 18:26:30
>>161
＞単純にレジスタが大きいから小回りが効かない。
これ、ネックになってる気がする。
0193デフォルトの名無しさん2005/07/26(火) 18:45:43
>>191
64bitではプログラムで超越関数を実現してるのか。恐れ入った。
もうさ、それでは絶対にx87より速くなりっこないから。
0194デフォルトの名無しさん2005/07/26(火) 18:50:56
>>193
そんなこたぁない。
0195デフォルトの名無しさん2005/07/26(火) 18:51:56
RISC的な考え方なのかもしれない。

どうせ複雑な処理はマイクロコードで展開するわけで、
だったらコンパイラにやらせりゃいいじゃん、という。
0196デフォルトの名無しさん2005/07/26(火) 19:03:43
32bitな某コンパイラも、超越関数はソフトウェアだな
0197デフォルトの名無しさん2005/07/26(火) 19:58:27
なんで妙な勘違いするんだろうね。
0198デフォルトの名無しさん2005/07/26(火) 20:05:42
一昔前のマイクロコードだと超越関数は反復(CORDICとかSTLとか)だったけど
精度保証がいらないなら級数展開が断然速いんじゃないかな。

64Bitの話題から脱線しまくっております。
0199デフォルトの名無しさん2005/07/26(火) 20:14:02
>>196
詳しく。
MSCは直接x87を呼んでいるようだけど。
0200デフォルトの名無しさん2005/07/26(火) 20:35:45
プログラミングって、インラインアセンブラがあるからこそ
高尚なものになりえてると思うんだ。
0201デフォルトの名無しさん2005/07/26(火) 20:55:47
>>198
反復ってNewton法みたく収束反復のことでは?
0202デフォルトの名無しさん2005/07/26(火) 23:29:41
>>200
ネタですか？
0203デフォルトの名無しさん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向けにビルドしても結構バグで落ちるらしいけど
大丈夫かいのう
0204デフォルトの名無しさん2005/07/27(水) 00:25:52
淫乱アセンブラ使いたいならgccでいいじゃん
0205デフォルトの名無しさん2005/07/27(水) 00:26:36
>>171
思うにハードが十分普及して枯れてきてからが、ハードの演算ユニット実装数に依存しない
APICアーキテクチャの本領発揮かと。

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

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

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




ATL/WTLをWin64向けにビルドしても結構バグで落ちるらしいけど
大丈夫かいのう
0206デフォルトの名無しさん2005/07/27(水) 00:29:54
>>171
思うにハードが十分普及して枯れてきてからが、ハードの演算ユニット実装数に依存しない
APICアーキテクチャの本領発揮かと。

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

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

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




ATL/WTLをWin64向けにビルドしても結構バグで落ちるらしいけど
大丈夫かいのう
0207デフォルトの名無しさん2005/07/27(水) 00:41:17
落ち着けよ
0208デフォルトの名無しさん2005/07/27(水) 00:53:09
ごめん、なんかサーバの調子が悪くて連投になってもうた
0209デフォルトの名無しさん2005/07/27(水) 01:07:44
>>199
ICCのP4向け最適化がそんな感じだったかと。
0210デフォルトの名無しさん2005/07/27(水) 01:29:16
std::swap(p1, p2); で xchgに展開してくれるのが真の最適化コンパイラかと思う。
Intelコンパイラは酷すぎ。C++ライブラリクラスのメソッドのインライン化が全く利いてくれない。
SIMDだけなら最強だけど・・・
0211デフォルトの名無しさん2005/07/27(水) 01:43:10
xchgってかなり遅いんじゃなかったっけ？普通のロード/ストアに比べて。
そもそもバスロックかかるし。
0212デフォルトの名無しさん2005/07/27(水) 01:56:23
バスロックはかからないよ。

たいていはlock prefix付けてバスをロックして使うけどさ。
0213デフォルトの名無しさん2005/07/27(水) 02:29:22
レジスタ値の交換には有効でしょ。

Pen4はメモリ－レジスタが半端なく時間かかる
0214デフォルトの名無しさん2005/07/27(水) 03:14:43
>>212-213
えーと、インテルのマニュアルを読んだことはありますか？
0215デフォルトの名無しさん2005/07/27(水) 03:16:19
というか、インラインアセンブラだの最適化だのほざいてるのって
結局この程度の連中が殆どなんだよね。
0216デフォルトの名無しさん2005/07/27(水) 03:31:13
>>215
そういうお前は「この程度」以下なわけだな。
0217デフォルトの名無しさん2005/07/27(水) 11:12:30
つーか210は突っ込み所満載だからネタだろ？
0218デフォルトの名無しさん2005/07/27(水) 11:52:33
結局インラインアセンブラなんて使わずに、コンパイラに任せた方が大抵早くなるってこったなｗ
つーか、最近のコンパイラの最適化を侮っちゃいけない。
あれに勝てるアセンブリコード書ける人間なんてそういないんだし・・・
高速化のためにインラインアセンブラ使わせてくれってやつは、自分の実力把握してないんじゃね？

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

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

デスティネーション・オペランド（第1 オペランド）の内容をソース・オペランド（第
2 オペランド）の内容と交換する。オペランドには、2 個の汎用レジスタまたは1 つの
レジスタと1 つのメモリ・ロケーションを使用できる。メモリ・オペランドが参照さ
れていると、LOCKプリフィックスの有無、あるいはIOPL の値に関係なく、プロセッ
サのロッキング・プロトコルが交換操作が持続している間自動的にインプリメントさ
れる
0220デフォルトの名無しさん2005/07/27(水) 12:32:05
夏だな
うぜー
0221デフォルトの名無しさん2005/07/27(水) 12:35:13
Athlon64だと、XCHGは16クロックもかかる。（L1ヒットで）

mov rax, a
mov rbx, b
mov b, rax
mov a, rbx
の方がずっと速いと思う。
0222デフォルトの名無しさん2005/07/27(水) 12:37:25
>>218
コンパイラが吐かない命令を埋め込むときに使ったな。
ビットスキャン(場合によっては速い)とか
スピンロックとか。

あ。MMXモナー
0223デフォルトの名無しさん2005/07/27(水) 13:41:05
MMX使ってる原始人はもうこのスレ来るなよ
0224デフォルトの名無しさん2005/07/27(水) 14:00:03
Win64限定じゃあるまいし
0225デフォルトの名無しさん2005/07/27(水) 16:07:07
>>210
レジスタが空いてないときに交換するなら便利かもしれんが、
そもそも自分でアセンブラ書くときにxchg使ったことないな。


>>213
Pen4ってLoadは普通に速いし、Storeはライトスルーだけど
その対策として384byteのストアバッファがあるから、交換目的には問題ないと思う。
0226デフォルトの名無しさん2005/07/27(水) 23:53:10
>>221
レジスタ同士の値交換したい場合は？

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

でもいいんだけどさ。
0227デフォルトの名無しさん2005/07/27(水) 23:53:53
こうや・・・間違えたorz

xor *ax, *bx
xor *bx, *ax
xor *ax, *bx
0228デフォルトの名無しさん2005/07/27(水) 23:57:09
http://www.dd.iij4u.or.jp/~okuyamak/Information/xor_fixed_swapping.html
0229デフォルトの名無しさん2005/07/28(木) 00:20:45
いまさら奥山教祖かよ、、、
0230デフォルトの名無しさん2005/07/28(木) 00:52:50
少なくとも現代のCPUならテンポラリレジスタ使って普通に書いたほうが
ずっと速いぞ。64bitならレジスタも増えるし。
0231デフォルトの名無しさん2005/07/28(木) 20:12:03
x86やx64のxchg命令は速度よりアトミックな交換ができるという点が重要なわけで
0232デフォルトの名無しさん2005/07/29(金) 00:42:57
/O3や/Oxでコンパイルしてもstd::swapをわざわざ関数コールするICCのアホさ加減こそ突っ込みどころじゃなかろうかと
0233デフォルトの名無しさん2005/07/29(金) 01:44:10
>>232
関数なんてコールしていないじゃないか。
嘘つき野郎
0234デフォルトの名無しさん2005/07/30(土) 00:08:29
嘘も方便
0235デフォルトの名無しさん2005/08/02(火) 12:45:15
、 ｌ ∥＿ ＞:=‐ ￣￣「　ｌ| l　 　 } ､　　ヽ 　　んっ　んんっ…
ヽ　､i`─ '´　___　　　｜ ｌl　⌒;　j　 、 　 ヽ
　＼ヽ　r,ﾆ､‐‐'‐'　u　.ｌ　ｌl 　 '_ノ　　 ､　 　 ヽ　
　　 ｀ ＼"＼):､　　　 ｜ ｌ|　　｀､　ヽ　 ､　　　ヽ
　　　 　 ヽ　 ゞ'＾ 　 　 !　lｌ　　　｀､　ヽ　　､　 　 ヽ
　　　　　丿　 　.:::.　　｜ l|　　　　 ＼　ヽ、　､　　 ヽ
　　　　 丶､_　 　 　 　 |　l|/ｌヽ　　　｀＞=‐- ミヽ 　 ｀、
　 　 　 　 　 ｀⌒ヽ_　　|　ｌ| |　ﾊ　 ／´　　　　 ｀ヽ　　 ､
　　ﾁｭﾊﾟ　　/　　/.　｀´|　ｌ| | l / 〃　　　　　　　　｀、　 ､
　ﾁｭﾊﾟ　　/ 　　/ 　 　 |　ｌ| | l' 〃　　　　 　 　 　 　
このレスを見た人はコピペでもいいので
10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ
出世しまくるわ体の悪い所全部治るわでえらい事です



0236デフォルトの名無しさん2005/08/06(土) 19:35:56
32ビット実行形式から64ビットモジュールを呼び出す方法は存在しないのか?
0237デフォルトの名無しさん2005/08/06(土) 19:42:45
ShellExecuteかsystemあたりでパラメータ渡して起動するだけなら原理上できそうだけど
それに何のメリットがあるのか
0238デフォルトの名無しさん2005/08/06(土) 19:43:09
ないわきゃない。API呼び出しは結局すべて64bitのntdllに転送されてるんだから。
でも公開されてない。
0239デフォルトの名無しさん2005/08/06(土) 19:48:18
out-of-process COMって手もあるね。結局はプロセス間通信だが。
0240デフォルトの名無しさん2005/08/07(日) 02:58:35
まあ32bit/64bitの区切り単位がプロセスなんだからプロセス間通信になるのは
仕方ないよね。COMでも自前で適当なstubを書いてもいい。
そのあたりを自動生成するツールなんてもう誰か書いてそうな気もするけど、ないの?
0241デフォルトの名無しさん2005/08/07(日) 03:04:01
で、その橋渡しをするのが怒涛熱湯ですよ

本屋を当たる限りWin64の情報が全く無いんだけど、全部CLRに移行させる気なのかね。
基本命令セットすら知らない。
mmintrin.hで書いたMMX向けコードをx64向けにコンパイルしたらｘ64汎用レジスタベースに展開されてしまった。
パックド演算特有の処理をどう展開するのかはまだ試してないが。
0242デフォルトの名無しさん2005/08/07(日) 03:17:58
基本的には*mmintrin.hで書いておけばx86でもx64にもIA64にも対応する並列化コードが書けることだけはわかった。
それにしてもItaniumのコード素晴らしすぎる。惚れた！ここまでレジスタがリッチだとなんでもできんのね。
一般向けには売らないのかしら。。。
0243デフォルトの名無しさん2005/08/07(日) 03:23:31
Intelは一般向けもIA64に移行させる夢を描いていましたが
市場にそっぽを向かれてAMD64で止めを刺されますた
0244デフォルトの名無しさん2005/08/07(日) 03:36:43
唯一Powerに対抗できるプロセッサだし方向性が間違ってたわけじゃないとおもうけど
ダイナミックトランスレーションで「同クロックのNetBurst並みの性能」じゃちょっとどうしようもないかもね。
同クロックのPentium M並みならかなりイイが
0245デフォルトの名無しさん2005/08/07(日) 03:37:29
>>242
つ ttp://page9.auctions.yahoo.co.jp/jp/auction/k23304285

いまんとこ5万円だ。
0246デフォルトの名無しさん2005/08/07(日) 03:39:31
やっぱLinuxしかないのか。
0247デフォルトの名無しさん2005/08/07(日) 03:52:57
単にOSなしってだけで、WindowsはMSDNでダウンロードすればいいんですよ。
0248デフォルトの名無しさん2005/09/03(土) 02:16:52
64bitアプリ開発の参考になるサイトない？
0249デフォルトの名無しさん2005/09/03(土) 06:28:41
OSは?
0250デフォルトの名無しさん2005/09/03(土) 17:54:56
64bit版WinXP
02512492005/09/03(土) 20:59:01
>>250
ならば、マイクロソフトのサイトやMSDNを見たほうが早いよ。
0252デフォルトの名無しさん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

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


0253デフォルトの名無しさん2005/09/04(日) 01:57:32
簡単に設定したければ VisualStudio 2005 の発売を待つ。かな。
0254デフォルトの名無しさん2005/09/05(月) 03:00:08
「はじめて読む486」みたいな良い本で、
最近の pent3～pent4・amd64 までサポート
しているような書籍ってないですかね？
0255デフォルトの名無しさん2005/09/05(月) 13:18:09
>>254
そんな都合の良い本は売ってない。
書籍メーカーも儲けないといけないので、全部別冊で出してるよ。
0256デフォルトの名無しさん2005/09/05(月) 14:01:50
ttp://www.tkool.org/punge/sinsa/No2.zip
ここにひとつのゲームがある。
このゲームは既存に存在するゲームへのアンチテーゼ。
何から何まで説明され、ユーザーが考える余地のないゲームが
多く存在する昨今、今回は「逆にまったく説明しない」または
「教えようとしない」コンセプトで作ってある。

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

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

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


目覚めよ、人間たち

0257デフォルトの名無しさん2005/09/05(月) 16:18:53
>>256
もう夏は終わりだよ。
0258デフォルトの名無しさん2005/09/15(木) 14:33:35
32bitの演算も高速化されるのでしょうか？
0259デフォルトの名無しさん2005/09/15(木) 15:35:03
>>258
ほとんど変わらん。
0260デフォルトの名無しさん2005/09/15(木) 15:35:35
されないのがふつー
0261デフォルトの名無しさん2005/09/15(木) 16:30:02
32bitの演算は技術的には通常のまま
ただし、64bitと32bitの変換が入るので、オーバーヘッドは微々たる物だが、あるといえばある。
基本的に32bitの処理は32bitOSにやらせるのが一番。

ま、カーネルチューニングもされてるので、多少高速化されてるんだけどね。
ただ、ドライバのチューニングは逆に遅れてるので、結局総合的に見て、同じか判らない程度劣ってるんじゃないかな。
0262デフォルトの名無しさん2005/09/15(木) 16:44:20
>>261
32ビットの演算で、64ビットと32ビットの変換のオーバーヘッドがかかる
32ビットの演算が、32ビットOSと64ビットOSで速度が違う

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

私はてっきり、オーバーヘッドなし、速度の違いなし、だと思っていたのですが・・・。
0263デフォルトの名無しさん2005/09/15(木) 16:49:09
>>262
ただの32bit懐古厨なので放置推奨
0264デフォルトの名無しさん2005/09/15(木) 16:50:18
>>262
オーバーヘッドってのはOS呼ぶときにの話でしょ。
そんなの微々たるものだし、そもそも計算ネックのアプリケーションでは
無視できる程度だよ。
0265デフォルトの名無しさん2005/09/15(木) 19:02:47
amd64/EM64Tで、64ビットOS上で64ビットアプリで32ビット計算をする
話なら、レジスタ数や関数コールの違いで速くなるんじゃないかね。

02662622005/09/15(木) 21:25:20
>>264
OSを呼ぶと変換が生じるのでオーバーヘッドがあるのはわかるのですが・・

>>261には、32ビットの演算に変換が生じてオーバーヘッドがかかり、
32ビットの演算なら32ビットのOSのほうが速いと書いてあるので、
なんか自分の知っているのと違うなぁ、と思いまして。
0267デフォルトの名無しさん2005/09/15(木) 22:43:31
>>266
>>261は気にするな。ｗ
02682622005/09/16(金) 00:02:31
>>261は釣りか、さもなくば真性の馬鹿だったんですね。

今夜は安心して眠れそうです。
0269デフォルトの名無しさん2005/09/16(金) 00:33:18
真性のバカに一票
0270デフォルトの名無しさん2005/09/16(金) 01:42:42
プレス子の実装だと、多少はあるんじゃねーのか。
あと、アーキそのものが違うからなんとも言えないがIA32＞IA64上のIA32EL
0271デフォルトの名無しさん2005/09/16(金) 22:42:46
かつてのAlphaみたいにクロックの差で補うつもりだったんだろう
でもどうしても一番金の掛けられるIA32の進化には勝てない
0272デフォルトの名無しさん2005/09/17(土) 02:49:12
>>258
「32bitの演算」に限定すれば同じ
「32bitのデータの処理」辺りまで広げれば違いがある可能性がある
けど一般論は無理だろう　具体的かつ定量的に検討しないと
0273デフォルトの名無しさん2005/09/17(土) 02:51:41
16bit32bitになったときに、とても高速になった気がしたのですが、
今回はあまりそんな気がしないのが何故？
0274デフォルトの名無しさん2005/09/17(土) 03:16:08
>>273
どうせ32bitの初めて買ったCPUが486とかPentiumとか、そういうオチなんだろ。
0275デフォルトの名無しさん2005/09/17(土) 03:21:33
アドレス空間も整数の幅も 32bit で十分なアプリが殆どだから
64bit 幅のデータ転送が結構大変だったから
>>273 が Pentium を使ってるから

どれ?
0276デフォルトの名無しさん2005/09/17(土) 03:46:22
16ビットの時にhugeポインタを使いまくってたから、に一票。
0277デフォルトの名無しさん2005/09/17(土) 04:11:29
>>275
64ビット幅のデータバスなんて初代Pentiumでも実装してたぞ。
Pen4はコア内では最大256ビットじゃなかったかな。上り下り計で。
0278デフォルトの名無しさん2005/09/17(土) 05:06:10
>>273
１６ビットＣＰＵは２８６で２０ＭＨｚくらいまででキャッシュメモリなし
３２ビットＣＰＵは３８６以降で３３ＭＨｚくらいからで命令もキャッシュメモリも追加された
ビット幅に関係なく３２ビットが早い。

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

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

メモリは２０ＭＢくらい以上でWindows９５の方がはやくなるが、それ以下では３．１が早い。
当時１６ＭＢ～３２ＭＢが普通だったし。
0279デフォルトの名無しさん2005/09/17(土) 05:27:43
適当すぎ。
286は5～１2MHz
386は16～33MHz
ちなみに、486は20～100MHｚな。
0280デフォルトの名無しさん2005/09/17(土) 05:53:01
386でL1キャッシュが載ったのは、サードパーティ発売分だけだろ。
Intel(c)謹製にはなかったのでは？
0281デフォルトの名無しさん2005/09/17(土) 05:56:10
あ、サードパーティ≠セカンドソースな。

で、386、486と模造品を作られるのに業を煮やしたIntelは、586として
発売予定だったCPUをPentium(c)として登録商標化し、他のメーカーが
使えなくした。
0282デフォルトの名無しさん2005/09/17(土) 08:40:41
全角英数ウソ書きすぎ
0283デフォルトの名無しさん2005/09/17(土) 08:52:36
>>278
2chデビューしたてで、何でも書いてみたかったのか。
どの板でもそうだが、嘘を書くと、激しくバッシングされるぞ。特にIDの出る板は気をつけな。
0284デフォルトの名無しさん2005/09/17(土) 09:02:13
>>279
あれ、386のクロック下限 > 286のクロック上限だっけ? 逆じゃない?
少なくとも80286の16MHzはあったと思う。
PC-9801で80386載せたやつが出始めのとき、EPSONはそれより速い80286搭載の
互換機を出して「大差ないから速い方がいいでしょ」みたいな広告打ってた
記憶があるんだけど。
0285デフォルトの名無しさん2005/09/17(土) 09:15:48
Intel製でなくても良いのなら、286相当で20MHzというのもあったな。
確かAMD製だったか？
0286デフォルトの名無しさん2005/09/17(土) 09:18:28
俺のおぼろげな記憶だと、
386は16MHzから、286は16MHzまでだったんじゃないかな。
もしかしたら、286は12MHzまで(>>279の通り)かも。

で、エプソンに使われていた286の20MHzとかは
Intel製じゃなくて、AMDとかのセカンドソース。
これは、「命令互換」じゃなくて、中身の回路もIntelと同じもの。
02872862005/09/17(土) 09:21:40
つーか糞かぶりやん。
やっぱ286は中途半端で使い物にならんな。
0288デフォルトの名無しさん2005/09/17(土) 09:32:56
http://ja.wikipedia.org/wiki/Intel_80286
0289デフォルトの名無しさん2005/09/17(土) 09:40:16
16bit→32bit の時は速度よりも忌まわしい「セグメント：オフセット」の壁から解放されて
メモリがフラットに使えることが一番嬉しかった。

32bit→64bit では特殊な用途でもない限り、１つのアプリでそこまで大量のメモリを
必要とすることは当分ないだろうからなぁ・・・
02902782005/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
0291デフォルトの名無しさん2005/09/17(土) 13:10:45
>>290

ちょっと待て。

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

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

それを、俺がまるで知らなかったような書き方をされるのは、頭にくるな。
お前もうちょっと人の書き込みをよく読むようにした方がいいよ。自分に都合のいい
部分しか目に入らないとは、やっぱり馬鹿だと言われかねないぞ。
0292デフォルトの名無しさん2005/09/17(土) 13:13:17
昔話もちょっとは面白いけど、続けるならそういうスレ行ってやってくれない？
0293デフォルトの名無しさん2005/09/17(土) 13:14:46
Windows3.1をシングルタスクとか言ってる時点でバカ確定ですが
0294デフォルトの名無しさん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は２．０から使ってる。
0295デフォルトの名無しさん2005/09/17(土) 13:53:18
>>294
一つのアプリがハングしたら、全部のアプリがアウトだったからなぁ。
とても仕事には使えなかった。
0296デフォルトの名無しさん2005/09/17(土) 14:13:35
ぶっちゃけ>>294の職場の話なぞ聞いてはいない
0297デフォルトの名無しさん2005/09/17(土) 14:15:47
>>296
ぶっちゃけお前には言っていない。失せろ。
0298デフォルトの名無しさん2005/09/17(土) 14:16:27
>>296
はいはい。
レベルが低いとは言え、２００人ものプログラマを抱える部署で言われてたのを
馬鹿の一言で済ませるわけですか。

ばかっちゃあ馬鹿ですが、あんたに言われたくないってこった。
0299デフォルトの名無しさん2005/09/17(土) 14:20:07
>>298
>馬鹿の一言で済ませるわけですか。
もちろん済ませる。

>ばかっちゃあ馬鹿ですが、あんたに言われたくないってこった。
言わなくたって事実だしな。自覚があるのはいいことだ。
0300デフォルトの名無しさん2005/09/17(土) 14:21:52
ここは16bitスレですか？　いいかげんにしましょうよ。
0301デフォルトの名無しさん2005/09/17(土) 14:23:52
>>300
８ビット脳が１６ビットを語るとこうなると言う見本。
0302デフォルトの名無しさん2005/09/17(土) 14:24:00
マ板逝け！！
0303デフォルトの名無しさん2005/09/17(土) 14:24:56
でもまあ2.0はさらっと触って華麗にスルーが基本だったよね。
「２．０から使ってる。 」ってのは当時の判断能力を疑われても
仕方がない。
0304デフォルトの名無しさん2005/09/17(土) 14:28:14
>>303
日立のシステムで日立の人が入れたんですよ。
判断したのは日立です。
つーか２．０しか動かないような古い端末だし。
基本ホスト端末だし。

いや最初オペレーターだったから使うだけだったんだよね。
あのころはオペレーターっていう採用枠があって良かったよ。
0305デフォルトの名無しさん2005/09/17(土) 14:30:16
>>304
だからここは昔話をする板じゃありませんから。うぜーんだよジジイ。
0306デフォルトの名無しさん2005/09/17(土) 14:34:53
>>298と>>304を見比べると面白いな
「２００人ものプログラマ」と「オペレーターっていう採用枠」とやらの接点が分からんｗ
要は昔話してるじじいは当時下っ端の下っ端だったってことでOK？
0307デフォルトの名無しさん2005/09/17(土) 14:37:56
>>305
そんなこと言ってるとここゴミばっかりにするけど？
Windows２．０みたいに華麗にスルーすればいいのに、

君の判断能力を疑うよ。

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

>>306
新卒から下っ端じゃないなんてたいそうなエリートさんですね。
事件現場に居合わせた警察官僚はホントにじゃまばっかしくさって役にたたなかったよ。
事件が見えてないんだから。
0308デフォルトの名無しさん2005/09/17(土) 14:39:18
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　ま～たはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼
0309デフォルトの名無しさん2005/09/17(土) 14:41:43
>>307
これだから脳の硬直化したロートルプログラマは困るねえ。
0310デフォルトの名無しさん2005/09/17(土) 14:42:19
じじいの出口
つttp://bubble4.2ch.net/i4004/
0311デフォルトの名無しさん2005/09/17(土) 14:42:45
>>309 が柔軟な解決を見せてくれるそうですね。


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

0312デフォルトの名無しさん2005/09/17(土) 14:43:29
>>310
ナイス。
0313デフォルトの名無しさん2005/09/17(土) 14:47:49
>>310
悪いけど昔のPCには興味ないよ
Pen４よりPen３がいいとは思うけど、Pen３よりPenMがいいからね。
0314デフォルトの名無しさん2005/09/17(土) 14:52:10
>>313
詭弁じいさんは会社の中でも浮いた存在だろ。リストラはまだなの？
0315デフォルトの名無しさん2005/09/17(土) 14:53:54
これからはインテルよりAMDの時代かな。
ほんとのマルチコアが普及したらどうか分からないけど、
IA６４とかいらね。

IA６４が必要になるのってどんな？
0316デフォルトの名無しさん2005/09/17(土) 14:53:57
>>313
なに言ってるんだ？Pen3の話題なんかほとんどでねぇよ。
ここなんかお前にぴったりだ。じじいらしく引っ込んでろ。
【Win1.0】幻のOSを語ろう【Win2.0】
ttp://bubble4.2ch.net/test/read.cgi/i4004/1090495552/

>>314
ヒント：こんな時間に2ch
0317デフォルトの名無しさん2005/09/17(土) 14:54:25
>>314
オマエも早く就職しろよ
0318デフォルトの名無しさん2005/09/17(土) 14:55:23
>>316>>317
土曜日も仕事の弱小会社に勤めてるのか。まあ精一杯仕事してくれたまえ。
0319デフォルトの名無しさん2005/09/17(土) 14:59:39
>>318
馬鹿？
0320デフォルトの名無しさん2005/09/17(土) 15:00:47
>>319
（　´∀｀）オマエモナー
0321デフォルトの名無しさん2005/09/17(土) 15:05:19
２チャンネルの良心、モララーデビュー！ 2000/04/10 モララー誕生スレ
1 名前： 名無しさん 投稿日： 2000/04/10(月) 00:35

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



でもそれ以前に使ってたけどな。
0322デフォルトの名無しさん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倍。
0323デフォルトの名無しさん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ポイント

これ参考にするとクロックあたりでの計算しなかったかも。
でもいろいろ条件変えて実験したんだけどな。
0324デフォルトの名無しさん2005/09/17(土) 20:06:10
全角厨は馬鹿。
0325デフォルトの名無しさん2005/09/17(土) 20:28:08
てかさ、いいかげん過去の記憶だけで物言うのやめてくんないかな。
0326デフォルトの名無しさん2005/09/17(土) 20:28:33
>>323
CPUBENCHはキャッシュに収まるくらい小さいよ。
浮動小数点演算は286はソフトウェアでゴリゴリやるけど、486はハードウェアで計算するよ。
キャッシュをドライバで云々するのは偽486だよ。

286の10MHzはメモリアクセスノーウェイトだよ。
286でも486でも、メインメモリは同じ80nsのDRAMだよ。
0327デフォルトの名無しさん2005/09/17(土) 20:33:02
そろそろ64bitの話もしよーや。
0328デフォルトの名無しさん2005/09/17(土) 20:33:11
186→286の高速化はクロック上昇
286→386の高速化はパイプライン採用
386→486の高速化はマイクロコードのハードワイヤード化

だったような希ガス。いい加減な記憶で書いてるから
はずれてるかもしれん。
0329デフォルトの名無しさん2005/09/17(土) 20:38:18
16bitCPUスレ立ててそこでやれ！
0330デフォルトの名無しさん2005/09/17(土) 20:43:38
やれやれだぜ
0331デフォルトの名無しさん2005/09/17(土) 21:21:24
>>329
関連あるからいいだろ。
多ビット化は高速化に寄与するかって命題なんだよ。

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

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

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

>>330
まったくだ。
0332デフォルトの名無しさん2005/09/17(土) 21:30:24
いい加減すれ違いの懐古厨はｶｴﾚ
0333デフォルトの名無しさん2005/09/17(土) 21:51:51
>>332
オマエも無駄な発言してないで６４ビットについて語れ
0334デフォルトの名無しさん2005/09/17(土) 21:53:21
おいおい相手してもらえちゃってるから、喜んでるじゃねぇか。
全角厨はそっとしといてやれ。かわいそうな人なんだから。
0335デフォルトの名無しさん2005/09/17(土) 21:59:37
どうせ昔話をするならWindows 2000 for Alphaの話でもしようぜ。
0336デフォルトの名無しさん2005/09/17(土) 22:11:44
>>335
ああ、いいな。
いい感じだ。
WindowsNTなのにAlphaサーバーでツールが動かないんだよ。
パソコンで作ったソフトも動かないんだ。
エンディアン違うからそのままコンパイルじゃうまくいかないんだ。
でもあれが激早だったんだよな。
0337デフォルトの名無しさん2005/09/17(土) 23:41:00
>>336
そんなあなたにFX!32
0338デフォルトの名無しさん2005/09/17(土) 23:53:42
スゲー流れw
適当にしか見てないけど >>278 と >>294 は一瞬でバカ丸出し確定。
0339デフォルトの名無しさん2005/09/18(日) 00:03:13
いっその事Windows2000RC2の話しようぜ！
うちじゃ現役で動いてるよ！
0340デフォルトの名無しさん2005/09/18(日) 00:25:31
>>339
通報しますた。
0341デフォルトの名無しさん2005/09/18(日) 00:38:18
>>336

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

alphaはlittle endianだから、x86と同じだよ。
っていうか、Windows NTが移植されたプラットフォームは全て
little endian。
0342デフォルトの名無しさん2005/09/18(日) 00:43:11
で、結局64ビットになっても処理速度の点での恩恵は64ビットの演算を行わない限りあまり恩恵はないということでいいの
0343デフォルトの名無しさん2005/09/18(日) 00:45:22
>>342
（´・ω・）ｶﾜｲｿｽ
0344デフォルトの名無しさん2005/09/18(日) 00:46:49
>>342
それと64bitの（リニア）アドレス空間が要るかどうか。
0345デフォルトの名無しさん2005/09/18(日) 01:00:36
64ビットのアドレス空間があればさ、全部のファイルをメモリマップしてもいいね。

悲惨なことになりそうだが。
0346デフォルトの名無しさん2005/09/18(日) 01:11:59
ファイルシステムキャッシュの事じゃなくて？
0347デフォルトの名無しさん2005/09/18(日) 03:26:05
残念ながら64ビットのアドレス空間丸々使えるわけじゃないから
全部マッピングは無理っぽい
0348デフォルトの名無しさん2005/09/18(日) 06:04:40
2G程度の搭載メモリでは64ビットにしてもほとんど意味ない
0349デフォルトの名無しさん2005/09/18(日) 07:08:43
またその話かよ
0350デフォルトの名無しさん2005/09/18(日) 07:43:25
ロートルは黙ってろって言ったのに。
0351デフォルトの名無しさん2005/09/18(日) 07:49:23
64ビットのアドレス空間、今のところ一番ニーズがあるのはデータベース分野か。
他に単一java VMでいくつもサブシステムが動くとか、.
NETでAppDomainを大量に使うとかいった分野の需要はありそう。
0352デフォルトの名無しさん2005/09/18(日) 08:16:17
>>350
くそ野郎が発言するなボケ
てめーは親父狩りでもやってろ
0353デフォルトの名無しさん2005/09/18(日) 08:20:59
>>352
ファビョッた(^ω^)なにこいつ・・・・
0354デフォルトの名無しさん2005/09/18(日) 08:29:58
>>353
ロートルがなにか言ってるよ
0355デフォルトの名無しさん2005/09/18(日) 08:30:32
>>353
いちいち反応したがるのはなんで？
0356デフォルトの名無しさん2005/09/18(日) 08:31:25
>>353
しかもブサイクな鼻つけやがって
貴様はブタか
0357デフォルトの名無しさん2005/09/18(日) 08:32:10
ロートルは黙れ。
0358デフォルトの名無しさん2005/09/18(日) 08:32:32
>>357
そーだそーだかせいそーだ
0359デフォルトの名無しさん2005/09/18(日) 08:50:13
>>347
物理メモリへのアクセスが正味64bit分出ていないって話だろ?
マッピングには影響ない。
0360デフォルトの名無しさん2005/09/18(日) 13:19:54
変な馴れ合い喧嘩やめれ
0361デフォルトの名無しさん2005/09/18(日) 13:53:12
実際４GB以上のメモリをつみたくなる様な状況ってどんな？
0362デフォルトの名無しさん2005/09/18(日) 13:59:42
DB丸ごとオンメモリ
0363デフォルトの名無しさん2005/09/18(日) 14:19:36
>>362
４Gで十分なDBもどうかと。
更新も不安だし。
0364デフォルトの名無しさん2005/09/18(日) 14:25:48
意味不明
0365デフォルトの名無しさん2005/09/18(日) 18:29:55
>>361
数値計算などで倍精度実数の３次元配列を確保しようとする場合
4GBのメモリで確保できる配列の数は
100*100*100 で 536個
200*200*200 で 67個
500*500*500 で 4個
800*800*800 で 1個
四倍精度や複素数にすると更に半分になる。
0366デフォルトの名無しさん2005/09/18(日) 18:44:49
>>365
あーなんか少なく感じますねｗ
0367デフォルトの名無しさん2005/09/18(日) 20:50:16
OSのGUIが3D化して、３次元テクスチャ使いまくりになれば意味も出てくるな。
実搭載メモリが何十GBとかにならんと駄目だろうが。
0368デフォルトの名無しさん2005/09/18(日) 22:47:38
昨今のコンピュータはメモリアクセスより
計算の方が圧倒的に速いんだし
ベタな3Dテクスチャを使うなんて今後とも無さそうだが。
0369デフォルトの名無しさん2005/09/18(日) 23:40:29
>>359
物理アドレスが64ビットよりもずっと少ないだけでなく、
論理アドレスも64ビットよりも少ないというのを、
どこかで見かけたんだけどなぁ。

仮に64ビットフルに使えたとして、
今みたいに1ページ4KBのままでは、2^52ページにもなって、
1ページに1ビットのフラグ持たせたら、フラグだけで512TBですよ。
0370デフォルトの名無しさん2005/09/19(月) 00:19:16
>>369
2Mbyteの どでかページ も使えるので心配するな。ｗ
あと論理アドレスを制限するのは基本的にはOSだと思う。
0371デフォルトの名無しさん2005/09/19(月) 02:03:00
３次元テクスチャの話だけど、
電子地図帳Ｚの３Ｄのリアルモードみたいのを
建物の細かい構造、看板、電柱などたくさんのオブジェクト配置して
超リアルな街並みが再現できるかも。

ＢｏｏｍＴｏｗｎみたいなのって、こんなにメモリ食う構造だったんだな。
0372デフォルトの名無しさん2005/09/19(月) 02:50:26
メモリーが増えても出入り口の幅はほとんど変わらないから
有り難味が少ないなぁ．．．
0373デフォルトの名無しさん2005/09/19(月) 03:07:55
早くメモリ安くなんないかね
0374デフォルトの名無しさん2005/09/19(月) 03:15:35
フラッシュメモリなんて16Gbitチップ登場だよね。
DRAMもそのくらいに集積度上がって欲しいなぁ。
0375デフォルトの名無しさん2005/09/19(月) 03:24:26
真面目な話、x86の64bit化のメリットは、以下の３点だよ。
・１プロセスが32bitを超えるアドレス空間を扱える
・全プロセス合計で4Gを超える物理メモリを扱える
・レジスタ増加

理屈ではわかっていても、意外に(普通の)開発者から軽視されるのが真ん中の項目。
ちょっと考えると、サーバー用途以外ではあまり意味がなさそうにも思えるかもしれないけど
デスクトップで複数のタスクを動作させる、という事を抜きにしても
(これ自体も、マルチコア等でもっと一般的に行われるようになるかもしれないけど)
例えばRAMディスクにたっぷりと割り当てても他のプロセスへの影響が無くなるわけだし
単純にディスクキャッシュで扱えるメモリが増える、という意味でも
効果が期待できる場合もあるよ。
0376デフォルトの名無しさん2005/09/19(月) 03:32:59
真ん中はPAE使えやボケ
0377デフォルトの名無しさん2005/09/19(月) 03:39:10
PAEを有効利用できるデスクトップ版Windowsがあれば、ね。
0378デフォルトの名無しさん2005/09/19(月) 03:57:02
サーバでも 1 と 3 のが重要度高いな
0379デフォルトの名無しさん2005/09/19(月) 04:58:01
まあ、個人向けのパソコンではマザーボードの仕様上2Gから4G程度しか詰めないから、アプリも出てこないと言うことなのか。
それとも、データベースや科学計算のような特殊な分野以外に64ビットマシンは必要とされていないということなのか？
0380デフォルトの名無しさん2005/09/19(月) 05:08:14
>>375
４GB以上のディスクキャッシュはありがたいかもしれない。
電気は無駄に使うことになるし、リフレッシュのためにメモリが遅くなりそうだけど、
読み込みが減らせるからディスクアクセスが更新とか書き込みを
効率よくできるかもしれない。
断片化の発生を抑えた書き込みもできるかもしれない。

でもUPSが必須だな。
0381デフォルトの名無しさん2005/09/19(月) 05:16:53
あ、でも、DBとかはセキュリティの関係で読み込みのみってこたないな。
ノーツのDBも、開いただけでログ残ってたし。
「やべー。覗き見したらばればれやん」て思った。
覗き見するときはちゃんとその人のPCでその人のID使ってやらないとな。
0382デフォルトの名無しさん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分くらいかかると思う。

0383デフォルトの名無しさん2005/09/19(月) 05:42:03
>>378
32ビットの1プロセス2GB以内という制限は、けっこうキツいよね。

たとえば、1000クライアントを捌くサーバプロセスは、1クライアントあたり2MBしかメモリを使えない。
プロセスを分割したところで、プロセス間でメモリ共有を使って情報を交換するので、結局は同じことになる。

だから、とっとと64ビットになってほしいが、既存のDLLが32ビット・・・orz


>>379
AlphaやItanium2が、PCサーバ分野で鳴かず飛ばずだったのが、物語ってると思う。
32ビットではできないことをやろうとしたら、x86とバイナリ互換がないことは、
大した問題ではないと思う。不可能なのと、やればできるの違いは大きいから。
それなのに・・・ということは、32ビットではできないことをやる必要があんまりなかったんだね。
0384デフォルトの名無しさん2005/09/19(月) 05:42:17
>>379
メモリが積めないからアプリが出ないというより
一般向けに64bit環境が普及していないから需要が少ないという事でしょう。

ワープロと表計算くらいの用途なら64bitマシンどころか
16bit CPUと数MBのRAMしかないPCの時代でも出来たんだし
やってることの本質はたいして変わってない。

でも64bit CPUと64bit対応のOSを積んだマシンが普通に出回り始めれば
アプリの方もそれに合わせてくるだろうし
いずれはみんな、64bitな環境に移行するんだろうけど。
0385デフォルトの名無しさん2005/09/19(月) 05:56:24
>>384
６４モードで今までのソフトは動くの？

リブートが必要ならデスクトップで使われることはないよね
ＯＳも二ついるだろうし。
0386デフォルトの名無しさん2005/09/19(月) 06:08:11
64ビット空間というのは広大な空間だな。
32ビット空間は4GBで、PAEを使っても36GBなので、意外に早く
限界が来たけど。
0387デフォルトの名無しさん2005/09/19(月) 06:11:44
>>385
その昔 Windows はリアルモードとプロテクトモードの切り替えを
I/O 経由で CPU にリセット信号を送ることによって実現してた。
ありえないと思うが、必要とあればそれも選択肢かと。`
0388デフォルトの名無しさん2005/09/19(月) 06:15:54
>>386
そんなに使うのにワークステーション利用しないの？
0389デフォルトの名無しさん2005/09/19(月) 06:19:35
>>385
WinXP x64 Editionの場合は16bitコードを含むものや一部の特殊なソフトを除けば
32bitアプリもそのまま動く。
0390デフォルトの名無しさん2005/09/19(月) 06:37:39
>>387
それは286の話だね。386は自由にリアルモードとプロテクトモードの間を
行き来できるようになったので、関係ない。
0391デフォルトの名無しさん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
0392デフォルトの名無しさん2005/09/19(月) 08:32:22
>>385
64bit モードで 32bit プログラムを動かす手続きも x86-64 の仕様に含まれてた気がする
thunk layer だっけ?
当然、ライブラリやらドライバーやらはデータモデルを合わせてあげなきゃダメだけど。
0393デフォルトの名無しさん2005/09/19(月) 08:43:43
とっくに64bit化してるSPARCだって64bit Solarisの元で32bit用バイナリを実行
できるんで、それより後にやっとこさ64bit化したx86-64でできなきゃ嘘でしょう。
0394デフォルトの名無しさん2005/09/19(月) 08:44:01
>>391
リンク先記事だけど、PAE は Solaris や Linux, FreeBSD でも使えるのに、
と思ったら元麻布か。
0395デフォルトの名無しさん2005/09/19(月) 09:51:44
>>385
その話は、あまりにレベルが低すぎないか?
プログラマの発言とは思えない。
0396デフォルトの名無しさん2005/09/19(月) 10:28:25
>>395
そうかい？
使ってみないと分からないと思うけど。
0397デフォルトの名無しさん2005/09/19(月) 10:46:24
>>395
確か１６→３２のときは１６ビットアプリでも
コンパイラも３２対応製品に付属のでコンパイルしないとバグが出たと思う。
MSに問い合わせてもそういわれたし。
ということはベンダー提供のアップデートが必要になるってことだと思う。
0398デフォルトの名無しさん2005/09/19(月) 10:51:32
>>397
push sp した時のpushされる値の違いとかか？
0399デフォルトの名無しさん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

0400デフォルトの名無しさん2005/09/19(月) 12:35:59
>>399
0DIVエラートラップ時に積む値まで違っていたのか。初めて知った。
俺がx86使い始めたのは386が一番最初だったから知らなかった。
0401デフォルトの名無しさん2005/09/19(月) 12:37:26
まあでも俺の言い訳は言い訳にならないよな。Intel発行のデベロッパー
マニュアルを見れば、ちゃんと互換性の注意点とか書いてあるからな。
0402デフォルトの名無しさん2005/09/19(月) 21:38:40
>>396-397
ちょっとWindows板とか自作PC板とかの64ビットスレを見てきなよ。
0403デフォルトの名無しさん2005/09/19(月) 22:34:03
え～っと、、、
Windowsの最大の利点の１つは過去の資産との互換性でありまして
昔のプログラムを動かすのに一々リコンパイルが必要ならここまでの
シェアはっていうかぐぐればすぐに・・・
0404デフォルトの名無しさん2005/09/20(火) 00:00:41
push spとか0divの動作が変わったのは286が出た時だろ
0405デフォルトの名無しさん2005/09/20(火) 02:02:36
PAEって16ビット時代で言うところのFARみたいなものかと
思ってたけど違うの?
0406デフォルトの名無しさん2005/09/20(火) 02:08:31
http://www.microsoft.com/japan/whdc/system/platform/server/pae/default.mspx

ほれ
0407デフォルトの名無しさん2005/09/20(火) 02:08:37
>>405
違う
0408デフォルトの名無しさん2005/09/21(水) 01:48:32
おまいらついにVMwareが64bitゲストをサポートしましたよ

ttp://slashdot.jp/article.pl?sid=05/09/19/2220211&topic=104&mode=thread&threshold=-1
0409mokorikomo KHP222009212068.ppp-bb.dion.ne.jp2005/09/23(金) 18:12:10
webprog
0410デフォルトの名無しさん2005/09/25(日) 14:05:33
64bitプログラミングしてみたいんですが、
VC++　2005　express edition beta 2 で出来ますか？
0411デフォルトの名無しさん2005/09/25(日) 17:36:52
Expressは64bitコードを生成できない
0412デフォルトの名無しさん2005/09/25(日) 18:32:51
マジで？どのコンパイラなら64bitコード吐いてくれますか？
0413デフォルトの名無しさん2005/09/25(日) 18:51:57
gcc
0414デフォルトの名無しさん2005/09/25(日) 19:05:15
PathScale
0415デフォルトの名無しさん2005/09/25(日) 19:33:48
>>412
Plartform SDKにコンパイラが入ってる
0416デフォルトの名無しさん2005/09/25(日) 22:44:21
gccかぁ。Cygwinでやる場合Cygwinも64bit版じゃなきゃだめでしょうか。
0417デフォルトの名無しさん2005/09/25(日) 22:57:26
>>416
Cygwin64/mingw64はまだじゃないかな。gccは当面はLinux等だね。
0418デフォルトの名無しさん2005/10/01(土) 10:52:05
>>341
亀レスですまんが、たまにはPPC版NTのことも思い出してあげてください
0419デフォルトの名無しさん2005/10/01(土) 10:53:50
PPCゎbi-endianじゃないっけ？
0420デフォルトの名無しさん2005/10/01(土) 11:27:37
>>418-419
PPCはリトルエンディアンとビッグエンディアンを初期化時に選択できて
Windows NTが使っているのはリトルエンディアンモード
0421デフォルトの名無しさん2005/10/01(土) 11:53:32
>>418
PowerPCにはWindows CEがあるじゃないか。

まだサポートされてたよな？
0422デフォルトの名無しさん2005/10/02(日) 12:32:21
>>418
でもって、WinCE でもやっぱり little endian しかサポートされてないん
じゃなかったっけ。違った?
0423デフォルトの名無しさん2005/10/02(日) 13:19:43
あぁendianの差が移植の最大の障害になってたのかWindowsは。
てことはx86系のUnixとかLinuxはendianの関係で余計なオーバーヘッド
背負ってるのかな。使ったことないからわからないけど。
0424デフォルトの名無しさん2005/10/02(日) 13:26:23
>>423
そんなことはない。Microsoftの技術が稚拙なだけ。
0425デフォルトの名無しさん2005/10/02(日) 13:43:25
そうだよなぁ。LHAなんてbig endianのだけど
別にパフォーマンスで特に問題なんてないよなぁ。

まあWindowsはクライアント以外には用のないOSだから
需要の点で移植が進まなかったんだろうけど。
需要があるんなら金の力でなんとかしただろうし。
0426デフォルトの名無しさん2005/10/02(日) 13:48:04
あぁｺﾞﾒｿ勘違いだ。LHAはlittle endianだ。
0427デフォルトの名無しさん2005/10/02(日) 13:50:20
TCP/IPのヘッダなんかはbigだよね。
効率悪いからlittleに変えようなんて話、出てこないよな。ｗ
0428デフォルトの名無しさん2005/10/02(日) 13:58:35
ヘッダとかアクセス頻度が低いものならほとんど何の影響もないよね。

えらい昔68000でZ80のエミュレータを書いた時はエンディアンの違いがウザくて
閉口したもんだったけど。
アレがなけりゃ三割ぐらい性能アップしてたかも。
0429デフォルトの名無しさん2005/10/02(日) 14:10:32
そこでBSWAP命令ですよ。
0430デフォルトの名無しさん2005/10/02(日) 14:50:38
>>423
Linuxはもともと386用のカーネルだったわけですが。
つか、まともなコードなら両方対応できるようにマクロ切ってあるはず。


それはそうとPPCのVPERMユニットってあまりにリッチなんだが
あれはエンディアンの変換用にあるんじゃないかって思った。
0431デフォルトの名無しさん2005/10/02(日) 15:21:00
やっぱりインラインアセンブラがないとダメですね
0432デフォルトの名無しさん2005/10/02(日) 15:33:15
単純にMMX/SSE使うだけなら昔ならともかく今は組み込み関数が使えるから必要ないといえば必要ない。
0433デフォルトの名無しさん2005/10/02(日) 15:48:31
PC用のソフトではがんばってインラインアセンブラで最適化しても
CPUが変わるとかえって遅くなったりしちゃうし。
0434デフォルトの名無しさん2005/10/02(日) 18:24:32
インラインアセンブラで書くよりも、
組み込み関数を使って書いたほうが、

・書くのが楽。書いたものを変更するのも楽。
・コンパイラの最適化は、そんなに悪くない

性能的には
SIMD使わない << インラインアセンブラで下手に書く < 組み込み関数でSIMDを使う < インラインアセンブラで上手に書く
だと思う。

自分の技量と使える時間に相談して、選べばいいと思うよ。


今のコンパイラはサポートしてなかったりするけど、
CPU別の最適化や、CPUのアーキテクチャが変ってMMXがなくなっても、SSE2を使うコードに変えてくれる
とかの将来性がある。
0435デフォルトの名無しさん2005/10/02(日) 18:40:25
MMX→SSE2はほとんど負担ねーと思うぞ。一度に2倍のデータを使うように改造するだけで殆ど事足りる。
0436デフォルトの名無しさん2005/10/03(月) 21:13:36
>>434
インラインアセンブラで下手に書く　＜　SIMD使わない
0437デフォルトの名無しさん2005/10/04(火) 04:04:41
まあ、SIMD使えば同時に扱うデータ量が倍になるし、下手なスケジューリングしても
アウトオブオーダ実行もあるから、SIMD不使用のコードより多少は速いってことはあるんじゃねーの？
整数の場合はAMD64で汎用ALU使ったほうが速そうだけど。

どのみちインラインアセンブラは使えなくなるんだし、*mmintrinで書いておけば、
各CPU向けに特化したスケジューリングはコンパイラがやってくれるから手間が省けるし、
来るマルチコア・メニィコアにうまくタスクを割り当てることに時間を割くほうが有意義だと俺は思ふ。
0438デフォルトの名無しさん2005/10/08(土) 13:22:31
> どのみちインラインアセンブラは使えなくなるんだし

Intel コンパイラや mingw の EM64T/AMD64 版がでたら、まず間違いなく
インラインサポートするでしょ? 使えなくなるっていうのは言い過ぎだと
思う。
.NET を普及させたいからネイティブコンパイラの方で手を抜いてたなんて
いった政治的理由だったりすると嫌だな。
0439デフォルトの名無しさん2005/10/08(土) 14:04:15
＞インラインアセンブラは使えなくなるんだし

マイケルソフトの糞コンパイラだけの話だろ。
0440デフォルトの名無しさん2005/10/08(土) 14:37:38
ICCのEM64T対応版はもう出てたと思うがなｗｗ
0441デフォルトの名無しさん2005/10/08(土) 16:40:25
まあ最近インラインアセンブラなんて使ってない俺にとってはどうでもいい話だがな。
0442デフォルトの名無しさん2005/10/08(土) 17:28:32
>>438
gcc-x86_64-linux-elf ならすでに asm ふつうに使えてる
0443デフォルトの名無しさん2005/10/08(土) 22:52:00
EM64T版ICCもインラインアセンブラは使えないよ。
0444デフォルトの名無しさん2005/10/09(日) 00:14:31
UNIX版iccの方はgcc互換にするって建前があるので、
使えるようにするんじゃねえ?
0445デフォルトの名無しさん2005/10/09(日) 00:35:00
>>443
インラインASM禁止はIntelが言い出したことじゃねーのかと思っている。

>>444
AMD独自拡張のニーモニックが含まれてるとエラー吐くのもIntelクォリティ
0446デフォルトの名無しさん2005/10/09(日) 01:00:49
まあそりゃインテルのコンパイラだし
0447デフォルトの名無しさん2005/10/09(日) 02:46:27
AMD64のCPUは高速なかわりにアセンブラプログラムを直接実行できない
無理にアセンブラを使おうとすると「互換モード」で実行されるので実行速度が非情に遅くなる

もう時代遅れのアセンブラは必要ないのですよ
0448デフォルトの名無しさん2005/10/09(日) 02:56:39
アセンブラプログラムってなんだそれｗｗ
0449デフォルトの名無しさん2005/10/09(日) 03:15:42
いやー、AMD64に限らず、CPUが直接実行できるのは機械語だけだし。


・・・・ということを言っているわけではなさそうだな。
0450デフォルトの名無しさん2005/10/09(日) 08:47:09
「互換モード」でアセンブラプログラムを実行できるAMD64最強w
0451デフォルトの名無しさん2005/10/09(日) 12:49:34
>>447
うわー電波
0452デフォルトの名無しさん2005/10/09(日) 12:53:20
>>447
>>アセンブラプログラム
きっとアセンブラ自体のことだなｗｗ
きっとアセンブルする時に動作劇重になるんだろうと、
ウルトラ良心的解釈でもしてみる。











んなわけねーだろ。電波。
0453デフォルトの名無しさん2005/10/09(日) 20:13:37
アセンブラで書いたコードをアセンブラでアセンブルして
アセンブればアセンブるときアセンブろう
0454デフォルトの名無しさん2005/10/16(日) 00:21:24
>>453
そんなにアセンブらないこと。
0455デフォルトの名無しさん2005/10/16(日) 18:17:30
　　　　　　∧＿∧ 　トンファーキ～ック！
　　　　　_（　 ´Д｀）
　　　 ／　　　　　　）　　　　　ﾄﾞｺﾞｫｫｫ　＿　　／
∩ 　/　,ｲ　、　　ﾉ/　　　　∧ ∧―＝￣　｀ヽ,　＿
| |　/　/　|　　　（ 〈　∵. ・（　　 〈＿_　>　　゛　、＿
| | ｜ |　 ヽ　　ｰ＝-￣￣＝_、　　（／　,　´ノ　＼
| | ｜ |　　　｀iー＿＿＝―＿　;,　／　／ ／←>>454
| |ﾆ(!、)　　　=＿二＿＿￣_=;,　／　／　,'
∪　　　　　/　 /　　　　　　　／　 ／| 　|
　　　　　／　 /　　　　　　　!､＿／ / 　 〉
　　　 ／ ＿/　　　　　　　　　　　　 |_／
　　　 ヽ､＿ヽ
0456デフォルトの名無しさん2005/10/21(金) 11:47:48
64bit期待age
0457デフォルトの名無しさん2005/10/21(金) 14:20:38
つくったよ
0458デフォルトの名無しさん2005/10/24(月) 17:15:18
なにを？
0459デフォルトの名無しさん2005/10/25(火) 00:33:32
よくわからないけど、たぶん中村さんの発明じゃないの？
0460デフォルトの名無しさん2005/10/31(月) 21:46:11
大賞の賞金100万円らしいが、何か考えてる香具師いるか？

Windows XP Professional x64 Editionソフトウェアコンテスト
ttp://win64xp.impress.co.jp/
0461デフォルトの名無しさん2005/10/31(月) 22:41:55
メモリorメモリ空間をむっちゃ使う類以外ので何かあるかなあ・・・
0462デフォルトの名無しさん2005/11/01(火) 01:38:12
諦めてる。
0463デフォルトの名無しさん2005/11/01(火) 01:40:08
レジスタをむっちゃ使う用途とか。
0464デフォルトの名無しさん2005/11/01(火) 01:50:48
PowerPCでいいだろそんなの。
0465デフォルトの名無しさん2005/11/01(火) 11:48:09
32ビットのDLLを64ビットのEXEから使うための何か。
32ビットのドライバを64ビットのWindowsで使うための何か。

そういうものを作ったら、ものすごく喜ばれるのではないかと。
0466デフォルトの名無しさん2005/11/01(火) 16:14:39
既にあるんだけど・・・
0467デフォルトの名無しさん2005/11/02(水) 06:48:48
>>466
まじですか?

それは何ですか?
0468デフォルトの名無しさん2005/11/02(水) 08:54:28
ただの感違いでしょ
0469デフォルトの名無しさん2005/11/02(水) 13:51:46
out-of-process COM とかかな。
0470デフォルトの名無しさん2005/11/02(水) 17:01:19
64bit版のIEで32bit版のplug-inというかActiveXコントロールが使えるとかでないと
意味がない。
out-of-processサーバーでできるとか言われても
新規にプログラムを書く必要があるなら最初から64bit版書けば済むわけで
0471デフォルトの名無しさん2005/11/03(木) 11:17:06
なんだかんだ言いながら、32bitに依存しまくったプログラムばかりだったということだ。
0472デフォルトの名無しさん2005/11/03(木) 12:58:21
ソースがなくて、既存バイナリをそのまま使わないといけない、という話だよ。
0473デフォルトの名無しさん2005/11/03(木) 13:05:31
そーっす。
0474デフォルトの名無しさん2005/11/03(木) 19:42:00
Windowsで遊びに使えて、4GB超のメモリを使えるLispインタプリタみたいなのを
作りたいんだが、intとポインタが64bitなコードを吐くコンパイラはもうありますか？
0475デフォルトの名無しさん2005/11/03(木) 19:49:44
もうあります。
0476デフォルトの名無しさん2005/11/03(木) 21:19:19
>>474
いざとなれば#define int boost::int64_tという手もあるｗ。
0477デフォルトの名無しさん2005/11/03(木) 22:14:28
4GB超のメモリを贅沢に使い潰して、マルチプロセッサでＧＣと本来の処理を並行させたり
したいわけだが。intだけ64bitになってもなぁ・・・。情報thx.
0478デフォルトの名無しさん2005/11/03(木) 22:21:05
>>477
Win64用のコンパイラなら、ポインタ64bitは当然。>>476はその上でintも64bitに
する方法を書いてくださっているのだ。
0479デフォルトの名無しさん2005/11/03(木) 22:25:34
ありがとうございます。精進いたします。
0480デフォルトの名無しさん2005/11/03(木) 23:04:18
4GB分のGCにかかる時間を想像してみたよ
0481デフォルトの名無しさん2005/11/04(金) 13:57:03
GCって出番があるのかな。

確保したいメモリ容量分の、連続した空き領域が存在しない確率は、かなり低くなると思う。
4GBのメモリに対して、数百MBのメモリを連続して確保したりするなら、別だけど・・・。


0482デフォルトの名無しさん2005/11/04(金) 13:59:44
マークするだけで５分とかかかりそう
0483デフォルトの名無しさん2005/11/04(金) 15:12:22
GCが新しいボトルネックということですね
0484デフォルトの名無しさん2005/11/04(金) 22:39:48
GBオーダー時代のGC手法
というのでペーパーかけそうだ
0485デフォルトの名無しさん2005/11/05(土) 20:30:26
4GB超のメモリ空間で動作するOSを考えると、ＧＣからは決して逃げられないと思うのだが。
各アプリがメモリを食い散らかして、freeせずにexit、という事象に対する耐久性は、メモリ量
向上ゆえに上がるかもしれないが、いずれ、ごみ集めが必要になる事態は避けられまい。
まして、連続稼動するアプリケーションサーバならなおさらである。
0486デフォルトの名無しさん2005/11/05(土) 20:39:10
>>485
ヘボイ根拠だね。
0487デフォルトの名無しさん2005/11/05(土) 20:41:48
その「4GB超のメモリ空間で動作するOS」とやらは
メモリ管理もろくに出来ない代物なのか？
0488デフォルトの名無しさん2005/11/05(土) 21:19:17
>>487
そうなんですよ。
0489デフォルトの名無しさん2005/11/05(土) 21:29:21
>>485
大体のOSはメモリがどのプロセスに属しているかという情報を管理していて、
プロセスが終了するときにはそのプロセスに属するメモリを丸ごと解放するようになっている。
0490デフォルトの名無しさん2005/11/06(日) 00:46:45
>>489
ブッブー。
メモリへの参照を外す、ですね。
もう少し勉強しましょう。
0491デフォルトの名無しさん2005/11/06(日) 00:48:22
そうそう。他のプロセスに悪さしないように、プロセスって概念があるのだからね。
OSがそこんところうまくやってくれてるんだよ。普通は。普通でないことが
しばしば起こる場合もあるが。
0492デフォルトの名無しさん2005/11/06(日) 00:50:07
>>490
だからそれはOSや処理系依存なんだって。もう少し勉強しましょう。
同じUNIX系でもAIXとLinuxは驚くほど仕組みが違う。
0493デフォルトの名無しさん2005/11/06(日) 00:54:07
>>492
で、で、でた、後だしジャンケン。
一部の実装を持ち出して云々されても・・・
0494デフォルトの名無しさん2005/11/06(日) 00:57:59
これだからJava厨は・・・
0495デフォルトの名無しさん2005/11/06(日) 02:01:15
よーわからんが
とりあえずだ。
頭の悪い俺にわかるように教えて欲しい。

環境はWindowsXPとLinuxとする。
アプリでmalloc()した領域をアプリ終了時にfree()しなかったら、まずいのか？
0496デフォルトの名無しさん2005/11/06(日) 02:11:50
全然まずくない。

サーバープログラムでメモリのフラグメントが気になるケースはあるが
よほど無駄な使われ方(4K内に1byteだけ頻繁にアクセスする等)でない限り
ページングによりある程度カバーできる。

というより、64bitだと「アドレス空間が足りない」という事態がまず起こらないので
ほぼページングによる「あまり使われていない領域のスワップアウト」で事足りる。
0497デフォルトの名無しさん2005/11/06(日) 04:31:27
AMD廚ウザイな。氏ねよ。
実際のプログラミング話が出て来ない所を見るとOpteron持ってないのか？

64bitプログラミングできるOSと言語ってどれが最強？
malloc(4GB)できるのある？
0498デフォルトの名無しさん2005/11/06(日) 08:12:12
>>497
Win64ならできるみたい。

#define _HEAP_MAXREQ 0xFFFFFFFFFFFFFFE0
0499デフォルトの名無しさん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

どれが「最強」かは各自の用途と財布の中身で変わってくる。
0500デフォルトの名無しさん2005/11/06(日) 13:51:13
このスレは重複しているので削除依頼だしておきます。
0501デフォルトの名無しさん2005/11/06(日) 14:15:31
> malloc(4GB)できるのある？

64 bit OSでそれができなかったら意味ないだろ。
0502デフォルトの名無しさん2005/11/06(日) 14:31:57
>>497の前半の無意味な煽りと後半の救いようのない教えてクンぶりから
推定(精神)年齢は12～14歳。
0503デフォルトの名無しさん2005/11/06(日) 15:42:27
>>485
それはプロセス内でGCするのではなく、
OSがプロセスに貸し出した物理ページをGCするということ?
物理ページが連続していなくてもいいと思うのだけど。

unix系の人の書いたコードは酷いのが時々あるね。
mallocしたのをfreeしないとか、
複数のスレッドから呼ばれることを考えてないライブラリとか。

マルチスレッドにせずに、シングルスレッドのプロセスをポコポコとforkしまくって、
1つずつのプロセスが短時間で終了することで、
リソースの管理をOSがやっているのだからアプリはやるのは二重管理で無駄
というスタイルは、ちょっとねぇ。
0504デフォルトの名無しさん2005/11/06(日) 15:55:04
パタヘネ？ヘネパタ？どっちだか忘れたけど簡単な方に、
ページングの仕組みとその利用方法が載ってるから、厨房は一度読むべきだな。
0505デフォルトの名無しさん2005/11/06(日) 16:09:46
>>503
> マルチスレッドにせずに、シングルスレッドのプロセスをポコポコとforkしまくって

そのせいで、Apache2はめっちゃ苦労してたな
0506デフォルトの名無しさん2005/11/06(日) 17:37:09
>>503
> unix系の人の書いたコードは酷いのが時々あるね。

よく理解もせずに、適当なこといいなさんな。
0507デフォルトの名無しさん2005/11/06(日) 17:40:57
ページング使っているのに何でGCが必要なんだよ。
アホじゃん。
0508デフォルトの名無しさん2005/11/06(日) 18:15:26
ページングとGCは別物で同居可能だと思うが？
0509デフォルトの名無しさん2005/11/06(日) 18:20:40
階層の違う話をいっしょくたに混同してないか？
どの技術も（場合によっては）必要だと思うが。
0510デフォルトの名無しさん2005/11/06(日) 19:20:50
共有メモリって参照カウント方式でGCされるやん。
0511デフォルトの名無しさん2005/11/06(日) 19:24:34
>>510
ここは理解不足を誇らしげに発表するスレですか？
0512デフォルトの名無しさん2005/11/06(日) 19:26:10
>>511
残念だがお前の理解が不足しているんだな
0513デフォルトの名無しさん2005/11/06(日) 19:35:16
OSメモリ管理ではページングがあるから、ガベージコレクションは
必要ないでしょ。
ユーザプログラム上での話ならGCの必要不必要はプログラマ次第。
0514デフォルトの名無しさん2005/11/06(日) 19:39:49
GCってプロセスが死ぬまでの話ね。了解？
0515デフォルトの名無しさん2005/11/06(日) 19:57:37
>477が話の始まり。
>485でOSのメモリ管理の話が出てきた。

で、今に至る。
0516デフォルトの名無しさん2005/11/06(日) 20:10:06
Java厨とは、分かってないのに分かったつもりになって
ぐだぐだと知ってる単語を並べるものだから。
0517デフォルトの名無しさん2005/11/06(日) 20:28:11
>>512
精一杯の皮肉乙
恥の上塗りですね
0518デフォルトの名無しさん2005/11/06(日) 20:32:31
そこで初めて読む486ですよｗ
0519デフォルトの名無しさん2005/11/06(日) 22:20:47
>>506
freeせずにexitは、unix文化ですよ。
0520デフォルトの名無しさん2005/11/06(日) 22:25:54
GCするのなんて、
8ビットのパソコンのBASIC
組み込みを考えていたJava
ヒープの速度がネックになるほどメモリ確保・解放をしまくるJava
くらいでしょ。

実際、Javaはすごかったよ。
プロファイラで見ると、信じられないくらいの回数、オブジェクトの生成・解放をやってる。
よくもまぁ、そんなにやっても、速度が出るなぁと感心したよ。
0521デフォルトの名無しさん2005/11/06(日) 22:32:35
.NET CLR も仲間に入れてやれよ。
0522デフォルトの名無しさん2005/11/06(日) 22:34:32
UNIX使ってる人はメモリ確保するまでは慎重にやって
その後はぞんざいに扱う人が多い気がする。
0523デフォルトの名無しさん2005/11/06(日) 22:54:32
DOSや組み込みでプログラミングしてた人の方が
メモリは慎重に扱うかもしれない？
UNIXはカーネルハッカーとアプリケーションプログラマで
メモリに対する意識はかなり違いそう。
0524デフォルトの名無しさん2005/11/07(月) 00:03:18
>>519
>freeせずにexitは、unix文化ですよ。

そうそう。で、どこが酷いのだろうね？
ユーザレベルでの、ママゴトみたいな解放処理を省いただけで。
0525デフォルトの名無しさん2005/11/07(月) 00:16:05
まさか
GC：言語処理系のための不要なメモリ回収の仕組み
としか考えられないのかな？
0526デフォルトの名無しさん2005/11/07(月) 00:32:08
さすがにそこまで頭悪いとは思わんが
0527デフォルトの名無しさん2005/11/07(月) 00:36:42
はいはいわろすわろす
0528デフォルトの名無しさん2005/11/07(月) 00:38:13
>>525
は？こいつ何言ってんの？
頭おかしいんじゃね？
バーカバーカ
0529デフォルトの名無しさん2005/11/07(月) 01:23:31
もうちょっと気の利いた煽りを入れてくれよ。
そんなんじゃ見てる方が恥ずかしくなってくるわ。
0530デフォルトの名無しさん2005/11/07(月) 10:19:08
はいはいわろすわろす
0531デフォルトの名無しさん2005/11/07(月) 20:27:09
>>524
短時間で終了するプロセスをポコポコとforkするunix文化なら、問題にはならないかもしれない。

長時間動き続けるプロセスの場合、
もう使っていないメモリを掴んだままになるので、
リソースがもったいない。
0532デフォルトの名無しさん2005/11/07(月) 20:30:51
たとえば、関数が100個あり、
それぞれの関数が内部ワーク用として、それぞれ1MBのメモリをローカルに使うとする。

関数100個を順番に呼び出していく場合、
ちゃんとfreeするようになっていれば、全体で1MBのメモリで済む。
freeしない場合、全体で100MBのメモリが必要になる。

メモリを1GB搭載したPCで、上記プログラムを20個走らせた場合、どうなるか考えてみてよ。
0533デフォルトの名無しさん2005/11/07(月) 21:02:18
相変わらず話の噛み合わないスレだな
0534デフォルトの名無しさん2005/11/07(月) 22:04:43
で、おまいら結局何GBまでメモリ積んで走らせたことあるんですか？
構成込みで情報ｷﾎﾞﾝﾇ
0535デフォルトの名無しさん2005/11/07(月) 23:08:27
>>532
順番に呼び出していくのなら仮想記憶があれば大丈夫じゃないか？
0536デフォルトの名無しさん2005/11/08(火) 00:28:57
>>535
いちいちスワップアウトしちゃうじゃんという話では？
0537デフォルトの名無しさん2005/11/08(火) 03:24:28
malloc/free のナイーブな管理で安心しちゃ駄目だよ。

俺なら、長時間の稼働が求められるときは、
最初にガバっと確保したメモリを自前で管理する。

皆はどうしてるの？
0538デフォルトの名無しさん2005/11/08(火) 03:50:02
こまめに確保
0539デフォルトの名無しさん2005/11/08(火) 07:17:32
こまめに自前でHDDに入れたり、メモリに出したりしてる。
OSなんて信用しねぇ！
0540デフォルトの名無しさん2005/11/08(火) 09:25:31
ときどき虫が湧くな
0541デフォルトの名無しさん2005/11/08(火) 14:18:03
>>536
どうせされる時はされるだろ
0542デフォルトの名無しさん2005/11/08(火) 20:40:50
>>541
いちいちされるように作ることはないのでは？
0543デフォルトの名無しさん2005/11/08(火) 22:57:44
>>518
その前にはじめての8086。な，いいからオレの言うこと聞いとけ。
0544デフォルトの名無しさん2005/11/08(火) 23:07:55
eaxとかの32ビットレジスタ載ってないじゃん
0545デフォルトの名無しさん2005/11/08(火) 23:19:04
>>543
釣りか？
セグメント関連とか今では忘れたほうがいい話が多すぎるだろ。
0546デフォルトの名無しさん2005/11/08(火) 23:30:19
>>545
オマエはプログラミング言語は得意みたいだが
自然言語はかなり不得意みたいだなw
0547デフォルトの名無しさん2005/11/09(水) 09:09:49
>>546
ここはそんな人ばっかりです
0548デフォルトの名無しさん2005/11/09(水) 09:50:06
はいはいわろすわろす
0549デフォルトの名無しさん2005/11/10(木) 00:35:57
>>537
そういう人がいるのだけど、
やっていることがCランタイムライブラリのヒープ以下だったりする。
0550デフォルトの名無しさん2005/11/10(木) 00:39:54
>>541
そこで>>532の例ですよ。

もし物理メモリが1GB余っている場合、
スワップされるのは、
ちゃんとfreeしていた場合1000個以上同時。
ちゃんとfreeしない場合10個以上同時。

されるときはされるが、
されるまでの処理能力が違う。
0551デフォルトの名無しさん2005/11/10(木) 00:48:48
つまり、あなたはfreeを呼ぶ度にメモリをOSに返す、
つまりfreeの度にカーネルモードに移行するという非常にコストのかかる処理を行う、

そんな糞ライブラリを常用していると言うことですか？
0552デフォルトの名無しさん2005/11/10(木) 00:56:57
ちなみに、普通のメモリ管理の実装では
freeを呼んでもOSにメモリブロックを返したりはしないよ。
少なくとも、毎回必ず返すなどというバカな実装はあり得ない。

で、OSから見たら、メモリは「プロセスに割り当てたか否か」でしか区別しないから
「ライブラリが管理している(free済み)」「アプリケーションが管理している(未free)」の違いはない。
アプリケーションが管理していても、使っていれば(アクセスがあれば)別だけど
そんな領域は、そもそもfree出来ないわけだし。
0553デフォルトの名無しさん2005/11/10(木) 01:07:17
Windows の DLL って扱い違わなかったっけ
0554デフォルトの名無しさん2005/11/10(木) 06:49:40
普通のプログラマが、>>532みたいな「バカみたいな無駄」を平気で残していると考えるのは、Java厨だけ。
もちろん、普通の「Javaプログラマ」も、>>532みたいなやり方が異常だということはよく分かっている。
分からないから、「Java厨」と呼ばれる。
0555デフォルトの名無しさん2005/11/10(木) 12:53:03
Javaについては↓の記事が興味深い。（別に信者でも布教活動でもないぞ）
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml
0556デフォルトの名無しさん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) ;
}

の違いの話をしているのですが。
0557デフォルトの名無しさん2005/11/10(木) 20:39:28
Windowsの方が仮想メモリシステムをアプリケーション側から細かく制御できるんだっけ
0558ものは言いよう2005/11/10(木) 21:01:29
Windowsの方が仮想メモリシステムをアプリケーション側から細かく制御しなくてはなりません
0559デフォルトの名無しさん2005/11/10(木) 22:29:55
>>556
その、メモリリークのバグ入り糞プログラムと
64bitに何の関係があるのですか？

まさかとは思うけど、64bit==デュアルコアとか思ってないですよね？
0560デフォルトの名無しさん2005/11/10(木) 22:33:46
もう一つ。

Javaにおいても、大きなバッファ等をローカル変数に割り当てたままで
別のメソッドを呼び出す事が、当然出来ますが
このバッファがGCにより回収されると思っていますか？

>>532の「freeせずに別の関数を呼びだす」とは、↑と同じことですが
GCがあれば、このような事が起きなくなるとでも思っていますか？
0561デフォルトの名無しさん2005/11/10(木) 22:47:42
>>560
回収されるんじゃない？
0562デフォルトの名無しさん2005/11/10(木) 22:51:38
>>561
メソッド呼び出しから戻った後、実行可能性のある部分がそのローカル変数を
参照していたら当然GCされない。（逆は必ずしも真ではないことに注意）
0563デフォルトの名無しさん2005/11/10(木) 22:53:47
資源を大切にね！
0564デフォルトの名無しさん2005/11/10(木) 22:57:29
>>562
そりゃぁ、それを回収したら GC じゃなくて・・・なんて言うの（ｗ？
556の下のほうのように参照が無くなれローカル変数だって回収されるでしょ。
0565デフォルトの名無しさん2005/11/10(木) 23:02:50
>>564
それをGC様が判断できるかという問題になるな。
ローカル変数の入ってるスタックフレームが開放されるまではGCの対象に
ならないと考えるほうが（プログラマとしては）安全側の配慮だと思う。
0566デフォルトの名無しさん2005/11/10(木) 23:04:34
もちろん >>556 の下の場合のようにローカル変数（この場合はp）を上書き
していれば、最新のもの以外は確実にGCの対象になる。
0567デフォルトの名無しさん2005/11/10(木) 23:16:42
そ。
何のためにわざわざnullを代入するか、ってことだよ。

まあ、実際には、ローカル変数に対してnullを代入するケースは少ないけど
何らかの(ローカルを含む)変数が指している領域は
GCの対象にはならないわけ。
だから、Javaでも>>532は当然起こる。

>>556でfreeを入れると何が違うかといえば
ライブラリが別のところからのmalloc呼び出しに対して再利用可能にすること。
これはJavaにおいて、nullを代入してGC可能であることを明示するのとまったく同じ。

だから、>>532のケースを「GCがあれば」と論じるのは妥当ではない。
0568デフォルトの名無しさん2005/11/10(木) 23:19:45
一応。
「null入れときゃいいじゃん」という理論には
「freeすればいいじゃん」という言葉が返りますので。
0569デフォルトの名無しさん2005/11/10(木) 23:25:52
俺、GCのソースコード読んで理解したんだけど、すごいよ。
おまえらの無駄さが笑える程しっかりやってる。
それ以来、GCに頼れるところは頼りまくりまクリスティーヌ。
0570デフォルトの名無しさん2005/11/10(木) 23:34:56
まあ一口にGCと言っても、
実装は山ほどあるわけで。
0571デフォルトの名無しさん2005/11/10(木) 23:51:52
>>568
参照を消すことは比較的安全だけど、実体を消すことはそうではないことが多い。
同じだと思うのは極めてナンセンス。
0572デフォルトの名無しさん2005/11/10(木) 23:53:52
>>571
参照を消す＝その先の実態も消える。
0573デフォルトの名無しさん2005/11/10(木) 23:57:35
「参照にnullを代入して『GC対象であること』を明確にする」のと
「メモリブロックをfreeして再利用可能にする」のは別ですか。
そうですか。
0574デフォルトの名無しさん2005/11/11(金) 00:00:42
>>573
他からも参照されてる可能性を考えれば、別に決まってるじゃん。
0575デフォルトの名無しさん2005/11/11(金) 00:05:45
ローカル変数の話をしているのに
他からも参照ですかそうですか。
0576デフォルトの名無しさん2005/11/11(金) 00:06:29
ローカル変数っていうか、ローカルで用いるバッファだな。>>532のような。
0577デフォルトの名無しさん2005/11/11(金) 00:09:46
だから、何が争点になっているのかを明確にしてくれよ。
0578デフォルトの名無しさん2005/11/11(金) 00:13:28
なんだ、論点もわからず揚げ足取りしてたのか
0579デフォルトの名無しさん2005/11/11(金) 00:29:37
もはや64bitプログラミングと何ら関係ない論争になっている点について

ていうかそんなにGCの話がしたけりゃ、GCスレ立ててそっちでやってくれよ。
0580デフォルトの名無しさん2005/11/11(金) 00:33:27
OSレベルのメモリ管理の話をしてるとき（だよね）に「Java厨」とか無意味な呪文を
唱えてGC原理主義者を召還するからじゃないのか？
0581デフォルトの名無しさん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厨２「何が争点になっているのかを明確にしてくれよ」
0582デフォルトの名無しさん2005/11/11(金) 00:37:14
>>580
ごめん。まとめてたらモロに。。。ほんとごめん。

というか>>485とか>>532とか、それ以外の言葉が浮かばないんだもん。
(「Java使い」は「Java厨」とは違うよ)
0583デフォルトの名無しさん2005/11/11(金) 00:39:52
だからOS側の管理の話とプロセス内のヒープの管理の話をごっちゃにしてるんだろ？
GC云々ってのは（普通は）後者の話でしょ？
0584デフォルトの名無しさん2005/11/11(金) 01:56:33
結論としては、Java最強、ということで。
0585デフォルトの名無しさん2005/11/11(金) 02:09:25
おまえら.NET CLRは無視ですかそうですか。
0586デフォルトの名無しさん2005/11/11(金) 02:11:15
別に無視じゃないが、パフォーマンスはネイティブの１／３でメモリ使用量は数倍ってイメージ。
0587デフォルトの名無しさん2005/11/11(金) 02:22:23
64bitマンセーって逝ってる香具師とJavaマンセーって逝ってる香具師は同じ痛さを感じるのは気のせいだろうか(w
現状では32bitでC使ってるソフトが最速だ。
0588デフォルトの名無しさん2005/11/11(金) 02:43:32
>>587
正しいがつまらん。
0589デフォルトの名無しさん2005/11/11(金) 08:13:24
Javaはいつ標準化されんの？後出しのC#はECMA標準規格が存在するけど。
0590デフォルトの名無しさん2005/11/11(金) 10:47:26
jabaは字実上の標順だからｗ
ECNAに票準してもらってるC$と比べないでほしいねｗ
0591デフォルトの名無しさん2005/11/11(金) 11:20:29
>>590
>>590
0592デフォルトの名無しさん2005/11/11(金) 11:24:15
>>590
ﾜﾛﾀ
0593デフォルトの名無しさん2005/11/11(金) 21:09:53
64bitのCLRって32bitのより速いん？
05945562005/11/11(金) 23:50:51
unix文化だとmallocしてもfreeしない
というのはJava登場以前からある話です。


0595デフォルトの名無しさん2005/11/11(金) 23:55:03
>>594
異文化に対する偏見だ。必要ならやるし必要なければやらないだけ。
0596デフォルトの名無しさん2005/11/12(土) 00:46:57
>>594
それ何て文化？
0597デフォルトの名無しさん2005/11/12(土) 01:03:53
Javaは配列の添え字がint固定だね。
java.nioのByteBufferもintでしか範囲指定できないし。
Javaアプリケーションは64bitアドレスをリニアに扱えないってことか。
0598デフォルトの名無しさん2005/11/12(土) 01:16:17
>>597
intは符号付きしかないから、現在の仕様では2G要素（事実上2Gバイトか？）が
一つのオブジェクトの大きさとしては限界になりそうだね。超でかいファイルを
一気にマップしてランダムアクセスなんてやるときは、マップし直したりする手間が
入りそうだな。
0599デフォルトの名無しさん2005/11/12(土) 02:21:07
リニアな配列でデータ扱う必要があるケースって稀だと思うが。
0600デフォルトの名無しさん2005/11/12(土) 02:55:07
>>594
「unix文化」と言い切るからには、そういうやり方をしているプログラムを複数挙げてくれよ。
もちろん、おまえの言うように
「10-100M単位で確保」「複数同時に動かす可能性もある」もので
「使い捨てでない」「実際に実用的な」ものを、な。

当然だが、「exit前のfree」問題の話じゃないぞ。
「使い捨てバッファ」を「ひたすら確保だけして解放しない」プログラムを、な。

「unix文化」は、昔から、ソースからコンパイルするのが当然だから
「それが普通」なら、ソースコードがいくつでもあるはずだよな。
0601デフォルトの名無しさん2005/11/12(土) 03:13:51
例えばファイルを処理するのに
ちまちま一行ずつ読んだりブロックで読んだりせず
statでサイズを取ってmallocし、まとめて一気に読み込む、みたいなやり方は確かにある。

けど、これをサーバー(daemon)でやるわけないし
多数のファイルを扱うプログラムが、
ファイル毎に別のバッファを確保するようなやり方になっているとは
とても思えないが。
0602デフォルトの名無しさん2005/11/12(土) 08:21:37
Javaは32bit時代のプログラミング言語なんだよね
64bitのパワーを生かすならJavaは選択肢から外すことになる
0603デフォルトの名無しさん2005/11/12(土) 08:23:20
601
> ちまちま一行ずつ読んだりブロックで読んだりせず
> statでサイズを取ってmallocし、まとめて一気に読み込む

mmap使うだろそれ

600
>「使い捨てバッファ」を「ひたすら確保だけして解放しない」プログラム

昔のgnuのgrepなんかがそうだった気がするyo
いまはどうだか知らんが
0604デフォルトの名無しさん2005/11/12(土) 08:25:00
そういう用途だったら今ならmmapするのが多いとは思う。
statでサイズが取れるってことはnonseekable streamを相手にしなくてよいわけ
だから。
0605デフォルトの名無しさん2005/11/12(土) 08:38:47
で、何GBというサイズのファイルをmmapしたいときに、64 bit OS の出
番ですよ！！！11！
0606デフォルトの名無しさん2005/11/12(土) 09:32:51
>>602
64bitのパワーってなんですか？
0607デフォルトの名無しさん2005/11/12(土) 09:45:29
>>606
> >>602
> 64bitのパワーってなんですか？

こと、x86-64に限って言えば、メモリ空間が32bit(4GB)を超えること。
汎用レジスタが64bitに拡張されているため、42億を超える整数を
扱えること。

決して、命令を64bit毎にフェッチするから速い、VLIWだ、なんてことはない。
0608デフォルトの名無しさん2005/11/12(土) 09:53:21
> 64bitのパワーってなんですか？
すごい消費電力
0609デフォルトの名無しさん2005/11/12(土) 10:51:25
>>604
たとえば、CIFSをマウントしてもmmapは無理だよね。
多くのソフトは、mmap不可なときへの対応も必要だよね。

# 可能なとき、mmapするのには異論ないよ。
0610デフォルトの名無しさん2005/11/12(土) 11:57:32
>598
> intは符号付きしかないから、現在の仕様では2G要素（事実上2Gバイトか？）が
細かい話だけど、Javaのlong配列だと8バイト×2G要素=16GBになる。
0611デフォルトの名無しさん2005/11/12(土) 12:16:24
>>610
今のJavaVMで2G以上の大きさの配列ってnewできる？
0612デフォルトの名無しさん2005/11/12(土) 12:18:28
>>605
Javaってさ、4GB超えるサイズのmmapってできるのかなあ
できないんじゃ・・・ちょっと・・・
0613デフォルトの名無しさん2005/11/12(土) 14:44:09
>>608
つ[座布団]
0614デフォルトの名無しさん2005/11/12(土) 21:30:13
>>605
まさしくその通り。
でないと昔のEMSを彷彿とさせるような切り替えをプログラマがやらなきゃいけない。
0615デフォルトの名無しさん2005/11/12(土) 22:21:38
>612
FileCnannel.map()の引数は64ビットになってるから、実装次第かと。
64ビットOS上で動作するJVMなら大丈夫なのでは。
0616デフォルトの名無しさん2005/11/12(土) 22:43:57
>>615
いや、だからmapし直さないとファイル全体をアクセスできないって話でしょ。
ByteBufferのほうは2Gまでしかシークできないから。
0617デフォルトの名無しさん2005/11/13(日) 00:34:44
>>609
OSによるでしょ。
Windowsはリモートのファイルをメモリマップできるよ。
原理上、ローカルのファイルのメモリマップとの相違点に要注意だけど。


64ビットならファイルをメモリマップで、というのは乱暴すぎるよ。
OSのVMはそんなに賢くないし、ましてやエスパーでもないので、
もう参照しない場所までマップしたまま放置しておくのは良くない。
0618デフォルトの名無しさん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) した方が
勿論いいけど。

結局場合によりけりかな。
0619デフォルトの名無しさん2005/11/13(日) 06:07:41
>>602
最悪の場合でもVMで動いてるJavaや.NETはVM上で32bitモードとか64bitモードとか
モードを分ければすむことじゃないか？
コンパイラのオプションを指定するのと同じように起動時に指定させればいいように
VMを作ればいいだけじゃん
0620デフォルトの名無しさん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 からも
出るんじゃないの?
0621デフォルトの名無しさん2005/11/13(日) 08:24:08
Javaで
long[] long_array = new long [ 2*1024*1024*1024/*2G個*/ ];
はできますか？
0622デフォルトの名無しさん2005/11/13(日) 09:07:29
>>617
> 64ビットならファイルをメモリマップで、というのは乱暴すぎるよ。
> OSのVMはそんなに賢くないし、ましてやエスパーでもないので、
> もう参照しない場所までマップしたまま放置しておくのは良くない。

普通のページングと同様に参照しなければ実メモリはそのうち別のプロセスに
使われるので全然問題ありませんが。
そりゃ、プログラマがアクセス特性をきっちり把握してれば陽に制御した方がVM
任せよりはよくなることが多いだろうけどさ。
0623デフォルトの名無しさん2005/11/13(日) 09:11:38
Javaは賢いから大丈夫ですよ（苦笑）
0624デフォルトの名無しさん2005/11/13(日) 11:49:38
64bit版のJava VMではIntが64bitになったりしないの？
64bit版のVM使ったことないからわからない
誰か教えて
0625デフォルトの名無しさん2005/11/13(日) 13:00:50
Javaの言語仕様が変わらない限り32bitのまま。
0626デフォルトの名無しさん2005/11/13(日) 13:08:22
JavaとゆうかJVMが32bitしか考えてないからな
0627デフォルトの名無しさん2005/11/13(日) 13:08:43
>624
VMの仕様上intは32bit固定になってる。配列の確保時のサイズ指定や、
配列アクセス時のインデックスも32bit固定なので、64bit対応にするためには
VMに新しい命令を追加するしかない。
0628デフォルトの名無しさん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
0629デフォルトの名無しさん2005/11/13(日) 13:19:59
Java Plug-inﾏﾀﾞｰ? (AAry
0630デフォルトの名無しさん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

だろ大抵。
0631デフォルトの名無しさん2005/11/13(日) 18:58:33
自分の世界だけで語らんでくれたまえ厨房
0632デフォルトの名無しさん2005/11/13(日) 19:03:27
>>630 みたいなバカが死滅するまでプログラマーは低賃金長時間労働者の
ままなんだろうな・・・
0633デフォルトの名無しさん2005/11/13(日) 19:09:12
純粋にわからん。int＝64bitな処理系ってあんの？
shortやlongって何ビットなんだ？
0634デフォルトの名無しさん2005/11/13(日) 19:13:07
JBossのようにひとつのVMでマイクロカーネルモデルをやってるようなアプリが64it化で使いやすくなるかな。
0635デフォルトの名無しさん2005/11/13(日) 19:16:07
>>634
知ったかすんな。いい子ぶりやがって。
0636デフォルトの名無しさん2005/11/13(日) 19:18:46
>>634
おめーが発してる単語一つ一つにどれだけの人がかかわって
苦労したのかわかってんのかよ。
JBoss, VM, カーネル、マイクロカーネル、カーネルモデル、アプリ、64bit化。
おまえが発するには荷が重すぎる。
0637デフォルトの名無しさん2005/11/13(日) 19:19:24
どういうたたかれかただよ
0638デフォルトの名無しさん2005/11/13(日) 19:24:24
>>633
ILP64でぐぐれ。
0639デフォルトの名無しさん2005/11/13(日) 19:37:49
>>634
>>636
>>637
ワロータ
0640デフォルトの名無しさん2005/11/13(日) 20:38:00
ILP64 採用してるのって、昔の CRAY ぐらいでしょ。
ほぼ全ての 64bit OS は 630 の言う通りで、
LP64 (UNIX 系) か LLP64 (Windows 系) の筈。
0641デフォルトの名無しさん2005/11/13(日) 20:43:28
>>640
今は亡きAlphaがILP64じゃなかったっけ？
0642デフォルトの名無しさん2005/11/13(日) 21:17:07
>>622
別プロセスに使われるまでが、問題なのです。
やってみればわかるけど、全体のパフォーマンスが落ちます。
0643デフォルトの名無しさん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日までは新規納入のための受注を受け付けてる
ので、まだ死んでない。死にかけだけど。
0644デフォルトの名無しさん2005/11/13(日) 21:49:23
>>642
やったことあるけど落ちないよ。
0645デフォルトの名無しさん2005/11/13(日) 22:42:32
Java最強ってことでFA?
0646デフォルトの名無しさん2005/11/13(日) 23:04:36
一時バッファの終了処理はおおざっぱにvectorとか、boost.scoped_arrayとか使う、
OSが勝手に確保するような特殊なのは関数内クラスで終了処理する。
C言語できちんと書くのは面倒、結論 C++ を使え。
0647デフォルトの名無しさん2005/11/13(日) 23:04:52
最強厨はJavaでも使っておとなしくしてなさい、ってことで。
0648デフォルトの名無しさん2005/11/13(日) 23:31:23
Javaはポインタ使わないからC言語ほど32bit→64bitの考慮の必要はないね
0649デフォルトの名無しさん2005/11/13(日) 23:49:14
議論を蒸し返すのも嫌なので上に頷いておく。
0650デフォルトの名無しさん2005/11/14(月) 09:18:57
>>644
メモリが余りまくってるからじゃないか?
0651デフォルトの名無しさん2005/11/14(月) 09:47:30
今からこのスレは貧乏スペック自慢スレになりますた
0652デフォルトの名無しさん2005/11/14(月) 12:18:16
Javaなら64bitのこと考えなくていいから、むしろ32bitの速いCPUで十分な罠。
0653デフォルトの名無しさん2005/11/15(火) 10:14:31
>>634
>>636
>>637

ﾜﾛｽ。>>636の叩き方は愛があるな
0654デフォルトの名無しさん2005/12/14(水) 18:15:03
0655デフォルトの名無しさん2006/01/07(土) 20:58:14
見事な廃れっぷりだな。64bitはまだ先ってことでFA
0656デフォルトの名無しさん2006/01/07(土) 21:32:28
Vistaで半ば強制移行。
0657デフォルトの名無しさん2006/01/07(土) 21:44:58
結局 x86-64 に軍配？
って、 x86-64 ってのは正式名称？
0658デフォルトの名無しさん2006/01/07(土) 22:05:17
初期にAMD64と言われていたものを広く浸透させるために
会社の名前を取って一般名称にしたとかなんじゃ。
インテルの力でEM64Tの呼称が浸透する可能性もなきにしもあらず。
0659デフォルトの名無しさん2006/01/07(土) 22:07:05
マイケルソフトは x64 と四㌦ね
0660デフォルトの名無しさん2006/01/07(土) 22:09:22
>>658
http://ja.wikipedia.org/wiki/X86-64
どうやら逆らし。

MSはx64で統一するつもりらし。
0661・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/01/08(日) 00:27:10
Intelにとっては主役は飽くまでIA64(IPF)だからね。
0662デフォルトの名無しさん2006/01/08(日) 00:30:31
>>661
そこは笑うところですか？
0663デフォルトの名無しさん2006/01/08(日) 00:34:17
そんなことより、もともと Intel が進めていた
x86 互換の 64bit 拡張と、AMD64 との間の違いを知りたい。
0664デフォルトの名無しさん2006/01/08(日) 00:35:13
まぁインテルの現状を見る限り大したことはしてなかったと思う
0665デフォルトの名無しさん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：全モード
0666デフォルトの名無しさん2006/01/08(日) 01:27:20
>>665 え？ AMD64 と EM64T の間に違いがあったのか。
ってことは、マイクロソフトがいう x64 ってのは
実は異なる二つのアーキテクチャの総称？？？
0667デフォルトの名無しさん2006/01/08(日) 01:42:49
>>666
386 と 486 程度の違いだから、同じアーキテクチャと言ってよいと思う。
それに一口にEM64Tと言ってもプロセッサモデルによって多少の違いはあったりするし。
0668・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/01/08(日) 01:43:24
>>665
Prescottの現行ステッピングではAMD64は全部サポートしてるような。。。
0669・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/01/08(日) 01:44:44
>>666
MS謹製のx64 Assemblerでは互換性の無い命令は使えないようにしてたハズ。。。
0670デフォルトの名無しさん2006/01/08(日) 03:43:00
>>668
最初から全部サポートしていればなぁ。
サポートしていないCPUが存在すれば、使えないわけで。

ちゃんとインテルに情報開示しなかったAMDが悪いよ。
今まで散々、互換プロセッサで商売してきたのにさ。
0671デフォルトの名無しさん2006/01/08(日) 03:45:27
>>670
ちゃんと開示してるよ。
0672デフォルトの名無しさん2006/01/08(日) 08:03:38
>>671
ほんと?

俺が読んだ記事では、
AMDの資料に問題があり、インテルがAMDと同じように実装できなかった
ということになっていたが。

なんでも、AMDの資料には、AMDのCPUの実態とは違うことが書いてあったらしい。
0673デフォルトの名無しさん2006/01/08(日) 08:08:11
結局 Microsoft は無難な共通点だけを使うってことかな。
で、それを x64 って呼ぶよってことじゃないか？
0674デフォルトの名無しさん2006/01/08(日) 13:20:09
きちんとオリジナルを調べる責任は常にコピーする側にあると思うが。
0675デフォルトの名無しさん2006/01/08(日) 15:12:35
AMDの初期のdocに書きそこねがあったんでしょ
intelも意地張らずにすり合わせしとけばよかったのに、と思う
0676デフォルトの名無しさん2006/01/08(日) 17:01:03
ダンプに関数パラメータ情報が無いという素敵なx64のABIを策定した奴を100回ﾇｯｺﾛｼﾀｲ。
0677デフォルトの名無しさん2006/01/08(日) 21:27:22
レジスタ渡しで、スタックに引数を積まない、のかもな。

>>675
AMDのCPUに対して、ドキュメント通りの実装ではないのでエラッタだ、
AMDのほうが修正すべきだと要求するのが本来の筋だと思うんだな。

インテルは度量が大きいから、
しかたねーな、こっちが合せてやるよ、
ってことになったのだと思われ。
0678デフォルトの名無しさん2006/01/08(日) 21:29:09
>>677
エラッタってのは具体的に何の話？
少なくとも>>665に書いてる話は最初からドキュメントされているが。
0679デフォルトの名無しさん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)と書かれている。
0680デフォルトの名無しさん2006/01/09(月) 00:11:12
どっちにしても実チップが存在したのだから、それに合わせるのが「互換チップ」の
基本だわな。インテルはそういうことに慣れていなかっただけだろう。
0681デフォルトの名無しさん2006/01/09(月) 00:23:10
>>679
あのさ、LAHFもSAHFも代替可能な古い命令だぞ？
そこまで目くじら立てる理由がわからん。
文章では64bitモードで使えないと書いておいて、後からx87との互換性かなんかで
横槍入って一応使えるようにしておいたってだけだろうが。
SSEを推進しているIntelがそれを実装していなかったとしても何も問題ないし、
OSベンダーやソフトハウスが最大公約数としてのx64を考えているのなら賢明だってだけじゃんか。

x64互換としてのAMD64とEM64Tと考えれば何も問題はない。
0682デフォルトの名無しさん2006/01/09(月) 00:38:16
実際、AMD64とEM64Tで「互換性がなくて困る」って話は聞かないもんな。
0683デフォルトの名無しさん2006/01/09(月) 00:47:04
> 目くじら立てる

そう、 >>665 にある命令で、差異があることで本当に困るものって無いんだよね
それを吟味せずにピーピー騒いでるのは滑稽。

あ・・CMPXCHG16Bってどうだろ。
0684・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/01/09(月) 01:32:58
そもそもx86-64の設計に横槍入れてたMSがx64アプリではx87をサポートしないんじゃなかったっけ。
AMDとしては3DNOW!なんかの資産のあるFP/MMレジスタベースを生かしたほうが有利だっただろうけど
結局XMMレジスタを生かすことになったってのは、ある意味Intelの思惑がかなった形だわな。

まぁMSはコンパイラが象徴するように「80bit浮動小数なんていらねーよ」って態度貫いてきたからね。
それよかXMMレジスタベースで高精度浮動小数サポートしてほしくね？
0685・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/01/09(月) 01:36:11
x64アセンブラの本とかって出版されてる？
製本されたリファレンス欲しい。
なぜか無駄にItaniumのアセンブラ本持ってたりするがｗ
0686デフォルトの名無しさん2006/01/09(月) 07:34:21
NX(Intelの呼び名ではXD)ビットはさすがにサポートの有無を判別して動作してるな。
0687デフォルトの名無しさん2006/01/09(月) 17:53:33
インテルが度量が大きいというのはどういう視点で見るとそうなるんだろう
0688デフォルトの名無しさん2006/01/09(月) 20:13:55
資本力が大きいですし・・・
0689デフォルトの名無しさん2006/01/09(月) 21:25:51
Itaniumは結局消えるのかな。
あまりマトモに扱われているという話を聞かない。
0690デフォルトの名無しさん2006/01/10(火) 00:49:39
>>682-683
ピーピー騒いでいるのは、
何がなんでもインテルを叩きたいAMD厨
なんですよ。
0691デフォルトの名無しさん2006/01/10(火) 01:51:31
マカーじゃないかな？
真の64bitはmacだけ、ということにしたいわけだし。
0692デフォルトの名無しさん2006/01/10(火) 01:53:47
>>691
もうすぐ仲間になるんだから、仲良くやりましょうよ。ｗ
0693・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/01/10(火) 01:54:37
まぁ無理やり付け足した感もないところが綺麗だわな。
もともと32bitのPPCは「64bit CPUの32bitバージョン」ということらしいし。
0694デフォルトの名無しさん2006/01/10(火) 03:25:28
>>692
これまでのマカーから行動から予想するに
AMDを叩きだすだろうな
0695・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/01/10(火) 03:51:27
>>694
それなんてMacオタ氏？
0696デフォルトの名無しさん2006/01/10(火) 19:20:36
AMD厨はマカーよりもたちがわるい。
0697デフォルトの名無しさん2006/01/10(火) 20:50:03
厨はとにかくたちがわるい
0698デフォルトの名無しさん2006/01/11(水) 15:22:32
Win64(x64)の仕様ではx87レジスタは使用してはいけないという話だが
SDKのmathライブラリ内でx87命令が使われている。どういうことか？
0699デフォルトの名無しさん2006/01/11(水) 16:09:46
>>698
user-modeではx87レジスタは使用可だよ。
kernel-では使っていけないという話なのに・・・
0700デフォルトの名無しさん2006/01/11(水) 16:52:27
ユーザーモードで利用可じゃないとそもそもx87使った32bitアプリを
動かせないんじゃないの？いや、よく知らないけど。
07016982006/01/11(水) 17:24:19
>>699
レスどうも。
自分でも調べてみたのですがそのようですね。
0702デフォルトの名無しさん2006/01/11(水) 18:54:13
>>700
まあ仮想PCみたいに変換噛ませば不可能じゃないんじゃない？
パフォーマンス落ちるだろうけど。
0703デフォルトの名無しさん2006/01/12(木) 00:25:23
とにかくAMD厨はたちがわるい
0704デフォルトの名無しさん2006/01/12(木) 00:27:37
そろそろ鬱陶しいな
0705デフォルトの名無しさん2006/01/12(木) 01:23:27
>>700
32ビットアプリの話ではなく、64ビットアプリの話ですよ。
0706デフォルトの名無しさん2006/01/12(木) 13:23:13
厨うざい

>>705
拡張精度が扱えるのはFPUだけではない?
なので「非推奨」ということで。
0707デフォルトの名無しさん2006/01/12(木) 14:22:47
>>705
Longモード（要するに64bitのOSが乗っかってる状態）だと、32bitと64bitのプロセスが
混在する中でマルチタスキングしないといけない。
最低限FP/MMレジスタの退避をサポートする必要があるわけで、64bitでも
結果的に「使える」という話。

だからFP/MMがレジスタ拡張されるわけでもなく、消されるわけでもなく、
残ってるのはそのため。

MMXはともかく、x87の場合「スタック」として扱うから論理レジスタ本数増やしても
パフォーマンスの向上しえないしね
0708デフォルトの名無しさん2006/01/12(木) 14:47:29
>>707
＞SDKのmathライブラリ内でx87命令が使われている。

とあるが、パフォーマンスの向上しえないのになぜMSは使っているのか。
手抜き？
0709デフォルトの名無しさん2006/01/12(木) 15:30:20
作ったやつしか知らないよ。
0710デフォルトの名無しさん2006/01/13(金) 22:53:50
53bitの精度を出すには53bitの演算じゃ手間がかかるってことさ
0711デフォルトの名無しさん2006/01/15(日) 03:25:16
X64対応のXeonでx87命令使うとめっさ遅い気がする。
ia32 同クロックのXeon上で同じ32bitバイナリを
動かしたときの３倍は遅い。
何か下方修正があった？
0712デフォルトの名無しさん2006/01/15(日) 10:21:56
SIMD 命令を使えって言う神様のお告げじゃないのか。
0713デフォルトの名無しさん2006/01/15(日) 17:04:48
Intel MKLのem64t版でもx87使っててめっさ遅いルーチンがあるのさ。
0714・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/01/15(日) 18:36:18
80bit精度使ってるからじゃなくて？
0715デフォルトの名無しさん2006/01/15(日) 19:55:39
x87使うのはもち80bit精度のため。
OpteronはSSE2よりx87使って書いた方が
速いことも多いんだけどなぁ。
0716デフォルトの名無しさん2006/01/15(日) 23:02:18
結局>>711の遅い原因は何であるっぽいの？

内部80bitだからって32bitでは遅くならないが。
（メモリ転送や平方根、除算などを除いて）
0717デフォルトの名無しさん2006/01/16(月) 00:25:13
なぜOpteronには4倍精度がないのだ。
0718・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/02/08(水) 22:23:20
ICC9の64bit向けコンパイラってコア別最適化がWとPしかサポートされてないんだが
Wって32bitと同じくWillametteだとしたら暗にSSE3未サポートの初期AMD64向けの最適化オプションだよな。
Prescottコア以降でしかEM64T使えないし。

Woodcrest（MeromベースXeon）？まさかね。
0719デフォルトの名無しさん2006/02/18(土) 18:32:23
TextSSを64bit版でコンパイルして欲しい
0720デフォルトの名無しさん2006/02/18(土) 18:40:56
６４bitでネイティブ動作する2chブラウザをつくろう
0721デフォルトの名無しさん2006/02/19(日) 20:34:00
>>707
> MMXはともかく、x87の場合「スタック」として扱うから論理レジスタ本数増やしても
> パフォーマンスの向上しえないしね

FXCH命令のレイテンシ、知ってる？
0722デフォルトの名無しさん2006/02/19(日) 22:52:28
命令数の問題じゃないんか？
0723・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/02/20(月) 03:34:40
P6以降のCPUでfxchって実行自体されない気が。
0724デフォルトの名無しさん2006/02/20(月) 05:54:06
リネーミングになるからじゃんじゃか使えという話をみたような。
0725デフォルトの名無しさん2006/02/20(月) 13:22:01
そしてデコーダは燃え上がる。
0726デフォルトの名無しさん2006/04/05(水) 21:02:01
http://www.forest.impress.co.jp/article/2006/03/24/64bitcon_result.html
結局こういうのがじゅしょうするわけか。
まあ、他に作りようがないけどなあ。
ある状況下で少し速くなるとか作りやすいとかの変化でしかないもんな。
0727デフォルトの名無しさん2006/04/09(日) 21:21:42
うーわ、ものごっつつまんね。
0728デフォルトの名無しさん2006/04/12(水) 01:18:37
age
0729デフォルトの名無しさん2006/04/22(土) 11:29:26
だから64bitなんざSVHSだって言ってんだろ。
0730デフォルトの名無しさん2006/06/08(木) 01:16:06
　
0731デフォルトの名無しさん2006/06/08(木) 16:28:57
で、64bit環境でアセンブラいじってるヤシはおらんのか。
0732デフォルトの名無しさん2006/06/09(金) 00:03:18
つ[ http://user64.psychedance.com/2005/09/mty20050910_x64.html ]
0733デフォルトの名無しさん2006/07/18(火) 21:17:33
Core2の64bit性能がイマイチということだが、
このスレの過疎っぷりを見ると問題なさそうだな。
0734デフォルトの名無しさん2006/07/18(火) 22:13:16
そのせいでMSがvista 64bitをプッシュしなくなっちゃった！

サーバサイドではプッシュしまくりだがね。
0735デフォルトの名無しさん2006/07/18(火) 22:34:58
簡単な(初心者でもできる)プログラミング教えてください！！
0736デフォルトの名無しさん2006/07/18(火) 23:31:39
>>735
無い。
なんだかんだ言ってどれも平等に難しい。
0737デフォルトの名無しさん2006/07/23(日) 01:40:41
64bit Windowsは窓使いの憂鬱が対応するまで移行できん……。
0738デフォルトの名無しさん2006/07/23(日) 02:12:56
なんのためにソースが公開されてるんだとか言ってみる
64bitならコンパイラも含めて無料で手に入るし
0739デフォルトの名無しさん2006/08/11(金) 01:03:54
x64のMS Access ODBC Driver ってあるの？
0740デフォルトの名無しさん2006/08/11(金) 01:10:19
VC8 MFCソリューションから使用できる
COMコンポーネントのFlexGridを
誰か知りませんか。
MSFlexGrid6.0 はx86しか対応してないし・・・
昔作成したプロジェクトをx64対応させなあかん
のやけど、Grid系は.Net Framworkコンポネーントでしか
見つからんし
0741デフォルトの名無しさん2006/09/20(水) 12:17:28
さしあたり、Vistaの64bit版が出たらだね。
アセンブラで増えたレジスタの効果を確かめるのと、
対応コンパイラでどれだけ高速化するかがネタになる。
0742デフォルトの名無しさん2006/09/20(水) 21:55:58
XP x64ではできない画期的な何かがVista x64にはあるんですか?
0743デフォルトの名無しさん2006/09/20(水) 22:10:10
XPx64は誰にでもお勧めできる代物じゃないからね。
64ビットプラットフォームとしてVistaに期待できるでしょ。
0744デフォルトの名無しさん2006/09/20(水) 22:19:20
まだ最終製品でないから断言はできないがVista x64も誰にでもお勧めできるかは微妙だよ
http://itpro.nikkeibp.co.jp/article/COLUMN/20060911/247700/
「4Gバイトを越えるメモリーが必要だとか，特殊なアプリケーションが必要だとか，そういった
特別な用途がなければ，x64版のWindows Vistaを無視するのが無難だ。」
0745デフォルトの名無しさん2006/09/25(月) 11:23:08
>>744
改善されるのを願うしかないなあ。
64bitモードでアセンブラをいじるという用途のために、
次は64bitOSを選ぼうと思っていたんだが。
0746デフォルトの名無しさん2006/09/25(月) 12:02:51
16→32bitの時のような待望感が32→64bitではないね
0747デフォルトの名無しさん2006/09/25(月) 12:09:32
逆に、128bit化する必要は当分ないというのはあるかも。
ビット数を倍にすると扱える数は2倍でなく2乗になるからな。
完成形の64bitを早く定着させてほしいものだ。
0748デフォルトの名無しさん2006/09/25(月) 12:12:13
128bitの型の名前は一般名称として定着しているのはありますか？
byte 8bit
short 16bitのように。
0749デフォルトの名無しさん2006/09/25(月) 12:21:47
QWORD
0750デフォルトの名無しさん2006/09/25(月) 12:35:11
byte 8bit
word 16bit
dword 32bit
qword 64bit
tbyte 80bit

PUNPCKLQDQとかのニーモニックからすると
128bitはdqword？
0751デフォルトの名無しさん2006/09/25(月) 12:39:01
128bitのデータって一般的なのは IPv6 のアドレスくらいかな。
（もちろん１「ワード」として扱える必要は特に無いだろうけど）
0752デフォルトの名無しさん2006/09/25(月) 12:58:37
>>751 IPv6、なるほど。
0753デフォルトの名無しさん2006/09/25(月) 13:03:41
IEEE754rが広がってきたとして、
浮動小数点はやっぱり
float 32
double 64
quad 128 でしょうか？
0754デフォルトの名無しさん2006/09/25(月) 14:12:08
UUID (GUID)も128bitある。
0755デフォルトの名無しさん2006/09/25(月) 14:24:16
128bit型は、だいぶ使い道あるし、大事じゃん。
64bit型はそうでもなかったけどさ。
0756デフォルトの名無しさん2006/09/26(火) 09:16:36
short 16bit
int 32bit
long 64bit
long long 128bit
こんな処理系も出てくるかな。
0757デフォルトの名無しさん2006/09/26(火) 10:34:28
very long とか longer の方が面白い。ｗ
0758デフォルトの名無しさん2006/09/26(火) 11:13:11
longestを出してしまったらそこで終わりだ。
人間、向上し続けることが大事だ。
0759デフォルトの名無しさん2006/09/26(火) 11:36:12
longer than longer 256bit
longer than logner than longer 512bit
　　　　　　　・
　　　　　　　・
　　　　　　　・
0760デフォルトの名無しさん2006/09/26(火) 12:41:11
きりが無いから
signed{32} x;
unsigned{128} y;
みたいな表記がいいな。
0761デフォルトの名無しさん2006/09/26(火) 12:45:35
例えばint128を組み込み型としておいて、
typedef int128 longer;
とか、やっぱり typedefっぽく
ユーザーが型宣言というか型定義っぽくなるのかなと思う？
0762デフォルトの名無しさん2006/09/26(火) 17:58:55
C99的には当然、int128_tとuint128_tとして提供されるんだろう。
0763デフォルトの名無しさん2006/09/26(火) 18:32:43
みんな独自定義して
short, int, longのような共通とかないんだろうと思っちゃう…
0764デフォルトの名無しさん2006/09/26(火) 20:27:21
wow64で動いている32bitアプリから64bitのDLLを呼び出す場合ってDCOM使わんと駄目？
0765デフォルトの名無しさん2006/09/26(火) 21:42:54
Microsoftがいやがるような裏技はあると思うぞ
少なくともwow64.dll wow64win.dll wow64cpu.dllの3つはマップされてるんだから
0766デフォルトの名無しさん2006/09/27(水) 00:28:01
逆に比べれば簡単だろうな
0767デフォルトの名無しさん2006/09/28(木) 22:27:54
なんでWin16/32のときのようなサンクを用意しなかったんだろう？
0768デフォルトの名無しさん2006/09/29(金) 23:33:52
IA-64版と機能差を付けたくなかったんだろう
0769デフォルトの名無しさん2006/10/01(日) 09:53:55
Vistaインストールしたので64bitのプログラムを
作ってみたいのですが、いいコンパイラはありますか？
Borland C++ Compilerをずっと使っていましたが、
どうやら64bit版はないようで・・・
0770デフォルトの名無しさん2006/10/01(日) 10:10:03
>>769
とりあえずPlatform SDKをインストールすればVC++の64bit版コンパイラも付いてくるはずだぞ。
0771デフォルトの名無しさん2006/10/01(日) 17:46:52
>>769
ActiveBasicww
0772デフォルトの名無しさん2006/10/01(日) 17:53:55
>>770
VisualStudio2005 TeamSuiteはインストールしていますが、
さらにPlatformSDKも入れる必要がありますか？

>>771
とりあえずC++のが欲しいんですよｗ
0773デフォルトの名無しさん2006/10/01(日) 18:03:04
>>772
Visual Studioを持っているなら、それが使えるはずだ。
俺持っていないから詳しくは知らないけど。
0774デフォルトの名無しさん2006/10/02(月) 01:45:51
だめだorz
コンパイルしても動かないorz
0775デフォルトの名無しさん2006/10/02(月) 05:55:07
Borland C++は64ビット対応してないの?
0776デフォルトの名無しさん2006/10/02(月) 06:35:35
してない
0777デフォルトの名無しさん2006/10/02(月) 07:09:07
>>774
まさかこんなメッセージが出てないよな？
...は有効なWin32アプリケーションでありません。
0778デフォルトの名無しさん2006/10/07(土) 16:50:19
TeamSuiteを入れる人間の質問とは思えないんだが…
0779デフォルトの名無しさん2006/10/07(土) 20:41:17
割れ物注意ｗ
0780デフォルトの名無しさん2006/10/10(火) 02:30:57
VS2005で、純粋仮想関数を使った基本クラスをライブラリ（libファイル）に
し、その派生クラスと仮想関数をmainのあるところで書いてコンパイルしよ
うとすると、リンクエラーでリンクできません。解決方法はありますか？
0781デフォルトの名無しさん2006/10/10(火) 07:32:18
>>780
それは普通は問題ないはずだけどな。
64bitコンパイラだけで起きる現象なら何かあるかもしれないが、
32bitでコンパイルしても同じ現象が出るようなら単なるコーディングミスだと思う。
答えが欲しいなら再現性のあるコードをアップしてみて。
0782デフォルトの名無しさん2006/10/15(日) 00:19:06
ここで質問していいのかどうかよくわかりませんが、教えてください。
１テラバイトくらいのメモリを必要とするアプリを開発＆実行させたいのですが、
WindowsXP64bit版でVisual Studio 2005を使って開発したアプリは、1テラバイト
のメモリ空間を利用できますか？
0783デフォルトの名無しさん2006/10/15(日) 00:37:19
メモリ空間は8TBのはず
0784デフォルトの名無しさん2006/10/15(日) 00:40:15
>783
ありがとうございます。
そうすると、500GBのHDDを20台くらい使えば、8TB使うアプリを
ページングしながら動かすことはできますかね？
0785デフォルトの名無しさん2006/10/15(日) 02:37:10
物理メモリを8TB積め
0786デフォルトの名無しさん2006/10/15(日) 04:23:03
現在の６４ビットのPCサーバーで１６GBから６４GBくらいが最大搭載容量だからつらそ。
0787デフォルトの名無しさん2006/10/15(日) 08:57:13
>786
ありがとうございます。
PCは64GB程度のメモリ搭載を想定しています。そこにページング用のHDDを
沢山乗せて、64bitのOSを使って数テラバイトのメモリ空間を使うアプリ
を動かしたいのです。現時点で、そういうことは可能でしょうか？
OSはwin,linuxなど何でもOKです。
0788デフォルトの名無しさん2006/10/15(日) 09:24:44
動いても凄い遅そうだな。
0789デフォルトの名無しさん2006/10/15(日) 12:16:38
一体何の処理をするんだ？
0790デフォルトの名無しさん2006/10/15(日) 12:37:12
脳内だけで、釣りだろ。
0791デフォルトの名無しさん2006/10/15(日) 18:23:01
>789
ええっと、ある種のシミュレーションです。
>790
釣りではありません。実際にやりたいのです。

0792デフォルトの名無しさん2006/10/15(日) 18:28:26
クラスタとかとまた違うのか？
まあPCの性能限界に挑戦とかなら興味ないしどうでもいいけど。
0793デフォルトの名無しさん2006/10/15(日) 18:46:23
>>791
本当に物理的に8TBもの場所にアクセスが必要なの？
必要なところだけポインタであれするとかできないのか。

本当に必要なら、どんなシミュレーションか気になるね。
0794・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 2006/10/15(日) 18:50:53
リニアアドレッシングさえ考えなければ32bitでも不可能じゃないと思う。
0795デフォルトの名無しさん2006/10/15(日) 19:29:32
大規模って言うか壮大な計画がなら、豊富な資金を用意して、
ハード面は業者任せ（比較的安い価格で組む特注ハード）？だと思おうけどさ。
たいていは、数人のハッカー企業か大学の研究室で、予算ないんだろうな。
もし本当にやるつもりなら、人柱でヨロシク。
性能比較をHPで公開してよ。結果楽しみ…
0796デフォルトの名無しさん2006/10/17(火) 23:43:02
できるものならクラスタリングした方が、、、
0797デフォルトの名無しさん2006/10/18(水) 09:56:19
障害時の被害が凄そうなシステムだ
0798デフォルトの名無しさん2006/10/18(水) 11:58:37
>>794

それを言ったら64bitのアドレッシング全否定じゃん
16bitだって可能
0799デフォルトの名無しさん2006/10/18(水) 12:34:25
実際に搭載される物理メモリが増えたときの性能的利点のために今から64bitで作っておく
というのが多いんじゃないかな。
0800デフォルトの名無しさん2006/10/18(水) 12:47:52
>>799 それを本腰で使うのはいつからだ？素人は黙ってろ。
0801デフォルトの名無しさん2006/10/18(水) 12:49:13
>>800
馬鹿は黙っててくれ
0802デフォルトの名無しさん2006/10/21(土) 05:15:26
ランダムアクセスの場合、ディスクはメモリの100万倍くらい遅いので、
64GBしかメモリがないのに、8TBあるつもりでアクセスしたら、
64GBあるつもりの場合の128倍じゃなくて128*100万=1億倍くらい遅く
なりそうだが、それでもいいんだろうか。

問題を分割して、メモリ64GBのマシンを128台用意して解いた方が
いいんじゃねえ？
0803デフォルトの名無しさん2006/10/21(土) 05:43:11
スラッシングというやつだな。
アクセスを局所化しないで物理メモリより大きな仮想メモリを使うのは馬鹿
0804デフォルトの名無しさん2006/10/21(土) 07:53:50
馬鹿にも使える64ビット電卓
0805デフォルトの名無しさん2006/10/21(土) 08:50:34
スラッシングの意味違わない？
0806デフォルトの名無しさん2006/10/21(土) 10:51:15
>>782
OSは何でもいいというんだからSolarisでもいいんだろう。
これ買え。1TB載るそうだから。
http://jp.sun.com/products/servers/highend/sunfire_e25k
0807デフォルトの名無しさん2006/10/21(土) 13:05:36
>>802
アクセスパターン次第。完全にランダムなアクセスでない限りそういう単純計算の
程度よりは速くなるように設計されている。「100万倍遅い」というのも誰に聞いたか
知らんが不正確。とりあえずもうちょっと勉強しなさい。

>>806
物理メモリを1TB載せたいなんて話は誰もしてないと思う。
0808・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 2006/10/21(土) 15:53:50
アクセス速度と信頼性両立するならRAID0+RAID1でどーよ
0809デフォルトの名無しさん2006/10/21(土) 20:38:25
>>807
でも素直にできるだけ物理メモリが沢山載るマシンを買った方が
賢いと思うぞ。
0810デフォルトの名無しさん2006/10/21(土) 21:37:36
金があればそうだがTB越えだとメモリだけで億いくぜ。
0811デフォルトの名無しさん2006/10/21(土) 22:08:50
>>809
賢いかどうかは微妙
0812デフォルトの名無しさん2006/10/25(水) 11:28:02
782の本人ですけれど、
みなさんありがとうございます。
いろいろ参考になりました。Sunの1TBマシンは値段いくらかしりませんが
高くて買えないと思います。大規模なクラスタも予算、設置場所の点で
難しいです。ですので、64GBﾒﾓﾘくらいのSMPの8CPUくらいのマシン１台を
考えています。メモリアクセスは、ほとんどの場合ランダムではなく、
連続的に読み書きする場合が多いです。そいうい条件でも
ページングの影響でとても遅くなりますか？
たとえばdouble型8byteで1T個の配列を確保して合計8TB。
その1T個の配列を
for(i=1;i<1e12;i++){

0813デフォルトの名無しさん2006/10/25(水) 11:29:37
すみません、手が滑って、途中で書き込んでしまいました。
続きです。
なんていう風にループで回すと、どれくらいの計算時間になりますかね？
0814デフォルトの名無しさん2006/10/25(水) 11:38:41
ＰＣの寿命が先に尽きる希ガス
0815デフォルトの名無しさん2006/10/25(水) 12:07:38
>>813
自分でやってみれ。いきなり１TBでテストする必要は無いんだぜ。
小規模なテストモデルを考えて、自前のPCで動かしてみれ。
問題を分割出来ていないのが問題化と。
0816デフォルトの名無しさん2006/10/25(水) 14:31:30
>>812
100MBずつにループを分解してやれば、
32bitCPUのWinXPマシン＋大容量HDDで
できるんじゃないの？
0817デフォルトの名無しさん2006/10/26(木) 00:10:21
それ以前にループにフロート使っちゃダメだろ
0818デフォルトの名無しさん2006/10/26(木) 00:54:35
あ、気づかなかったｗ
1e12は整数の1000000000000のことだと思ったけど、
これは32bit整数じゃ表せない大きさだ。
floatではなおさらダメだがdoubleならできなくはない。
0819デフォルトの名無しさん2006/10/26(木) 04:03:45
整数に収まるかどうかは問題ではない
i++で下位ビットが欠ける数値はカウンターには使えないだろ
0820デフォルトの名無しさん2006/10/26(木) 04:35:59
それはi+=1.0とかにすればいいじゃん。
まあ、整数使え。
0821デフォルトの名無しさん2006/10/26(木) 05:03:39
だから桁が増えるとi+=1.0が欠けると
0822デフォルトの名無しさん2006/10/26(木) 05:53:39
>>821
doubleで1e12なら欠けない。
doubleは絶対値が2^53以下の整数を厳密に扱える。
0823デフォルトの名無しさん2006/10/26(木) 06:07:35
せっかくの64bit CPUなんだから64bit整数使えばいいじゃない(ﾏﾘｰ
64bit CPUじゃなくても64bit整数は使えるけど無理やりスレタイに関連付けてみた
0824デフォルトの名無しさん2006/10/30(月) 23:41:04
先日x64版Linuxに意味も無く移行した
自前のソースが全然コンパイルできなくて唖然とした
低スキルの素人プログラマだから自業自得なんだけど
閑話休題
おまえら！x86とx86_64でソース互換性を保ったままコーディングする方法について詳しく解説してる本とかサイト知ってたら教えてください
あ、言語はCです
0825・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 2006/10/30(月) 23:44:41
#include <emmintrin.h>

0826デフォルトの名無しさん2006/10/30(月) 23:56:53
asmを使わない
0827・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 2006/10/31(火) 00:00:20
型の大きさの表現に即値は使わない

例：　sizeof (int *)
0828デフォルトの名無しさん2006/10/31(火) 00:16:19
>>824
キャストは使わないｗ
0829デフォルトの名無しさん2006/10/31(火) 01:09:04
ポインタ型を整数型にキャストするときにはintptr_t/uintptr_t。
08308242006/10/31(火) 02:32:09
>>825-829
みなさんの仰られていることでぐぐったらやるべきことが見えてきた気がします
あれこれ調べながら小さいものから書き直してみようと思います
曖昧な質問なのにアドバイスありがとうございました
0831デフォルトの名無しさん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名等が違うだけで、基本的な考え方は同じ。
08328242006/10/31(火) 21:46:28
>>831
ありがとうございます
わかりやすくまとまっていてとても勉強になります
>>ALL
とりあえずmalloc()でsegmentation faultが出なくなりました！
この調子でマイペースに楽しみながらデバグしていこうと思います
本当にありがとうございました
0833デフォルトの名無しさん2006/11/26(日) 02:14:35
Insure++やDevPartnerなど、ランタイムエラーを捉えるツールで、X86-64
のWindowsXP64ビットで使えるものってありますか？
0834デフォルトの名無しさん2006/12/13(水) 01:20:52
ＦＦＦＴＰの６４ビット版つくってください
0835・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 2006/12/13(水) 01:26:19
あるじゃねーかｗｗｗｗｗ
0836デフォルトの名無しさん2006/12/13(水) 01:35:42
MS-DOSの64bit版つくってください
0837デフォルトの名無しさん2006/12/13(水) 01:44:55
64bitでネイティブ動作するテキスト置換ソフトは何を使ってる？
0838・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 2006/12/13(水) 02:12:02
テキスト置換なんか強いて64ビットでやる必要ねーだろ
0839デフォルトの名無しさん2006/12/13(水) 02:15:10
64bitにすればなんでも速くなるとでも思ってるの？
0840デフォルトの名無しさん2006/12/13(水) 13:12:51
おうよ！
0841デフォルトの名無しさん2006/12/13(水) 13:13:37
数値が２倍なんだから２倍速くなければ公取が動きますよ
0842・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 2006/12/13(水) 21:46:27
あふぉや
SSE2のpcmpeqb使って並列比較したほうがまだマシ
0843デフォルトの名無しさん2006/12/13(水) 22:34:13
>>835
あったっけ？＜ＦＦＦＴＰ６４ビット
0844デフォルトの名無しさん2006/12/13(水) 22:43:54
メモリ帯域は変わらないよね？
全部64bitにすると全部32bitの場合の半分の個数しかデータ送れないんじゃないの？

あんまり詳しくないけど。
誰か教えて。
08458442006/12/14(木) 14:16:29
むむ。誰からも返事が無い。
自分の疑問は合ってるのかな。
0846デフォルトの名無しさん2006/12/14(木) 16:58:05
>>844
64bit精度が必要なところ以外では
今まで通り32bit変数を使うから、
そういう心配はいらないのだ。
0847デフォルトの名無しさん2006/12/14(木) 16:59:56
　　　　　　　　　　 ∩＿
　　　　　　　　　 　〈〈〈　ヽ
　　　　　　　　　　〈⊃　　}
　　 ∩＿＿＿∩　 |　　 |
　　 | ノ　　　　　 ヽ !　　 !
　　/　　●　　　● |　　/
　 |　　　　( _●_)　 ミ／ ＜こいつ最高にアホ
　彡､　　　|∪|　　／
/　＿＿　 ヽノ　/
(＿＿＿）　　　/
0848デフォルトの名無しさん2006/12/14(木) 17:10:52
>>847
AAに同感するとは思わなかったが、同感だ。
0849デフォルトの名無しさん2006/12/14(木) 17:33:15
俺も知らんけど、アホとか言ってないで説明できないの？
0850デフォルトの名無しさん2006/12/14(木) 17:44:40
847がそうなのはわかったが、アホなのは844なのか846なのかはっきりしる。
0851デフォルトの名無しさん2006/12/14(木) 19:29:54
どう考えても846
0852デフォルトの名無しさん2006/12/14(木) 20:40:12
で、どうなの？
0853デフォルトの名無しさん2006/12/14(木) 20:50:59
広い範囲のメモリをバンバン読み書きするタイプの処理の場合、
844の心配は現実になるよ

整数なら範囲がわかっていれば32bitにすることもできるけど
ポインタはそうはいかないんだよねえ
0854デフォルトの名無しさん2006/12/14(木) 21:11:53
>>843
ソース公開されているんだから、自分で64ビット対応の修正すれば作れるのでは？
0855デフォルトの名無しさん2006/12/14(木) 21:12:29
ポインタだけでキャッシュに収まらないほどの量になるの？
0856・∀・）っ-{}@{}@{}@ ◆DanGorION6 2006/12/14(木) 22:06:46
収まるか収まらないかの問題じゃない。
転送帯域が同じなのにデータサイズが増えるならそれだけでスループット落ちる。

あとは命令サイズの問題か。
imm64とかをうかつに使うと命令フェッチ帯域圧迫されるしREX使えばそれだけで命令長1バイト増える。
Core 2 Duoは4命令同時デコードに対して16byte/clkの命令フェッチ帯域しかないから32bitのほうが速いことも多いよ。
08578442006/12/15(金) 12:34:25
なるほど。みなさんありがとうございます。
0858デフォルトの名無しさん2006/12/15(金) 21:13:10
>>856
理論的にはそうだが、自分で試した上での発言か?
0859・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 2006/12/15(金) 22:42:25
Pentium 4だと、レジスタ増えてるのにスループット全く変わらなかった。
SIMD演算ユニットの割にロード・ストアのスループットが良すぎるから
レジスタ数の増加程度で性能は伸びない。

従来型アーキテクチャだとデコード前の命令長の影響はもろに受けるからね。
Core 2 Duoで4 IPCが3 IPC前後に落ちる現象も知ってる。

ロード・ストアの頻度の多いプログラムでレジスタの増分性能が改善されたり、
あと4GB以上のメモリ空間が必要な処理なら十分性能出せるんじゃないかと。


つかね、ただパフォーマンスを上げるだけなら、現状、SIMD使った方がいい。
0860デフォルトの名無しさん2006/12/15(金) 23:39:55
別に排他的なもんじゃあるまい＞SIMDと64bit
0861・∀・）っ-○◎●創聖のダンゴリオン ◆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プレフィックスは
命令サイズを増大させるので、先に指摘した問題がある。
あと、レジスタが増えた分だけ待避・復帰処理の時間が増える。
0862デフォルトの名無しさん2006/12/16(土) 00:54:02
つか、64bitの利点はデータの幅じゃなくてアドレスの幅だべさ。
64bit整数なんて32bit環境でも普通に使えるべ。
0863デフォルトの名無しさん2006/12/16(土) 07:34:10
SIMDを多用して速度が向上するような処理は
REXプレフィックスの足かせよりレジスタ数増加の恩恵の方が大きいと思う。
0864デフォルトの名無しさん2006/12/16(土) 12:07:32
long long intを32bit環境でやると、遅いと言うより使いづらい。
配列なんて確保したら、殆どの場合セグメントフォルトだし
0865・∀・）っ-○◎●創聖のダンゴリオン ◆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のほうが優位。
0866デフォルトの名無しさん2006/12/16(土) 13:41:47
>>864
なんでやねん
0867デフォルトの名無しさん2006/12/16(土) 13:49:48
>>865
ダンゴリオンさんは、いろいろ書いてくれてるけど知識だけじゃなくて、
SIMD使ってとりわけ速くなる様なコーディング経験があったってことなん？
0868・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 2006/12/16(土) 14:10:11
いちおう有るには有る。64bitのほうはまだ世に出してないが
Core 2のSIMD整数モンスターぶりがよくわかるのは個人で出してる

0869デフォルトの名無しさん2006/12/16(土) 17:31:28
>>868
それ見たい。
0870・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6 2006/12/16(土) 18:13:12
おいらのサイト
ttp://tripper.kousaku.in/


John the Ripperのビルドなら自分で試してみるのも良いかなと
08718692006/12/16(土) 18:48:53
>>870
ありがとう。すごいなぁ。
08728672006/12/16(土) 20:23:29
>>870
ちらっと拝見しましたよ。NANDとNORを追加とかアセンブラ書きの人の言やねw
0873デフォルトの名無しさん2006/12/30(土) 21:34:35
>>824
遅レスだが、この人に聞けばいいヒントが見つかるかもしれない
ttp://pc9.2ch.net/test/read.cgi/notepc/1160039483/404
0874デフォルトの名無しさん2007/01/29(月) 00:26:58
>>854
作者に無断で改変して配布するわけには　いかんだろ
0875デフォルトの名無しさん2007/01/29(月) 00:43:44
>>874
フリーソフトなのにそんな変なライセンスなの？
0876デフォルトの名無しさん2007/01/29(月) 00:44:04
別に修正ＢＳＤライセンスなんだからいいんでねーの。
0877デフォルトの名無しさん2007/01/29(月) 11:09:28
俗に言う64bitCPUというのは何をもって64bitなのですか？
CPUからにょろっとでてる配線の数が64本だから？
ポインターの大きさが８バイトだから？
0878￣￣￣￣￣∨￣￣￣￣￣￣2007/01/29(月) 11:35:01

　┌┐.┌i　　 ┌┐　　__　┌┐　　| | [][]
　｜└[][]L.ﾛﾛ |　[][]　|　| ﾛﾛ |.[][] l└─┐
　｜┌┤.r‐┘│┌┘ | └┐└─┐l￣￣
　└┘..凵　　 └┘　　!　l￣__l￣￣.┘　　ﾞ!!
　　　　　　　　 　 　 　 └┘
　　　　　　　　　　　　 ∧＿∧　　　　!
　　　　　　　　　　　　（　＾∀＾）
　　　　(　　;;　　　　　⊂　　　）⊃
　　　(　(　　;(　;;　;　０爻爻爻０
0879デフォルトの名無しさん2007/01/29(月) 14:24:39
汎用レジスタのサイズじゃね？
0880デフォルトの名無しさん2007/01/29(月) 19:56:50
バス幅が64bitとか、
32bitが2つで64bit級とか。
0881デフォルトの名無しさん2007/01/29(月) 20:08:47
サターンを彷彿とさせるなぁ
0882デフォルトの名無しさん2007/01/29(月) 20:18:59
64bit Windowsのユーザーアドレス空間が
0x10000 - 0x0000 07FF FFFE FFFF x64
0x10000 - 0x0000 06FB FFFE FFFF itanium
こうなってるとか見たことがある。
CPUとしては倍の16TBくらいなのかな？
0883デフォルトの名無しさん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ビット級ってわけか?
0884デフォルトの名無しさん2007/02/01(木) 01:55:36
32bitからいきなり64bitなんてやりすぎだろ。まずは40bitくらいを目指すべきではないのか？
0885デフォルトの名無しさん2007/02/01(木) 02:29:02
アドレスバスとデータバスを混ぜるのは良くないですよ。
0886デフォルトの名無しさん2007/02/01(木) 07:06:43
>>884
現時点では48bitくらいしか使われてなくて残りは予約されてなかったっけ?
0887デフォルトの名無しさん2007/02/01(木) 12:38:02
今のプログラムはいわゆるタイニーメモリモデルだから
スモールメモリモデルにすれば8GB
ラージメモリモデルなら1024GBまでいけるな。
0888デフォルトの名無しさん2007/02/01(木) 13:29:08
ナツカシス
0889デフォルトの名無しさん2007/02/08(木) 14:08:53
このスレをざっと見てみたけど
float と double は32ビットから64ビットに移行しても
メモリ中に占めるサイズは変わらないってことですよね？
0890デフォルトの名無しさん2007/02/08(木) 21:53:33
流石にそれが変わったら大騒ぎｗ
0891デフォルトの名無しさん2007/02/09(金) 06:40:20
>>889
浮動小数点演算の場合はIEEE 754という縛りがあるんで、
単純にCPUの処理ビット幅が増えたからといってそのまま大きくするわけにもいかない。
0892デフォルトの名無しさん2007/02/09(金) 18:16:13
>>890-891
ありがとうございます。
0893デフォルトの名無しさん2007/02/09(金) 20:31:04
レジスタ幅(内部計算精度)がx87は80bitで、x86-64はSSE 64bitという違いがあるな。
0894デフォルトの名無しさん2007/02/09(金) 22:20:57
>>893
確かにx86-64だと80bit精度にはならないが、
それだとCで同じコードを書いても結果が異なるということになる。
元からdoubleは内部も64bitじゃなかったっけ？
0895デフォルトの名無しさん2007/02/09(金) 22:27:15
中間結果の精度が高いために結果が異なる場合がある。
もっとも64bitでなくても今はSSEのほうが速いので、いずれx87は廃れる運命だろう。
0896デフォルトの名無しさん2007/02/09(金) 22:52:49
結果が異なってもいい規格なのか。どうも。
まあ、今どきレジスタがスタック形式はないよな。
0897デフォルトの名無しさん2007/02/09(金) 22:55:48
浮動小数点は、定数のたたみ込み具合で値が変わるという話があったな。
0898デフォルトの名無しさん2007/02/10(土) 21:31:52
Javaで問題になったねえ・・・どう決着したんだっけ
0899デフォルトの名無しさん2007/02/11(日) 01:06:55
つ http://www.shudo.net/publications/NASDA-200212/
0900デフォルトの名無しさん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/
0901デフォルトの名無しさん2007/03/05(月) 13:13:40
x86版はXP x64で正常動作しないの？
0902デフォルトの名無しさん2007/03/05(月) 13:16:09
>900それくらい自分でやれよ
0903デフォルトの名無しさん2007/03/05(月) 17:02:23
つ V2C
0904デフォルトの名無しさん2007/03/07(水) 00:24:05
>>901
win32api つかってるからアウト
delphiで書かれたモノはアウト
まぁjava(v2c)もいいけど
x64対応があってもイイわな
0905デフォルトの名無しさん2007/03/07(水) 00:30:55
win32apiを使ってることはx64 Editionで動かない理由にはならないだろ。
Delphiで書かれたWin32用アプリってx64 Editionで動かないの？
何か大きな勘違いをしてないか？
0906デフォルトの名無しさん2007/03/07(水) 00:32:30
2chブラウザは大量メモリが必要なわけでもなく、高速な処理が必用なわけでもない。
64bit化することに全く意味がない。
0907デフォルトの名無しさん2007/03/07(水) 00:38:35
きっと64bit化しないと64bit OSで動かない（または遅くなる）と思ってるんでしょ
0908デフォルトの名無しさん2007/03/07(水) 00:38:47
OKわかった。とりあえず開発機材よこせ。
0909デフォルトの名無しさん2007/03/07(水) 00:43:29
自作板の64bit版2chブラウザスレ、厨房大杉でﾜﾛｽ
0910デフォルトの名無しさん2007/03/07(水) 01:18:14
過去ログ検索だったら分からんでもないが
それでも個人用途なら64bitは要らんだろうなあ
0911デフォルトの名無しさん2007/03/07(水) 01:33:06
オンメモリに2chの過去ログ全部のてみせます！
推奨メモリ・２５６GB
0912デフォルトの名無しさん2007/03/07(水) 01:35:30
発端が>>900だからなぁ、とてもそういうものを望んでるとは思えん。
0913デフォルトの名無しさん2007/03/07(水) 01:42:54
winの64bit版は32bitアプリ動かないのか
0914デフォルトの名無しさん2007/03/07(水) 01:51:45
まさか
0915デフォルトの名無しさん2007/03/07(水) 01:55:08
夜釣りご苦労様です。
0916デフォルトの名無しさん2007/03/07(水) 01:57:10
６４ｂｉｔて死滅しちゃうの？
0917デフォルトの名無しさん2007/03/07(水) 02:00:18
32bitからいきなり64bitなんて無茶するからだよ。
とりあえず34bitくらいから順に上げていくのが良いのではないか？
0918デフォルトの名無しさん2007/03/07(水) 02:03:08
何をどうしたらそういう発言ができるのかわからん
0919デフォルトの名無しさん2007/03/07(水) 02:03:31
あれあれ？いいんですか？
セグメントモデル復活させますよ？
0920デフォルトの名無しさん2007/03/07(水) 02:06:43
IA-64では復活したと聞いた
0921デフォルトの名無しさん2007/03/07(水) 02:08:30
そもそも多重仮想記憶やPAEはセグメントと言えないこともないな
0922デフォルトの名無しさん2007/03/07(水) 02:09:14
祝！FARポインタ(16+32bit)復活。
0923デフォルトの名無しさん2007/03/07(水) 02:10:22
これからやるなら64bit+64bitにしてください
0924デフォルトの名無しさん2007/03/07(水) 05:08:25
IA-64のポインタは一種のFARポインタだよ。
Win16の時代と違ってコンパイラが完璧に隠蔽してるだけで
参考:
http://msdn.microsoft.com/msdnmag/issues/1100/hood/
0925デフォルトの名無しさん2007/03/07(水) 18:02:37
>>924
セグメントレジスタというより基底レジスタに近い感じだな。
41bit/1命令 x 3命令 + 5bit ということは命令として直に指定できる値が限られるわけだ。
IBM S/360のアセンブリに似ている・・・
0926・∀・）っ-{}@{}@{}@2007/03/07(水) 21:11:34
RISCなどの固定長命令型アーキはみんなそうだよ
0927デフォルトの名無しさん2007/03/07(水) 23:05:26
むしろx86が特殊
「特殊」なもののシェアが大きすぎてそっちが標準的に見えてしまうけど
http://blogs.msdn.com/oldnewthing/archive/2004/09/14/229387.aspx
0928デフォルトの名無しさん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
0929デフォルトの名無しさん2007/03/07(水) 23:32:58
IA-64は2バンドル使って64bit即値代入してるな
0930デフォルトの名無しさん2007/03/08(木) 00:16:43
>>928
多少の非効率は押してでもx86からの以降のしやすさを狙ったのがx64だからね
0931デフォルトの名無しさん2007/03/09(金) 02:20:59
>>913
win32apiで組んだものは動かないのが多いよ
WoWはアテにならない
0932デフォルトの名無しさん2007/03/09(金) 02:21:29
またテキトーなことを
0933・∀・）っ-○◎●2007/03/09(金) 02:22:33
乞食がこっちのスレに戻ってきたか
0934デフォルトの名無しさん2007/03/09(金) 02:45:12
x64で動かすためにはポータブルメソッドで書き直さないとダメだろう
0935・∀・）っ-○◎●2007/03/09(金) 02:47:09
また知ったかぶりですか？
ただのtypedefとマクロなのにｗｗｗ
0936デフォルトの名無しさん2007/03/09(金) 02:48:31
団子がいままでx64向けに書いたものを見せてくれ
0937デフォルトの名無しさん2007/03/09(金) 02:48:46
ソースレベルの話なのかバイナリレベルの話なのかわけわからんな
0938デフォルトの名無しさん2007/03/09(金) 02:51:04
団子って delphi しか使えないひとなんでしょ？
0939デフォルトの名無しさん2007/03/09(金) 02:51:19
WoW（うぉーう）ってなんですか？
0940・∀・）っ-○◎●2007/03/09(金) 02:52:31
C/C++とDelphiのコードも見分けられないのか
馬鹿だな
0941デフォルトの名無しさん2007/03/09(金) 02:54:01
>>939
Window Of Windows
0942デフォルトの名無しさん2007/03/09(金) 02:54:22
>>931
そんなことはないよ。よほど行儀の悪いプログラムばかり使う人ですか？
0943デフォルトの名無しさん2007/03/09(金) 02:55:05
プログラム板にプログラム書けない人が来ても馬鹿にされるだけだよ
0944デフォルトの名無しさん2007/03/09(金) 02:55:15
#include <stdio64.h>

int main(){
printf("Hello X64 World! WoW!\n");
return 0L;
}
じゃ、駄目？
0945デフォルトの名無しさん2007/03/09(金) 02:56:01
ちょっと動かないソフトの例を挙げてもらえまいか
>941
ofではなくonだと思っていたわけだが
0946デフォルトの名無しさん2007/03/09(金) 02:56:27
なんでintとlongを混ぜるん？
0947・∀・）っ-○◎●2007/03/09(金) 02:58:56
>>945

えーと、>>944はコンパイルエラーになると思う
32ビット64ビット関係なく
0948デフォルトの名無しさん2007/03/09(金) 03:04:36
>>946
いや、漏れ的には64bitだからlong long int返せば64bitアプリになる思ったんだが駄目？
じゃ、最後はreturn　(long long int)0;　でどう？

>>947　手直しヨロシコ
0949・∀・）っ-○◎●2007/03/09(金) 03:06:12
インクルードファイルをオープンできません　'stdio64.h'
0950デフォルトの名無しさん2007/03/09(金) 03:08:18
入門者スレに誤爆したの誰？
95 名前：デフォルトの名無しさん ：2007/03/09(金) 03:05:00
・∀・）っ-○◎●　は x64でのデータ型の定義も知らずに何をほえているのか？
なんかVisualC++に挫折経験があるみたいだけどｗ
delphi 厨の典型だな
0951デフォルトの名無しさん2007/03/09(金) 03:08:48
だから64bit化なんてしなくてもWin32のままで動かせばいいじゃん
0952・∀・）っ-○◎●2007/03/09(金) 03:16:12
>>950
自作板の自スレに貼ろうとして誤爆したらしい
0953デフォルトの名無しさん2007/03/09(金) 03:20:32
Win32でﾌﾟﾛｸﾞﾗﾐﾝｸﾞするのも飽きてきた　→　何か新しいことをやりたい

こんなかんじかな

あとdriverとかは独自のが要るよな
0954デフォルトの名無しさん2007/03/09(金) 03:21:32
おーい、見てるかい、自作PC版ブラ君たち、ム版へおいでよ
そこ、そこスレ違い甚だしいだろ
0955・∀・）っ-○◎●2007/03/09(金) 03:22:17
俺はVIPからの出張人だ
0956デフォルトの名無しさん2007/03/09(金) 03:22:24
>948
じゃあなんでint main()なんだよ。
0957デフォルトの名無しさん2007/03/09(金) 03:23:15
>>953
Vistaでドライバー仕様が変わったからね、デバドラ人大変だよ
0958・∀・）っ-○◎●2007/03/09(金) 03:23:32
それ以前にstdio64.hってなに？
0959デフォルトの名無しさん2007/03/09(金) 03:26:15
>>956
お前が動くように汁、おれ、プログラム解らんよ
0960・∀・）っ-○◎●2007/03/09(金) 03:26:19
>>957
個人では実質的にカーネルモード触れなくなった。
HDコンテンツの保護が目的らしいが

MSの墨の付いてないデバドラを有効にすると、DRM保護コンテンツが再生できなくなったりとかｗ
誰が望んだんだろうねVistaって。
0961デフォルトの名無しさん2007/03/09(金) 03:31:19
>>958
よく効くおまじない

>>960
へー、良く分からんけどそうなんだ、DRMってなんだ
きっと、へぼいドライバー出入り禁止にしたいんだよ
0962・∀・）っ-○◎●2007/03/09(金) 03:39:42
簡単に言えばコピープロテクト。

カーネルモードドライバの挿入を無条件に許可してると
プロテクトを回避されるおそれがあるから

0963デフォルトの名無しさん2007/03/09(金) 03:46:31
>>962
すいません、カーネルモードって何なんですか？
だいたい、ユーザーの物は隔離したほうがいい！指輪はたくさんあるのにね
0964・∀・）っ-○◎●2007/03/09(金) 04:02:58
charからintへの代入を知らないと、貴方が心から思いこんでる相手に
ものを聞くのは間違いでしょう？

それとも、撤回できる？
0965デフォルトの名無しさん2007/03/09(金) 04:03:02
ねるぽZzzzzz
0966デフォルトの名無しさん2007/03/09(金) 04:09:45
>>964
良くわからんが、自信をもって撤回します、熱烈完全撤回します。
0967デフォルトの名無しさん2007/03/09(金) 08:27:14
>>948
stdio.hはISOで定められている規格の一部なんだから、
何ビットの環境になろうと、通用するに決まっている。
0968デフォルトの名無しさん2007/03/09(金) 13:26:38
久しぶりに来たらスレのレベルが一気に下がってて驚いた
0969デフォルトの名無しさん2007/03/09(金) 16:46:22
899と900の日付を見れば・・・
0970デフォルトの名無しさん2007/03/09(金) 22:41:50
だんごここにもいるやｗ
0971デフォルトの名無しさん2007/03/09(金) 23:30:06
ダンゴがくると途端にレベルが下がるな・・・
0972デフォルトの名無しさん2007/03/09(金) 23:36:01
このやりとりはさすがに相手のレベルのほうがアレだと思うが。
まあこういうのを呼び寄せるという意味では確かにレベルが下がるな
0973デフォルトの名無しさん2007/03/21(水) 20:46:39
AppVerifier って、６４ビットネイティブでも使えますか？
0974デフォルトの名無しさん2007/03/23(金) 10:44:14
団子厨は嫌いじゃない俺が居る。
なんで嫌われてるんだ？割と気が合いそうなんだが・・・
0975デフォルトの名無しさん2007/03/23(金) 22:00:15
>>974
団子が嫌われてんのは厨房なノリで暴走することがあるから。
俺も、なにげに団子と考えることが一致していることは多々ある。
0976デフォルトの名無しさん2007/03/23(金) 23:25:15
たまに誉めて欲しいが故の発言が痛いけど
それでこそ団子ちゃんだしなぁ。
キャラ立ってて良いと思われ。
0977デフォルトの名無しさん2007/03/23(金) 23:32:18
団子の発言ほとんどが知ったかぶりなので見てて痛い
自作板見て濃いよ、目を覆わんばかりの無知っぷり
0978・∀・）っ-○◎●2007/03/23(金) 23:44:53
>>977が吠えてます
0979デフォルトの名無しさん2007/03/23(金) 23:46:20
せめて◇でいいからトリもつけてくれたほうが笑いになったのに
0980ﾋﾟﾖﾋﾟﾖ>（・◇・）っ-○◎●2007/03/23(金) 23:59:01
こうか？
0981デフォルトの名無しさん2007/03/24(土) 00:07:53
団子がいるとレベルを下げる方向にしか働かないからなあ。
試しに１００年ほど名前入れないというのはどうかな。
0982デフォルトの名無しさん2007/03/24(土) 00:09:09
名無しの団子を看破するのは容易
0983ﾋﾟﾖﾋﾟﾖ>（・◇・）っ-○◎●2007/03/24(土) 00:11:56
>>980
こっちみんな
0984・∀・）っ-○◎●2007/03/24(土) 00:20:31
まあ、ネタフリすら出来ずに他人のことをとやかく言うしかないやつが
一番無知で低レベルなんだよな
0985デフォルトの名無しさん2007/03/24(土) 01:06:41
団子が来るとスレがピリッと引き締まるな。
0986デフォルトの名無しさん2007/03/24(土) 22:24:52
それ褒め過ぎｗ
0987デフォルトの名無しさん2007/03/25(日) 14:59:32
>まあ、ネタフリすら出来ずに他人のことをとやかく言うしかないやつが
>一番無知で低レベルなんだよな

団子ちゃん、これが痛いんだよなｗ
ボクチャン凄いでしゅーって、そんなにアッピールせんでもよろし。
0988・∀・）っ-○◎●2007/03/25(日) 17:13:52
あたまわりーなこいつ→>>987←生きてる価値あるの？
0989・∀・）っ-○◎●2007/03/25(日) 17:17:37
埋め立てとくぞ

次スレは不要だよな
0990デフォルトの名無しさん2007/03/25(日) 17:17:41
>>988
ないよ。てか、いちいちそんな当たり前のこと訊くなよ。
あたまわりーなこいつ→>>988←生きてる価値あるの？
0991・∀・）っ-○◎●2007/03/25(日) 17:17:46
９９０
0992・∀・）っ-○◎●2007/03/25(日) 17:17:52
９９１
0993・∀・）っ-○◎●2007/03/25(日) 17:17:58
９９２
0994・∀・）っ-○◎●2007/03/25(日) 17:18:18
９９３
0995・∀・）っ-○◎●2007/03/25(日) 17:18:29
ずれてたおｒｚ
0996・∀・）っ-○◎●2007/03/25(日) 17:18:37
１００００
0997・∀・）っ-○◎●2007/03/25(日) 17:18:51
１０００００００
0998・∀・）っ-○◎●2007/03/25(日) 17:18:57
１００００
0999デフォルトの名無しさん2007/03/25(日) 17:19:03
１０００！
1000・∀・）っ-○◎●2007/03/25(日) 17:19:05
１
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。