Sun Microsystem 最大の遊撃

**名無しさん＠お腹いっぱい。** · 2005/12/08(木) 17:43:05

今更「オープンソース」とか言い出したり、
　…でも「OpenSolaris-Closed-Bins」って一体…（´Д`;）

今更「Ultra20」とか言い出したり、
　…でも「"Ultra"SPARCではなくOpteron」って一体…（´Д`;）

Fujitsu製造のSPARC64V,
AMD製造のOpteron,
TI製造のNiagara(UltraSPARC T1)などと矢継ぎ早にCPUを模索しているが、
これは縦読みで、製品群が"FAT"になる暗示か？w

【前スレ】
Sun Microsystems 最後から二番目の真実
http://pc8.2ch.net/test/read.cgi/unix/1127872934/

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 15:46:56

SunはもうSPARC積んだWS出す気はあまりないだろ。
niagaraですけど、ちまちましたことを平行していっぺんに
俺としてはそれもありかなぁとは思う。
どーせ、SPARC積んだWSなんて、単体運用より端末として使われる方が多いだろうし。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 15:52:00

>niagaraですけど、ちまちましたことを平行していっぺんに、って、
>デスクトップにも良いんではないかと思うのですが

どのへんが？全然良くないと思うケド

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 16:02:39

Niagalaはどうみても Webサーバとか Oracleみたいなスレッドを
たくさん作って、がーっとやるジョブ向けのCPUじゃん

メールとワードを同時に動かすとか、そういうの向けじゃないよ

68 · 2005/12/17(土) 16:04:00

日本人だから L と R　を間違えるのは仕方ない

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 16:34:19

>>65
個人のワークステーションで、ロードアベレージが32に達する
状況なんてないでしょ。つまり Niagara の性能はワークステー
ションでは全然生きないってこと。
今のところ、ワークステーションではシングルスレッド性能が
大事だから、Opteron の方がいいよ。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 17:30:08

うーん、メールとワードじゃ、いっしょだと思うが。FPU 付きの Niagara2 になったら
マルチメディアで並列も期待できるし、値段いっしょだったら Niagara2 取るけど。オレは。
そもそも今 PowerPC G4 1.25GHz だけど、もっと速いの欲しいとかあんま思わんし。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 17:44:40

> そもそも今 PowerPC G4 1.25GHz だけど

G4 はスーパスカラでしょ。
Niagara はシングルイシューだから、シングルスレッドだと、
G4 1.25GHz よりも、さらに遅いよ。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 17:57:44

うーーーーん、だとしても、メールとワードじゃいっしょでしょ。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 19:02:56

>>65
その分野のWSではCellがあるからね
PS3が成功すれば少なくともPS3用ゲームの開発マシンとしてそれなりの台数は出るだろうし

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 19:09:38

WSはOpteron搭載でx86-64版 Solarisでいいんじゃないか

65 · 2005/12/17(土) 20:21:34

うーむ、目の前のデスクトップ見て、たいていのものはウィンドウ毎にプロセスが走ってて、
個々のウィンドウの中でもwebブラウザとかはいろんなこといっぺんにやってるよなぁ、
などとふと思ったのでしたが、
68 >>メールとワードを同時に動かすとか、そういうの向けじゃないよ
あ、そういうの向けじゃないんですか。
なんかで、(x86ので)hyperthreadingのに変えただけで、裏で重いことやっててもかくかくしなくなったみたいな
話を見た記憶でテキトーなこと書いてました。すんません。

>>74
CellのWS...欲しいです。SolarisでもLinuxでも良いです。出たらいいなぁ。

>>75
w1100使ってるんですけど、ふとしたときにカクカクして、そんときってやっぱり気持悪いんですよね。
w2100にしとけば良かったかなぁ。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 20:27:55

T1000/T2000とRay serverの組み合わせってどうよ？

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:13:42

