08/07/30 22:57:31
>>509 の辺りをちらりと読んでアレレ？と心配になってしまいました。
でも、考えてみたら、タスクスイッチのときに、
今のコンテキストの情報(全レジスタ丸ごと)をメモリにコピーして
スイッチ先タスクのコンテキストの情報を丸ごとメモリから読み込む訳だから、
コアが幾つあっても、タスクを実行するコアが入れ替わっても、
全然問題ありませんよね。
547:デフォルトの名無しさん
08/07/30 23:16:18
上によってタスク(スレッド)毎に別のレジスタセットをそれぞれ持っているような状態が作られる訳だから
マルチタスク環境での MMX/SSE の使用は問題なくて、
ただ、スレッド開始時のコンテキストの情報がどうなっているかは、環境依存だろうから、
スレッド開始時にフラグを設定しなおした方がいいという事ですよね。
複数の CPU がある場合でも、タスクを実行する CPU が入れ替わらなければ、1 CPU の時と同じだし、
タスクを実行する CPU が入れ替わる場合でも何らかの形でコンテキストの情報丸ごとを受け継がなければ、
タスクの続きを正常に実行できなくなるわけだから、アプリケーションを作る
プログラマが心配するような事では全くありませんよね。
なんかグダグダ書いてしまいって、見苦しいですよね。
御不快でしたら、スルーして下さいよね。
548:デフォルトの名無しさん
08/07/31 11:11:55
うるせーペニス
549:デフォルトの名無しさん
08/08/01 23:37:03
8bit単位のシフトつけてくれ
明日までに欲しい
550:デフォルトの名無しさん
08/08/09 16:28:29
32bit幅の配列があり、
指定の下位nビット(1 <= n <= 32)以外のビットが立っていないときに、
その配列をnビット幅の配列としてメモリ上にギチギチに詰める＆
詰めたものを32bit幅の配列に戻す、ということをやりたいです。
詰めるフォーマットは自由で、
詰め元・復元先について先頭のalignmentは揃えられます。
551:デフォルトの名無しさん
08/08/09 16:53:05
そうですか。
552:デフォルトの名無しさん
08/08/09 16:57:05
そうですね
553:デフォルトの名無しさん
08/08/10 03:17:26
やればぁ
554:,,・´∀｀・,,
08/09/01 11:12:38
>>343
PowerPC(970以降)は命令間レイテンシが大きいからそれはそれで
隙間埋めるのが大変なんだがな。
1回だけ使うデータのロードだけでも１命令分使っちゃうこととか、
32ビット即値をレジスタにセットするのにも2命令かかったりとか、
いざ使ってみるとパフォーマンスにかかわる制約が多すぎる。
Int/FP/SIMD各32本とレジスタ本数が多いのが逆に災いして
レジスタリネーミングそのものも弱いから、高速化のためには
レイテンシ隠蔽のため静的なアンロールに費やされることになり、
結果的にはx86に対するレジスタ本数差分の優位すら覆されてしまう。
ジョブズの「今までの○倍」ってプレゼンもあながち誇張でもない。
ものによっては確かにそれくらいIntel CPUのほうが性能が出る。
命令セットは汚く論理リソースは限られてるが、その分だけ逆に
アグレッシブな動的最適化技術が比較的有効に働くからね。
Java仮想マシンがスタックマシンなのだって、スタック構造は
並列度を抽出しやすいから。また、論理レジスタが少ないほど
アウトオブオーダ・レジスタリネーミングのリソース管理が楽。
もちろん、静的な最適化で事足りるならそれに越したことはないんだが
実行ステージのパイプラインが深くなったりするたびに再コンパイル
（最悪の場合再コーディング）してられないなど、「コード資産」
という名の制約もあるからね。
Intelのx86は新命令を取り入れつつも、既存のコードもコンパイル
しなおさなくてもある程度は速く走ることを主眼に改良してきたから、
いろんな処理を無難にこなせるわけだ。
555:,,・´∀｀・,,
08/09/01 11:13:26
>>543の間違い。しかも亀
556:デフォルトの名無しさん
08/10/01 14:05:22
PPC信者に触っちゃいけません
557:デフォルトの名無しさん
08/10/02 08:53:34
PowerPCのアセンブラって、Z80から入った俺にしてみたら
すっごくわかりやすかったんだよなぁ
信者になる気持ちもわかる
558:デフォルトの名無しさん
08/11/15 22:15:50
SSE組み込み関数のラッパーを作ったんで
簡単なベンチとったら↓以下のようになった。
SIMDに有利な内容だったとはいえ、SSEは結構すごいんだな
floating_point time = 0.012824
std::valarray time = 0.137409
packed_value time = 0.000011
559:デフォルトの名無しさん
08/11/15 22:50:49
あまりに差が大きいんで、
ベンチを見直したら↓になった
そりゃそうだよね orz
float time = 0.036192
std::valarray time = 0.117789
packed_value time = 0.026709
560:デフォルトの名無しさん
08/12/02 00:46:09
_mm_movemask_epi8に
0x00000000000000FF0000000000000000
渡すとなぜ0x8000になるのですか？
561:デフォルトの名無しさん
08/12/02 11:54:51
>>560
ならないはず。
__m128iにそのデータをセットして_mm_movemask_epi8を
呼び出すまでのコードをアップしてみて。
562:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/12/03 01:27:00
>>562
それで0x0100
564:デフォルトの名無しさん
08/12/03 22:41:53
0x0100
なんで0x0100するの？どこにもそんなこと出てないけど
565:,,・´∀｀・,,）っ-○◎●
08/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:デフォルトの名無しさん
08/12/06 10:02:32
そうだったりした
許してください