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

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

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

1 : ◆TimpoiKAMI :2005/07/21(木) 14:26:37
ようやく64ビットを気軽に試せるようになったので、
せっかくだから
ナニヤラ目新しいことして遊ぼう藻前裸。

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

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

823 :デフォルトの名無しさん:2006/10/26(木) 06:07:35
せっかくの64bit CPUなんだから64bit整数使えばいいじゃない(マリー
64bit CPUじゃなくても64bit整数は使えるけど無理やりスレタイに関連付けてみた

824 :デフォルトの名無しさん:2006/10/30(月) 23:41:04
先日x64版Linuxに意味も無く移行した
自前のソースが全然コンパイルできなくて唖然とした
低スキルの素人プログラマだから自業自得なんだけど
閑話休題
おまえら!x86とx86_64でソース互換性を保ったままコーディングする方法について詳しく解説してる本とかサイト知ってたら教えてください
あ、言語はCです

825 :・∀・)っ-○◎●創聖のダンゴリオン ◆DanGorION6 :2006/10/30(月) 23:44:41
#include <emmintrin.h>



826 :デフォルトの名無しさん:2006/10/30(月) 23:56:53
asmを使わない

827 :・∀・)っ-○◎●創聖のダンゴリオン ◆DanGorION6 :2006/10/31(火) 00:00:20
型の大きさの表現に即値は使わない

例: sizeof (int *)

828 :デフォルトの名無しさん:2006/10/31(火) 00:16:19
>>824
キャストは使わないw

829 :デフォルトの名無しさん:2006/10/31(火) 01:09:04
ポインタ型を整数型にキャストするときにはintptr_t/uintptr_t。

830 :824:2006/10/31(火) 02:32:09
>>825-829
みなさんの仰られていることでぐぐったらやるべきことが見えてきた気がします
あれこれ調べながら小さいものから書き直してみようと思います
曖昧な質問なのにアドバイスありがとうございました

831 :デフォルトの名無しさん:2006/10/31(火) 04:23:05
とりあえずここ一通り目を通しとけ。
http://docs.sun.com/source/806-4836/conv_v9.html
http://docs.sun.com/app/docs/doc/819-0389?l=ja

Win64でもtypedef名等が違うだけで、基本的な考え方は同じ。

832 :824:2006/10/31(火) 21:46:28
>>831
ありがとうございます
わかりやすくまとまっていてとても勉強になります
>>ALL
とりあえずmalloc()でsegmentation faultが出なくなりました!
この調子でマイペースに楽しみながらデバグしていこうと思います
本当にありがとうございました

833 :デフォルトの名無しさん:2006/11/26(日) 02:14:35
Insure++やDevPartnerなど、ランタイムエラーを捉えるツールで、X86-64
のWindowsXP64ビットで使えるものってありますか?

834 :デフォルトの名無しさん:2006/12/13(水) 01:20:52
FFFTPの64ビット版つくってください

835 :・∀・)っ-○◎●創聖のダンゴリオン ◆DanGorION6 :2006/12/13(水) 01:26:19
あるじゃねーかwwwww

836 :デフォルトの名無しさん:2006/12/13(水) 01:35:42
MS-DOSの64bit版つくってください

837 :デフォルトの名無しさん:2006/12/13(水) 01:44:55
64bitでネイティブ動作するテキスト置換ソフトは何を使ってる?

838 :・∀・)っ-○◎●創聖のダンゴリオン ◆DanGorION6 :2006/12/13(水) 02:12:02
テキスト置換なんか強いて64ビットでやる必要ねーだろ

839 :デフォルトの名無しさん:2006/12/13(水) 02:15:10
64bitにすればなんでも速くなるとでも思ってるの?

840 :デフォルトの名無しさん:2006/12/13(水) 13:12:51
おうよ!

841 :デフォルトの名無しさん:2006/12/13(水) 13:13:37
数値が2倍なんだから2倍速くなければ公取が動きますよ

842 :・∀・)っ-○◎●創聖のダンゴリオン ◆DanGorION6 :2006/12/13(水) 21:46:27
あふぉや
SSE2のpcmpeqb使って並列比較したほうがまだマシ

843 :デフォルトの名無しさん:2006/12/13(水) 22:34:13
>>835
あったっけ?<FFFTP64ビット

844 :デフォルトの名無しさん:2006/12/13(水) 22:43:54
メモリ帯域は変わらないよね?
全部64bitにすると全部32bitの場合の半分の個数しかデータ送れないんじゃないの?

あんまり詳しくないけど。
誰か教えて。

845 :844:2006/12/14(木) 14:16:29
むむ。誰からも返事が無い。
自分の疑問は合ってるのかな。

846 :デフォルトの名無しさん:2006/12/14(木) 16:58:05
>>844
64bit精度が必要なところ以外では
今まで通り32bit変数を使うから、
そういう心配はいらないのだ。

847 :デフォルトの名無しさん:2006/12/14(木) 16:59:56
           ∩_
           〈〈〈 ヽ
          〈⊃  }
   ∩___∩  |   |
   | ノ      ヽ !   !
  /  ●   ● |  /
  |    ( _●_)  ミ/ <こいつ最高にアホ
 彡、   |∪|  /
/ __  ヽノ /
(___)   /

848 :デフォルトの名無しさん:2006/12/14(木) 17:10:52
>>847
AAに同感するとは思わなかったが、同感だ。

849 :デフォルトの名無しさん:2006/12/14(木) 17:33:15
俺も知らんけど、アホとか言ってないで説明できないの?

850 :デフォルトの名無しさん:2006/12/14(木) 17:44:40
847がそうなのはわかったが、アホなのは844なのか846なのかはっきりしる。