並列化といえばEPICのItanium2が来ましたよ。
先日のItanium Solutions AllianceのDeveloper Daysも
空席の目立つ湿っぽい開催で、Montecitoの発売も来年にズレ込み
相変わらず前途多難な模様でつ。
MontecitoからIA-32はソフトエミュレーションになるので、
VMが２段になるJavaの実行速度を上げる努力をするそうでつ。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:24:21

>>70
GNU makeで -j 64すりゃいい。

シーケンシャルなディスクアクセスがぶつ切りになって、
かえって遅くなったりするかもしれないが・・・。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:24:59

>>76
> なんかで、(x86ので)hyperthreadingのに変えただけで、裏で重いことやっててもかくかくしなくなったみたいな

それはniceしていないからか、OSがヘボだから。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:35:39

> MontecitoからIA-32はソフトエミュレーションになるので、
> VMが２段になるJavaの実行速度を上げる努力をするそうでつ。

これって、どういう意味? IA64 ネイティブの Java VM がないって意味?
そりゃ Sun にはやる気がないだろうけど、Intel は金ならあるんだから、
Sun に金払って、自力で開発して検証通して JRE を配ればいいんじゃないの?

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:42:11

Intelの友達はSunじゃなくてMicrosoft。
Itaniumに関しては喧嘩別れだし。双方が非難する発表。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 21:45:11

> Intelの友達はSunじゃなくてMicrosoft。
> Itaniumに関しては喧嘩別れだし。双方が非難する発表。

あまりそういう一面的な見方は禁物かと。
Microsoft は IA32 の 64bit 化では、Intel じゃなくて AMD 側に
ついたし。
Java VM については、Intel が金さえ出せば、Sun は拒否しないんじゃ
ないの? それとも拒否してるって意味?

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 22:21:05

ttp://www.itmedia.co.jp/news/articles/0512/17/news008.html
IBM、AIXセンター開設

IBMって、Linux に集中してるのかと思ったら、まだ AIX を諦めて
なかったのか。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 22:24:41

MVSだってまだやってますけど。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 22:45:00

>>81
IA64 用 JavaVM は BEA がやってるって誰か書いとったやん。

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 22:52:26

JavaのためにItaniumマシン買う人が果たしているのだろうか・・・

**名無しさん＠お腹いっぱい。** · 2005/12/17(土) 23:07:18

Itaniumマシンは秀吉が全て壊したので誰も買えなくなった。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 00:03:16

SunはJ2SE5からIA-64版を提供していないので、BEAが提供してる。

ttp://e-docs.bea.com/jrockit/docs50/install/install.html

HPもItaniumマシンではBEAのJDKを使う様勧めておる。

ttp://h50146.www5.hp.com/products/servers/integrity/document/pdfs/PDFHS05013-01.pdf

SunのJDKはガべコレのアルゴリズムがシングルスレッドなので
コアを増やそうがチップを増やそうがGCにかかる時間は短縮されない。
#GCの間はアプリが停止する
デカいApp鯖になるとこれが無視できなくなるので、JRockitではGCのアルゴリズムをマルチスレッド化して
極力アプリの停止時間が短くなる様にしてる。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 01:25:29

結局

> VMが２段になる

の意味は?
BEAのを使えば1段で済むわけだよねえ。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 02:37:24

IA64winでX86winのjavaアプリを動かす。→1段。
しかしx86javaVMは今までX86命令を直に実行していたItaniumではなく、
Montecitoのエミュレーションx86環境で実行される。→2段
って言いたかったのかしら?とjavaって何?の俺が強引に解釈してみる。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 06:51:33

Niagara搭載WSを出さないのは、PC-UNIXヲタに実用的な多CPU環境を
安く提供してしまうことになるから。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 07:15:35

それのどこがまずいの？ハードが売れればSunとしては万々歳じゃん。
Solarisに対抗するOSが成長する環境を与えるのがまずいってことかしら？

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 09:09:30

>>89
>SunのJDKはガべコレのアルゴリズムがシングルスレッドなので
>コアを増やそうがチップを増やそうがGCにかかる時間は短縮されない。
>#GCの間はアプリが停止する

ダウト

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 09:19:26

http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 10:20:37

>>92
真のPC-UNIXオタなら鯖でも買うと思うよ
今のNiagaraは浮動少数が弱すぎてWS向きじゃないのが欠点でしょう

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 11:46:37

>>89
今は、new/old世代両方とも平行でいける。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 17:01:23

>>91
それでOK。

>>97
スループットコンピューティングの石を出すにあたり、
さすがにそれはマズいだろうという事になった訳ですね。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 18:16:22

実行状態のスレッドが32個にもなると、ストレージまわりが大変そうよ。

1つずつ順番にやっていけば、シーケンシャルアクセスになるのに、
32個も同時にやったら、ランダムアクセスになってしまう。

ワークステーションみたいに、HDDが1台、という環境では辛そう。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 18:23:33

そんなタコい作りのカーネルなんてあるの？UNIXにはなさそうだ。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 18:35:14

標準だとT1000でHDDは1台T2000でHDDは2台しか積んでいないよ。>>99

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 19:17:26

IOスレッドが多い状況だとIOを強化すべきでそれこそNASやファイルサーバ専用機の出番じゃないの

99 · 2005/12/18(日) 20:35:41

>>100
過信しすぎ。

もしカーネルがなんとかしてくれるなら、
15,000rpmのHDDは不要
バッテリーバックアップ付きのRAIDコントローラ不要
ってことになるぞ。

>>101
だから、ローカルのストレージはOS用。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 20:45:41

時代はシリアル化へと。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 21:09:10

ケロッグの時代キター

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 21:14:39

ディスクI/Oのボトルネックで影響が大きいのはデータ転送時間ではなく、
シーク時間。古くはエレベータアルゴリズムでなんとかしていた分野だから、
特にランダムアクセス性能を上げるのはやっぱりカーネルの領域と思う。
シーケンシャルなアクセスでもバッファメモリ管理の領域だから、
やっぱりカーネルががんばるべき領域。
回転数とかバッテリバックアップとかは全然関係ないだろ。
まあ今はコマンドをタグ化して送っておいて、ディスクのコントローラが
自動的にヘッド移動を最適化してくれるわけだから、
「15000rpmも出せる高級なディスクではそういう高速動作も期待できる」という意味なら
分からないでもない。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 21:38:57

>>98
結構前からだよ。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 21:42:38

>>106
> 特にランダムアクセス性能を上げるのはやっぱりカーネルの領域と思う。

いやディスク・クラスターの領域です。スパコンでは常識。
東工大の奴はCluster File Systemsの。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 21:48:16

>>108
その辺は Solaris 君は考慮済なんじゃねーの? 非同期 I/O ってやつ?

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 22:28:40

カーネルだけじゃどうにもならないという話です。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 22:33:26

>>108
>>99はT1000の話をしてたと思うんだけど。

**名無しさん＠お腹いっぱい。** · 2005/12/18(日) 23:21:29

だから、T1000を何本ものラックにぎっしり詰めて、クラスタ処理する話でしょ?

ちなみに、整合性を確保するために、
書き込み順序を保証しろとか、ライトスルーしろとか、
そういうプログラムは、カーネルが手を出せない。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 00:15:35

いや32というのはT1000単体に乗っているNiagara一個が処理できるスレッドの最大数だから、
複数のT1000を前提にしなくても想定できるケース。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 01:37:22

まぁ、Windowsには絶対無理だな。

あっちは、P2PソフトでHDDの寿命が縮むくらい、カーネルがヘボいから。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 02:42:11

>>99
なんかソフトのスレッドとごっちゃになってないか。
Niagaraに出てくるスレッドはハードレベルの話なので、8コア4スレッドなら
ソフトからは32cpuに見えるはず。

ディスクアクセスはファイルシステム層で、UFSとかのレベルで
最適化されるし、Niagaraについて特別なことはないかと

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 07:22:32

Linus様が anti-IPF 宣言を…
Ita上の UNIX系 OS では Linux が唯一の希望なのに…
ttp://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=3941&Thread=68&entryID=60298&roomID=11

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 07:32:27

IBMのワンワンだから

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 09:47:10

