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

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

【IA64】64bitプログラミング総合スレ【[x86-64】

1 ：デフォルトの名無しさん：05/02/23 10:12:55: 無いので建ててみました。
32bitコードから、64bitコードへ移行する際の質問などなど
言語、OS問わずここでやりましょう。
952 ：デフォルトの名無しさん：2005/07/20(水) 13:02:06: >>950
そうなん？

組み方が下手なだけかもしれんが、ｘｍｍｘだとホントに早く
ならんのよ。データシートのスペックはともかくとして、
Pen4 PenM（バニアス）どっちも遅くなった。

mmxでレジスタ二個使って手動パイプラインガリガリに最適化した
コードをxmmxで128bitレジスタにまとめて命令数の削減を図った
バージョンが確実に遅かった。

プレフィックスの分、機械語サイズを見ると半分というわけにも
行かないから、その点でもxmmx不利じゃないかな

＞psadbwでも使ってる？
いやそれは使ってない。psadbwは命令の動作が納得いかないと
どこかに書いてあった気がする。
953 ：デフォルトの名無しさん：2005/07/20(水) 13:14:01: PenMは、たしかXMMベース演算はComplexデコーダじゃないと通らないからこれがネックになってるのでは
YonahではSSEμOpsフュージョンのおかげでどのデコーダパスでも通せるようになるとの話。
954 ：デフォルトの名無しさん：2005/07/20(水) 13:36:31: >>952
そうなんだ。PenMは自分でもやるけど遅くなることが多い。

実際に遅いんだから反論してもしょうがないかもしれないけど、
psadbw以外にXMMのが倍以上遅い命令ってあったかな。
プレフィックスも、Netburstならトレースキャッシュで関係ないと思うし。

キャッシュラインをまたぐ機会が増えるとか？
955 ：デフォルトの名無しさん：2005/07/20(水) 13:52:50: ライトバックバッファのミスとか。
論理レジスタ増えれば退避の頻度も減るし、性能は上がりそう。

ASCIIのベンチによればSIMD系はx64で目に見えて性能あがってた（Prescottの話）
956 ：デフォルトの名無しさん：2005/07/20(水) 14:08:29: >>955
それは僥倖
やはり物理的に数が増えれば効果あるのは、汎用レジスタと一緒か。
ちなみに目に見えて、は１割？
957 ：デフォルトの名無しさん：2005/07/20(水) 14:10:54: >>955
＞退避の頻度も減る
手で組むときは途中での退避一切なしだよ（SRCから読んで
DSTへ吐くだけ）
958 ：デフォルトの名無しさん：2005/07/20(水) 16:08:34: 俺もMMXがなおざりにされて悲しいクチだ。
上でもいわれてるよーにXMMだと現存のどのアーキテクチャでも
スループットが半分に落ちる。

ネトバで128ビットLoadが高速にできるというのがあるのだが
Hammerでも128ビットLoadはスループット1なのだな。

VC Toolkit x64 ってまだ入手可能だっけ?
959 ：デフォルトの名無しさん：2005/07/20(水) 21:22:02: >>958
x64のコンパイラならPlatform SDKに入ってる
960 ：デフォルトの名無しさん：2005/07/21(木) 00:06:07: メモリが無尽蔵にあると単純に性能や品質が上がるアプリある？
961 ：デフォルトの名無しさん：2005/07/21(木) 00:09:35: メモリは、単純に快適にするためだけに存在するので
動画のエンコードくらいだな。
962 ：デフォルトの名無しさん：2005/07/21(木) 00:22:11: エンコとデータベース意外ｷﾎﾞﾝﾇ
963 ：デフォルトの名無しさん：2005/07/21(木) 00:25:50: 俺は使ったことないから詳しくは知らないけど
フォトショップって、必ずスワップファイルを必要とするぐらいメモリ食うんじゃなかった？

とりあえず、それ系のレンダリングなんかにも有効なんじゃないかな。
964 ：デフォルトの名無しさん：2005/07/21(木) 00:27:18: それと、メモリがあるほど性能が上がるものとして、OSというのもありますよ。
もちろん、ディスクキャッシュとしての用途が大半ですが。
965 ：デフォルトの名無しさん：2005/07/21(木) 00:28:33: まぁ営業的な話もあるだろうから話半分に聞いたほうがいいだろうけど、
http://ascii24.com/news/i/topi/article/2005/07/20/657082-000.html
3Dアニメーション制作現場ではOpteronの導入が進んでいる!?
「国内ではフルデジタルが主流になっているもののセルアニメーションの
雰囲気を残すことが重視されている点を指摘。そのためには情報量の多い
背景のレイヤーを複数重ねるといった手法が取られることが多く、大量の
メモリーが必要となるため、64bit化が切望されている現状があるという。」
966 ：デフォルトの名無しさん：2005/07/21(木) 02:03:21: 現状の環境で、64bitのメリットを広大なメモリ空間が使える　と言う点だけで考えると破綻するよ。

だって、64bitの枠。すなわち従来ファイルからチビチビ読み込んでたデータを、一気に読み込んで
2Gオーバーのデータを扱えるんだけど
現在の環境で64bitとは言え、そんなにメモリ積んでるマシンって無いから、2Gのデータを読み込むと確実にスワップを起こす
スワップという事は、結局HDDからチビチビ読み込んで使うのと変わらない、むしろ更にオーバーヘッドがあるわけ。

そう考えると、64bitでしか出来ない事、より64bitだから出来る計算の効率に頭をおいたほうが良い。

例えば、64bit以上の変数を持つエンコード・デコード　とかな
数回に分けてた計算を１度に行える。
967 ：デフォルトの名無しさん：2005/07/21(木) 03:13:04: 物理アドレッシングと論理アドレッシングを混同して考えると破綻するよ？ｗ
968 ：デフォルトの名無しさん：2005/07/21(木) 04:05:50: それは概念の話
どちらにせよ、物理的に割り当てられてるメモリ容量が現状32bitも64bitも同じなのが殆どなのは確か
こればかりはどうしようもない。
969 ：デフォルトの名無しさん：2005/07/21(木) 04:09:02: 物理アドレッシングと論理アドレッシングの混同はともかく
だいたい>>966が言いたい事には同意かな

上の方でfread()で2Gオーバーのファイルを読み込むって話があったが
現在の環境で2Gオーバーのファイルを読み込むのは無茶としか…
970 ：デフォルトの名無しさん：2005/07/21(木) 04:19:55: そうなんだよな
そこなんだよ、従来から実装次第でいくらでも領域の問題は解決出来たけど
実行環境が32bitと64bitで実メモリが現状変わらないことが殆どなのが大問題

たまに64bit宣伝する時のうたい文句で、大容量のデータを扱える！
とか書いてるけど、んなもん従来から扱えたっての

＃実装上どうにでもなる事はユーザー側からすると出来る事と見なせる。
＃ユーザーがコーディングを行うわけじゃないから、ユーザーは出来るか出来ないかだけで通常判断

だから、64bitならでわのソフトが中々でないとか言うが、あれは無茶な話でもある。
971 ：デフォルトの名無しさん：2005/07/21(木) 04:35:39: >>970
扱うことは出来るかもしれないけど、データアクセスの速さ違うでしょ。
972 ：デフォルトの名無しさん：2005/07/21(木) 08:52:19: http://sourceforge.net/project/showfiles.php?group_id=69528&package_id=145079

NASAのWorld Windだけど
これをx64用にコンパイルできた人居る？
973 ：デフォルトの名無しさん：2005/07/21(木) 09:31:03: 結論としては、インラインASMができるようにすべき、ということでFA?
974 ：デフォルトの名無しさん：2005/07/21(木) 09:35:46: >>973
流れ読んでないだろ。正しいけどｗ
975 ：デフォルトの名無しさん：2005/07/21(木) 09:36:22: 必要ありません。
インラインアセンブラがほしければ、自分で作ってやってください。
976 ：デフォルトの名無しさん：2005/07/21(木) 09:57:34: >>972
ライブラリのFrameworkが32bitへの決め打ちなんで、Framework64ディレクトリへ全部変更するのがめんどくさい
あと、古い関数使ってるんで、２つほどエラー出る。
977 ：デフォルトの名無しさん：2005/07/21(木) 10:05:43: >>949
SSE3で初めてついたらしい。
ベクトルの内積をやりたかったら
1つのXMMレジスタにxyzwをいれるんじゃなくて
4つのXMMレジスタにxxxx、yyyy、ｚｚｚｚ、wwwwと入れて
内積しろよと。これがSSEのポリシーだったんだよね。
いまさらながら追加されたのはなぜ？
978 ：デフォルトの名無しさん：2005/07/21(木) 10:11:39: フーリエ変換とかで複素数使うからじゃないかな。
でも今更だよな。なぜ最初から入れない。。
979 ：デフォルトの名無しさん：2005/07/21(木) 10:31:22: SSE3でも積和命令なんてないでしょ。
980 ：デフォルトの名無しさん：2005/07/21(木) 10:49:52: どっちだよ！
981 ：977：2005/07/21(木) 11:13:00: ごめん、勘違いしてた。
単に水平方向の加減算がついただけだった。
982 ：デフォルトの名無しさん：2005/07/21(木) 11:18:54: まあそういうわけで、整数と小数の違いもあってSSEはMMXの
代わりにはならんちゅーこってす。あとはXMMXの性能がまとも
になるかMMXの復活を待つしか
983 ：デフォルトの名無しさん：2005/07/21(木) 11:35:14: >>966　とそのレスへ
メモリの値が下がったとはいえ、１００G～テラ級の容量が
民生用に降りてくることになると思いますか？

たとえばVHSやDVDプレーヤ。安くなってとはいえ１万以下
とか数百円にはならんでしょ。メモリも今くらいの均衡から
さらに大容量に動くのかな。HDはTへ行きそうだけど…
984 ：デフォルトの名無しさん：2005/07/21(木) 11:51:21: >>983
>メモリの値が下がったとはいえ、１００G～テラ級の容量が民生用に降りてくることになると思いますか
必ずなるでしょう。
>たとえばVHSやDVDプレーヤ。安くなってとはいえ１万以下とか数百円にはならんでしょ。
すでに１万円は軽く切っているが、数百円はむずかしいでしょう。そうなる前にそれらは消えていると思われます。
985 ：デフォルトの名無しさん：2005/07/21(木) 12:11:22: ＞必ずなるでしょう
現状のx64アーキテクチャやOSの概念がそのままの延長線上で、
という条件ではどうか

SVHSが大して注目されなかったように、市場の要求があるか
どうかも大事じゃね？　要は今の周りの状況から見るとホントに
必要なのかと言いたいのだ

その点が32bitに移ったときと決定的に違う

だから大量にメモリを使って嬉しいアプリを聞いてみたのだが、
民生用として誰もが使うだろうというのはなさげ
986 ：デフォルトの名無しさん：2005/07/21(木) 12:25:37: >>964
むしろこれかもしれん。ただしディスクキャッシュとかではなくて、
OSの変革を促す足場になる可能性がないだろうか

有用かどうかは判断できないが、インターフェイスの完全な３D化
にはメモリ倍増は貢献できそうだ。CUIからGUIになったときのように。

OSの操作系が別物になればそこで動くアプリもそれに沿って
メモリを使うような外観へと変わっていくだろう。

まあ半分たわごとだな
987 ：デフォルトの名無しさん：2005/07/21(木) 12:43:51: >>980
マニュアルくらい読めよ！
988 ：デフォルトの名無しさん：2005/07/21(木) 13:57:05: 次スレ立ててくれ！
989 ：デフォルトの名無しさん：2005/07/21(木) 13:57:28: だから物理メモリの話をしても意味がないんですよ

1GBのメモリを積むのが夢だった遥か大昔から

32bitの論理アドレス空間は狭すぎてギスギスしてたの

物理アドレスが欲しいなら今はPAEで十分

64bit化する必要はない

そうじゃなくて

64bit化が必要なのは論理アドレス空間が足りないから

物理アドレスと論理アドレスを混同するなと言ってるんですよ
990 ：デフォルトの名無しさん：2005/07/21(木) 14:07:02: ＞MMX派諸氏
SSE4以降でXMMレジスタで64bitの部分レジスタとMMX相当命令をサポートすれば万事解決とか思ってるのは俺だけ？
128ビットSIMDが普及しないけどｗ
991 ：デフォルトの名無しさん：2005/07/21(木) 14:13:21: >>991
SSEはいつまで経ってもしょぼいし
捨てて
AltiVecのライセンス受ければいいのに
992 ：デフォルトの名無しさん：2005/07/21(木) 14:17:09: >>958
> ネトバで128ビットLoadが高速にできるというのがあるのだが
> Hammerでも128ビットLoadはスループット1なのだな。

ネトバはストアも同時にできるが、浜ーは次のクロックサイクル待ち。
993 ：デフォルトの名無しさん：2005/07/21(木) 14:20:37: x86の拡張の範囲内でSIMDだけ3オペランド演算ベースにするってのは
ライセンス云々より技術的に難しい。

SIMDだけ別プロセッサ作ったほうが良くなる。
それならむしろIPFとPentiumMのデュアルコアでもやってくれって思うよ
994 ：デフォルトの名無しさん：2005/07/21(木) 14:22:14: ＞64bit化が必要なのは論理アドレス空間が足りないから
論理アドレス空間が足らない例ｷﾎﾞﾝ

データベースとエンコ以外で
995 ：デフォルトの名無しさん：2005/07/21(木) 14:25:15: >>993
と結局Cellみたいなのが
最適解になっちゃうのかな？
996 ： ◆TimpoiKAMI ：2005/07/21(木) 14:27:06: 間に合うか??

次スレ
【IA64】64bitプログラミング総合ｽﾚ【x86-64】2
http://pc8.2ch.net/test/read.cgi/tech/1121923597/l50
997 ：デフォルトの名無しさん：2005/07/21(木) 14:27:14: >>994
レンダリング
998 ：デフォルトの名無しさん：2005/07/21(木) 14:27:51: 記念ﾏｷｺ
999 ：デフォルトの名無しさん：2005/07/21(木) 14:28:27: >>990
それだと32bitと64bitで違うasmコード書かないと行けなくなる
もうちょっと互換性ほしい
1000 ：デフォルトの名無しさん：2005/07/21(木) 14:29:05: 1000だったら人妻に中田氏
1001 ：１００１：Over 1000 Thread: このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

237 KB

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

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)