てっきり私は、
全充＝完全充電＝お休み
だと思ってました^^;

よく考えたらvさんの1文字というのもすごいですよね。

＃だいぶ寒くなってきました。
＃夜はオリオン座がきれいです。

ハンドル変えないほうがいいでしょうか？
ほとんど本名っていうハンドルはどんなもんだろう
という他愛ない疑問から抵抗を試みているのですが
しかし変えないほうがいいかなということで上記のような
折衷案を考えてみました。

zenjyuuと読みます。
戦国時代の武将、岩田助全充乃守一成（実在しません）
から採用したものです。

Kazuさん、ハンドルかえるんですか？

v

梟の城は確か司馬遼太郎さんの最初の新聞連載
小説です。で、いきなり賞を取ったところがす
ごいです。

私は司馬さんの本は幕末維新ものばかり読んで
戦国ものや伝奇ものは読んでいません。と、
いうことで梟の城は読んでいません。

それはともかく、CMで見る限りすごいCGですね。
さよならジュピターで負ったトラウマ（笑）を
いつまでも背負っている場合じゃないかも。で
も、忍者の立ちポーズが妙にゲームを感じさせて
そこはかとなく不安です（笑）

v

>はは、そんなのあったんですね（汗）
>人にスペース貸していたの忘れてました。

おょっ、違いましたか。
なんだか雰囲気の違うページだなーと思ったら、
他の人のでしたか(笑)

>トップページに秘密の扉が
>ｖさんに会うためにとリンクはったままだった。

>開発者は11月11日11時11分に一般に試験公開と
>わけのわからないこといっています。

むー、どうやら隠しリンク等の細工がいくつかあるようですね。
どっちもわかりません。
11年11月11日11時11分11秒までには見つけたいなぁ(笑)

はは、そんなのあったんですね（汗）
人にスペース貸していたの忘れてました。

うーーーん、おしいですね＞うるりさん

あれは試してもらえばわかりますが、単なるHTMLファイル
しかもリンク先がなぞです。

開発者は11月11日11時11分に一般に試験公開と
わけのわからないこといっています。

開発中なのは../i-mode/ですか？
最近日記ネタに突っ込み入れてばっかりだな＞自分^^;

＃6:25ごろ地震がありました。
＃震源は香川県みたいです。
＃地震で一番に気になるのはHDDへの衝撃と電源断^^;;;

お役に立ててなによりです。
またなにかありましたら気楽にどうぞ^^

>Athlonって便利ですね。
そうなんですけどね・・・
どうせちょこっとしか追加しないなら、
はじめから3DNow!に入れといてくれれば
便利だったのに〜(といつも言っている私^^;)
Athlonで3DNow!補助関数をちょこっと増やされても
使いにくいだけだよ〜＞AMD

うるり＠ちょっと壊れ気味

こんにちわ
うるりさん、vさんどうもありがとうございます。
Athlonって便利ですね。
でも、やっぱりみなさんの言う通りデータの見直しをしたほうがいいですね。

>私もインテルの技術的先見性や積極さには
>舌をまいています。あえて冒険をしてでも
>先に進もうという意気込みを感じます。

次がどうなるかが楽しみです。
どんなものを持ってくるのだろうか。

>マーケティングに問題があるだけなんです
>よね。

