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

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

■コピペモード
□スレを通常表示
□オプションモード
□このｽﾚｯﾄﾞのURL
■項目テキスト

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は新命令を取り入れつつも、既存のコードもコンパイル 
しなおさなくてもある程度は速く走ることを主眼に改良してきたから、 
いろんな処理を無難にこなせるわけだ。

次ページ