【隔離】P4アーキテクチャについて議論する【スレ】
■ このスレッドは過去ログ倉庫に格納されています
0001Solaris使い
02/10/13 23:04ID:utORR5yf「P4-PCやXeon-PCてPMG4より速いんですか？その6」
http://pc.2ch.net/test/read.cgi/mac/1032957357/
を追い出された人(Solaris使いとMACオタさん)が議論を続けるスレです。
議論の展開は 675-767 をお読みください。
0002名称未設定
02/10/13 23:09ID:8vBos9Tdハードウェア板とかな。
この時点でMacとは離れてるわけだし
0003Solaris使い
02/10/13 23:11ID:utORR5yf・ハイパーパイプラインと命令並列度の関係について
・キャッシュラインのサイズを大きくする(16→64バイト)とプリフェッチ
・ストライド付き転送命令の有効性（議論中 SIMDプリフェッチ命令と呼んでいる)
・キャッシュの連想度は何に起因してきまるのか？
0004名称未設定
02/10/13 23:12ID:8vBos9Td0005名称未設定
02/10/13 23:18ID:8vBos9Tdコリンさん出番ですよ！
0006コりソ
02/10/13 23:19ID:pyxPF58k0007名称未設定
02/10/13 23:28ID:8vBos9Td0008名称未設定
02/10/13 23:29ID:jMN5HxYoっていうかかなり解りやすい板違いすね。
0009Solaris使い
02/10/13 23:34ID:utORR5yf議論することによって、POWER4 & GPUL を理解しようというのが趣旨です。
でも目立つのでもう少し下がってから開始します。
0010名称未設定
02/10/13 23:42ID:8vBos9Tdだったら尚更板違い。
Macとかけ離れてしまったんだもんね。
ハードウェア板でやっても何の問題は無いだろう。
0011名称未設定
02/10/13 23:45ID:8vBos9Td私的利用ならメッセンジャーでチャットでもしろよ。
削除対象だな。
0012名称未設定
02/10/13 23:55ID:jMN5HxYoその趣向を1に明記しておけばよかったのに、と思います。
で、タイトルはGPULとP4云々、にしとけば。
GPULの正体の一部？がもうすぐIBMから明らかにされる訳で、
それも交えながら楽しく電波発信できたんでは。
0013名称未設定
02/10/13 23:58ID:8vBos9Tdこっちでやれ、誰の迷惑にもならん。
＞GPULの正体の一部？がもうすぐIBMから明らかにされる訳で、
それでも板違いだよ。
0014名称未設定
02/10/14 01:11ID:YDPSUt160015Solaris使い＞MACオタさん
02/10/14 02:23ID:bPNHvqGXぜひとも 8vBos9Td さんも答えてください。
問題点：
「AltiVec の dst 命令のようなストライド付きブロックプリフェッチ命令は有効か」
私の論点。
「キャッシュを前提としてレイテンシが大きくスループットが十分でない、RISC
プロセッサ上に実装するには高価すぎる命令。
プログラマに利便性をもたらす命令だが、優れたプリフェッチ命令とは言い難い」
MAC オタさんは、元スレの 733 で
> あなたが書いているロングベクトルのプロセッサの話と思われるす。
> PC用のショートベクトルのSIMDとわ共通の点と、異なる点があって
> あたりまえすけど。。。
ベクトル機の場合、メインメモリが SRAM ベースなのでアクセスレイテンシが小さく複数ブロックの転送を行ってもレイテンシの増加が少ないのです。
一方、RISC ベースのプロセッサは SDRAM ベースです。連続したデータ転送は速いのですがアクセスレイテンシが高いため、ブロック毎にペナルティをもらいます。1回の dst で長い場合は、数千サイクルを要するという状態になりませんか？
無論、dst 命令は実際のデータ転送を行う前にリタイアしてVTQ というキューに繋がりますから、パイプラインに負担は係りません。ただ、この長時間の転送を中断させるために、転送を停止する命令まで用意されているのを見ると処理が複雑すぎると思います。
> PC用のSIMDわ、現在のPC 用プロセッサの状況に合わせてつくられているのでわないすか？
> AltiVecわその中で最も優れているという評価わ一般的なものだと思うすけど。
> http://www.arstechnica.com/cpu/1q00/simd/simd-1.html
演算部分に関してはそうかもしれませんが、dst のような命令は PC 向けというよりは数値計算向けです。
ただ、本当に数値演算アプリを書くならストライド付きブロックプリフェッチ命令よりも、ストライド付きプリロード命令が欲しいのです。
0016Solaris使い＞MACオタさん
02/10/14 02:25ID:bPNHvqGXMAC オタさんは元スレの 767 で
> ここで書いているプリフェッチわハードウェアによる実装も含むす。
ここまでずっとマルチワードキャッシュライン v.s プリフェッチ命令
(ソフトウェアプリフェッチ)の話をしていたと信じていたのですが。。。
元スレの 730 で MACオタさんが書いたように、マルチワード
キャッシュラインはハードウェアプリフェッチの1種です。
> 64byte/line = 32byte/line × 2 hardware prefetch
ただ 現在の一般に hardware prefetch と呼ばれる機構は、シーケンシャル
アクセスパターン/ストライドアクセスパターンを読んで、次のアクセスに
備えるようなタイプです。
そのため ある程度データに幅のあるストリームデータがターゲットになり、
ランダムアクセスのプリフェッチには逆効果だと思われます。
> マルチプロセスやTLP (Thread Level Paralellism)わ現代のプロセッサの
> 重要なテーマすから，タスクの種類や数に合わせてメモリアクセスを調整
> するという概念わ，今後実装されてくると思うすよ。
> 実際にPowerPCのBook E規格でわPIDレジスタという，プロセス番号をプロ
> セッサ内部で管理するレジスタが規定されているすけど，たぶんOSと強調
> してプロセス単位でプロセッサの挙動を調整するために使うんじゃないかと
> おもわれるす。
この内容には同意します。
一応、書いておくと、研究レベルではラインサイズや連想度を動的に変更
可能なアーキなんかが提案されています。
http://kasuga.csce.kyushu-u.ac.jp/~lsi-fab/CHIP/CD97-05.html
http://ne.nikkeibp.co.jp/award/papers/2002_univ19.pdf
後の pdf にはキャッシュの消費電力に関する考察もあります。
0017Solaris使い＞MACオタさん
02/10/14 02:26ID:bPNHvqGX> 命令の並列度抽出わ P4のようなアーキテクチャより、もっと大規模なスーパースカラプロ
> セッサでの問題すから。
私は元スレの 753 で、
> ご冗談でしょうファインマンさん。
> P4 はスーパースカラープロセッサの中でもっと大規模な部類に入ります。
MACオタさんは元すれの 753 で
> ファインマンさんわ正しかったのでわ？(笑)
> IU x 3, FPU(&SIMD) x 1, LSU x 2というP4わ，Athlon (IU x 3, FPU x 2,
> LSU x 4)やG4+ (IU x 4, FPU x 1, SIMD x 4, LSU x 1)と比べても少ないす。
> 並列度よりクロックを優先した普通のスーパーパイプライン構成だと思われるす。
P4 は IU 2(速)+1(遅)、FPU x2(ただし非対称)、LD x1、ST x1 です。
ただし IU (速い方)は 2 倍の速度で動作しているため、単純な整数演算は1/2
サイクルで動きます。これは仮想的に IU を増やす効果があります。
だから、実質的な整数ユニットは少なくない。FP が少ないのは確かですけどね。
747 でMAC オタさんが触れている POWER4 は、FX(IU) x2、LSU x2、FP x4(2+2)、
BR x1、CR(フラグ計算)x1 で、こちらの方が少ない気がするのですが。
しかも IU のレイテンシは 2 サイクル以上ですし、、、
0018MACオタ＞Solaris使い さん
02/10/14 04:48ID:Cop5M7s/そもそもRISCやショートベクトル機のプリフェッチ命令わメモリのレイテンシを隠ぺい
する程度のもので，ロングベクトル機のようにパイプラインそのものの一部でわ無いす。
ハードウェアの複雑さわ，AltiVecユニット全体でせいぜい4百万トランジスタ，面積に
して10mm.sq@180nmくらいすから現在の半導体プロセスでわ，もはや問題にならないす。
プリフェッチわメモリ-プロセッサ間とプロセッサ内部の速度差を埋めるものす。プロ
セッサ内部が十分高速な現在，プリロードでレジスタ迄送る必要わ無いし，マルチプロセス
環境でわむしろ有害す。
プリフェッチの有効性わ，むしろコアとBIU (Bus Interface Unit)の並列動作にあると
見るべきすね。
0019MACオタ＞Solaris使い さん
02/10/14 05:47ID:Cop5M7s/POWER4の実行ユニットわ，同時命令ディスパッチ数を上げるためにかなり工夫
したと考えられるす。IU，FPU, LSUを全て同機能のもので揃えたことわ注目
すべきじゃないすかね。
実際上，IUのSlowとFastとか，x86 FPUとSSEが同時使用されることわ無いすから。
なお，POWER4のIUのレイテンシわ1クロックす。ただし，結果をすぐにフィード
フォワードできないので依存命令わ1クロック待たされるす。詳しくわこちら。
http://groups.google.co.jp/groups?scoring=d&q=%22POWER4+integer+ALU+latencies%22+group%3Acomp.arch
0020名称未設定
02/10/14 06:17ID:XPmK31/2┃○ ○┃
┃ ハなイ こ ま ┃
┃ マ ボ ｜らン こ ┃
┃ ッ ケ ド�Aテ は と ┃
┃ ク �A 板Ｗル マ ┃
┃ は カ でｉ等 ッ め ┃
┃ 愛 ス やｎの ク ┃
┃ だ �A れか話 板 よ ┃
┃ ！ ク �B ┃
┃ ズ う ┃
┃○ ○┃
┗━┳━━━━━━━━━━━━━━━━━━━━━━━━━━┳━┛
0021MACオタ＞20 さん
02/10/14 06:21ID:Cop5M7s/対抗する技術の間の進歩と言うものわ蛙飛びに進むものす。
お互いに相手の現世代での特長を次世代で取り込み，逆に欠点も一緒に
抱え込んだりするものす。
0022名称未設定
02/10/14 10:45ID:CSrwnbryここはMac板なのでハードウェアに関することはハードウェア板でやるように
MACオタとSolaris使い さんは出て行くように
以上
0023名称未設定
02/10/14 11:44ID:v5vuNJj0って、表現が曖昧過ぎるというか、間違ってると思うんだけど。
ここはソフトウェアに限った議論しか出来ない板では無いですよね？
パーツに関する議論をするならより相応しい板があるでしょ、と言いたいのだろうか？
0024名称未設定
02/10/14 11:44ID:H49WrcO0>お互いに相手の現世代での特長を次世代で取り込み，逆に欠点も一緒に抱え込んだりするものす。
この板で議論する理由になっていません。
削除対象なので出ていって下さい。
0025名称未設定
02/10/14 11:48ID:a3qJI4zt実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。
0027名称未設定
02/10/14 11:52ID:H49WrcO0MacにPower4が採用されたらっていう所まではよかったが
Power4自体に関する議論になりMacとは関係なくなっている。
無理矢理Altivec関連の話題を出してるが
本筋はPower4の話をしたいだけだろ。
ハードウェア板に逝くべきだよ。
その方が議論も有意義になると思う。
0029名称未設定
02/10/14 11:58ID:rtzK5mh6関して伝えていました。そのプロセッサー名は「PowerPC 970」と呼ば
れ、32-bit アプリケーションも動かすことが可能(Book Eアーキテク
チャーと予想される)で、来年後半に1.8GHzで生産開始されるようです。
遅いなあ....
0030名称未設定
02/10/14 12:00ID:H49WrcO00031名称未設定
02/10/14 12:00ID:H49WrcO0実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。
0032名称未設定
02/10/14 12:01ID:H49WrcO0実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように
0033名称未設定
02/10/14 12:02ID:H49WrcO0実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。
0034名称未設定
02/10/14 12:02ID:H49WrcO0実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように
0035名称未設定
02/10/14 12:06ID:v5vuNJj0うん、そういう指摘なら良いと思うんだけどね。
「ここはMac板なのでハードウェアに関することはハードウェア板でやるように」
ってのは違うだろと言いたかった。
実際んとこ、適切な板でやった方が参加者が増えて、よりよい議論が出来そうですよね。
003629
02/10/14 12:06ID:rtzK5mh6されたコンピューター・サーバー、コード名をつけられた「レガッタ・
レース」に昨秋それはそれを送り出した)の「ライト」バージョンである
と言いました。
関係有るだろう。
0037名称未設定
02/10/14 12:11ID:U3RpC5/4Mac で使われるなんて一言も書いてないけど ? ?
0038名称未設定
02/10/14 12:14ID:v5vuNJj0詳しい人の一番多そうな板。
ハードウェア板という所がそうなんでしょうか？
0040名称未設定
02/10/14 13:18ID:uMZmnXkzだからと言って板違いスレッドを存続させるわけにはいかないだろう？
よく考えてから発言してくれよ
0041Solaris使い＞MACオタさん
02/10/14 13:18ID:bPNHvqGX一応断り書きを。17 で P4 と書いているのは、Pentium4 です。
>>19
> POWER4の実行ユニットわ，同時命令ディスパッチ数を上げるためにかなり工夫
> したと考えられるす。IU，FPU, LSUを全て同機能のもので揃えたことわ注目
> すべきじゃないすかね。
MAC オタさんはおそらく演算器のクラスタ化(MACオタさんの言い方で言えば VLIW 化?)を念頭において、
それぞれのクラスタに機能ユニットが一式入ることの利点を指摘したいのだと思いますが違いますか？
(一応、言っておくと POWER4 の FPU は 4個ですが、2種x 2個 で 4個です。)
> 実際上，IUのSlowとFastとか，x86 FPUとSSEが同時使用されることわ無いすから。
IU の Slow と Fast は同時実行されることは多いですよ。
Slow 側の IU は shift/rotate/multiply/divied で使います。rotate はまず使いませんが、それ以外は結構でてきます。
Fast と Slow には 4 : 1 の(実質的な)ユニット数の差があり、Slow で処理する命令は 4 サイクル以上かかるようなレイテンシの大きなものなのですから。
x86 FPU と SSE は同時使用され頻度は低いので、同じユニットで処理していますね。
Pentium4 も内部はクラスタ化されています。HT をやるから当たり前なんですけど。
0042Solaris使い＠41の続き
02/10/14 13:19ID:bPNHvqGXMAC オタさんの挙げた comp.arch の投稿って、IBM の POWER 開発者が答えているのですね。
POWER4 の IU が依存がなければ 1 サイクルというのは了解。
ただ IU 部が 2-way のスーパースカラーなので、すでに命令レベル並列性を使ってしまっていて、前後するサイクルに依存性がない命令を並べるのは難しいでしょうね。
(もし、それができるのであれば IU を増やす方向に行くでしょうし。)
余談としては、comp.arch の人たちが何故 Alpha の話を始めてしまうかというと、スーパースカラープロセッサの(CPU 内演算器の)グループ化(or クラスタ化)を始めたのが DEC が最初だったからです。
Alpha 21264 は 2つの演算器群をクラスタ化したばかりか、それぞれのクラスタ用にレジスタファイルを持っています。
同じ物理レジスタが 2 個あるのは、レジスタの outputstanding を実質的に上げるためと、レジスタ<->演算器の距離の縮めるため(2枚のレジスタはミラーリングをやりながら同期をとります)。
クラスタへの命令の割り付けはコンパイラの仕事で、21264 は 4命令を同時にフェッチし、奇数番を右クラスタ、偶数番を左クラスタに割り付けつけます(逆かもしれない)。
21264 をクラスタ境界できってやれば自然と SMT になります。
前に書いたけど、Pentium4 はこの構成を踏襲しています。
0043MACドザ ◆I/6l6yJHSI
02/10/14 13:21ID:GnyC37WNなんでこのスレだけ必死なんすか？（笑
0044名称未設定
02/10/14 13:23ID:23LV7otXこのスレッドは突然終了するおそれがあります。
こちらへ移動してください。
[統一] 次世代MacのCPUを語ろう
http://pc.2ch.net/test/read.cgi/mac/1034223390/l50
0045MACオタ＞Solaris さん
02/10/14 13:26ID:Cop5M7s/今のところCMPわ考えていないすから，ちょっと違うす。
POWER3/4わLSUが2組あるのを見ても判るように，スーパースカラ構造でマルチサイクル
の命令をどんどんディスパッチしていくという方針す。逆にシングルサイクルで大半の
処理が終わるIUわ他のプロセッサと比べても多くないのも，全実行ユニットを極力
並列で動かすという方針からだと思われるす。
0046名称未設定
02/10/14 13:29ID:uMZmnXkz0047MACオタ＠補足
02/10/14 13:30ID:Cop5M7s/dispatch, issue, executeの並列性わ分けて考えた方がよいかもしれないすね。
0048名称未設定
02/10/14 13:33ID:23LV7otXこのスレッドは突然終了するおそれがあります。
こちらへ移動してください。
ハードウエア板
━━━━━━━━━━━━ 終了 ━━━━━━━━━━━━
0049名称未設定
02/10/14 13:36ID:uMZmnXkz板違いっていってるだろ！
都合の悪いことは無視しないで下さい。
★☆★☆★☆ スレ乱立警報 ★☆★☆★☆
このスレッドは突然終了するおそれがあります。
こちらへ移動してください。
ハードウエア板
━━━━━━━━━━━━ 終了 ━━━━━━━━━━━━
0051名称未設定
02/10/14 14:08ID:gTsvX5ngMacはハードウエアじゃないのか？
0052名称未設定
02/10/14 14:19ID:mEZ9eoIZ実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。
0053Solaris使い＞MACオタさん
02/10/14 14:19ID:bPNHvqGX> 今のところCMPわ考えていないすから，ちょっと違うす。
CMP(Chip-On-Multi) ？
私は単に演算器のクラスタ化(依存関係を極力切る複数のパイプライン)の話をしています。
その先に SMT があります。
あと、この話は元スレ 747 での MACオタさんの
> 具体的なP4の実装についてわその通りす。命令の並列度抽出わ
> P4のようなアーキテクチャより、もっと大規模なスーパースカラプロ
> セッサでの問題すから。
が契機になっていますから、Pentium4 との比較だけで充分だと思います。
Pentium4 も演算器のレイテンシは単純な演算では 1 サイクルです。
(依存がある場合にレイテンシが伸びるという話は、まだ見聞きしていない)
あと、Pentium4 は演算器のクラスタ化も行っています(SMT をやるためでもある)。
0054MACオタ＞Solaris さん
02/10/14 14:21ID:Cop5M7s/じゃ，POWER4のFPUが4つというのわ どういう意味すか？2つしか無いすけど。。。
0055Solaris使い＞MACオタさん
02/10/14 14:43ID:bPNHvqGX失礼。「IBM ＠ server POWER4 System Microarchitecture」
http://www.ibm.com/servers/eserver/pseries/hardware/whitepapers/power4.pdf
の
"Two identical floating-point execution units, each capable of starting a fused multiply and add each cycle, i.e., a maximum 4 floating-point
operations (FLOPs) per cycle per core, are provided."
を読んで演算器は 2 つだが、最大2命令分発効できるキャパがあると
勘違いしていました。
POWER4 の FPU が 4 つだという点は訂正します。
0056MACオタ＠補足
02/10/14 14:48ID:Cop5M7s/並列度についてわPentium 4わ6命令/clock, POWER4わ8命令/clockで
実行ユニットにissueできるようになっているす。大きな差だと思うす。
0057MACオタ＞Solaris さん
02/10/14 14:54ID:Cop5M7s/このAlphaの実行ユニットのクラスタリングの話すけど，Pentium4の場合
http://www.intel.co.jp/jp/developer/technology/itj/2002/volume06issue01/art01_hyper/p04_implementation.htm
のように，各キューにパーティションが設けられているだけで，実行ユニット
をグループに分けているようにわ見えないす。
CRISC自体が本質的にCISC命令をμOPのグループに分けていると言われれば
その通りだと思うすけど。。。
0058Solaris使い＞MACオタさん
02/10/14 15:13ID:bPNHvqGX> そもそもRISCやショートベクトル機のプリフェッチ命令わメモリのレイテンシを隠ぺい
> する程度のもので，ロングベクトル機のようにパイプラインそのものの一部でわ無いす。
> ハードウェアの複雑さわ，AltiVecユニット全体でせいぜい4百万トランジスタ，面積に
> して10mm.sq@180nmくらいすから現在の半導体プロセスでわ，もはや問題にならないす。
プロセスルールやトランジスタ数だけで決まる問題ではないです。
でも、MACオタさんがそう考えているというのなら、現在の参照資料だけで このまま議論しても平行線をたどるだけですね。
もう少しちゃんとした資料をもってきます。キャッシュの way 数に関するものも含めて。
> プリフェッチわメモリ-プロセッサ間とプロセッサ内部の速度差を埋めるものす。
> プロセッサ内部が十分高速な現在，プリロードでレジスタ迄送る必要わ無いし，
> マルチプロセス環境でわむしろ有害す。
私の立場の確認ですが、
2,4,8ライン数で連続したキャッシュラインを読みこんで来るようなプリフェッチ命令を問題にしているのではないです。
ストライドを付けて複数ブロックを読みこむマイクロアーテキクチャの立場に立てば「優秀なプリフェッチ命令の例(元スレの690)」とは言えないだろうという立場です。
プリロード命令に関しては説明不足だったかも知れません。
私が意図していたのは従来型のレジスタに転送するタイプのものではなく、
元スレの 707 で挙げたような scrratch pad に対するプリロードや、
あるいは IA-64 のスタック汎用レジスタのバッキングストア動作のようなものを想定しています。
あと、マルチプロセス環境の問題は当然考えています。
ですから、私は数値計算アプリと条件を付けています。
分かってもらえると思うのですが HPC アプリのことです。
> プリフェッチの有効性わ，むしろコアとBIU (Bus Interface Unit)の並列動作にあると
> 見るべきすね。
プリフェッチ一般に関してはそうです。
0059MACオタ＞Solaris さん
02/10/14 15:21ID:Cop5M7s/参照資料の方わよろしくお願いするす。
プリフェッチについてわ，あんまりストライドのことわ考えていないすよ。私の
頭でわpermuateと同様にデータ構造から処理したい命令をまとめて抽出する方法
と解釈されているす。むしろ最初の議論に戻って，
http://pc.2ch.net/test/read.cgi/mac/1032957357/689
のような，
-------------------------
米つきバッタ見たいに prefetch 命令を発効し続ける必要があるから。
-------------------------
という意見に対して，PowerPC/AltiVec流のやり方を説明しただけす。
0060MACオタ＠続き
02/10/14 15:26ID:Cop5M7s/http://pc.2ch.net/test/read.cgi/mac/1032957357/707
に関して言えば，「ソフトウェア」プリフェッチわデータ構造が判っているから
つかえるす。AltiVecの場合わトランジスタ数をケチるためにL1にscrratch pad
の機能を兼用させているだけだと思われるす。そのため，キャッシュ機能の方が
優先で"dst"命令によってデータがL1にあるかどうかわ「保証されない」ということ
になっているす。
0061MACオタ＠続き
02/10/14 15:33ID:Cop5M7s/商用プロセッサわHPC用途とマルチプロセス用途の両方をバランス良く満たすことが求め
られているす。HyperThreadingにしてもHPC用途で役に立つのわ，
http://www.intel.com/jp/developer/technology/itj/2002/volume06issue01/art03_specprecomp/p02_intro.htm
こういう話が実現されてからでわないすかね？
0062Solaris使い＞MACオタさん
02/10/14 15:45ID:bPNHvqGX完全に等価なユニットが複数あるのは IU(Fast) しかなく、それ以外は共有せざる得ないので P4 で、
クラスタ化というとオーバーだったかもしれません。
スケジューラのアクティブキューの制約でもあるのですが、HT 時には同一スレッドの命令は
片側の IU(Fast) 割り当てるように、もう片方側はスケジューリングします(資料は検索中)。
いいたいことのまとめ。クラスタ化したパイプラインの中に流れる命令列を
・Alpha はコードのアドレスによって(コンパイラが生成)
・POWER4 は動的スケジューラが
・Pentium4 は HT によって
生成している。
> CRISC自体が本質的にCISC命令をμOPのグループに分けていると言われれば
> その通りだと思うすけど。。。
ここは良く分からないのですがどういう意味か説明ねがえませんか？
0063MACオタ＞Alpha使い さん
02/10/14 15:59ID:Cop5M7s/まず質問についてすけど，CRISCわ最初からx86命令がRISC命令の「グループ」であると
考えられて，この単位で命令の順序を管理すれば良いことが保証されているす。
POWER4のグループわdispatchとretireの順序を管理を単純にするために設けられて
いるとのことすから，こうした順序をCISC命令から抽出することわ意味があるかも
しれないという話す。
上手に固定長にならないすから，たわごとかもしれないすけどね。。。
0064MACオタ＞Alpha使い さん
02/10/14 16:04ID:Cop5M7s/アーキテクチャによるクラスタリングの違いの話すけど，
・Alpha(のSMT)とPentium4：マルチスレッドで命令スロットを埋める
・POWER4：シングルスレッドで命令スロットを埋める
と言う意味で，ちょっと違う気がするす。
0065Solaris使い＞MACオタさん
02/10/14 16:12ID:bPNHvqGXSupeculative precomputation はスレッド投機実行の 1種です。
適用分野としては、むしろ HPC 以外の メモリアクセスが読みづらい
アプリをターゲットにしています。
HPC は、メモリアクセスが単純なお馬鹿な世界ですから、今のままでも
プリフェッチはちゃんとかけられます。
Hyper-threading が HPC に効きづらいのは、複数の仮想プロセッサ
エレメントが L1 や Load/Store ユニットを共有するために
メモリ<->レジスタのスループットが不足することです。
>>63
> CRISCわ最初からx86命令がRISC命令の「グループ」であると
> 考えられて，この単位で命令の順序を管理すれば良いことが保証されているす。
合点承知しました。
>>64
お忘れかもしれませんが、SMT 化を図った Alpha 21364 は陽の目をみることはなくなったので、
現行の Alpha チップはみなシングルスレッドを処理するプロセッサとなります。
0066MACオタ＞Solaris使い さん
02/10/14 16:37ID:Cop5M7s/それを言い出すとマルチスレッド／マルチプロセス自体がHPCでわ不要になるのでわ？
CMPのPOWER4もHPC用のp690-HPCでわ片側のコアを殺していたりするす。
AlphaについてわIU+LSUが固定した「組」になっているすね。申し訳ないことに
いままで詳細をしらなかったすけど，先ほど21264の資料で確認したす。
0067MACオタ
02/10/14 16:57ID:Cop5M7s/最初の話わ，
「NetBurstとHyperThreadingわメモリアクセスのレイテンシを隠ぺいできるか？」
で良いすよね？
http://pc.2ch.net/test/read.cgi/mac/1032957357/675
自体わデータ予測をのぞけば，同意できるす。
http://pc.2ch.net/test/read.cgi/mac/1032957357/676
のPenitum 4のアーキテクチャの解釈にわ異論があるということすけど。
0068Solaris使い＞MACオタさん
02/10/14 17:33ID:bPNHvqGX元スレの 689 の私の発言「米つきバッタ見たいに prefetch 命令を発効し続ける
必要があるから。」の意図は、プログラマにとってコーディングがしづらいということです。
ここでは、プリフェッチ命令を発効することでの性能低下自体を勘案しておりません。
それはなぜかというと。。。
その前提として、MAC オタさんにお聞きしたいのですが、
現行の PowerMac G4 の実装では、dst が連続した複数のキャッシュラインを
フェッチしてくる場合に、1回のメモリバストランザクションで転送していますか？
例えば、4 ライン分を持ってくるなら、4回に分けて読みにいってませんか？
# 私は 元スレの 689 を書いた時点では、ミドルレンジ以下の RISC 系のシステムに
# マルチラインのプリフェッチ命令があっても後者のような実装しかせんだろうという
# 読みがあったのですが、、、
0069名称未設定
02/10/14 17:33ID:sM1QmSRy実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。
0070Solaris使い＞MACオタさん
02/10/14 17:34ID:bPNHvqGX> それを言い出すとマルチスレッド／マルチプロセス自体がHPCでわ不要になるのでわ？
> CMPのPOWER4もHPC用のp690-HPCでわ片側のコアを殺していたりするす。
マルチスレッドというのは SMT のことだと思うのですが、
マルチプロセスというのはマルチプロセッサ(CMP)のことですか？
そうだとして話を進めると、
CMP に関しては、p690-HPC(1CPU/1PE で 16PE)は ノーマル p690 の 16PE (1CPU/2PE で 16PE)
よりは速いけど、フル実装の p690 (1CPU/2PE で 32PE) よりは遅いですよ。
あと、同一プロセッサ内の PE が同じ仕事をすることによって、共有するデータが
増えるので、L2 / L3 を共有した CMP はまるっきり無駄というわけではないです。
SMT に関しては、性能は上がるけど上がり幅は小さいです。性能が落ちる要因もあります。
そもそも SMT は遊んでいる機能ユニットを有効活用させるのが主眼ですが、
HPC の世界はコンパイラががんばって機能ユニットを遊ばせない世界ですから、、、
＃ だから、みんな FORTRAN を使う。
>Alpha については...
マイクロアーキテクチャの世界では、
DEC は偉大な存在でした(過去形)。
研究者肌のエンジニアが多かったので、特許より論文を書くことに夢中で滅びてしまいました。
IBM はまだ巨大な存在です。新しいアーキテクチャを考案して、プロセッサも製造します。
Intel は MPC を最初に作ったけど、以降はただの製造者に落ち着いています。
0071Solaris使い＞MACオタさん
02/10/14 17:46ID:bPNHvqGX> だいたいお互いの言い回しなんかが理解できて来たところだと思われるすけど，
> 最初の話わ，
> 「NetBurstとHyperThreadingわメモリアクセスのレイテンシを隠ぺいできるか？」
> で良いすよね？
基本的に OKです。
最初は、HT まで話を広げるつもりはなく、NetBurst の部分だけをやるつもりでした。
> http://pc.2ch.net/test/read.cgi/mac/1032957357/675
> 自体わデータ予測をのぞけば，同意できるす。
う〜ん。
675 はアーキ全般の話の抽象的な話しかしていないので同意していただきたい所です。
あと議論点がいくつか残っていますが、
できるだけ現実の実装に沿って議論して行きましょう。
0072名称未設定
02/10/14 17:59ID:sM1QmSRy実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。
http://otakiller.virtualave.net/
もしくはこっちでやれ、誰の迷惑にもならん。
0073名称未設定
02/10/14 18:01ID:sM1QmSRy0074MACオタ＞Solaris使い さん
02/10/14 18:03ID:Cop5M7s/ご推察の通り，MPC7450 User Manualによれば，dst命令わハードウェア的にわ複数のdcbt
(32byteキャッシュラインアクセス命令)に分解されるとあるす。
ただし，split transactionでback-to-backアクセスが可能なバスで，これがどのように
問題になるのかわ私にわ判らないすけど？
0075MACオタ＞Solaris使い さん
02/10/14 18:08ID:Cop5M7s/しかしSPEC2000を稼ぐためにも，IBMわ片側のコアを殺した上，同じMCM上の
プロセッサからキャッシュをかき集めていたりするす。
Intelの研究部門に関してわ，大学発のベンチャーとして研究開発わ大学を支援する
というのがIntelの流儀だったすから，それほど貶すようなものでもないと思うす。
もっともそれが災いして，特許関係で不味いことになっているすけど。。。
0076名称未設定
02/10/14 18:09ID:sM1QmSRyhttp://tmp.2ch.net/test/read.cgi/mog2/1034585649/
上記２つのどちらかでやって下さい。
0077MACオタ＞Solaris使い さん
02/10/14 18:17ID:Cop5M7s/それでわ，まずキャッシュラインについてすけど
・小さなキャシュラインわヒット率わ上がるが，消費電力やレイテンシの問題がある
というのわOKとして，このレイテンシわコア内部の話だと思っているす。
メモリバス上でわ，
・大きなラインサイズわ無駄アクセスが発生する
・しかし帯域が大きければレイテンシのみが問題になるので，読み書きのサイズわ
気にならない
ということなんすか？私わ後者わ疑わしいと思うすけど。特に
・ヒット率が落ちることでメモリアクセスも増える
ということで，メモリアクセスに関してわ悪影響だと思うす。
0078Solaris使い＞MACオタさん
02/10/14 18:23ID:bPNHvqGX>>77
> ・小さなキャシュラインわヒット率わ上がるが,
これは私の主張ではありません。
0079MACオタ＞Solaris使い さん
02/10/14 18:26ID:Cop5M7s/普遍的事実でわ？違うのならヒット率が下がるとか，上がらないとかの根拠が欲しいす。
0080Solaris使い＞MACオタさん
02/10/14 18:51ID:bPNHvqGX元スレの689 でも触れましたが 、
http://pc.2ch.net/test/read.cgi/mac/1032957357/689
ラインサイズを大きくすることは、キャッシュミス率を上げる要因も 下げる要因もある。
＃ ここではプリフェッチ命令を挿まないような普通のアプリを想定しています。
＃ また、マルチプロセッサを考えていません。
1ワード=4バイトとして、64バイト(16ワード)の構造体へのアクセスを考えてみてください。
ラインサイズ16バイトのデータなら 4回キャッシュミスが起こって、キャッシュミス率 1/4。
ラインサイズ64バイトのデータならキャッシュミスは最初の 1回で、キャッシュミス率 1/16。
これが上がる根拠。
下がる根拠は、コンパイラがキャッシュラインに揃えてデータを整形するので、
ラインサイズ中に使えない部分があり容量性のキャッシュミスが起きる可能性が増える。
プログラムのデータ構造との兼ね合いによって決まる最適値がある。
しかし、私は Pentium3 までの16バイトというのはやや小さすぎで最適値ではないと考えます。
また、同一キャッシュ容量なら消費電力やレイテンシは、キャッシュラインサイズよりも連想度(associativity) に受けると考えれます。
＃ 消費電力はともかくレイテンシのはすぐには納得いかないと思いますが、
＃ 指摘があれば説明します。
p.s.
MACオタさんは、683で「L3 タグ管理がサボれる」、717 で「ラインサイズの
拡大でトランジスタ数と時間わ節約できる」と言われました。
http://pc.2ch.net/test/read.cgi/mac/1032957357/683
http://pc.2ch.net/test/read.cgi/mac/1032957357/717
これを読んだときから、ちょと変に感じていたのですが、どのような理由によってトランジスタ数と時間が節約できるとお考えですか？
なんらかの想定が必要でしたら 32KB の程度のキャッシュが 16バイト→64バイトをご仮定ください。
0081Solaris使い＠訂正
02/10/14 19:00ID:bPNHvqGX> に受けると考えれます。
また同一容量のキャッシュなら消費電力は、キャッシュラインサイズよりも連想度(associativity)
の影響を多く受けます。
またレイテンシについて考えると、L1 → レジスタであればラインサイズ
の影響を受けません。また、要求された語を先送りする early start の
ような技法を備えた実装も多いそうです（パタヘネ 7.2章より)。
0082名称未設定
02/10/14 19:05ID:5bwxwuyfSolaris使いさんも開き直らないで謝罪しる！
0083名称未設定
02/10/14 19:06ID:a0hQa18o実際にMacで使われていない
または使えないハードウェアに関することは
ハードウェア板でやるように。
0084MACオタ＞Solaris使い さん
02/10/14 19:08ID:Cop5M7s/キャッシュ容量が同じ場合，トランジスタ数が節約できる理由わ明白す。実例を書けば
PowerPC 750のL2のラインサイズわタグメモリのサイズが固定であるため，L2の容量
とともに次のように変わるす。
256KB/512KB: 64 Byte
1024KB: 128 Byte
すなわり1MBあたりのタグメモリわ128 byte/lineだと半分になっているす。
確かにレイテンシと消費電力わセットの数の方が重要すね。
0085名称未設定
02/10/14 19:10ID:dS1UerAGそれに謝罪ってなんでそこまで要求するかな。
0086名称未設定
02/10/14 19:11ID:yuTJAcBAこいつら、なんだ？CPUでも造ってる気になってるのか？
激しくくだらない知識ばら撒いてんじゃねーぞ！！オラー！！ (ﾉ｀A")ﾉ ┫：・’．：：
0087名称未設定
02/10/14 19:11ID:5bwxwuyf0088名称未設定
02/10/14 19:14ID:5bwxwuyf創造や生産、娯楽にすらMacを使いこなせないからこう言う方面に話がいってるのかもな。
オタを見てるとそう思う。
無力なことを思い知れよ・・・哀れ・・・。
0089MACオタ
02/10/14 19:22ID:Cop5M7s/0090名称未設定
02/10/14 19:25ID:a0hQa18oそうやって味方を増やしてどうにか板違いを正当化しようという魂胆みえみえす。
0091名称未設定
02/10/14 19:32ID:TffgUBH3叩きについて
最悪板以外では全て削除します。
スレッド
固定ハンドルが題名に入っている・固定ハンドルが占用している
・閉鎖的な使用法を目的としている
・等は、自己紹介板・最悪板・夢・独り言板
・おいらロビー・なんでもあり板以外では、
原則として全て削除または移動対象にします。
ただし、固定ハンドル個人が一群または二類に属する時は
他の削除規定に触れない限り様子見となります。
0092名称未設定
02/10/14 19:41ID:AAln9dngあれほど技術力のもった企業ってあんまりないよなぁ。
やっぱりミニコンに執着しすぎたのかなぁ、Unixを取りこむのも遅すぎたし。
最期のほうでAlphaなんてすばらしいプロセッサ出してくれたけど、やっぱり遅すぎたよなぁ。
# そういやハード、ソフトともにDECの技術を継いでるものって結構あるよなぁ。
0093名称未設定
02/10/14 19:45ID:oRqLg0PWMacのG4が現在IntelのCPUに勝てないからって、次世代に逃げて
オナニーしてるんじゃないだろうな。そうだとしたらお前らセガ
信者となんら変わりねーぞ。セガは悲惨だったな（藁
とりあえず、メガビのお前のスレを嘲笑しておいてやるよ。
いつまで経ってもMACオタは進歩しねーな（藁
MACオタはバカを晒して楽しいかもしれんが見てるこっちは気持ち
わりぃんだよ。どっかいけ！
0094名称未設定
02/10/14 19:45ID:lUD8Akdw君の掲示板ではありません。
板違いの話題はルールに反してますが？
0095MACオタ＞92 さん
02/10/14 19:46ID:Cop5M7s/最初のAlphaの登場が1992年すから，10年かけてもモノにならなかったとも言えるす。
結局わソフトの問題なんじゃないすかね。
0098名称未設定
02/10/14 19:53ID:lUD8Akdwhttp://pc3.2ch.net/test/read.cgi/hard/1034592680/l50
【隔離】P4アーキテクチャについて議論する
1 ：不明なデバイスさん ：02/10/14 19:51 ID:h1zNFJxu
ここは板違いの話題のために新Mac板を追い出された
MACオタがPower4アーキテクチャについて議論するスレです。
0099MACオタ
02/10/14 19:57ID:Cop5M7s/ttp://corn.2ch.net/test/read.cgi/nanmin/1034586378/
ttp://tmp.2ch.net/test/read.cgi/mog2/1034585649/
ttp://pc3.2ch.net/test/read.cgi/hard/1034592680/
0100名称未設定
02/10/14 20:00ID:lUD8Akdw重複スレを立てるなって言ってるんだろ。
厨房のやったことをネタに煽るのは如何なもんかと思うす(笑)
ま、いいだろ？移転先が見つかったんだから
http://pc3.2ch.net/test/read.cgi/hard/1034592680/
010192
02/10/14 20:03ID:AAln9dng漏れはオタさんじゃないですよ(w
>>95
DECってソフトウェアに関しても優秀な技術者がそろってるイメージだけどなぁ。
(自前でRT-11,RSX-11MやVAX/VMSなんて出来のいいOS作れるし)
やっぱりカトラーを干したのがまずかったか(w。
やつがMSに移りゃなきゃMSもいまよりもうちょっとましな商売してただろうし(w
0102MACオタ＞100 さん
02/10/14 20:04ID:Cop5M7s/真面目に聞くすけど，>>99の三つわ，いわゆる「同一掲示板にないマルチポスト」
として，かなり悪質度が高いと判断されるとわ考えなかったすか？
0103MACオタ＞100 さん
02/10/14 20:13ID:Cop5M7s/回答がないようすけど，悪気が無かったのなら自分で削除依頼を出しておくことをおすすめするす。
0104名称未設定
02/10/14 20:15ID:AyN/xV9i0105100
02/10/14 20:37ID:sM1QmSRyまぁ、２つは同一内容だが
http://pc3.2ch.net/test/read.cgi/hard/1034592680/
はこのスレの受入先じゃないか？
こちらもまじめに聞くが重複スレを立てたことは
謝らないのか？
0106MACオタ＞105 さん
02/10/14 20:46ID:Cop5M7s/>>98や>>100の方とわIDが違うようすけど。。。
ID:sM1QmSRyわ17:30頃からいるということわ，自作自演の告白すか(笑)
http://pc.2ch.net/test/read.cgi/mac/1034551147/62
0107Solaris使い＞MACオタさん
02/10/14 21:57ID:bPNHvqGX>>56
> 並列度についてわPentium 4わ6命令/clock, POWER4わ8命令/clockで
> 実行ユニットにissueできるようになっているす。大きな差だと思うす。
Pentium4 の単純な命令なら 0.5 サイクルで処理できる Low-latency ALU も
1命令/clockとカウントされているのですが...
>>75
> しかしSPEC2000を稼ぐためにも，IBMわ片側のコアを殺した上，同じMCM上の
> プロセッサからキャッシュをかき集めていたりするす。
SPEC 値の方はレイテンシをみるベンチだからしょうがないです。
当然、IBM も分かっていてスループットを測る rate 値の方では 32CPU が顏を出します。
1x16CPU int2k_rate=131 fp2k_rate=145
2x16CPU int2k_rate=249 fp2k_rate=260
SPEC の rate 値ってどのぐらい信頼性があるのかは謎ですが。
>>84
MACオタさんの挙げている点だけでは、タグメモリの容量が減ってないから全体のトランジスタ数は減っていないです。
「メインメモリ 1MB あたりのタグメモリ」では性能のパラメータになってしまう。
本当はタグビットとエントリ数を維持したまま、ラインサイズを拡大すると、タグメモリと連想検索を行う比較器がどの小さくなるかを指摘して欲しかったのですが。。。
0108Solaris使い＠訂正
02/10/14 22:07ID:bPNHvqGX>>56
> > 並列度についてわPentium 4わ6命令/clock, POWER4わ8命令/clockで
> > 実行ユニットにissueできるようになっているす。大きな差だと思うす。
> Pentium4 の単純な命令なら 0.5 サイクルで処理できる Low-latency ALU も
> 1命令/clockとカウントされているのですが...
失礼。
Low-latency ALU も含めて 6命令/clock でした。
0110MACオタ＞Solaris使い さん
02/10/14 22:23ID:Cop5M7s/コストを考えるとプロセッサの設計わ面積の取り合いすから，ラインサイズを大きくすると
同じセット数で面積が小さくできるというのわ意味があると思われるす。
単純に性能とコストのトレードオフとしてラインサイズが決定されているという要因わ
少なくないと思われるす。
ところで，ラインサイズの決定要因についてわこの文章が良くまとまっているすね。
多分Solaris使いさんの言いたいこともこれと同じだと思うすけど如何すか？
http://www.aceshardware.com/Spades/read.php?article_id=77
Why does the Athlon uses a 64 byte cache line? One of the reasons is spatial
locality. Caches work on the principle that some data is used over and over
again, but it is also true that it is very likely that if you access some
memory cells, you will need the data in a adjacent memory cell at some point
in the future. So, if you read in adjacent memory cells of a memory cell that
you need to have in the cache, you might get lucky in the future, as it is very
likely that you need one of those adjacent cells. In other words, spatial locality.
With a 64-byte line cache you can save the CPU quite a few trips to main memory.
Also, using a 64 byte cache lines instead of a 32 byte line decreases the total
number of cachelines by two. Less cachelines mean faster lookup speed.
0111MACオタ＞109 さん
02/10/14 22:26ID:Cop5M7s/結局，訳も無くスレ立てするのが好きなヒトだったすか(笑)
心の中に"棚"がたくさんあるすね。。。
0112Solaris使い
02/10/14 22:37ID:bPNHvqGX今、気づいたが P6(PentiumPro) のキャッシュラインサイズって 32 バイトだよ。
何故、16 バイトと勘違いしていたのだろう。プリフェッチのフェッチ幅も 32 バイト。
それ以上に、誰もツッコミを入れなかったのか不思議だ。
Pentium4 はキャッシュライン 64 バイト。
ただし、プリフェッチ命令は128バイト(キャッシュライン 2 つ分)のマルチラインプリフェチ。
ただし、幅は固定。
0115MACオタ＞Solaris使い さん
02/10/14 23:17ID:Cop5M7s/64bit幅のバスと現代のDRAMの組み合わせでわ8byte x 4beat burstで32byteのキャッシュラインが自然だという話だけすけど。
0116不定期
02/10/14 23:21ID:RGrqPVyC0117MACオタ＞Solaris使い さん
02/10/15 00:06ID:01d2nBRwを介しても送れるす。上の「不定期」さんわあちこちで迷惑をかけている変なヒト
すから，レス削除依頼をだしてみるのも良いかもしれないすね。
http://qb.2ch.net/saku/index2.html
0118Solaris使い＞MACオタさん
02/10/15 00:07ID:nqNc6rxM> ところで，ラインサイズの決定要因についてわこの文章が良くまとまっているすね。
> 多分Solaris使いさんの言いたいこともこれと同じだと思うすけど如何すか？
最後の 2文以外は、私の言いたいことと同じです。
ただ、このページで書かれていることはアーキテクチャの基本なので、教科書のたぐいであれば必ず書かれているはずです(x86に特化してはいませんが)。
特にアーキテクチャの教科書の代表の1つ David A. Patterson/John L.Hennessy の「Computer Organization and Design: The Hardware/Software Interface 2nd Edition」
(著者の名前を取ってパタヘネ本と呼ばれる)では、キャッシュに関しては PentiumPro と PowerPC 604 を比較も行っています。MAC オタさんにはぜひとも読んでみることをお勧めします。
http://www.amazon.co.jp/exec/obidos/ASIN/155860491X/
＃ 本当はもう1冊の方が有名。
＃ その名もずばり "Computer Architecture: A Quantitative Approach"
＃ 前の本と同じ著者が書いていて、名前順が違うのでヘネパタ本と呼ばれている。
> Also, using a 64 byte cache lines instead of a 32 byte line decreases the total
> number of cachelines by two. Less cachelines mean faster lookup speed.
これは少し怪しいと思われ。理由は下の方。
>>107
で書いたことはよく考えると嘘だ。
16KB の direct-mapped cache だとすると。
16KB で 32 バイト→ エントリ 512。インデックスビット 10ビット。タグビット16ビット。
16KB で 64 バイト→ エントリ 256。インデックスビット 9 ビット。タグビット16 ビット。
＃ タグビット幅はキャッシュの容量で決まり、エントリ数はラインサイズの逆数で決まる。
タグメモリ容量 = (タグビット + 1)×エントリ数。
1. メモリアドレスから direct-mapped なキャッシュを引く操作はインデックスビットが小さいほど高速(トランジスタ数も少ない)。
2. 比較器は構成はタグビットの長さによって決まるので変わらず。
3. マルチワードのキャッシュラインから任意のデータ取り出す処理はラインサイズが小さいほど高速(ここは実装方法の要素が大きい)。
0119MACオタ＞Solaris さん
02/10/15 00:16ID:01d2nBRwトランジスタ面積もばかにならないようす。
メモリとのやり取りわL1よりL2のリプレースメントによると思うすから，L2のライン
サイズの影響はいろいろと問題になるんじゃないすかね？
0120Solaris使い＞MACオタさん
02/10/15 00:34ID:nqNc6rxMMACオタさんは 84 では正しいことを言っているのに、119 では逆のことを言っていますよ。
タグビット幅 = log2(キャッシュ対象メモリ空間サイズ/キャッシュ容量)
エントリ数 = キャッシュ容量 / ラインサイズ
タグ容量 = (タグビット幅+1) / エントリ数
ですね。
0121Solaris使い＠訂正
02/10/15 00:36ID:nqNc6rxM> タグ容量 = (タグビット幅+1) / エントリ数
タグ容量 = (タグビット幅+1) × エントリ数
0122名称未設定
02/10/15 00:44ID:iUpQFB5q0123MACオタ＞Solaris使い さん
02/10/15 01:15ID:HxyO8J+R---------------------
119 では逆のことを言っていますよ。
---------------------
失礼したす。
0124名称未設定
02/10/19 11:37ID:tB+a0GxE0125MACオタ＞124 さん
02/10/19 11:47ID:zQb4C5jV保守してくれるのも結構すけど，もうSolaris使いさんわ来ないんじゃないすか？
0126名称末設定
02/10/19 12:36ID:hg5LXAjr0127名称未設定
02/10/19 12:37ID:tB+a0GxE> > >>120
> > ---------------------
> > 119 では逆のことを言っていますよ。
> > ---------------------
> > 失礼したす。
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆ 終わり ◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
■ このスレッドは過去ログ倉庫に格納されています