851 :デフォルトの名無しさん:2006/12/14(木) 19:29:54
どう考えても846

852 :デフォルトの名無しさん:2006/12/14(木) 20:40:12
で、どうなの?

853 :デフォルトの名無しさん:2006/12/14(木) 20:50:59
広い範囲のメモリをバンバン読み書きするタイプの処理の場合、
844の心配は現実になるよ

整数なら範囲がわかっていれば32bitにすることもできるけど
ポインタはそうはいかないんだよねえ

854 :デフォルトの名無しさん:2006/12/14(木) 21:11:53
>>843
ソース公開されているんだから、自分で64ビット対応の修正すれば作れるのでは?

855 :デフォルトの名無しさん:2006/12/14(木) 21:12:29
ポインタだけでキャッシュに収まらないほどの量になるの?

856 :・∀・)っ-{}@{}@{}@ ◆DanGorION6 :2006/12/14(木) 22:06:46
収まるか収まらないかの問題じゃない。
転送帯域が同じなのにデータサイズが増えるならそれだけでスループット落ちる。

あとは命令サイズの問題か。
imm64とかをうかつに使うと命令フェッチ帯域圧迫されるしREX使えばそれだけで命令長1バイト増える。
Core 2 Duoは4命令同時デコードに対して16byte/clkの命令フェッチ帯域しかないから32bitのほうが速いことも多いよ。

857 :844:2006/12/15(金) 12:34:25
なるほど。みなさんありがとうございます。

858 :デフォルトの名無しさん:2006/12/15(金) 21:13:10
>>856
理論的にはそうだが、自分で試した上での発言か?

859 :・∀・)っ-○◎●創聖のダンゴリオン ◆DanGorION6 :2006/12/15(金) 22:42:25
Pentium 4だと、レジスタ増えてるのにスループット全く変わらなかった。
SIMD演算ユニットの割にロード・ストアのスループットが良すぎるから
レジスタ数の増加程度で性能は伸びない。

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

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


つかね、ただパフォーマンスを上げるだけなら、現状、SIMD使った方がいい。

860 :デフォルトの名無しさん:2006/12/15(金) 23:39:55
別に排他的なもんじゃあるまい>SIMDと64bit

861 :・∀・)っ-○◎●創聖のダンゴリオン ◆DanGorION6 :2006/12/16(土) 00:44:16
そうだけど、別にSSEが128bitから256bitになるわけじゃないだろ?

64ビットは32bitが2個分だから性能が上がる、とか言う前に、まずSIMD使えって言いたいの。
SIMD命令なら各要素ごとにラップアラウンドしたり飽和処理したりするのが簡単にできるわけで。

現状、SIMDを多用するときは、汎用レジスタセットはデータのアドレス計算やループカウント、
あと細かいスカラの演算くらいにしか使わないんだよね。
汎用←→XMMレジスタ間の転送はmovd(32bit)やpinsrw/pextrw(16bit)くらいだし。

強いて言えばIA32→x64でレジスタ数の増加くらいの恩恵はあるけど、REXプレフィックスは
命令サイズを増大させるので、先に指摘した問題がある。
あと、レジスタが増えた分だけ待避・復帰処理の時間が増える。

862 :デフォルトの名無しさん:2006/12/16(土) 00:54:02
つか、64bitの利点はデータの幅じゃなくてアドレスの幅だべさ。
64bit整数なんて32bit環境でも普通に使えるべ。

863 :デフォルトの名無しさん:2006/12/16(土) 07:34:10
SIMDを多用して速度が向上するような処理は
REXプレフィックスの足かせよりレジスタ数増加の恩恵の方が大きいと思う。

864 :デフォルトの名無しさん:2006/12/16(土) 12:07:32
long long intを32bit環境でやると、遅いと言うより使いづらい。
配列なんて確保したら、殆どの場合セグメントフォルトだし

865 :・∀・)っ-○◎●創聖のダンゴリオン ◆DanGorION6 :2006/12/16(土) 13:39:46
まあ、Athlon64なんかは64bit ALU×3、64bit SIMD ALU×2(128bitは64bit2回に分割実行)
だから、それほど性能良くない。
Core 2なんかは64bit ALU ×3、128bit SIMD ALU×3だから、大量データ処理には
完全にSIMDのほうが優位。

866 :デフォルトの名無しさん:2006/12/16(土) 13:41:47
>>864
なんでやねん

867 :デフォルトの名無しさん:2006/12/16(土) 13:49:48
>>865
ダンゴリオンさんは、いろいろ書いてくれてるけど知識だけじゃなくて、
SIMD使ってとりわけ速くなる様なコーディング経験があったってことなん?

868 :・∀・)っ-○◎●創聖のダンゴリオン ◆DanGorION6 :2006/12/16(土) 14:10:11
いちおう有るには有る。64bitのほうはまだ世に出してないが
Core 2のSIMD整数モンスターぶりがよくわかるのは個人で出してる



869 :デフォルトの名無しさん:2006/12/16(土) 17:31:28
>>868
それ見たい。

870 :・∀・)っ-○◎●創聖のダンゴリオン ◆DanGorION6 :2006/12/16(土) 18:13:12
おいらのサイト
ttp://tripper.kousaku.in/


John the Ripperのビルドなら自分で試してみるのも良いかなと

871 :869:2006/12/16(土) 18:48:53
>>870
ありがとう。すごいなぁ。

872 :867:2006/12/16(土) 20:23:29
>>870
ちらっと拝見しましたよ。NANDとNORを追加とかアセンブラ書きの人の言やねw

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

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

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