[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 2chのread.cgiへ]
Update time : 10/27 07:58 / Filesize : 141 KB / Number-of Response : 567
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

MMX SSE 3D NOW!のプログラミング



1 名前:デフォルトの名無しさん [04/05/28 22:00]
どうぞ

543 名前:デフォルトの名無しさん mailto:sage [2008/07/09(水) 22:28:30 ]
つまり糞ってことだPowerPCと比較して
糞すぎるんだよなぁ

544 名前:デフォルトの名無しさん [2008/07/30(水) 21:25:16 ]
3D Nowの機能を使ったエンコードソフトなどありますか?

545 名前:デフォルトの名無しさん mailto:sage [2008/07/30(水) 22:18:57 ]
午後のコーダ
mencoder
ffmpeg

546 名前:デフォルトの名無しさん mailto:sage [2008/07/30(水) 22:57:31 ]
>>509 の辺りをちらりと読んでアレレ?と心配になってしまいました。

でも、考えてみたら、タスクスイッチのときに、
今のコンテキストの情報(全レジスタ丸ごと)をメモリにコピーして
スイッチ先タスクのコンテキストの情報を丸ごとメモリから読み込む訳だから、
コアが幾つあっても、タスクを実行するコアが入れ替わっても、
全然問題ありませんよね。


547 名前:デフォルトの名無しさん mailto:sage [2008/07/30(水) 23:16:18 ]
上によってタスク(スレッド)毎に別のレジスタセットをそれぞれ持っているような状態が作られる訳だから
マルチタスク環境での MMX/SSE の使用は問題なくて、
ただ、スレッド開始時のコンテキストの情報がどうなっているかは、環境依存だろうから、
スレッド開始時にフラグを設定しなおした方がいいという事ですよね。

複数の CPU がある場合でも、タスクを実行する CPU が入れ替わらなければ、1 CPU の時と同じだし、
タスクを実行する CPU が入れ替わる場合でも何らかの形でコンテキストの情報丸ごとを受け継がなければ、
タスクの続きを正常に実行できなくなるわけだから、アプリケーションを作る
プログラマが心配するような事では全くありませんよね。

なんかグダグダ書いてしまいって、見苦しいですよね。
御不快でしたら、スルーして下さいよね。

548 名前:デフォルトの名無しさん mailto:sage [2008/07/31(木) 11:11:55 ]
うるせーペニス

549 名前:デフォルトの名無しさん mailto:sage [2008/08/01(金) 23:37:03 ]
8bit単位のシフトつけてくれ
明日までに欲しい

550 名前:デフォルトの名無しさん mailto:sage [2008/08/09(土) 16:28:29 ]
32bit幅の配列があり、
指定の下位nビット(1 <= n <= 32)以外のビットが立っていないときに、
その配列をnビット幅の配列としてメモリ上にギチギチに詰める&
詰めたものを32bit幅の配列に戻す、ということをやりたいです。

詰めるフォーマットは自由で、
詰め元・復元先について先頭のalignmentは揃えられます。

551 名前:デフォルトの名無しさん mailto:sage [2008/08/09(土) 16:53:05 ]
そうですか。



552 名前:デフォルトの名無しさん mailto:sage [2008/08/09(土) 16:57:05 ]
そうですね

553 名前:デフォルトの名無しさん mailto:sage [2008/08/10(日) 03:17:26 ]
やればぁ

