[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[plamo:19678] Re: make-jについて
-
From:R4000 2.2
-
Date:Mon, 14 Jul 2003 16:32:06 +0900 (JST)
- Subject: [plamo:19678] Re: make-jについて
- From: "R4000 2.2" <tati@xxxxxxxxxxxxxxxx>
- Date: Mon, 14 Jul 2003 16:32:03 +0900 (JST)
こんにちは、立花@鎌ヶ谷市です。
In <20030714044649.GB3068@wiz7.prosaic1.a08.aist.go.jp>,
at Date: Mon, 14 Jul 2003 13:46:49 +0900,
on Subject: [plamo:19677] Re: make -jについて ,
OHNO Tetsuji <azure-ml@fan.gr.jp> writes:
| On Mon, Jul 14, 2003 at 12:18:03PM +0900, Shun-ichi TAHARA wrote:
| > 試したことはないのですが、実はシングルCPUなマシンでもSMPカーネルの方が
| > 速かったりして…
|
| もしかするとそうなのかもしれません。いつもシングルなカーネルばかり作って
| ますから、損しているかも (^^;
CPU 内部の並列性が OS から見えるようなやつなら、そうなのかなぁ、とは
思いますが、Pentium4 の μOP はソフトからは見えないですよね。
# Pentium4 の並列性って、μOP レベルで稼いでるんではなかったでしたっけ
そういうので、シングルCPU上で SMPカーネルが速くなるとは思えないです。
#かつての仕事で、CPUあたり75%を下回らなければ十分、というのを聞いた
#ことあります
単純に考えても、Test and Set や spin を試みる分だけ余計にかかるような。
| ああ、でも主に画面を書くのに使うわけだから、必要とされる計算自体依存関係が
| 少ないのかもしれませんね。そういう条件なら、並列化も難しくなさそう。
HT の発想って、まさにそれではなかったんではないかなぁ、と。
#MMX とか SSE とかも同じ発想のような
| > なんとなくですが、非決定分岐予測エンジン(ようは超並列パイプラインでの
| > 全枝同時実行)の裏で分岐予測も行なって、その的中率を覚えておいて、枝数
| > と的中率をはかりにかけて、そのスレッドでの今後の枝狩りのパラメータを動
| > 的に変更する、みたいなアーキテクチャが出てきそうな気がしません?
|
| (こういう深い話になってくると知識がないのがバレバレではずかしいのですが)
| ソフトウェアでやったほうが楽そうなかんじですね。CPUの中にそれ用の演算ユニット
| もったりして。
|
| # 分岐予測用サブプロセッサ付きプロセッサ、とか
|
| つうか今の分岐予測ってのもどうやっているのやら、私にはさっぱりなんですが...
分岐予測は私もわかってないですが、分岐予測せんでもええような
オブジェクトコードをコンパイラが吐き出せってのが古典的な RISC で、
CPU で分岐予測とかがんばっちゃうよ、てのが CISC でなかったでしたっけ。
分岐予測しなくてすむコードが常に吐き出せるわけでないので、結局 RISC でも
分岐予測が必要になって、一方 CPU でがんばるにも限度がある、ってんで
コンパイラにがんばってもらうようになったのが Crusoe とか IA-64 だった
ような。
#うーん、ヨタ話にしかならんなぁ
--
tati@kc5.so-net.ne.jp 立花 晃@鎌ヶ谷市
- Follow-Ups
-
- [plamo:19679] Re: make -jについて, SO
- [plamo:19686] Re: make-jについて, R4000 2.2
- References
-
- [plamo:19670] Re: make -jについて, OHNO Tetsuji
- [plamo:19672] Re: make-jについて, Shun-ichi TAHARA (田原 俊一)
- [plamo:19677] Re: make -jについて, OHNO Tetsuji
[検索ページ]
[メール一覧]
Plamo ML 公開システム