■スレッドリストへ戻る■ 全部 1- 101- 201- 最新50

(*゚Д゚)<MacとWinをアーキテクチャで比較スレ

1 :●~* :02/03/05 13:53

精神論や宗教論は排除して、技術面で面白い比較キボンヌ

議題その1
x86系CPUとPPCをCISCとRISCという観点で見た時のメリット・デメリット

2 : :02/03/05 14:07
関連スレ(上に行くほどヒット率高し):

PowerPCマンセーなみなさん、こんばんわ
http://pc.2ch.net/test/read.cgi/jobs/1003253967/

G4×2がペンV1Gより早い?
http://pc.2ch.net/test/read.cgi/jobs/975156527/

PPC G4 1GHz突破はもうすぐ
http://piza.2ch.net/mac/kako/967/967234541.html

おい、腐れマカーどうすんだよ
http://pc.2ch.net/test/read.cgi/jobs/998717252/

この時代、何がメリットでMacを選びますか?
http://pc.2ch.net/test/read.cgi/jobs/1002547473/


3 : :02/03/05 14:08
派生元:
旧Mac板初心者質問スレ#7
http://pc.2ch.net/test/read.cgi/jobs/1014545492/383-434


4 : :02/03/05 14:10
アスキー用語辞典:

CISC
http://yougo.ascii24.com/gh/00/000009.html

RISC
http://yougo.ascii24.com/gh/00/000010.html


5 : :02/03/05 14:13
議題に対する漏れの疑問:

・rc5ベンチとかが速いのって、RISCの特長を活かしているからなのか?
 (ビッグエンディアンは関係ないのか?)

・RISCは単純な処理に向いている、というのはわかるけど、
 クロック数もRISCの方が上げやすいと思ってた。どーなんだろ?

・Altivecは拡張命令では無いのか? RISCの特性と反するが良いのか?


6 :i桜 :02/03/05 14:15
とりあえず検索してヒットしたCISCとRISC比較解説ページ
ttp://bannin.net/den_noh/pc_4.htm
ttp://www.mentorg.co.jp/embedded/technical/risc.html

下のリンク先より
>システムのパフォーマンスはプロセッサのスピードだけで決まるものではありません。
>よく見落とされるのは、使用するコンパイラの最適化の能力です。
>与えられたプロセッサのアーキテクチャで最大限のパフォーマンスを得るためには、
>コンパイラによって効率の高いコードを生成することが重要です。

単純にクロックスピードや偏ったベンチ結果だけで比較しても
何か符に落ちないのはこのへんが所以かしら
# 知識が本当乏しいのでもっと勉強しないと駄目だなぁ…

7 : :02/03/05 14:28
>>6
う。話が最適化のほうに進むと、間違いなくシェア論に移行するか、
Photoshopベンチ叩きに移行するぞ。
あくまでハードウェア・アーキテクチャに限定して語ったほうが宜しいかと。

ともあれ、上のリンクでなんとなくPPCとx86の実情がわかった気がする。
ベースが違うだけで、どちらもやってる事は大差ないというか。


8 :i桜 :02/03/05 14:32
>>7
うひ。スミマソン

マイクロプロセッサの25年
http://www.ieice.org/jpn/books/kaishikiji/199910/19991001.html
非常に面白いが難解だw
全部理解するのに小一時間ほどかかりそうですw
RISCに関する言及は「7」以降

9 : :02/03/05 14:58
>>8
dj?

10 :i桜 :02/03/05 15:06
>>9
ん、よく読んだらあんまり比較なネタ書いてなかった
RISCとCISCで検索したらヒットしておもろかったから貼ってみただけぞな...

PPCマンセースレ読み返したらオモロー

11 : :02/03/05 15:11
>>10
まずは過去ログのまとめでもやった方か良さそうね。

# その前に、ネットワーク環境なおさにゃ。。。

12 : :02/03/05 16:48
>>11
お前の病気も治せよ w

13 : :02/03/05 16:49
>>12 オマエモナー

14 : :02/03/05 16:50
煽りは無視ということで w

15 : :02/03/05 16:56
>>12
わ、私、不治の病で、あと3ヶ月の命なんです。。。

16 : :02/03/05 16:58
梨は果物の王様だ!

17 : :02/03/05 17:01
>>16
つーか、殆どカターリだろw

# PPCマンセースレの要約は、あとで暇になった時にまとめてするさ。

18 :Laplace :02/03/05 18:14
>>8
>非常に面白いが難解だw
わざと,読みずらくしているんじゃないかなぁー.
センテンスが長過ぎる!
だらだらと,読み進んで...わけがわからなくなって,読み返し...
どこまで戻って良いかさえも,迷ってしまう.

内容的には,そこそこ,おもしろいけれど,無神経きわまりない文章.
そういえば,教科書にも,同じ事が言えるなぁー.
逝ってよし!


19 :●~* :02/03/05 20:35
i桜と梨のチャットスレはここですか?

20 : :02/03/05 20:56
ココは梨による求愛のためのスレです。

21 :●~* :02/03/05 21:36
求愛のダンスキボーソ

22 :●~* :02/03/05 21:54
まずのどを膨らませ・・・かえるか

23 :●~* :02/03/05 21:55
おれはチンコもみもみだと願って止まない

24 :●~* :02/03/05 22:01
折れは往年のカズを連想させる金玉踊りがいいな

25 :●~* :02/03/05 22:28
痛ぅ

26 :●~* :02/03/06 21:04
良いスレッドだと思ってたのに,
この展開はなんなのだ ?!

27 :●~* :02/03/06 22:53
この板のレベルなりのスレッドやん

28 : :02/03/06 23:26
>>26
正直、仕事忙しくてかまってらんなかった。。。

今から待ち合わせなんで、少し頑張ってみます。

29 : :02/03/07 02:27
要約(1/3)

アスロン1.4GHzでPowerPCをエミュると1GHz相当らしい。
MacOSがPPC版しかないだけで PPCマンセーな人ばかりでもないよな。
マカはいがいとAthlonにはキティ反応示さないね。
発煙・発火は家電、パソコンメーカーにとって、超重大事項。
あぽーは隠し通せる物は、隠すのが経営方針のようですが(藁
エミュのほうが本物を上回る速度が出てくるかもしれないんですね。
G4って32bitじゃないの?
CPUは64bitだったよ。どうやらCPU2つでデータバス128bitらしい。
>>128さんのソースのリンク先で見つけたんですが、モトローラ
のHPにも次のような記述がありました。やはりG4も32bitCPUですね。

Motorola's MPC7451 host processor is a high-performance, low-power, 32-bit
implementation of the PowerPC architecture with a full 128-bit implementation
of Motorola's AltiVec(tm) technology.


30 : :02/03/07 02:27
要約(2/3)

モトローラのMPC7451ホスト・プロセッサーは
モトローラのアルタベック(tm)技術の十分な128ビットのインプリメンテーションを備えた
パワーPCアーキテクチャーの高機能、低出力で、32ビットインプリメンテーションです。
このマイクロプロセッサーは、最先端コンピューティング、
埋め込まれたネットワーク・コントロールおよび信号処理アプリケーションにとって理想的です。
MPC7451は、2つの追加の実行ユニットを備えた新しくより深く、
7-段階パイプラインを持っています。L2キャッシュはより大きな速度のためのさいの上に
統合されており、64ビットのdatapathを備えた大きなL3キャッシュをサポートします。
MPC7451提示は、最小限の信号段取り時間を備えた、
アドレス空間および高い帯域幅のMPXバスを増加させて、
バス帯域幅を最高速度に増加させる使用されていないサイクルを縮小しました。
133MHz。MPC7451プロセッサーは単一のサイクルの
処理能力倍精度浮動小数点の性能および十分な対称な多重処理(SMP)能力を提供します。
最後に、MPC7451は、既存のモトローラMPC6XX、MPC7XXおよびMPC7XXXプロセッサーと
ソフトウェア互換性をもち、アルタベック技術の十分な可能性を開発します。


31 : :02/03/07 02:28
要約(3/3)


64bitCPUになったからって、単純にパフォーマンスが上がるわけじゃない。
基本的に、4GBより多くのメモリを扱えるようになる点がメリット。Itanium
も、パフォーマンスを上げるためにEPICやVLIWなどのテクノロジを導入して
いる。いずれにしてもPCには関係のない話だね。

(1) 現在デスクトップPCに使われているCPUわ、全て32bit CPUである。
(2) CPUの"bit"数わ
 ・整数レジスタの幅
 ・機械語におけるアドレス表現
のいずれかのことす。

SIMD :
Single Instruction Multiple Data :
一回の命令で複数のデータに対して同じ処理をおこなう方式.

SSE :
Streaming SIMD Extensions :
MMX の後継方式.
MMX の SIMD 命令は Integer しか,扱えなかったが,
Floating Point も扱えるようにした.(以下,略)


あと、「Altivecを外しても消費電力はさほど変わらないんでねーか」って話と、
「PowerPCはリトル・ビッグと切り替え可能なのです。」って話と、
「<!--これは--用法間違い--では?--> 」って話が比較的有意義かと。


つーか、RISCの話はまるで解決してなかった。スマソ。


32 : :02/03/07 02:47
要約(1/1)

Pentium4は対応ソフトでは性能2倍でも非対応アプリは遅いと批判されてる。
似てるなあ。
Pentium4≒G4
いや、周波数だけはどんどん上げられるみたいだぞ。
昔のスレッドって今見ると面白いね。
500MHzのCPUを二つ以上積んだ場合、スレッド分配のオーバーヘッドのせいで
単体500MHzより遅くなる場合があるのをご存知でしょうか?
マルチCPUのメリットって、速くなるんじゃなくて遅くなりにくいということを
お忘れなく。
>>2 鬱だ。。。


33 : :02/03/07 03:02
おい、腐れマカーどうすんだよ
http://pc.2ch.net/test/read.cgi/jobs/998717252/

要約(1/2)

マルチスレッドプログラミングについて言及しているが、なんか話が噛んでないw

66 名前:名称未設定(sage) 投稿日:01/10/28 16:44
順当にMacユーザが数を減らしている昨今、この板はその役割を終えつつあるといえよう。
http://www.watch.impress.co.jp/pc/docs/2002/0131/kaigai01.htm
DRAM
集積率が高く容量当たりの単価が安い、消費電力が低い、遅い
SRAM
集積率が悪く容量当たりの単価が高い、消費電力が高い、速い
http://www.yk.rim.or.jp/~okuno/be-free/jp/intro/RISC_and_CISC.html
ここちょっと面白い。
http://www.ceres.dti.ne.jp/~peg02305/new/sub19.html
関係ないけど。
http://www.zdnet.co.jp/mobile/news/0108/20/arm.html
マカのいいぶん。Pentium!!!の話よね。化けてるけど。
http://www.musin.co.jp/Computer/CPU_R.html
マカサイト。P4おせーなー。
http://www.barefeats.com/pentium4.html
分かりやすそうなページをハケーンしたよ。
http://www.infonet.co.jp/ueyama/ip/resume.html
PC/100 CL=2 と PC133 CL=3 の性能差の謎
http://www.yaroespage.com/nazo/nazo015.html
DRAMのアクセスの仕方が書いてある。


34 : :02/03/07 03:03
要約(2/2)

ええと、漏れも「SRAMは消費電力が低い」に1票。
時代によって変わるものだと思うから、暗記するもんじゃないと思うが。
http://wdic.asuka.net/?title=RAM
http://www.hitachi.co.jp/New/cnews/0101/0104.html
Crusoe派の漏れとしては、何bitあってもいいんだが。
http://ascii24.com/news/columns/10107/article/2001/08/09/628656-000.html
エルピーダに日本語のドキュメントがあった。これを読めばほとんど解決かもしれない。
http://www.elpida-memory.com/ja/products/index.html
20フェムトファラド。20x10^-15。
こんな小さなキャパシタの充放電にどれくらい時間がかかるって?
http://www.elpida.com/ja/news/20010622.html
DRAMの解説
http://www.atmarkit.co.jp/icd/root/35/5785735.html
  -------------------------------------------------
  コンデンサに蓄えられた電荷は、時間とともに漏洩して減少していくため、正しいデー
  タを保持し続けるためには、定期的にリフレッシュと呼ばれるプリチャージ(再充電)の
  操作が必要となる。また、データを読み出すときにコンデンサ内の電荷が失われるので
  (破壊読み出しされるので)、1回データを読み出した後にも、やはりプリチャージが必要
  となる。プリチャージ中やリフレッシュ動作中は、データの読み書きは行えない。
  -------------------------------------------------
ここに書いてある通り、読み込みの後には必ず書き戻す作業が必要だから、
DRAMのReadはWriteよりも遅い。
エルピーダの、SDRAMの使い方ユーザーズマニュアル24Pを見れば明らか。
http://www.elpida-memory.com/ja/products/index.html
ReadサイクルはWriteサイクルより遅い。
RAM Diskのベンチマーク
http://www.macdtv.com/Benchmark/RAMDBnch.htm
SRAMとDRAMの消費電力を調べていたら、こんなの見つけた。
http://www.arkweb.co.jp/~hirochen/iTAC/kougi/1st.asp
>SRAMとDRAMの消費電力について 投稿者:専門学校1年生 投稿日:7/14 18:50:41
このあたりから読むといいかもしれない。
じゃ、結論は「どちらともいえない」でいいです。。。
--

ごめん。全然議題と関係ない。。。


35 : :02/03/07 03:04
眠い。残りのスレの要約はまた今度。。。

36 :i桜 :02/03/07 11:17
http://www.page.sannet.ne.jp/nijinsky/Info_Tech/computer/comtext01.html
わりと明確かつ簡潔にメリットとデメリットの言及があった。(リンク先下の方の7と8)

ちょっとネタが古いけど、PentiumIIとPPC750(G3)
http://www.yomiuri.co.jp/bitbybit/bbb12/891101.htm

PPCがPentiumの2倍の処理性能ってのはマカの寝言かジョブヅの"拡張"講演のみだと思っていた自分w
あくまでも当時の性能比だろうし、参考ベンチも無いので何とも言えないけど。
ここでも2倍の処理性能の理由付けにRISCに関する言及がある。


37 : :02/03/07 11:29
オハヨ

マカの寝言だと思われw

RISCびいきな処理「のみ」においては、2倍程度の性能はあると思うが、
どうあれこんな人様に誤解を与える書き方をする人は信用しがたいぞ。


38 : :02/03/07 11:39
と思ったら、そんなに濃い記事じゃないのね。

「たぶん早いと思います。データもそんな感じだし。
 ま、ぼかぁウィナだからWindowsじゃないと使わないけどne!」

って感じなのかなあw

過去ログがあてにならん気がするけど、まだまだ要約しちまいます。


39 :i桜 :02/03/07 11:45
>>36の上のリンク先より
>・ コンパイラの最適化技術が実行速度に影響する。

>>6に上げたRISCコンパイラ最適化の話つながりで、
この辺がフォトショップのフィルタ処理に代表される、
"特定処理で異様に速い"理由かしらね。
何か話がまるでP4のSSE最適化に似てると思ったがw
P4って表向きはCISCだぁよね?

# いろいろ読んでみての雑感だが、
# 'ある程度' CISCとRISCという区別は曖昧になってきているのが現状みたい
# x86系がRISC要素を持っていたり、PPCがAltivec持ってるのがその例?
# ただ基本に立ち返るとやはり違いはあるようですね。


一番身近なRISC型64bitCPU搭載機で息抜きしてきますw

40 : :02/03/07 11:48
>>39
SPAR"K"か?w

# PPCは32bitよ。>>29後半を参照のこと。
# 詳しくはマ狂タンにききませうw

41 :マ狂 :02/03/07 11:50
>>40
うるちゃいw

42 :i桜@ネタ休憩 :02/03/07 11:52
>>40
甘いな。PPCが32bitなのは知ってるw
うちには2台ほどRISC型64bitCPU積んだ 'マシン' があるよw

43 : :02/03/07 11:52
あ、>>39本文には禿同です。
なんつーか、もう、CISCとRISCの区別を語る必要は無いようなw
結局話はコンパイラの最適化に集約されてしまいそうだ。

今後の展開をどうするかは、せっかくなので議長にお任せしますw

44 : :02/03/07 11:54
>>42
「一番身近な」という表現だと、漏れの場合SPARCで遊ぶことになるw
そちらは何で遊んでるなりか?

>>41
反応速度速すぎ!!w


45 : ◆FfmeJobs :02/03/07 11:57
>>36
>参考ベンチも無いので何とも言えないけど
BYTEmarkだと思われ。

>>39
>"特定処理で異様に速い"理由かしらね。
Altivec最適化だと思われ。

46 : :02/03/07 11:59
>>45
じゃ、x86 vs PPCの構図において、
「CISCであること」や「RISCであること」自体に、
アドバンテージがある訳では無く、
最適化によって違いが出ていると考えるべき、ってのが結論なのかな?

47 :i桜 :02/03/07 12:03
>>43
結論はそうだけど、
RISC系CPUのクロック数はCISC系CPUのクロックスピードと単純に比較出来ないと思うのね。
ある程度境界が薄れていても、基本的な部分は違うわけでしょう?
RISC系CPUは何でクロックスピードの進化がCISC系より遅いのか?その理由は?とか、
CISC系CPUのあるクロックスピードに対して、数字だけ見たら遅れを取っていても、
それを補うメリットが存在するんじゃないのか?とか。

P4の2.2GHzとPPCの1.0GHzを単純に数字だけ見てしか判断出来ないレベルから脱したくて
この議題を掲げたのでありますが、御理解いただけるか?

>>44
Nintendo64。w

48 : :02/03/07 12:07
>>47
うー。
心の中で「そりゃ競争社会の政治的な事情でねーの?」
と悪態を付く梨タンがうるさいので、幼児化してきます@大人の事情なんか嫌いだ

N64はまだまだ遊べると思うが、正直、NGCが欲しいw


49 :●~* :02/03/07 12:14
石橋を叩いて、叩いて、落としましたとさ w

50 :i桜 :02/03/07 12:26
>>45
PhotoShopのフィルタ処理が異様に速いのはAltivec最適化によるものなのne...
せっかくだからrc5ベンチへの御意見が聞いてみたいyo!!

>>48
"競争社会の政治的事情"がの形容先がわからんw
UltraSPARC IIIやPPCが未だ1GHz前後な政治的理由って何だ?

51 : :02/03/07 13:11
>>50
「シェアの影響による経済的な理由」と言い換えておこう。

SPARCはパソコンじゃないから、用途的に同列で語れない気がする。
マルチメディア拡張命令なんていらないしなw


52 :save :02/03/07 15:12
>>36-37
昔 appleのベンチに Intelがクレームをつけて
Intelが 自分達で ベンチをやったら
実際に 性能差が2倍あって 恥をかいたと言う記事ならあったな・・・

ちょうど appleが 煽りの入ったCMをやっていた頃だ

ナメクジの・・・

53 :save :02/03/07 15:22
書き忘れ・・・

appleがPhotoshopを ベンチに使うのは
RAMの内部で 完全に動かせるため
HDの性能や システムバスの速度といった
関係のない要素を 排除できるから・・・らしい

54 :●~* :02/03/07 16:26
64bitCPUはすべてRISC設計が採用される。
言い換えれば、256M程度のメモリでいい気になってるウナも
1Gのメモリでは夜も眠れないようなマカと同じになる。

55 :●~* :02/03/07 16:43
宇宙人>>54の通訳求む。

56 :54 :02/03/07 16:50
あと、ペン2あたりでCISC命令をRISC命令に変換して処理してただろ
内部回路はRISCじゃん。CISC対RISCの議論はもはや無意味だよ。
同じRISCでも思想的見解の違うAlplaアーキテクチャー対PowerPCアーキテクチャーの比較なら意味はある。

つうか、もっと精神論や宗教論でやんないと答えはでないだろ。


57 :54 :02/03/07 16:55
>55 なんだよ。
メモリ利用効率を重視したのがCISC高速処理を優先したのがRISCだろ。

58 :●~* :02/03/07 17:21
宇宙人の発言>>54 >>57の意訳求む。

59 :i桜 :02/03/07 17:29
>>52
ゴシップかマジネタか気になる記事だぁne!!w

>>56
ワーイ詳しい人が増えてウレチィ
PentiumIIの内部回路がRISCなのってPentiumProでないかえ?
素朴な疑問なんやけど今のP4(北森)とかって、
PentiumProの流れをいくらか汲んでるの?
ずっとAMDマンセーでいたからPentiumの知識が乏しくて、
この間からざっと調べてみた限りでは、
"現在のPentiumは初代Pentium,PentiumII,PentiumProの流れとは別物"
という雑感なんですが…

イソテルの次世代64bitCPUはx86系命令セットも持ったRISC系CPUらすぃですne...

>>57
>メモリ利用効率を重視したのがCISC高速処理を優先したのがRISCだろ。
非常にワッカリヤスー!!そうだったのネ
今の所1.5GBで快眠出来るけどne...>>54
※作業内容:A2版下作成DTP

60 :i桜@通訳 :02/03/07 17:42
>>58
私も大概デムパなので通訳しても無意味かもしれぬが...w

ようするにCISCとRISCの違いが>>57であってるとすれば、
今は256MBで充分使えているウィナも、64bitCPUの頃には、
1GBでも「ウワーン割当てるメモリが足らないよぅ」と泣いてるマカと同じになる、
と言うてはると思うぞな。

解釈違ってたらゴメンネ...

ちなみに、Winは2000しか触って無い上にメモリ1GB積んでるので、
ささやかな疑問なんだけど、
Winで仮にメモリが256MBだとして、
Macだとメモリ大量に割り当てるアプリ(フォトショとかイラレとか)
立ち上げても快適なのかな??
# イラレはCG板のスレでWin98リソース問題見た記憶あるけどw

61 : ◆FfmeJobs :02/03/07 22:05
>>46
激しく同意。

>>50
Altivec最適化。G3の結果と比較すると分かりやすいと思われ。
x86版はMMX Pentium用のMMX CORE以外SIMDは使われていないはず。

62 : ◆FfmeJobs :02/03/07 22:37
面白そうな記事ハケーン

マイクロプロセッサの25年
http://www.ieice.or.jp/jpn/books/kaishikiji/199910/19991001.html

63 : ◆FfmeJobs :02/03/07 23:05
inside the AS/400 第2章PowerPCテクノロジー
http://www-6.ibm.com/jp/as400/inside400/pdf/inside2.pdf

64 : :02/03/07 23:26
>>62
>>8

>>61
了承。漏れ的には解決。>>59-60の流れは気になるのであげあげ。

65 : ◆FfmeJobs :02/03/07 23:32
ガイシュツだったのか。鬱だ。

66 :●~* :02/03/07 23:39
なぜなに RC5
http://www.segausers.gr.jp/sug/rc5/naze-rc5.html

しかし、RC5ではシェアの影響なし?x86系はなぜ最適化されない?

67 :●~* :02/03/08 08:22
>>59

>PentiumIIの内部回路がRISCなのってPentiumProでないかえ?

こりゃPentium Pro以降全部(含Pentium4)。

Pentium II ≒ Pentium Pro + MMX + キャッシュ低価格化
Pentium III(Katmai) ≒ Pentium II + SSE
Pentium III(Coppermine) ≒ Pentium III(Katmai) + キャッシュ高速化
Pentium III(Tualatin) ≒ Pentium III(Coppermine)

よってPentium IIIまではPentium Proの親戚。

Pentium4は新規設計だけど、思想は似てる。
内部RISC化&アフォみたいな深いパイプラインでもって
クロックを稼ごう、というもの。

>素朴な疑問なんやけど今のP4(北森)とかって、
>PentiumProの流れをいくらか汲んでるの?

以上の理由から、Pentium Proの流れをしっかり汲んでいる。

68 :●~* :02/03/08 12:36
君たちはRISCのことを知らなさ過ぎる。

69 :●~* :02/03/08 12:49
>>68
うんなもんどうでも良い知識だな。
使ってる限りじゃ。

70 :●~* :02/03/08 15:05
>>68
批判はいいから、何か意見を書けようー
後が続かないじゃないかー

71 :54 :02/03/08 15:28
>>68
そうだね。
高性能CAD&大容量HDでCISCに欠点なし。
しかし、メモリ8M数十万円する時代ではないのでCISC設計にメリットなし。になってきた。
近い将来すべてRISC。
確かに、どうでも良い知識だな。
梨からモライモノしてなきゃ梨煽ってモリアガレタノニナ

72 : :02/03/08 15:35
>>71
ん? Cb3タンか?

73 :Cb3 :02/03/08 15:50
>>72
そうだよ。
最近ジャンクの98にはまって来たよ。
この間、ATARIの買取が68Kマクより高かったんで驚いたよ。
もう一台98つれて来ちゃったよ。得したな。

74 : :02/03/08 15:53
>>73
アタリですか。なかなか良い趣味をお持ちですな。
最近、漏れはジャンク遊びは出来ない体質になっちまったんで、
まわりにそっち系の人がいたら嬉しいんだけど、そうはいかなかったりして大変です。

つーか、遠慮せんと煽れw


75 :Cb3 :02/03/08 16:39
自分がゴミに出したアタリや68Kマクは趣味じゃないよ。
98がいいんだよ。*BSD(98)のオンラインテキストモニッポンゴダシ。
OSXのサブマシンにするよ。もう少し新しいジャンク仕入れたら。

ウナ、はやくゴミ捨てろよ。お前らが部屋を整理整頓するの待ってやってんだよ。

76 :●~* :02/03/08 16:43
と蛆虫が申しております。

77 : ◆FfmeJobs :02/03/08 16:43
>>71
>しかし、メモリ8M数十万円する時代ではないのでCISC設計にメリットなし。になってきた。
CISC、RISC、VLIW、それぞれメリット・デメリットがあるから、当分の間CISCは生き残ると思われ。
ってーか、高性能化する為にCISCプロセッサはRISCの概念を取り入れたり、
RISCプロセッサが肥大化する現状があるから、CISCvsRISCなんて議論は意味がないと思う。

>近い将来すべてRISC。
VLIWがはやって、RISC設計に意味なし!って言われるようになるかもね。


78 :save :02/03/08 18:46
>>59
記事の確認が取れない 取れないって事は ゴシップかな・・・スマソ

news サイト潜ってて 見つけた
http://japan.cnet.com/cgi-bin/Board/view/show.cgi/Board/view/?view=tree&arg1=0005¬e=note0094

全然 関係ない バグの話
http://japan.cnet.com/News/1998/Item/980214-8.html

79 : :02/03/09 17:15
>>77
VLIWって、やはりそこまで強い将来性があると見なしていいのかな?
なにげに凄い面白そうだとは思ったんだけど、発展するのかが疑問で。

>>75
*BSD(98)のためにジャンク漁りか。やるなあ。
漏れはスペック的に耐えられん。BSDは美味しいんだけど。

ところで、FreeBSD以外にも(98)ってあるのね。初めて知った。


80 :Cb3 :02/03/09 23:50
真っ先にOSXやXPに食いついて以来
ただでも見栄えのしないOSは使えなくなってきてしまったけど。
一部のマカの間では、
*BSDのなかでもっとも敷居の低いFreeBSD(98)が流行みたいなんで。


81 :i桜@無知の知 :02/03/10 06:57
>>67
わかり易い説明(*゚∀゚)カンーシャ!!

ネットで調べるとどうしてもPenIIとG3の頃のお話止まりデサ...
現状はその差を比較しても意味は無いのでゴザイマスネ
◆FfmeJobsタン Cb3タン デフォ名無しさんアリガート

VLIWてクルーソーだっけ?

82 : :02/03/10 09:22
VLIW
http://yougo.ascii24.com/gh/26/002691.html
http://www.atmarkit.co.jp/fpc/rensai/zunouhoudan004/vliw.html


83 :Cb3 :02/03/10 10:19
>>82
VLIW > スーパースカラーってこと?
PCはXBOXより安くなりマクは高いままってことになるんだね。

84 :i桜 :02/03/10 10:23
>>82
次世代PentiumはVLIW?


ところでちょっと話剃れるけど、
Macが相変わらずATA66なのは梨さん言う所の政治的事情だと認識してるんですが、
それとは関係無しに、ハード板でチョト気になるネタをハケンしたんだけど、
ATA100ってCPU負荷高いの?

85 :マ狂 :02/03/10 10:24
>>84
これ見れです
http://umz.pos.to/TMR/article.cgi?vliw

86 : :02/03/10 10:26
>>84
うそ? 関係なくない?
ATAのデータ転送をCPUが完全に制御してるなら納得もいくけど。
いまだにそんな仕組みだったっけか?

87 :マ狂 :02/03/10 10:27
あ、話題が終わってたw

88 : :02/03/10 10:31
>>87
いや、語り口が楽しかったのでOKですw

89 :  :02/03/13 14:16
 

90 :●~* :02/03/14 03:11
Pentium4の内部構造はRISCに近いものがある。x86の命令をいったん
μ-opsという命令に置き換えて、粒度を細かくしたものを一気に
パイプラインに流し込む。
ちなみにAthlonなんかもほぼ同じ手法だよ。

91 :●~* :02/03/14 03:14
PowerPCは32bit・・というのは半分当たりで半分外れだね。
IBMが出してるPowerPC RS64-IV はれっきとした64bit PowerPCだ。
PowerPCとバイナリ互換のPOWER4プロセッサは最高1.4GHz駆動で
すでに出荷済みだ。

92 :ho :02/03/14 03:18
>>84
次世代Pentiumは、ハイパースレッディング採用だ。

93 :●~* :02/03/14 03:28
Pentium4は今年中に3GHzに到達するそうです。

いくらPen4がクロックあたりの命令実行効率が悪いといっても、
ここまでブン回されたら速くないわけがないよなあ・・。

PowerPCのエミュレーションやったとしてもまあそれなりの速度は出るでしょ。
Cruesoeがあれだけ善戦してるんだから。
PPCによるx86のエミュレーションは、ビッグエンディアンとリトルエンディアンの変換が
ネックになってると聞いたけど。

94 : :02/03/14 03:30
バイエンディアンじゃないのか?>PPC

95 :●~* :02/03/14 20:55
だからPentiumはPro以降すべてRISCだっちゅーの。

そんなことも知らないから「洗脳された信者」とかいわれるんだっつーの。

RISCの最大の利点である構造の簡素化による高クロック化ってのは、
PowerPCが率先してやらなきゃいけないのに、技術がないから単にクロックあたりの効率しか
追求できていないということ。
IntelもAthlonもそんな壁はとっくに越えてるのにな。

最近は理解しているヤツも出てきたようだが、PentiumProのときに悟っていない時点で
敗北は決まったの。

Intel&Microsoftの強みは、常に己を悪役に置くことでユーザーに自由に批判させ、
社内を刺激して慢心させずに、企業努力を怠らないところだな。



96 :Lucifer :02/03/14 21:06
>>95
>RISCの最大の利点である構造の簡素化による高クロック化
RISC の最大の利点は 命令の均質化による Pileline の効率化だよ〜ん.
∴勘違い野郎いってよし!

97 :●~* :02/03/14 21:50
>96

アフォか。
両方だ。

98 :●~* :02/03/15 01:59
Pilelineあげ

99 :●~* :02/03/15 02:47
>>96
いってよし あげ > 逝ってよし

100 :●~* :02/03/15 02:50
>>96
分岐予測の投機実行ハズしたペナルティってのは相当デカいよ。
いくら分岐予測の精度が上がってるとはいえ、20段のパイプラインは。

101 :●~* :02/03/15 03:32
>>95
> Intel&Microsoftの強みは、常に己を悪役に置くことでユーザーに自由に批判させ、
> 社内を刺激して慢心させずに、企業努力を怠らないところだな。

当のIntel&Microsoft知ってか知らずか、そういう効果は大きいと思う。
Appleに最も欠けている点だな。

102 :Lucifer :02/03/15 08:46
>>97-99
ミスしまくり ... ぐふ.

>>97(95)
Wired Logic の利点が叫ばれた時期は,確かにあったさ.
でも,最近の Processor は,おせじにも簡単な構造じゃないよ.
おまえさまは," PPC は RISC でない " と言い張っているのと同じなのさ.
判決 : リノアの性奴の刑←極刑だよ〜ん←赤い玉...ぶるぶる...

>>100
だ〜よね!
20段ということは,20Clock 分のプロセスが無駄になるって事だもの.
はずしまくった場合,2GHz の Precessor の実力は 100MHz 相当.
なーんだ,僕のところの爺さんのほうが速いじゃん.

103 :●~* :02/03/15 10:36
>>102
マンセーもここまでくると哀れだ。

104 :●~* :02/03/15 11:51
>>103
まあまあ、やつらのようなシングルタスクの脳ではああいう程度しか理解不能なんだよね。
ほんとに哀れで涙が出るよ。

105 :nobodyさん :02/03/15 12:16
横槍失礼。

>>102
> はずしまくった場合
内容を吟味せずに、都合のいい仮定を出して満足する事は「比較」とは言わない。
「比較」を望むのなら、「何故Pentium4のパイプラインが分岐予測に失敗するか」を延べよ。

パイプライン処理(基礎)
http://www.nttpub.co.jp/paso/0845.html
http://www4.airnet.ne.jp/munakata/pipeline.html

Pentium4のパイプライン
http://www.atmarkit.co.jp/fpc/rensai/zunouhoudan007/pipline.html
http://tom.g-micro.co.jp/cpu/00q4/001120/p4-09.html

Pentium4とその他のCPUのパイプライン
http://pcweb.mycom.co.jp/news/2001/07/19/14.html
http://japan.cnet.com/News/2000/Item/001121-8.html?il
http://www.watch.impress.co.jp/pc/docs/article/20011102/kaigai01.htm

君の意見を否定する気は無いが、
> はずしまくった場合,2GHz の Precessor の実力は 100MHz 相当.
まるで「パイプラインが1段である事が優れている」ような書き方はどうかと思うぞ。


106 :●~* :02/03/15 12:29
>>102

http://musicfinder.yahoo.co.jp/shop?d=c&cf=10&id=tecw23854
http://www.meti.go.jp/policy/gas/kihonken/part2/2-purezen2-1.html

107 :マ狂 :02/03/15 12:35
じゃあ、単純に考えて(馬鹿なもので……すみません)
PPCのパイプラインを20段にしたら、PPCのクロックはいくらくらいなの?

108 :nobodyさん :02/03/15 12:46
>>107
G4のパイプラインは7段。
Lucifer氏のいいぶんによると、1GHzを7で割って20を掛ければ、
2GHzより多くなるから、G4の方が優秀だ、と言いたいらしい。

その理屈で行くと、パイプラインが無い方が優秀と誤解される恐れがある。
問題は、「何故20段だと遅くなるのか。20段だとどれだけ遅くなるのか」だ。


109 :(*゚∀゚)アヒャ :02/03/15 12:50
>>108
えーと、新板のG5スレの前スレあたりで、
Macヲタさんが同様の事を述べていた記憶があるが...
>(1GHz/7)*20=2.85GHz
違ったカモ...w

110 :マ狂 :02/03/15 12:50
じゃあ作れば良いのにね、パイプライン20段PPC。
計算したら2.8GHzちょいだった。

つまり、パイプラインがどれだけ増えようと(そりゃ限度はあるだろうけど)正確無比に事を進めれたら問題ないわけですよね?

111 :nobodyさん :02/03/15 12:52
パイプラインの存在意義については、
>>105で触れられているので参照されたし。
特に一番上のリンクが短い説明で、比較的易しいものとなっている。

112 :マ狂 :02/03/15 12:52
2857.1428571...MHz
2.7901785714...GHz
でしたw

113 :nobodyさん :02/03/15 12:53
>>110
> つまり、パイプラインがどれだけ増えようと(そりゃ限度はあるだろうけど)
> 正確無比に事を進めれたら問題ないわけですよね?

もしそういう前提があるなら、その通りだ。
問題は、「何故20段だと遅くなるのか。20段だとどれだけ遅くなるのか」だ。


114 :nobodyさん :02/03/15 12:54
>>106 モナー!

115 :nobodyさん :02/03/15 12:54
>>112
CPUクロックは、1kHz=1000Hzだと思うぞ。

116 :マ狂 :02/03/15 12:55
>>115
すいません、いつものクセでw

117 :nobodyさん :02/03/15 12:59
>>106
特に最後のリンクが、パイプラインに対する開発の方向性を
適切に述べているため、これを参照すると理解が深まると思う。


118 :(*゚∀゚)アヒャ :02/03/15 13:00
>問題は、「何故20段だと遅くなるのか。20段だとどれだけ遅くなるのか」だ。
ノースウッドでどうなったかはわからないが、
P4が当初、アプリによっては下位クロックの他のCPUを下回っていた原因がこの辺にある??

馬鹿な質問で恐縮だが、SSE最適化って結局は分岐予測の事ナーノ?

119 :nobodyさん :02/03/15 13:13
>>118
> P4が当初、アプリによっては下位クロックの他のCPUを下回っていた原因がこの辺にある??

「ベンチマーク」の話だね。
大方の見解では、パイプラインが問題視されている。
jobsも述べているし(笑

P4がより単純なビジネス処理等に性能が発揮できない理由も同じ。

> SSE最適化って結局は分岐予測の事ナーノ?

違う物だよ。混同しない方が良いかと。


120 :nobodyさん :02/03/15 13:19
上にも挙げたこのリンクは、CPUの全貌を把握し、
P4の持つ特徴を切り分けて把握するのに役立つだろう。

http://tom.g-micro.co.jp/cpu/00q4/001120/p4-01.html

(当然、これらが相互に作用して演算処理を行っている)


121 :●~* :02/03/15 18:57
ハイパースレッディングの時代にパイプラインストールの議論をしているとは、また敗北を選んでいるようだな。
理解すんのが遅すぎるんだよ。年単位で遅れてやがる。


122 :Lucifer :02/03/15 19:14
>>105
へんな名前...
おまけに自分にさんづけ...ぷぷぷ.

>都合のいい仮定を出して満足する事は「比較」とは言わない。
Lucifer は,悪魔だよん. まともな人といっしょにするんじゃねぇ〜.ぷぷぷ.

>「パイプラインが1段である事が優れている」ような書き方はどうかと思うぞ。
1段のパイプライン...
ばかみたい!ぷぷぷ. そんなもの,何の意味もないんだもの.

でも,リンク先,読むのが大変だったけど,おもしろかったよん.


123 :nobodyさん :02/03/15 20:11
パイプラインストール
>>121
無知を責めてはいけない。
この議論は、有識が前提では無い。

>>122
「名無しさん」の伝統に従っているまでだ。

> 1段のパイプライン...
> ばかみたい!ぷぷぷ. そんなもの,何の意味もないんだもの.

その通りだ。
よって、パイプラインが1段しか働かないという
> はずしまくった場合,2GHz の Precessor の実力は 100MHz 相当.
この発言は無意味だという事をご理解戴けるだろうか。


124 :●~* :02/03/18 22:54



125 :梨華 :02/03/24 20:27
CPUの話が終わってしまったようなので、次の議題。

精神論や宗教論は排除して、技術面で面白い比較キボンヌ

議題その2
HFS+(UFS)とNTFS5を「速度」と「信頼性」という観点で見た時のメリット・デメリット


126 :梨華 :02/03/24 20:35
MacOSXで現在もっとも推進されていると思われるHFS+は、
一体どれだけの信頼性があるんだろうか。
(UFSへの移行が論理的に必要なのかどうかも含めて)

127 :梨華 :02/03/24 20:51
OS9におけるHFS+の文字コードの扱いには問題がある、という話。
http://www.cosmos.ne.jp/~kaz6120/mclb/os_e/06_prblm_04.html

たとえば両方のOSを使っている人間にとって、
重要なデータをどっちのOS側に保存するかって、結構気になると思う。
今のところ、HFS+(や、Mac自体)が怖くて、
すべてWindows側で管理してるんだけど、みんなはどうなんでしょ?


128 :梨華 :02/03/24 21:00
2001.06.22
MacOS X の Apache Web Server にファイルを読みとられるセキュリティ・ホール
影響を受ける OS
 Apache を動作させている MacOS X (MacOS X Server では対策済み)

被害の概要
 HFS+ で Web ページ領域を公開していると,ファイル名の大文字・小文字を区別しない仕様のために,本来読まれるべきでないファイルが読めてしまう( .htaccess, cgi のソース等)。

対策:
 アクセス制限を設定していたり,ソースを読まれたくない cgi プログラムがある場合は Web 共有をオフにする。(デフォルトの設定のままでは Apache は起動しない。)

http://isl.educ.fukushima-u.ac.jp/~shinoda/net-docs/enduser-security-old.shtml


129 :名無しさん@Emacs :02/03/24 21:24
FSはアーキテクチャじゃないような。
>>127
Mac OS XでもFSSpec使ってると問題あるよ。
StuffIt系とか。
で、Unicodeなんか使うなという主張ですか。
だからって、ファイル名にISO 2022使うのもアレだし。
>>128
対策済みだし、NTFSも一緒だと思うけど。

ところで、NTFSをよく知らないんだけど、どっかにいい解説ない?

130 :梨華 :02/03/24 21:34
ファイルシステムアーキテクチャはアーキテクチャだと思うような。

>>129
Unicodeを使うなというんじゃなくて、混在を許すならまともに対応しろと。
さもなくば最初から全部Unicodeに変換して、それだけをサポートすればいいような。

リソースキットには間違いなく解説あると思うけど、探してみる。


131 :梨華 :02/03/24 21:36
こんなんじゃ嫌?
http://www.zdnet.co.jp/help/howto/win/win2000/0007special/review_professional/ntfs/01.html


132 :名無しさん@Emacs :02/03/25 00:19
>>130
すでに混在しちゃってたらどうしようもないでしょ。
全部正確にUnicodeに変換なんてのも無理な話。
オレはTMとか(R)とかを手で修正したよ。
もっといい方法があるんなら教えて。

つーか、異なるシステムの異なるファイルシステムの比較に
どれほど意味があるのか激しく疑問。
現状ではMac OSとMac OS XにはHFS+が最適なんだし、
いくらNTFSが優れてても採用されることはないでしょ。

133 :梨華 :02/03/25 03:59
>>132
>>127
CISCとRISCを比べたからといって、G4がP4になる訳では無いでしょ?

それはそれとして、UFSが論理的には最高なのに移行が出来てないとしたら嫌だね。


134 : :02/03/25 04:11
折れはUFSでフォーマットしてるよ。
遊び用だから出来るのかもしれないけれど。
ばっさり切り捨てちゃえばいいのに、と思うのは折れだけか。

135 :名無しさん@Emacs :02/03/25 10:41
>>133
CISCとRISCを比べるのに、G4とP4は適切じゃないような。
逆もまた然り。

Mac OS XでUFSとHFS+どっちがいいか比較するとかなら目的はわかるけど、
HFS+とNTFSじゃ何がしたいのかサパーリわからん。
Mac OSとNT系Windowsじゃ堅牢性が違うんだから、設計思想も違うだろうし。

とりあえずMac OS XでのUFSは
・遅い。
・一部アプリケーションが動かない。
・大文字・小文字の区別ができる。
・Mac OS側から見えない。

それにしても何で最高とかそういう単語が簡単に出てくるかねぇ。

136 :●~* :02/03/25 11:52
HFSの上位規格キボンヌ

137 :●~* :02/03/25 12:40
>>136
>HFSの上位規格キボンヌ
HPFSはいかが?

さげ。

138 :梨華 :02/03/25 12:44
>>134
禿同。下手に互換させるから大胆な変更が出来ないってのは、
いまだにCドライブを残すWindowsに対するMacユーザの言う皮肉では無かったか。

試しにUFS領域も作ってみようかな。さよならVine(涙

>>135
>>127を読んでね。何がしたいかアサーリよくわかるから。

> CISCとRISCを比べるのに、G4とP4は適切じゃないような。

ここはそういうスレだし、これからもそういうスレだと思うぞ。。。

「Windowsは関係無いじゃん」というのも一つの使い道だとは思うが、
Windowsと比較検討したい人もいる。
ユーザとして最適解(=「最高」)を求めるからG4とP4を比べたりしたの。

とりあえず、UFSは互換性の問題でまともに評価されるに至ってないのね。
「遅い」のが信頼性とのトレードオフの結果生じたなら、将来的に評価する価値はある。
OSXへの移行や対応が遅れているのが、残念でならないね。

>>136
MFS(Macintosh File System)ってのがあるという噂を聞いたけど、本当?


139 :梨華 :02/03/25 12:45
>>137
ワラタ。
あんなOS使ってる人って、どんな人なんだろう。


140 :マ狂 :02/03/25 12:47
>>136じゃないけど、MFSは初期のMacのフォーマットです。
階層構造ではないので、保存ダイアログなどでみると、
ファイルごちゃ混ぜになってますw

141 :マ狂@追伸 :02/03/25 12:48
ちなみに、MFSは8bitです。

142 :梨華 :02/03/25 12:52
下位規格だったのね。。。

143 :名無しさん@Emacs :02/03/25 18:50
>>138
Pentium4とG4を比べるのは別に構わないけど、
何でそこでRISCとCISCが出てくるのかってこと。

>>127を前提に話進めるなら、
ジャーナリングファイルシステムらしいNTFSでいいんじゃない?
でも、お互いファイル名に制限があったりするから、
MacのファイルはHFS+に、WindowsのファイルはNTFSにってのが
一番無難な方法だと思う。
つーか、重要なデータならファイルシステムがどうこう言ってないで、
使わないときはアンマウントした状態で置いとくべきじゃないかい。

UFS(つーかFFS)が遅いのはDarwinの実装の問題で
他の*BSDではそんなに遅くないらしい。
ちょっと古いけど簡単なテストの結果。
http://www.tech-arts.co.jp/macosx/macosx-jp/htdocs/7100/7136.html

144 :  :02/03/31 03:30
めんて

145 :●~* :02/05/07 00:58
age

146 :i桜 :02/05/10 10:27
亀レスだが禿しく気になったからレスしておこう…

>>143
梨が誤解を招きそうな発言をしているが、
別にG4とP4でRISC,CISC比の話しになったのではナイーヨ

単純にx86とPPC比較から始まっただけれす。
RISC・CISC比で見れるデータって、P2とG3が限界くさかった。正味。
結論言うならG4、P4で見た時、両者をRISC・CISCで比較するのには意味ねーよ、だったな。確か。

以上遅すぎる亀レスw

147 : :02/05/10 10:44
キャッシュのはなしすれ。CPU(内部・外部)、OS、HDD、フォント、ネット。
3次キャッシュってほんとに意味あんのか?


148 :i桜 :02/05/10 10:58
>>147
イイね。

L1、L2、L3ってさ、
結局のところ、DRAMのレイテンシー軽減が主な役割だっけ?
CPUのキャッシュメモリってシステム高速化が主な存在意義だと思ってたが…
どうも勉強が足りないくさい。
3次キャッシュが必要なMacのメモリ回りの構造って問題なんでせうか…?
無知故の疑問は尽きない…

149 : :02/05/10 11:07
いや、俺もよく知らない。
ただ、キャッシュをフローさせたらキャッシュはじゃまでしかない。
最近はデータがでかいし、CPUも多段パイプライン化して連続データを
前提にしているフシあり。多段キャッシュって意味あるのかと。

150 :●~* :02/05/10 12:51
そもそも、メインメモリが速ければ三次キャッシュなんていらないんでない?
あ、バス幅はどうなんだろね。
よくわからん。

151 :梨華 :02/05/10 13:15
ねぇ、三次キャッシュってすげーの?
http://pc.2ch.net/test/read.cgi/mac/1020217553/

ネタスレだけど、マジレス禁止って所が新板っぽいよね。


152 :Lucifer :02/05/10 19:17
ぼくも,まぜてくで〜.
(ただし,僕の発言はマユツバです. くれぐれも検証をお忘れなく ...)

HDD の Cache(Buffer) って,もしかして S-RAM ?
だとすると, SD-RAM より, HDD の方が速いってことも起こりうる.
事実, Virtual Memory On の方が速くなることもあるのだとか ...

>>148
>システム高速化が主な存在意義だと
と,いうより, ' 低速化 ' 防止の役に立っているといったほうが正しいっす.
(積極的な ' 高速化 ' の力はなく, 時として, ただの二度手間.)

3次キャッシュが必要なMacのメモリ回りの構造って問題なんでせうか…?
D-RAM を使っている以上,避けられない問題です.
S-RAM ならば,改善されますが, Capacity & Cost の問題が ...

>>150
>メインメモリが速ければ
Precessor : " 早くデータよこさんかーい,ごるぁ〜. "
Memory : " 準備中,準備中,準備中, ... ほれ ! "
Precessor : " てめぇーのせいで, 操業停止だっぁ〜, すかたん ! "

これが実際のところでーす.


153 :●~* :02/05/10 20:26
インターフェイスの速度を無視するなよ〜

154 : :02/05/10 20:36
ボルトネック?

155 :梨華 :02/05/10 21:33
>>152
はいよ。SDRAMだとさ。むしろキャッシュ専用として、
プロセッサに近い位置に組み込まれる事に意義があるのでは?
>>148
問題があるとかじゃなくて、あったら速くて便利ってだけでねーの?
漏れももうちっと調べてみるわ。


156 : :02/05/10 21:37
>>155
>3次キャッシュは2Mバイトもあるので,起動しているアプリケーションコードやデータの大部分を格納できる。
だっからさ、これマジすか?今どき2Mでたりるのかと。

157 :梨華 :02/05/10 21:43
CPU話は弱いんで、ハード強い人きぼんぬ。

>>156
所詮キャッシュだから、レイテンシが起きない程度に領域確保してたら
十分なんでねーの?

158 : :02/05/10 21:48
>>157
2MじゃMP3ファイルの一個も入らないジャン。
フローしたらWiredキャッシュでも
結局効率落ちるんじゃねーかと思うのだが。
そう言うもんでもないのかなぁ。

159 :梨華 :02/05/10 21:51
>>158
だから、一度に全部入れねーんでねーの?
MP3だって、一瞬で聞くわけではあるまい?

160 :(*゚∀゚)アヒャ :02/05/10 21:58
L1、L2、L3は基本的にパイプラインと思想が似ている罠
ようするにキャッシュするのは、「頻繁に使われる命令」らすぃ
主要命令をキャッシュしてプールすることで高速化を計る
# るしふぁの言を借りれば「低速化を防ぐ」

だから2Mとかで足りるんじゃないかな?

161 : :02/05/10 21:58
>>159
でもさ、MP3みたいなストリームつかシーケンシャルデータだとさ
分割してもキャッシュきかなさそうじゃん。
逆に2Mに納まってキャッシュききそうなデータって何かなとね。
CPUが、小さいプログラムと大きいプログラムとデータ見分けて
キャッシュ制御したりすんだろうか?謎だ。


162 :●~* :02/05/10 22:02
Macオタ呼んでこい!
話はそれからだ!!!

163 : :02/05/10 22:10
ワロタ

164 :梨華 :02/05/11 00:00
>>161
MP3のくだりは、なんか勘違いしてる気がするが。。。

実行ファイルをまるごと載せる訳では無いでしょ?
「命令」に対するキャッシュなんだと思われ。

165 : :02/05/11 00:07
>>164
だから、よーわからん。
「命令」と「データ」をファイルの中からどう見分けるんだろ?
最近のパソコンは非ノイマン型コンピュータ?

166 :梨華 :02/05/11 00:22
>>165
ちょっと確認。君の言う「命令」と「データ」って何?

167 : :02/05/11 00:41
>>166
どっちも実行ファイル上に並んだ数字の羅列

168 :マ狂 :02/05/11 18:40
キャッシュは、使わないコードの破棄を繰り返して、
体感的に早く見せるんだと思う。
ようはコードのつまみ食いだね。一気食いはしないw

ん?論点が変わってきてるな……
>>167
アプリケーションからの"命令"で、
データが"処理"されるから

169 :●~* :02/05/11 18:41
うんこはくさい

170 :名無しチェケラッチョ♪ :02/05/11 18:43
>>168
続きを是非ともキボン

171 :マ狂 :02/05/11 18:45
>>167
アプリケーションにある"実行コード"で、
データが"処理"されるから
間違える事はないと思う

172 :名無しチェケラッチョ♪ :02/05/11 18:47
>>171

リクに応えてくれて有難う

173 :MACオタ>マ狂 さん :02/05/11 19:54
>>171
そんなに話が簡単ならシステムエラーわ起きないす。

174 :マ狂 :02/05/11 20:00
>>173
それはバグのせいでは?

175 : :02/05/11 21:48
>>171

んではアプリケーションにある"データ"は?オペランドね。

一連の話は簡単にいうと3次(外部)キャッシュにプリフェッチはキクか?
効いたとして有効なのか?てな話だと思う。漏れは疑問視するスタンス。


176 :犬球@▼´ェ`▼ :02/05/11 23:02
プリフェッチってコードつまみぐいのソムリエみたいなもんかな‥‥。
だとすれば2MBのL3キャッシュでもかなーり有効な気が。

でも実際効いてるんかと言われればヤパーリ疑問視。

http://www.atmarkit.co.jp/fwin2k/special/winxp_over/winxp_over_19.html

177 : :02/05/12 15:15
犬球さんて、ふぇっちのアイコンに似てるね。。

178 : :02/05/12 17:05
フロッピーくわえてるやつだっけ?ふぇっちのアイコン

179 :●~* :02/05/12 17:35
http://fetchsoftworks.com/

180 :犬球@▼´ェ`▼ :02/05/12 21:09
じゃあTransmit使うのやめてふぇっちにしよかな。
まだお金払ってなかったし。

181 : :02/05/12 23:03
コレクションにふぇっちのフリーのバージョン見つけたよ。

182 :犬球@▼´ェ`▼ :02/05/13 03:05
あれっ、昔の英語バージョンはフリーだったんだっけ。
Xなのでまずはカーボソ版を使ってみるよ。

183 : :02/05/13 12:13
>>168
>キャッシュは、使わないコードの破棄を繰り返して、体感的に早く見せる
>んだと思う。ようはコードのつまみ食いだね。一気食いはしないw

コード実行の際のCPUのパイプラインはそのためにあるんじゃないかと。

パイプラインはコードの最適化プリコンパイルみたいなものをCPUが自分で
Wiredに行う機構だ〜ね。いわばCPUは自分で「使わないコード」を知っている、
というか、そう結線されてる。

だが高速メモリそのものであるCPUキャッシュは、どれが「使わないコード」
であるかわからない。区別するにはCPUの判断が必要になる。CPUは一旦
キャッシュに読まれたコード、データを、それはとっておいてとか、それは
捨ててとか指示する(キャッシュ制御)。あるいはそれだけは優先的に上位の
キャッシュに送って、と指示するのかもしれないがよくわからない(ぷりふぇっち)。
どっちにしろキャッシュには最低限一回はコード、データがロードされる必要が
ある。キャッシュだけで器用なつまみ食いはできない。また、ぷりふぇっち
するならCPUによる下位キャッシュまでの監視制御機構が不可欠になる。
(つづく)


184 : :02/05/13 12:15
(つづき)

読み込まれるコード、データがキャッシュの容量を超えたらどうなるか?
「使わないコードの破棄を繰り返し」、そして再読み込みが激しく発生する。
キャッシュは当然効かなくなり、2度手間、3度手間が多発する。
効率は落ちることはあってもあがることはない。

で、だ。現在OSだけで常時「生きている」コードが数十MBに達する。
アプリケーション、スクリーン上のフォントの展開だけでもおそらく
数MBにはなるだろう。(もっともこれはOSXではQuatrz、特に次の
Quatrz ExtremeではCPUではなくビデオカードにやらせてるかもしれないが。)

というわけで、
>>155-156
>3次キャッシュは2Mバイトもあるので,起動しているアプリケーションコードや
>データの大部分を格納できる。
だっからさ、これマジすか?今どき2Mでたりるのかと。
>>149ほんとに3次キャッシュって意味あるのか?ということになる。

まぁ、高速バスにはそれなりの意味はあるだろうし、
サイズがキャッシュに納まるフォトショベンチやπベンチには、
かな〜り有効かもしれない。得意なベンチマーク対策かなぁなどと邪推したり(w



185 :梨華 :02/05/13 17:00
>>184
その理屈でいくと、いまどきの3次キャッシュは256MB必要だって事か?w

「生きている」の再定義をよろしく頼む。
漏れはMP3の曲で言うなら、ファイル全体では無くて、
今再生している部分こそが「生きている」データだと思ってたし、

厳密にはメインメモリのデータを読み込んで処理する、
プレイヤーの再生部分の命令だけがキャッシュされるのがL3だと思ってたんだけど。


186 :マ狂 :02/05/13 18:56
初期のG3(750)ってプロセッサ自体の評価は
604e(Mach)より同等かそれ以下なんです。
で、604e(Mach)より遥かに高い能力を発揮できたのは、
バックサイドキャッシュのおかげだったそうです。

2次キャッシュがオンダイになってから今の3次キャッシュの効果って、
バックサイドキャッシュの補助効果に近いのではないでしょうか?

187 :Lucifer :02/05/13 20:36
>>155
Response 遅すぎで申し訳ありません.

それで,リンク先を見てみたところ,僕の発言とはかけ離れている感じ.
僕が言っているのは, HDD の一部として組み込まれている ' Buffer ' のこと.

もし,仮に DRAM だとすると,
System での DiskCache との二度手間になって,
かえって,パフォーマンス低下の原因になると思うのです.
だいいち, 512kB とか 2MB 程度のものなら,
SRAM でも,さほどコストが問題にならないでしょ.
(もっとも,これは希望的推測に過ぎず,なんの根拠もありません.)

188 :イヒ :02/05/13 20:40
>>187
Writeキャッシュという考えはないのかのぉ? >HDD
たいていはそのはずだが。

189 :●~* :02/05/13 20:40
>>187
Luciferタン、その文体(・∀・)イイ!
幼児言葉風文体の時よりも好感度激しくUP!

190 :イヒ :02/05/13 20:54
>>184
そのキャッシングじゃバッファでしかないぞ。
キャッシングの最大の目的は遅い要素へのアクセスを最小限にすることなのだから
高精度な予測との組み合わせで効果が出る。

MP3の場合はファイルの方はそのデバイス以上の速度では読めないのだから
キャッシュの意味はない。意味があるのは実行コードの方だ。

191 :Lucifer :02/05/13 20:58
>>164-165
Harbard Architecture って,ご存じ?
(スペル間違っているかもしれません. 辞書でヒットしなかったので.)

>>188
くわしくは,知りません.

>>189
いつ,退行化するか,自分でも予想がつきません.

192 :イヒ :02/05/13 22:21
>>188
書き込み時にシークの間に待たされたくはなかろう。

193 :イヒ :02/05/13 22:27
しもた(汗
s/188/191/

>>191
ついでだ。
カナのほうが素直に見つかる。 >Harvard architecture

194 :Lucifer :02/05/13 22:49
>>183-184
長い文章 ...
テーマとしてはおもしろいし,
3 次 Cache については,疑問が残るのは確かです.
(On-Die で,十分な Capacicy を確保できるほうが良いに決まってます)
でも,反論は簡単.

>>186 が言うように, 604 と 750 を比べると,
' Core ' としては,604 の方が高性能でした.
それにもかかわらず, 明らかに 750 の方が,速かったでしょ ?
その原因となったのが, たった(?) 562kB の BackSide Cache .
この事実をどう説明しますか?

195 :●~* :02/05/14 09:44
×562kbB
○512KB

アルファベットの大小にも意味があるので注意。

196 :●~* :02/05/14 10:28
http://www-6.ibm.com/jp/servers/aix/developer/feature/power10/c02.html

197 :●~* :02/05/14 11:10
ストリーミング(MP3)や巨大データ等のcacheが有効に働きそうにない条件だけ考慮して、
「大容量L3Cacheは無意味だ!」と言うのは意味がないと思われ。

198 : :02/05/14 11:42
いや、自分の理解も定かじゃないからさ、半分は憶測なのだよ。
せっかくsageで書いてたのに(w。んでは、順番に
>>185
>「生きている」の再定義をよろしく頼む。
メインメモリ(あるいはヴァーチャルメモリ)に展開されたコードすべてとしよう。
コードは、OSであれば、キーボードをスキャンしデバイスを監視し、ネットワークと
コネクションし、その他もろもろのOSのサービスを提供しているすべてのコードだ。
マルチタスクでアプリケーションを起動しているのであれば、当然オンメモリのそれら
のコードも含む。全部でメモリ上にどのくらいのコードがあるか?Mp3プレーヤと
メッセとワープロなり画像処理ソフトなりを同時起動すれば、それがいかに膨大で
あるかは想像しやすい。

>厳密にはメインメモリのデータを読み込んで処理する、
>プレイヤーの再生部分の命令だけがキャッシュされるのがL3だと思ってたんだけど。
君のMacにはメインメモリに接続されたMP3再生デバイスでも搭載されているのかな?
(例えばAGP経由で描画命令を専門に実行するビデオカードのような。漏れのMacには
ついないようだ。)MP3が再生されるためにはMP2layer3データがCPUのレジスタに
送られてデコードされる必要があり、その際に(結局データがキャッシュされず破棄される
にしても)、一旦「キャッシュを通過し容量を消費する」と思うのだが。
ファイル丸ごといくのか、ある程度のサイズで分割されデータブロックが連続処理
されるかは知らないが、大きな違いはないと思う。もし、気になるのであれば
MP3データのようなデータブロックは無視してもかまわない。確かにキャッシュを
通さずスルーしている可能性もある。しかし、ならばそのときCPUは遅いメインメモリを
待って足踏みしているか、そのデータブロックを利用すべきコードを破棄して
データが届くまで、別のコードを発行しているはずだ。


199 : :02/05/14 11:42
>>190
>高精度な予測との組み合わせで効果が出る。
だからどうやって高精度に予測するのかと聞いているのだが?
キャッシュは高速メモリでしかない、キャッシュが独自で予測などできんよ。

>>186,194
半分同意。

>' Core ' としては,604 の方が高性能でした.
>それにもかかわらず, 明らかに 750 の方が,速かったでしょ ?
>その原因となったのが, たった(?) 562kB の BackSide Cache .
これのソースキボン。おそらく解はここにある。

200 :●~* :02/05/14 11:49
>>199
>だからどうやって高精度に予測するのかと聞いているのだが?

そんなコアなことはメーカー的には教えてあげないよプンプンだとおもわれ

201 :イヒ :02/05/14 12:41
>>200
実装はともかく理論そのものは山程宣伝されとるようだが(w

>>199
まず、過去の参照頻度が得られますな。
次いでマシンコードの体系と分岐からくる参照範囲というのは当然割り出せる。

キャッシュが高速メモリに過ぎなければ御説通りに一杯になった時点で効果が落ちてしまうよ。
ましてや1次2次3次などと多層化する意味はなく単に1次を大容量化したほうが
良くなってしまう。でもそのように作っていないよな?

ソフトウェアの経験則である「頻度の高いコードは全体のごく僅か」というのがあって
そこを改善すると全体の効率が上がるのだな。
CPUから見れば今処理しているコードが何に関係するか知る由もないが、使用頻度と
マシンコードの依存関係はわかる。よってそれに基づいてコード処理の時間の最適化を
はかる手法のひとつがキャッシュなんであって、大容量化はそのキャッシュ管理手法による
オーバーヘッドとのバランスの問題になってくる。

キャッシュを大容量化しても効率が上がりにくくなる限界というはあるから、その見込みを
もとに容量を決めているだけのことよ。

202 : :02/05/14 18:11
>>201
うむ、おおむね同意だよ。

>キャッシュが高速メモリに過ぎなければ御説通りに一杯になった時点で効果が落ちてしまうよ。
>ましてや1次2次3次などと多層化する意味はなく単に1次を大容量化したほうが
>良くなってしまう。でもそのように作っていないよな?

で、ここだな。例えばPen4のオンダイキャッシュはプリフェッチ機構が
実装されている。はたしてG4の3次キャッシュは?というところだと思う。

漏れがこれほどまでに3次キャッシュの有効性に疑問をもつのには実は理由があって
アポには前科があるのだ。MacがPowerPC(603)化された頃の話、一部の機種には
256KBのL2キャッシュなるオプションパーツが用意されており、アポによれば
それを取り付ければ10〜30%の速度向上が見込めるといううたい文句であった。
たしか\20000弱はしたと思う。阿呆な漏れは購入したさ。が、効果はほとんど
なかった。ハードディスクを交換した方がよほど効果があった。

「3次キャッシュ搭載」、これは実効より非搭載機種との差別化、新機種の価格帯の
維持など、販売上の心理的影響のほうがでかいのではないか?なにしろ、消費者には
「3次キャッシュなるよくわからないがスゴイものが搭載されているので、速いに違いない」
という思い込みが存在する。現に、販売促進的意味をもつ前出の下記の記事には
>3次キャッシュは2Mバイトもあるので,起動しているアプリケーションコードやデータの大部分を格納できる。
なんて記述もみられたりするわけだ。とにかくよくわからんがスゲースゲーのである。

203 :マ狂 :02/05/14 19:06
>>202
そのL2キャッシュってフロントサイドに接続されてるから、効果が薄かったんだよ。
つまり
    メインメモリ
     |
CPU−フロントサイド−その他の装置
     |
     L2キャッシュ

じゃデータの転送速度が最高50MHzだったり、他の装置と競合したりして、実力が出せなかった。そして現在は

              メインメモリ
               |
L2キャッシュ−バックサイド−CPU−フロントサイド−その他の装置

と言う形になり、他と競合せず高速な(CPUの半分の速度)バスを使うようになり、実力を発揮できるようになったんですよ。
アーキテクチャ的にはこういう感じ。

204 :マ狂 :02/05/14 20:08
なんちゃって(藁

205 :マ狂 :02/05/14 20:20
>>204
ダマーリやめんしゃいw

206 :マ狂 :02/05/14 21:26
>>205
うるちゃいw

207 :マ住 :02/05/14 21:31
訂正。

古いの

CPU
 |
L2キャッシュ
 |
FSB-その他の装置
 |
メモリ

新しいの

CPU-L2キャッシュ
 |
FSB-その他の装置
 |
メモリ

訂正おながいします。

208 :マ狂 :02/05/14 22:08
>>206
ゴホンゴホン、チキショー!

209 : :02/05/14 22:21
>>203
まぁよくは知らんよ。まぁ、前半分は当時のMacはCPUがVRAM描画までしていたから
しょうがないとも言えるし。だがキャッシュが飽和したら接続がどうでも結局キャッシュは無意味だよね。
将来「そのL3キャッシュって、効果が薄かったんだよ。得意になっている人は多かったけど」
って言われなきゃいいなぁと思うのさ。

アポ曰く

●PowerPC マイクロプロセッサ(※L2 キャッシュ の解説)
>L2 キャッシュを追加すると性能が向上する理由は、PowerPC マイクロプロセッサがその
>パイプライン処理をフルに活用できるためで、これによってより速く効率的な処理が
>可能になります。マイクロプロセッサは、まず内部キャッシュに命令があるかどうかを調べ、
>次に L2 キャッシュ、そして最後にメインメモリ(DRAM)を調べます。キャッシュメモリは
>DRAM より高速であるために高速なアクセスが可能となり、このためパイプライン処理が
>フルに活用されます。 これはまた、性能の向上が決まっていないことの説明にもなります。
>頻繁に利用されるコードはプロセッサの近くにとどまり、より高速に実行されます。ほかの
>コードではできません。一般に、L2 キャッシュを利用するコードでは、10 〜 15 % の性能の
>向上が期待できます。

だそうで、当時漏れを含めてこれを信じてマンセーしとる人もいたのさ。そして今、

●高いパフォーマンスを生む新アーキテクチャ(※L3 キャッシュ の解説)
>新しいPowerBook G4の内側にあるVelocity Engine搭載のPower PC G4プロセッサは最速の
>667MHzまたは800MHzで動作。そして、新たに1MBのDDR SRAM三次キャッシュも追加され
>ました。三次キャッシュはきわめて短時間で動作する高速メモリで、プロセッサがデータや
>命令にすばやくアクセスするのを助けて、システムの処理性能を向上させます。このアーキ
>テクチャによるパフォーマンスの向上は、言葉で語り尽くせないほど。

だそうで、今も昔も言うことは大差ない。そしてやっぱり懲りずにマンセーしとる人がいる。
アポが言う通り、どうやら語り尽くせないらしい(w。

210 :マ狂 :02/05/14 22:27
ぶっちゃけて、10%じゃ体感できないっす。
CPUのクロックアップの経験しかないけど。
20%なら体感できるっす

211 :イヒ :02/05/15 00:41
まぁ、モトローラの方を信ずるなら、今の3次キャッシュの役割はハード的な互換性と、メインメモリとCPUの動作クロックの
ギャップを埋める役割といっていいんだろうな。
あった方がいいが、その効果は「やたらにメモリを読み書きするアプリケーション」でないとあらわれにくいだろうと
予想されるな。

212 :●~* :02/05/15 03:47
アーキテクチャ全然わからんけど、HDDの読み書きとか3Dゲームでも
BackSide L2の効果は絶大だった。今のL3もそれと似たようなものと
考えていいのだろうか。

# 256KBとか512KBとか1024KBとか変えて試した。上記の局面では
512KBじゃ足りなくて1MBあれば大体十分、という結果だった。2MB
積んでも大差ないだろうな、という感触。あくまで感触だけど。

213 : :02/05/15 09:54
>>212
それはキャッシュの効果より>>203のいう接続形式の変更が大きいかも。
BackSide用の(キャッシュではなく)バスがあれば、HDDーメモリの転送や
メモリービデオの転送の際に、他のタスクでCPUーメモリアクセスのためにシステムバスが
干渉を受ける必要がなくなるから。3DゲームはAGP(のビデオカード)の
搭載のほうがかなり効いているかと。
BackSide L2が1Mで十分ならL3は必要なのだろうか?

今思ったのだがデュアルCPUマルチタスクならひょっとして効果が
あるのかもしれないねぇ。それぞれのCPUが少量でも専用のメモリを持っている
ようなものだから。




214 :マ狂 :02/05/16 18:45
Macのキャッシュアーキテクチャの歴史

スタンダードアーキテクチャ(68kMac〜NuBusPPCまで?)
    メインメモリ
     |
CPU−フロントサイド−その他の装置(NuBusなど)
     |
  プロセッサーダイレクトスロット(キャッシュスロットとしても利用可能)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


L2キャッシュアーキテクチャ(Performa5400(?)〜PowerMac9600/233まで)
    メインメモリ
     |
CPU−フロントサイド−その他の装置()
     |
    L2キャッシュ
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


インラインキャッシュアーキテクチャ(ラディウス社製(?)キャッシュダブラー〜PowerMac9600/350(Kansas)まで)
             メインメモリ
              |
CPU−インライン−L2キャッシュ−フロントサイド−その他の装置
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


バックサイドキャッシュアーキテクチャ(PowerMacG3〜PowerMacG4/500Dual(?)まで)
              メインメモリ
               |
L2キャッシュ−バックサイド−CPU−フロントサイド−その他の装置
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−


オンダイキャッシュアーキテクチャ(PowerMacG4/466〜)
                       メインメモリ
                        |
L3キャッシュ−バックサイド−CPU(L2キャッシュ内蔵)−フロントサイド−その他の装置
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

多分あってると思う。

215 :マ狂 :02/05/16 18:53
ああ、押し間違えた……

216 : :02/05/16 21:51
>ラディウス社製(?)キャッシュダブラー

だからさ、こういうのがパチっぽいつーかいかがわしいつーか、
全般的に神秘がただようMacアーキテクチャの世界なり。

※アイコンパレードでお祈りをかかしてはいけない。あなたの祈りが
 天に届いた時Macのキャッシュは未曾有の性能を発揮するのだ。
 さぁ、祈りなさい。



217 :マ狂 :02/05/16 23:45
祈ろう……

アーメン

218 :  :02/06/11 03:22
あげ

219 :●~* :02/06/11 13:37
このスレ、密かに旧板で一番好きだ。

72KB
新着レスの表示

スレッドリストへ戻る 全部 前100 次100 最新50

0ch BBS 2004-10-30