SGIは頑張れ。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 10:05:18

>>116
こんなボクちゃんのタワゴトで大勢してあっち向いたりこっち向いたり... sigh。
IPF って Ita Processor Family の略? やめてよねこんなしょーーもない略語作るの。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 11:43:25

最近の PostgreSQL ってすげーなぁ。
T2000 で MP 活かせない 8.0 と改善されてる 8.1 の比較やったら
Niagara のありがたさもキワダツんじゃね? キョーミあるぜ。

【PostgreSQLウォッチ】第23回本当に速いPostgreSQL 8.1
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20051213/226148/

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 13:46:00

>>116
そりゃ、Linuxはgccにおんぶにだっこだから。
gccが出力するIA-64コードは、とても遅いのよ。

それに加えて、IA-64はx86ほど昔の技術ではない、というのもあるかも。
RISC以上にハードからソフトにお仕事の比重が移っているし、
高可用性やプラットフォームの違いを吸収することを前提としたアーキテクチャで、
そのためのレイヤや処理が必要だったりもするし。

でも、Linus氏は、かなり以前からIA-64は使いこなせないと言ってたよね。

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 15:19:09

IPFならIntelのコンパイラ使えばいいやん
gccにこだわりがあるのかネェ

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 15:27:25

IntelがIPF専用Linuxディストリをつくればいいんだ

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 16:25:32

Linuxカーネルはpatchあてないとgccしかコンパイルできない。
http://www.pyrillion.org/index.html?showframe=linuxkernelpatch.html

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 17:05:15

>>121
> でも、Linus氏は、かなり以前からIA-64は使いこなせないと言ってたよね。
ああ、昔からアセンブラの方が速いとかシステムコールのパラメーターはチェックしなくていいとか
シェアードライブラリは固定数値使ってていいとか仮想記憶をオーバーコミットできないように
する必要はないとか、いろいろ言ってるよ、彼は。
関係ないけど、「氏」つけるんなら Family Name の方じゃないか普通?

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 19:49:29

だれかリーナスをシメてこい

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 22:11:38

　　 ∩＿＿＿∩
　　 | ノ　　　　　ヽ
　　/　　●　　　● |　
　 |　　　　( _●_)　ミ　　　俺がやるクマー
　彡､　　　|∪|　　､｀＼
/　＿＿　ヽノ　/´>　 ) 　　
(＿＿＿）　　　/　(_／
　|　　　　　　 /
　|　　／＼　＼
　|　/　　　 )　 )
　∪　　　（　＼
　　　　　　＼＿)

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 22:15:07