554 名前:,,・´∀`・,, mailto:sage [2008/09/01(月) 11:12:38 ]
>>343
PowerPC(970以降)は命令間レイテンシが大きいからそれはそれで
隙間埋めるのが大変なんだがな。

1回だけ使うデータのロードだけでも1命令分使っちゃうこととか、
32ビット即値をレジスタにセットするのにも2命令かかったりとか、
いざ使ってみるとパフォーマンスにかかわる制約が多すぎる。

Int/FP/SIMD各32本とレジスタ本数が多いのが逆に災いして
レジスタリネーミングそのものも弱いから、高速化のためには
レイテンシ隠蔽のため静的なアンロールに費やされることになり、
結果的にはx86に対するレジスタ本数差分の優位すら覆されてしまう。

ジョブズの「今までの○倍」ってプレゼンもあながち誇張でもない。
ものによっては確かにそれくらいIntel CPUのほうが性能が出る。
命令セットは汚く論理リソースは限られてるが、その分だけ逆に
アグレッシブな動的最適化技術が比較的有効に働くからね。

Java仮想マシンがスタックマシンなのだって、スタック構造は
並列度を抽出しやすいから。また、論理レジスタが少ないほど
アウトオブオーダ・レジスタリネーミングのリソース管理が楽。

もちろん、静的な最適化で事足りるならそれに越したことはないんだが
実行ステージのパイプラインが深くなったりするたびに再コンパイル
(最悪の場合再コーディング)してられないなど、「コード資産」
という名の制約もあるからね。
Intelのx86は新命令を取り入れつつも、既存のコードもコンパイル
しなおさなくてもある程度は速く走ることを主眼に改良してきたから、
いろんな処理を無難にこなせるわけだ。

555 名前:,,・´∀`・,, mailto:sage [2008/09/01(月) 11:13:26 ]
>>543の間違い。しかも亀

556 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 14:05:22 ]
PPC信者に触っちゃいけません

557 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 08:53:34 ]
PowerPCのアセンブラって、Z80から入った俺にしてみたら
すっごくわかりやすかったんだよなぁ
信者になる気持ちもわかる

558 名前:デフォルトの名無しさん [2008/11/15(土) 22:15:50 ]
SSE組み込み関数のラッパーを作ったんで
簡単なベンチとったら↓以下のようになった。
SIMDに有利な内容だったとはいえ、SSEは結構すごいんだな

floating_point time = 0.012824
std::valarray time = 0.137409
packed_value time = 0.000011


559 名前:デフォルトの名無しさん mailto:sage [2008/11/15(土) 22:50:49 ]
あまりに差が大きいんで、
ベンチを見直したら↓になった
そりゃそうだよね orz

float time = 0.036192
std::valarray time = 0.117789
packed_value time = 0.026709


560 名前:デフォルトの名無しさん mailto:sage [2008/12/02(火) 00:46:09 ]
_mm_movemask_epi8に
0x00000000000000FF0000000000000000

渡すとなぜ0x8000になるのですか?

561 名前:デフォルトの名無しさん mailto:sage [2008/12/02(火) 11:54:51 ]
>>560
ならないはず。
__m128iにそのデータをセットして_mm_movemask_epi8を
呼び出すまでのコードをアップしてみて。 



562 名前:デフォルトの名無しさん mailto:sage [2008/12/02(火) 20:45:48 ]
>>561
えーと上のコードだと以下の計算で会ってますか?

(0x00 >> 7) << 15 |
(0x00 >> 7) << 14 |
(0x00 >> 7) << 13 |
(0x00 >> 7) << 12 |
(0x00 >> 7) << 11 |
(0x00 >> 7) << 10 |
(0x00 >> 7) << 9 |
(0xFF >> 7) << 8 |
(0x00 >> 7) << 7 |
(0x00 >> 7) << 6 |
(0x00 >> 7) << 5 |
(0x00 >> 7) << 4 |
(0x00 >> 7) << 3 |
(0x00 >> 7) << 2 |
(0x00 >> 7) << 1 |
(0x00 >> 7)

563 名前:デフォルトの名無しさん mailto:sage [2008/12/03(水) 01:27:00 ]
>>562
それで0x0100

564 名前:デフォルトの名無しさん mailto:sage [2008/12/03(水) 22:41:53 ]
0x0100
なんで0x0100するの?どこにもそんなこと出てないけど

565 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/05(金) 08:04:19 ]
たぶんさ、
デバッグウィンドウに出てきた16進ダンプをビッグエンディアンだと思い込んでるんじゃないの?

00 00 00 00 00 00 00 FF 00 00 00 00 00 00 00 00
を0x00000000000000FF0000000000000000だと勘違いし

80 00

を0x0080じゃなくて0x8000だと勘違いしてると。


566 名前:デフォルトの名無しさん mailto:sage [2008/12/06(土) 10:02:32 ]
そうだったりした
許してください






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<141KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef