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 ] そうだったりした 許してください