　　　　　　　　　　　　　　　　　　　　　　＿／-　イ､_
　　　　　　　　　　＿＿　　　　　　　／: : : : : : : : : : : (
　　　　　　　　　〈〈〈〈　ヽ　　　　　/: : : : ::;:;: ;: ;:;: ; : : : ::ゝ
　　　　　　　　　　〈⊃　　}　　　　　{:: : : :ノ　--‐'　､_＼: : ::｝
　　 ∩＿＿＿∩　 |　　 |　　　　　 {:: : :ノ ,_;:;:;ノ､ェｪヾ: :::}　　
　　 | ノ　　　　　ヽ !　　 !　　　、　　ｌ: :ﾉ　／二―-､　|: ::ﾉ
　　/　　●　　　● |　　/　　　，,･_　　|　/／　￣7/ /::ノ
　 |　　　　( _●_)　ミ／　, ’,∴ ･　¨　〉(_二─-┘{／
　彡､　　　|∪|　　／　　､･∵ ’　　／､／/|　￣￣ヽ ←Linus
/　＿＿　ヽノ　/　　　　　　　　／　　 //　|／／＼〉
(＿＿＿）　　　/　　　　　　　　/　　　 //　　 /＼／

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 22:31:59

カーネルをgccでコンパイルしてても、それでアプリケーションの動作が
遅くなるもんなのかな。minixのコードくらいしか知らないで言うのもの
なんだが、コンパイラの最適化によってOSの性能が大きく変わるような
とこって何？ファイルシステムのマルチリストの扱いとか？

**名無しさん＠お腹いっぱい。** · 2005/12/19(月) 23:38:32

いまさらだが…
なぜItaniumの話に？

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 00:04:34

>>116 に訊け

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 00:12:29

>>129
gcc で -O0 してできたカーネルと比べてみればいいのでは。C で書いてあって
頻繁に使われるとこは効くと思うよ。ファイルシステムとかネットワークとか。
メモリ割当もかな? Linux じゃ DTrace できんが。

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 05:37:35

gccはGenericなコンパイラなので、Itaniumに特化したプリディケーションやスペキュレーション
みたいな機能をうまく使いこなす様にできてないんじゃないの?
リーナス自身がソフトでごちゃごちゃやるより、IBMみたくハードでなんでもやっちゃう方が好きだとか。

>>132
つttp://sources.redhat.com/systemtap/

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 17:30:21

IA64やEM64TのJavaは、
MicrosoftがAMDと天秤にかけて、
サポートを弱くするようIntelに迫ったという噂がある。
http://pc.watch.impress.co.jp/docs/2004/0218/intel.htm

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 17:57:26

>>134
参照張ってある記事と言ってることになんの関係もないようだが。

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 18:18:51

>>129
Itaniumは他のCPUと比べてコンパイラでの最適化の効果が大きいというか
最適化しないと遅くて性能が発揮できないということじゃないか？

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 20:15:19

今時のCPUがハードで頑張ってる先読みやリオーダリングを
コンバイラにやらせて、ハードは楽をしようっていうCPUだからね

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 20:36:39

米グーグル、時価総額でＩＢＭ抜く－ＡＯＬへの出資合意を好感
http://www.bloomberg.com/apps/news?pid=90003017&sid=a.Zn8c4L_13g

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 21:50:05

IBMの技術者は、苦労してハード側で匠な実装を施してるのに、
分岐パターンを始めから全部実行しといて、分岐条件にハズれた物は全て捨て去る様な
潤沢なリソース使いのアイテニアムは許せんらしい。

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 21:59:39

Sunのユーザーは、苦労して社内で匠な実装を施してるのに、
ヒトもモノも始めから全部用意しといて、リストラ条件にハズれた物は全て捨て去る様な
潤沢なリソース使いのIBMグローバルサービスは許せんらしい。

**名無しさん＠お腹いっぱい。** · 2005/12/20(火) 22:35:31

なんかイカス

**名無しさん＠お腹いっぱい。** · 2005/12/21(水) 00:05:20

>>136
結構肝心な部分はアセンブラで書いてあるから、「そんなに効き目あるのか?」ってことだと
思うよ。スケジューラーや割り込み扱いあたりはアセンブラだからね。
アセンブラで書いてあるからにはコンパイラは関係ないけど、そもそもそのアセンブラの
記述自体で EPIC 活かすのは大変だ（≒不可能?）ってことでしょ。
＃アセンブラで書く... アセンブリ言語で書く、が正しい?

**134** · 2005/12/21(水) 00:30:02

>>135
↓これと間違えた…
http://pc.watch.impress.co.jp/docs/2004/0130/kaigai059.htm

**名無しさん＠お腹いっぱい。** · 2005/12/21(水) 21:55:09

システム設計ではハードで実装する機能とソフトで実装する機能の切り分けを行なう訳だが
今後益々複雑化する機能の実装を、限界が近付いたプロセスや製造コストの高く付くハード側に振らないで
ソフトに振るというのもアリだと思うのだが。

**名無しさん＠お腹いっぱい。** · 2005/12/21(水) 22:23:32

? 主旨が不明だが、分担がハードヘ行ったりソフトへ戻ったりってのは常に繰り返されてるよ。
グラフィックスや外部記憶 I/O とかでもね。
それと、ただただクロックアップだけここ数年やってきた特定の某企業が自分とこが
行き詰まったからってどこも同じだと言ってるけど、これはわかんないよ。
クロックアップと構造の工夫の両方をやりつつこれまでも「限界」と言われてたところを
乗り越えてきてるわけで、ここ数年はライバルがあらわれたことでナリフリかまわず
クロックアップだけやってきてるから、まじめに工夫しながら今 2GHz すぎあたりの
グループ（某系以外全部だけどね）が 3GHz 越えるくらいにはまた限界が先へ延びるかも知れない。

**名無しさん＠お腹いっぱい。** · 2005/12/21(水) 23:49:17

Gate長が狭すぎてVthのコントロールが難しいとか言ってた今までの限界とはもう次元が違うよ。
30nm、15nmといったら分子サイズだから、これを越えるともう歩留りを保つだけのリソグラフィ技術が
ついてこれないと思うよ。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 10:07:36

>>146のようにとやかく予言していた学者たちは皆シリコンバレーに敗退した。
1GHzは無理だとか言っていた人たち、どこいったんだろ。
熱雑音やショットノイズが問題になるくらいまではなんだかんだ言って
いくかもしれないじゃん？

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 10:57:39

IA64は、幾らEPICっていっても、ベースがVLIWだから
命令セットの互換性での性能の犠牲がいや。

ISAを拡張するならまだしも、互換性のためにEPICの
ようなことをしなきゃいけないのが、不自然。

この頃は、pipelineすらなくcoreとthreadをswitch
することでmemory latencyをカバーしようとする
Niagaraが眩しくなってきまつた。。。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 11:07:21

プロセッサが変わったらコンパイルしなおし。GentooLinuxや*BSDなら常識。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 11:23:35

> この頃は、pipelineすらなく

おいおい、pipeline はあるぞ。6段と、今どきのプロセッサとしては短めだが。
Itanium 2 も pipeline はかなり短い方だけど、それでも8段ある。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 11:33:20

OS/360に戻りなさい。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 15:38:04

>>147
そんでもって、Intel は特定の条件下で 9GHz を現実に動かしてるわけで、
今自分で言ってる「限界」を越える可能性が一番高い位置にいる。そのうち
「ついに限界打破、ぶれいくするー!!」とか発表するわけだ。まさにマッチポンプ。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 18:44:30

>>152

動作してても、電子垂れ流し状態じゃないの？
現実には意味ないでしょ。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 19:19:04

>>153
現在において意味がないことと、将来にわたって意味がないことが
同値であることを証明せよ。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 20:05:12

>>154

製造／工学的な改良では、現在のレベルからは前に進めないでしょ。

でも、今までは、従来の物理理論に立脚する製造／工学的な改良による
進歩でムーアの法則があったわけだけど、量子レベルで干渉するところ
まで来ると、物理理論から出直す必要があるわけで、それは今やっている
ことと直接のつながりがない。

だから、発想の転換でNiagaraのようなMulti coreなものが出て来るわけで、
これだと、従来の発想の延長でよいので、今までの製造技術がそのまま
使える。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 21:22:38

笑っちゃうなぁ、量子レベルの問題とは。従来の物理理論ってなによ？
古典電磁気学のこと？マクスウェル方程式は（今のところ）正しいぜ？

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 21:27:25

なるほど、Intel は全く意味もないのに巨大なリソースつぎこんで環境作って 9GHz 動作してみたんだ、
へぇ～そこまで気が狂ってたのか気の毒に。だって意味ないのに..w

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 21:43:26

>>155=157
自演乙。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 21:44:31

>>156

量子物理学

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 21:47:31

なにもそんなに自分の無知をさらさなくても・・・

**157** · 2005/12/22(木) 21:47:52

>>158
いやいや、155 さんは Intel & Itanium 擁護したい人ですよ。別人です。

**157** · 2005/12/22(木) 22:11:43

あっ、ちがうな、Intel & NetBurst(Pentium4) 擁護したい人か?

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 23:22:20

何だこのアホ臭い展開は…

**157** · 2005/12/22(木) 23:26:44

>>163 この人が 155 でしょう。

**名無しさん＠お腹いっぱい。** · 2005/12/22(木) 23:35:04

Itanium、これから伸びると思う？