作ってる人と、売ってる人は別ですからね。
今も問題になっているようで、なんとも面白い
会社です(^^;

>「百才あって一誠なし」

えらくお年ですね？？

追加

>punpckldq mm1, mm0
>punpckhdq mm0, mm1
については、レジスタの依存性を切るなら
movq mm1, mm0
punpckhdq mm0, mm0
punpckldq mm0, mm1
のほうがよいかもしれません(通常は使わないだろうけど)。

別のレジスタに上下逆を求めるなら(mm0->mm1のとき)
movq mm1, mm0
punpckldq mm0, mm0
punpckhdq mm1, mm0
ですかね。

Athlonが搭載している3DNow!拡張では
pswapd mm1, mm0
とすることでmm1にmm0の上下DWORDを入れ替えたものが
入ります(もちろんpswapd mm0, mm0も可能)。

この手のものはパズルみたいで楽しいと思います(^^;
vさんも言われている通り、
あと余りに上下を入れ替えたりする場合は、同一レジスタにパック
されているデータの組み合わせを考えた方が良いときもあります。
どのあたりで考え直すかは、なかなか難しいとこですが。

時間がないのでざつですがこんな感じでよろしいでしょうか？？

はじめましてゆうさん。
気軽な書きこみ歓迎します〜♪

プログラムはあっていそうですよ、
ただ、シフト演算は演算器が1つしかないので
今回は使わない方がいいかな？

では、過去ログより

>1999/05/18 (火) 13:22 うるり なるほど。こんなのも小技？
>
>ついでに小技？を１つ。
>ＦＬＯＡＴ［２］をＭＯＶＱとは上下逆にロードする方法。
>
>ＭＯＶＤ ＭＭ０，ＦＬＯＡＴ［１］
>ＰＵＮＰＣＫＬＤＱ ＭＭ０，ＦＬＯＡＴ［０］
>
>メジャーかな？
>
>ＭＭ０の上位下位ＤＷＯＲＤ入れ替えは
>ＭＭ１を作業用に使って
>
>ＰＵＮＰＣＫＬＤＱ ＭＭ１、ＭＭ０
>ＰＵＮＰＣＫＨＤＱ ＭＭ０、ＭＭ１
>
>かな？Ｋ６で２クロック必要だね。

私もインテルの技術的先見性や積極さには
舌をまいています。あえて冒険をしてでも
先に進もうという意気込みを感じます。

マーケティングに問題があるだけなんです
よね。

「百才あって一誠なし」

v

ゆうさんこんにちは。

この話題はどこかで見かけたけど忘れました。
すみません。おそらくどなたかがヒントをくれ
るでしょう。

と、言うことで私からは別のアドバイス。SIMD
演算は、ストリーム間の演算、ストリーム間の
移動をしなくていいようにするのが一番簡単
な逃げ道です。

v

はじめまして
みなさん、レベルが高いのでこんな質問をするのは
恥ずかしいのですが、一つ分からないことがあるの
ですが、教えて下さい。
使用するCPUはMMXです。

mm0の上位３２ビットと下位３２ビットを入れ替える
にはなにかいい方法はないでしょうか？
私は以下のプログラムを作ったのですが、なにか
もっと簡単に出来る方法（命令）は無いもので
しょうか？

mm0
64 32 0
[abcdefghijk |opqrstuvwxy]
　　　　　　↓
64 32 0
[opqrstuvwxy |abcdefghijk]

−プログラム−
movq mm1,mm0
psrlq mm0,32
punpckldq mm0,mm1
（このプログラムは一度も動かしたことがないので
そもそも、文法的にあっているのかどうかさえ
分かりません）

この企画をやっていて思うのですが、
Intelの先見性には驚かされます。
P5,P6ともにすばらしい出来です。
fxch、Out-Of-Orderなど良いタイミングで
投入しているように思います。
＃SSEもそろそろスループットが上がるかな？

＃いまだにP6コアが通用していることは
＃やっぱりすごいことだ。

>最近では、私のコードでP6で突出して速いものは、
>つぼにはまったから速いのではないという見方を
>しています。どのコードもあのくらい速くなるのを
>見込んでコーディングしているのですが、何かが
>原因でストールしていると考えています。

うーん、vさん強気な発言(^^;
でも理論性能を出すのはかなり難しいと思いますよ。
K6の3DNow!なんかはK7の倍は早くてもおかしくないけど、
実際は「あんなもの」ですから(^^;;
P6の性能をあそこまで引き出せたのには価値があるかと
思います。
＃別にK6の3DNow!が駄目だといっているわけでは
＃ありません。
＃3DNow!の魅力をもっと簡単に引き出せるCPUだったら
＃いいのになぁ、ということです。あしからず。

酒井さんはじめまして。

投機実行、分岐予測、スケジューリング、デコード
などは、すべて折り込み済みでコーディングしてい
ます。が、やはりピーク性能に迫っているからでしょ
うか、なかなか思うように速度向上しません。速度
向上しなかったからループにこだわった、というのも
あります。

最近では、私のコードでP6で突出して速いものは、
つぼにはまったから速いのではないという見方を
しています。どのコードもあのくらい速くなるのを
見込んでコーディングしているのですが、何かが
原因でストールしていると考えています。その何
かがなかったのが突出して速いコードになった理由
だと思います。

v

おっと、重要なことを書いてなかった。

>もちろんループを超えて命令はスケジュールされ実行されます

この一文が、つぼにはまる原因ですね。
P5,K6はつぼにはまれるほどROBが広くないので
今までお目にかかれませんでした。

>IntelのOptimization ManualやCQ出版の「トランジスタ技術1999年9月」
>あたりが参考になると思います。トラ技のほうは説明はちょっとだけだけど。

どうも、参考にしてみます。

)BTBエントリが有限なので条件分岐の数や

分岐まわりはあんまり関係ないような気がします。
予測以前の問題のようですので。

酒居さんは、午後のこ〜だの方でFPU、SSEコードを書いて
おられます。
前からこちらの方を見られていたようですが、突然
参加されたようで、チトびっくりです(^^;

講義中なのでとりあえずこのへんで退散します(^^;;;

はじめまして。

P6は動的実行します。そのとき(静的あるいは動的)分岐予測が
当たれば条件分岐にまつわるペナルティはありません。
もちろんループを超えて命令はスケジュールされ実行されます。
## その筋の研究会では投機的実行が大流行だった時期がありました...

IntelのOptimization ManualやCQ出版の「トランジスタ技術1999年9月」
あたりが参考になると思います。トラ技のほうは説明はちょっとだけだけど。

実行ユニットの5つのポートにまんべんなく命令をぶち込めばツボに
はまりそうに思います。そのために命令デコードのところで詰まらないように
平均して3-1-1μOPになるように命令を並べるといいみたいです。
gogo向けに書いているときは、演算命令をメモリオペランドにするか
レジスタオペランドにするかをデコードのされ具合を考えて選択すると
妙に速くなるときがありました。BTBエントリが有限なので条件分岐の数や
位置についても変えると速度に大きく影響します。

K6メモ更新しました。
お暇ならどうぞ。
http://ww1.tiki.ne.jp/~hino/k6memo.txt

>私は、Kazuさんが作ってくれた表をみるときには、
>縦方向の比較は安心して行っていますが横方向に
>は、数パーセントの誤差があるだろうと考えてみて
>います。

そうですね、完全に同一条件ではないことを頭に
入れておかないといけませんね。

なち＠にゃさんがAthlonの結果を上げてくれています。
またしても、vさんのコードがつぼにはまる(笑)
「OoO FPU 1.80E+002 mS 1082 cycle」
「OoO 3DNow! SIMD 1.26E+002 mS 756 cycle」
つぼの謎は解明したいですね〜。

vさんのソースコードを見る限り特別なことは
していないようです。
P6、K7ともにループを超えてスケジュールが可能
なのかな？(ReorderBufferが広いのはこの2つだけだし)

> Round1で1クロック単位の争いをしていたので
> Round2では余裕で精度が取れるだろうと思っていた
> のですが、そうはいかないみたいですね。

Run AllやBatch Runで得られる結果は相対的には
高い精度を持っています。つまり、おのおののエン
トリーの比較においては、十分信用できると思って
います。揺らぎはありますが、そのための繰り返し
ですし。

異なるOSでは、アプリの外でのオーバーヘッドを
コントロールできないので、いかんともし難いです。

私は、Kazuさんが作ってくれた表をみるときには、
縦方向の比較は安心して行っていますが横方向に
は、数パーセントの誤差があるだろうと考えてみて
います。

v

>Round2 に限らず、Round1でもOSによる
>差は出ます。また、OSが同じでもメモリー
>速度による差は出るはずです。

Round1で1クロック単位の争いをしていたので
Round2では余裕で精度が取れるだろうと思っていた
のですが、そうはいかないみたいですね。
実行時間が長い分かえってOSの消費時間が増えてる？？
スレッド優先順位を変えても根本的な解決にはならないので、
OSが時間を消費しているということを頭に入れて
結果を評価すれば良いのではないでしょうか。

vさんソース公開ですね。後で覗いてみよっと。
私は今、Round1のまとめを書いてるとこ(^^;
Round1ってまとめにくいよ〜お。
＃とりあえず寝ます。Zzzz・・・

Round2 に限らず、Round1でもOSによる
差は出ます。また、OSが同じでもメモリー
速度による差は出るはずです。

プリエンプティブOSなので、どうしても
実行中にコンテキスト切り替えが発生し
ます。コンテキスト切り替えオーバーヘッド
はOSによって異なりますし、切り替えにより
キャッシュはミスヒットしますのでメモリー
速度の影響を受けます。

スレッド優先順位を極端に高くすれば幾分
影響は小さくなりますが、プログラマと
しての原理主義に障るところがあり、いま
のところ実行を見合わせています。

この辺、ご意見をお聞かせください。

v

P.S
書き込みに失敗したのは、つぼのごみ話だったので
気にしないでください^^。

やっぱり昨日の書き込みはされてませんね。
送信ボタン押したと同時にIEが落ちゃいました(^^;
久々に不安定でした。

Round2でちょっと無視できないことを発見しました。
それは結果がOSやメモリに依存してそうだということです。
傾向は同じなのですが、多少値に差が出ます。
P55Cでメモリ設定を速くすると全体的に10clock速くなりました。
P2@350(NT)で私のx87コードを計ると、現在測定されて
いるものより100clock近く速いです。
また、速いコードほど差が少ないようです。
やはり、CPUの純粋な能力とはいかないのでしょうか？？

遅くなるつぼですか。。。。。
腰痛を楽にするつぼはあるようですが
はあぁ、昨日は（今日か）2時間しか寝ていない
眠い（自業自得ですが：朝4時まで飲んでました）
#でも客先には9時半までにいきました
#えらいでしょ

> >「つぼにはまる」パターンが隠れているかもしれません。
> vさんしか知らない秘密のパターンですね。

いえ、私にもわかりません（笑）。正直言って
戸惑っています。

v

>「つぼにはまる」パターンが隠れているかもしれません。
vさんしか知らない秘密のパターンですね。
長パイプライン対策ということでだだっ広く展開して
みたのですが、短く綺麗にというのも有効みたいですね。
分岐時のペナルティが有るのか無いのか、どの程度なのか、
がいまいちつかめていないのが敗因(?)かもしれません。

>3DNow!@k6より3DNow!＠Athlonのほうが遅いんですよね
Athlonで遅くなるのは、レイテンシの伸びを吸収できて
いないからでしょうか？
他には遅くなる要因は無いような気がするのですが。
もしかして、遅くなるつぼがあるとか？

Kazuさん、お忙しい中、集計ありがとうございます。
Athlonの測定、ATCompで聞いてみましょうか？

P6のFPUが一つだけ突出しているので、「バグか」
などとびびってました。不思議ですが、mP6でも
同傾向が出ています。「つぼにはまる」パターンが
隠れているかもしれません。特に、ループに固執し
た私のコードは全面的にうるりさんの展開コード
に負けているのに、これだけ伍しているのが面白い
です。

v

ソース公開の件よろしくご検討の程を
最近なにも有用な情報を提供していないもんで
ちょっと分析してみようかな、などと考えています。
しかしAthlonの正式結果がでていないのでなんともですが
予選の結果からみて私のコードだけ
3DNow!@k6より3DNow!＠Athlonのほうが遅いんですよね

下の発言に追加。

vさんのP6での記録ってすごいかも。
SSEとFPUが同じ処理速度になってますね。
これはなんだかすごい事のような気がします。
4命令同時演算と1命令演算が同じくらいの速度？？

>Round2について

たしかにvさんのP6での結果は飛びぬけてますね。
私のP6に対する愛情が不足しているのかもしれませんね。

Round2のソースは公開しようと整理しているのですが、
非常に面倒なのでなかなか進んでいません。
全展開状態なので公開しても読む方も大変ですよ〜。
確か、Round1のコードも修正中だったような(汗)

#あ、P6用の4-1-1OP形式のコードを用意するのを
#忘れてた(^^;

Round2の一覧が出てきましたね。
Kazuさんお疲れ様です。

SSEの結果も出てますけど、今回は値が変動する
ということは無かったのかな？
安定しないコードのようで申し訳無いです。
SSE (SOA)(OoO)コードが意外と効果ありなのが収穫です。

＞Kazuさん
日記掲示板の方は気がついたら書いた後でした。
なんだか気絶したみたいです(笑)

＞はい。しかもそのフラグがあるレジスタにアクセス
＞するには、別のレジスタのフラグを立てないといけません。
デフォルトOFFというのが不思議ですね。
WinChipも似たような機能がありましたね。＞機能選択機能

＞Pentium や mP6 の結果をどうするか、考えあぐねて
＞います。何か特殊な点があるのでしょうか
単に、パイプラインが有効に働くということでは？
fxchは通常のx87と並列実行できて、スタックトップへの
依存を打ち消せる。
一方、WinChipのようにパイプライン化されていても
fxchがクロックを消費する場合は、スループットが高くならない
ということでしょう。たぶん。

忘れそうなK6関連の情報をまとめてみました。
K6-2がメインになってます。
http://ww1.tiki.ne.jp/~hino/k6memo.txt
動機は気が向いたのでなんとなく、というやつです(^^;

> これってもしかしてフラグ立てないとCPUIDが有効に

はい。しかもそのフラグがあるレジスタにアクセス
するには、別のレジスタのフラグを立てないといけ
ません。

>「まとめ」内の「fxch命令を”発光”」という誤字を
> 見つけてしまいました(^^;

ありがとうございます。修正せねば

> ついでに、Pentiumでのfxchも効果は絶大ですよ。

Pentium や mP6 の結果をどうするか、考えあぐねて
います。何か特殊な点があるのでしょうか

＞WEBページに置き捨てられていた「x86の特殊計算機能」。
＞FPUを書き直しました。少し読みやすくなったと思います。
拝見しました。ゆっくり読む時間がないのですが(泣)、
要点がまとまっていて非常に読み易く、またわかりやすい
という感想です。
あと、
「まとめ」内の「fxch命令を”発光”」という誤字を見つけて
しまいました(^^;
ついでに、Pentiumでのfxchも効果は絶大ですよ。
同じような構造のmP6もそうですね。Round2で確認できました。

＞サーバーが重いとは思いませんが、
＞たまにまったく反応しないことがありますね。
なるほど私だけ憑かれているわけではないのですね。
安心しました。
(2,3日前ぐらいからつながりにくいような気もします)

＞M2の問題は、M2ではなくマザーにありました。
＞CPUIDをイネーブルにしていなかったのです。

これってもしかしてフラグ立てないとCPUIDが有効に
ならないという奴でしょうか？
Cyrixも謎な機能を搭載してますね♪。
そういえばCyrix独自拡張MMXも謎ですね(^^;

M2の問題は、M2ではなくマザーにありました。
CPUIDをイネーブルにしていなかったのです。

結局CPUID機能をオンにするソフトを作って
逃げました。

M2を一個余分に買ったのが痛いです。

v

サーバーが重いとは思いませんが、
たまにまったく反応しないことがありますね。
あ、これが重いのか？

濃緑研の日記は私も拝見しています。

v

ここのサーバーめちゃくちゃ重いような気がします。
もしかして私のほうの環境がわるいのでしょうか？？

そうそうｖさん、M2は生きていたんですか？
しかし結果は惨敗ですね＞M2

＃まだ書き足りないらしい＞自分

お休みしていた2日分のゴミを撒きます(^^;

「濃緑研の日記」が不思議な感じです。
だって、題名に「さん」がついてるもん。

MMXPen@166にWin98いれたら・・・重い。
メニュー開くのがニュルニュルとおそいっす。
元の環境に戻さないと駄目かな。

お二人とも腰痛持ちなんですね。
私は姿勢が悪いので御仲間入りするのかも。いやだぁ。

vさん、Round3発動準備着々と進んでますね。
もうすぐカウントダウンでしょうか。

＃（寝るための）時間がいっぱい欲しいです。
＃時間ダブラとか売ってないかな〜。

WEBページに置き捨てられていた「x86の特殊計算機能」。
FPUを書き直しました。少し読みやすくなったと思います。

さ、涼しくなったし次はMMXです。

Round3、先週末、アセンブラによるサンプルがついに
完成しました。現在ヘルプ作成中です。

v

腰痛（いわゆるヘルニアってやつでしょうか）
ひどいときは起き上がれません。
朝目覚めて、起き上がろうとしても
努力、根性の範囲外です（そもそも力が入らない）
いわゆる腰が抜けたって表現はぴったりです。

まあ今回は起き上がることはできます。
しかし腰が重いです。
寝てばかりいてもあまりよろしくないので
こうしてたまに椅子に座って作業しています。

あれ、腰痛そんなにひどいのですか。

私も去年からしつこい腰痛に悩まされていました。
長時間座るとだめです。で、嫁がびびって医者に
連れて行かれたのですが、結果は「異常なし。や
せなさい」。最近は少し軽いです。

くれぐれもご無理されぬよう。

v

今日は腰痛のため会社を休んでしまいました。
しかしこれだけひどいのは、1年半ぶり
だんだん間隔が短く、症状が悪化しているような。
学生時代三段跳びで無理したむくいです
きっと
魂を悪魔に売ってましたから
#ただ単にクーリングダウンをないがしろにしていただけかもしれませんが。

あれま、ちょうど過去記事にいってしまうタイミングでした。
でもOKのようです。

ちょっと書き込みテストです。
ホーム、憩いの広場にもどれますように