Sun Microsystems 最大の敵はItanium
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2006/02/26(日) 01:49:21【前スレ】
Sun Microsystems 最大の滝壷
http://pc8.2ch.net/test/read.cgi/unix/1138786320/
0209名無しさん＠お腹いっぱい。
2006/03/22(水) 13:16:00さっぱり理解できん。バランス感覚のないデザイン。
0210名無しさん＠お腹いっぱい。
2006/03/22(水) 13:56:16そもそも、Intel X86のデザインって、めちゃくちゃじゃない？
Intelはデザインなんて考えてないよ。
デザインでいったら、AMD64の方がメチャ綺麗。
0211名無しさん＠お腹いっぱい。
2006/03/22(水) 19:13:42レジスタの値１つ変更するだけでレジスタの退避など全自動でタスクスイッチの処理をしてくれるようなCPU他にあるのか？
0212名無しさん＠お腹いっぱい。
2006/03/22(水) 19:16:14AMD厨は、こんなところにまで・・・
>>207
64ビットあれば十分で、コストをかけてまで拡張精度を用意する必要はない
という割り切りをしているんだろうね。
PAEについては、一部の例外的にメモリを多量に使うアプリのためのもので、
たとえば、DBMSのように、メモリアクセスにオーバーヘッドがあろうとも、
HDDにアクセスに行くよりは桁違いにマシ、という用途で使うことを想定してる。
0213名無しさん＠お腹いっぱい。
2006/03/22(水) 19:25:570214名無しさん＠お腹いっぱい。
2006/03/22(水) 22:55:59じゃあさ、CPUの仕様の違いを教えてよ。
みんな分かってるようであんまり良く分かってないんで無いの？
画像のエンコードとかやるならSS2の精度で十分だけどまともな数値計算するなら64bitじゃお話にならないし、
ソフトで他倍長計算するのってなんかやだ。
0215214
2006/03/22(水) 22:57:02○多倍長計算
0216名無しさん＠お腹いっぱい。
2006/03/22(水) 23:01:04全然知らんｗ
よく使われる精度が決まってないのなら、ソフトで実装するしかないのでは
0217名無しさん＠お腹いっぱい。
2006/03/22(水) 23:23:20多く使われるといえばIEEE754の倍精度(64bit)か拡張倍精度(80bit)なんじゃない？IA32でサポートしてるし。
でもSPARCやAlphaの4倍精度(128bit)で作ったプログラムを移植しようとしたらIA32じゃつらいよね。
IA64なら問題無いと思うけど、SSE2を推奨するx64はどうなんだろ？
0218名無しさん＠お腹いっぱい。
2006/03/23(木) 07:46:11めんどくさい手法で4GB以上使えると聞く。
どっかのDBが利用してるらしい。
0219名無しさん＠お腹いっぱい。
2006/03/23(木) 07:59:28もう、二十年来の不満だよｗ
0220名無しさん＠お腹いっぱい。
2006/03/23(木) 09:26:50SQLServerだっけ
0221名無しさん＠お腹いっぱい。
2006/03/23(木) 10:29:040222名無しさん＠お腹いっぱい。
2006/03/23(木) 21:50:08long double a, b, c;
c = a*b;
をコンパイルしたらこうなった
fldt -16(%rbp)
fldt -32(%rbp)
fmulp %st, %st(1)
fstpt -48(%rbp)
0223名無しさん＠お腹いっぱい。
2006/03/24(金) 15:13:09long doubleをdoubleにすると、xmm使うみたいですね。
gcc-4.1 amd64
デフォルト(-mfpmath=sse)
movlpd -24(%rbp), %xmm0
mulsd -16(%rbp), %xmm0
movsd %xmm0, -8(%rbp)
-mfpmath=387
fldl -24(%rbp)
fmull -16(%rbp)
fstpl -8(%rbp)
long doubleは必ずFPU使うのか。
0224名無しさん＠お腹いっぱい。
2006/03/24(金) 18:55:48http://www.anandtech.com/systems/showdoc.aspx?i=2727
Niagaraｼﾎﾞﾝﾇ?
0225ありがとう
2006/03/24(金) 21:31:27守ってください、本当にありがとうよかった・・・・・・
0226名無しさん＠お腹いっぱい。
2006/03/24(金) 22:24:19http://www.theinquirer.net/?article=30514
0227名無しさん＠お腹いっぱい。
2006/03/25(土) 20:16:050228名無しさん＠お腹いっぱい。
2006/03/25(土) 20:29:370229名無しさん＠お腹いっぱい。
2006/03/25(土) 20:32:38残念でした。Sun復活でつ。。。。
0230名無しさん＠お腹いっぱい。
2006/03/26(日) 14:37:44結局、痛 やってるのは日本の会社だけだから
インテルから切り離しちゃうんでしょ？ｗ
0231名無しさん＠お腹いっぱい。
2006/03/26(日) 17:04:40そりゃこのスレ的には『HP-UXを使ってるユーザなんて無視』でもいいけど
現実にはどうしても痛を使いたいユーザのほどんどはHP-UXだろ
WindowsとかLinuxを使っているならx64に移れば桶だし
本当にエンタープライズシステムクォリティが必要なら
POWERに移ればいいのだから
だから痛を日本のメーカーがコントロールするようになっちゃうと
HPが黙っていないだろ
0232名無しさん＠お腹いっぱい。
2006/03/26(日) 18:20:01これだけで、Itaniumの数は伸びない...って感じがする。
HP-UXでも、PAからItaniumに移行しないで、IBM, Sunに移行していく
ユーザっていそうだし。PAユーザってまだ相当いそうだし。
HPがPAを止めたのは完全に失敗だったね。
0233名無しさん＠お腹いっぱい。
2006/03/26(日) 21:13:42Itaniumは技術的にもマーケティング的にもどう考えてもすべて90年代の発想です
0234名無しさん＠お腹いっぱい。
2006/03/26(日) 21:15:38hpは何やってもダメでしょ。必要ない。
0235名無しさん＠お腹いっぱい。
2006/03/26(日) 21:25:010236名無しさん＠お腹いっぱい。
2006/03/26(日) 21:32:290237名無しさん＠お腹いっぱい。
2006/03/26(日) 21:42:070238名無しさん＠お腹いっぱい。
2006/03/26(日) 21:47:120239名無しさん＠お腹いっぱい。
2006/03/26(日) 21:48:22売り払っちまったんでないの？
0240名無しさん＠お腹いっぱい。
2006/03/26(日) 21:57:14Alphaの技術はXeonの方にいっちゃったけど、CPUを使ったホストは
CompaqからHPへ。で、マシンが残っている以上、サポートしないといけないし。
そうなると、HPって、いつまでもAlphaとPA, VAXをサポートしていくのね。
Itaniumへの移行をすすめつつ。まぁ途中でサポートを切るんだろうけど、
今の感じだと、Itaniumへ移行すると、今度はItaniumのサポートが早々
うち切られそうな状況なので、Itaniumを使ったホストへの移行が進みそうにないね。
0241名無しさん＠お腹いっぱい。
2006/03/26(日) 22:05:16http://www.asahi.com/politics/update/0326/004.html
> 総務省によると、文部科学省以外の電子申請にはパソコンにあらかじめ、米サン・マイクロシステムズ社のＪＲＥというプログラムを導入する必要がある。パソコンの基本ソフトであるＯＳが違っても申請のための操作を可能にするためだ。
>
> しかし、ＪＲＥは随時、バージョンアップされており、各省庁の申請の種類によってバージョンがばらばらになっている。総務省によると、新版を入れたパソコンは旧版対応の申請ができないことが多く、旧版を入れたパソコンは新版対応の申請が難しくなるという。
確かにありがち！
0242名無しさん＠お腹いっぱい。
2006/03/26(日) 22:11:45この、「文部科学省以外の電子申請には...」って何？
全省庁、Javaで統一しろよ。そういうことしてるから、税金が無駄に使われる。
文部科学省も、Javaを使えよ。
0243名無しさん＠お腹いっぱい。
2006/03/26(日) 22:15:03これって、具体的にどういうこと？
新版で動く ==> 旧版で動かない っていうのは、アプリが新版で導入された新しい
インタフェース、関数を使っていて、旧版ではその呼び出しができないっていう
ことかなって思うけど、
旧版で動く ==> 新版で動かない っていうのは、どういう場合？
アプリが新版で廃止になるdeprecateな関数呼び出しを使っているってこと？
（つまりバグ？）
0244名無しさん＠お腹いっぱい。
2006/03/26(日) 22:32:24確かに基本的にはあり得そうもないが...
0245名無しさん＠お腹いっぱい。
2006/03/26(日) 22:35:02オレの経験上では、旧版でセキュリティ的にめちゃくちゃなことやってて、
新版では手動で JVM の設定緩めないと動かなくなって、全クライアント（Web ブラウザ）機で
そんなことやってらんない、ってやつ。JRE のせいにするか普通? って思うけど。
0246名無しさん＠お腹いっぱい。
2006/03/26(日) 22:47:46そういうのは、アプリの問題で、全然Javaの問題じゃないよね。
そもそも、コーディングの仕方を知らないって言うレベルで、発注先を変えた方が
いいかも。
0247名無しさん＠お腹いっぱい。
2006/03/26(日) 22:53:14全国あちこちで導入されてる。
0248名無しさん＠お腹いっぱい。
2006/03/26(日) 22:55:10官庁関係の開発って、孫外注、曾孫外注の開発で、最後は相当スキルの低いとこが
コーディングしてる例って結構あるよ。
0249名無しさん＠お腹いっぱい。
2006/03/26(日) 22:57:13調べると、開発元のスキルがみえてくるよ。
スキルがないとこが開発すると、遅いのですぐ分かる。
0250名無しさん＠お腹いっぱい。
2006/03/26(日) 23:04:01うーん、でも、末端のコーディングとかの問題じゃなくて、アプレットのレイアウトとか
アプリ構成の大枠の話だったりするし、内製だったと思うけど。メンテでその大手企業の
社員さんが来てたから。
スキルとかいうより、セキュリティ感覚というか、文化というか、そういう問題と
思った。その件に関しては。
でも、外ヅラ的には客には Java の互換性問題に見えるし、その大手企業も Java のせいに
してたし、適用やってた作業者も Java に文句たれてたよ。ひどい話だけど。
0251名無しさん＠お腹いっぱい。
2006/03/26(日) 23:16:43JavaはObj指向のデザイン、コーディングが必要な上に、セキュリティモデルを最初から
設計に入れて、仕様を決めていく必要がある。その上、ネットで展開する場合は、
パフォーマンスを考慮して、詳細仕様を詰めていく必要があるので、それなりの
スキルがないと、ちゃんとしたアプリは開発できないと思うよ。
上の話をみると、請け負った大手コンピュータ？会社側にJavaでアプリを開発する
スキルがなかったということだと思う。
日本でちゃんとJavaでアプリを組めるとこって、まだあんまりないのかもね。
Javaが出てきて10年以上たつのに、何のスキルもつけてこなかったってこと？
海外じゃ、相当量の開発が行われているのに。source forgeでは、C++のプロジェクト
数をJavaが抜いたらしいし。
0252名無しさん＠お腹いっぱい。
2006/03/26(日) 23:40:33単純にSwingのプログラミング方法をしらないだけじゃない？
確かに、日本語の書籍を見てもSwingの解説を丁寧にしてるJavaの書籍はここ2年くらい前以降に出た
比較的新しい本ばかりだし種類も少ないし情報不足というのもあるんじゃない？
スキルの無い開発者なんて市販の日本語のJavaの書籍で勉強してそうだからな
0253名無しさん＠お腹いっぱい。
2006/03/27(月) 00:24:50クロックを上げることよりも、スレッド数を上げることよりも、
IPC向上を至上命題にしたアーキテクチャは、開発当時は正しくても、今は正しくないよね。
0254名無しさん＠お腹いっぱい。
2006/03/27(月) 00:46:01Write once debug anywhere と言われていた時もある品。
0255名無しさん＠お腹いっぱい。
2006/03/27(月) 10:43:03NetBurstはどうなった？
バブル時代の体育会系の営業みたいで大嫌いなんだが。
0256名無しさん＠お腹いっぱい。
2006/03/28(火) 09:45:48NetBSDはバイナリー互換性を維持するために頑張ってるんだから、オプソOSと
一括りにしないでくれないかな。
0257名無しさん＠お腹いっぱい。
2006/03/28(火) 12:54:51ハハハ
居たの？って感じｗ＞NetBSD
0258名無しさん＠お腹いっぱい。
2006/03/28(火) 13:15:15NetBSDもいいじゃんか、別に。Unixなんだし。
OpenSolaris, Linux, {Open,Net,Free}BSDは、似たりよったり。
皆基本的に無料だし。
組み込みにも使われるNetBSDは、Niagaraへのポートもしやすいだろうね。
Linuxのポートができたので、次はNetBSD/OpenBSD/FreeBSDの番だね。
Windowsは無視。
0259名無しさん＠お腹いっぱい。
2006/03/28(火) 23:41:58各OSの支持者が一斉に文句を言い始めそうなことを
さらりと言ってのけましたなあ…
0260名無しさん＠お腹いっぱい。
2006/03/29(水) 00:27:42Niagaraは、その能力を十二分に使い切れてこそ意味がある。
でなければ、その辺の糞CPUにも劣る。
NetBSDなどは、ただ単に動きますというレベルには比較的容易に
もっていけるのかもしれないが、自己満足以外の何でもない。
0261名無しさん＠お腹いっぱい。
2006/03/29(水) 15:55:42それを言ったらフリーOSはほとんど自己満足だな。OpenSolarisがその出自か
らかろうじて違うくらいか。ところでOpenSolarisってNiagaraに対応済なの?
0262名無しさん＠お腹いっぱい。
2006/03/29(水) 16:31:13ソフトウェアベンダも含めてLinuxは結構な商売道具になってる。
このスレに沿った話をすれば、Itanium機の多くはLinuxでしょ。HP-UXや
OpenVMSをItaniumで、ってところは少なそう。
0263名無しさん＠お腹いっぱい。
2006/03/29(水) 23:44:44このスレに沿えば、ItaniumではHP-UXが殆どなのだが…
実績に乏しいLinux IA64を使うリスクを冒す企業はごく僅かだろう。
唯一の例外がHPC。極めて限定的な用途。
0264名無しさん＠お腹いっぱい。
2006/03/30(木) 05:06:450265名無しさん＠お腹いっぱい。
2006/03/30(木) 07:30:50最初から対応済みでしょ。
0266名無しさん＠お腹いっぱい。
2006/03/30(木) 07:34:35高いんだし。
でも、HPCになると、今度はCPUがない日本のメーカーがItaniumを採用して
（墓穴を掘った？）、OSがないもんだからLinuxなんだよね。
Linuxの版数があがると、追従するのが大変だよ、きっと。
ドライバの互換問題もでてくるだろうし。
アプリはさほど問題じゃないよね。
OpenSolaris + Debianの環境で、Linux + Debianのアプリ、ライブラリが動くもの。
アプリにとってはカーネルと言うより、ライブラリやコマンドといった取り巻きの
環境の方の影響が大きいから。
0267名無しさん＠お腹いっぱい。
2006/03/30(木) 14:31:26確かに NetBSD はジャイアントロックでの SMP 対応だから Niagara で上がるように
しただけでは CPU バウンドな仕事除いて Niagara の真価を発揮することはできない。
けど、SMP 実装迷宮入りしてしまった Linux なんぞに比べたらこの先の進展は
不用意な実装を避けてきている NetBSD の方が有利な可能性はあるよ。
0268名無しさん＠お腹いっぱい。
2006/03/30(木) 15:14:05> アプリはさほど問題じゃないよね。
>
> OpenSolaris + Debianの環境で、Linux + Debianのアプリ、ライブラリが動くもの。
それこそベンダのサポートがあるかないかが重要なんじゃないの？
例えばFreeBSDでOracleが動くといっても、積極的にそんなことする
ところがあるかなあ。
0269名無しさん＠お腹いっぱい。
2006/03/30(木) 15:46:40そうね。
考えてみると、libcの版数が変わっただけでも、昔は大変なことに
なってたものね。Linuxでは、互換性の維持がたしかに大変かも。
そうなると、Itaniumでは、HP-UXぐらいしかないのね。
SolarisがItaniumに移植されていたら、Itaniumも助かっただろうにね。
でも、この頃Itaniumって、ますます存在感が薄くなっている気がするのだけれど。
Intel社内でも、存在感がなくなってない？
0270名無しさん＠お腹いっぱい。
2006/03/30(木) 16:15:52実態が見えないようにしてあるごまかしもの。今が創業以来最悪の状態なんじゃない?
Pen-M ベースの 64bit チップが AMD の次の一手に間に合わなかったら、Intel 終わるんじゃ
ないかなぁ。
メインストリームはずれるのが確定した Itanium なんかにかまってるヒマはまったくないはず。
0271名無しさん＠お腹いっぱい。
2006/03/30(木) 16:35:25そして、いよいよ、Intelおわってる、の時がくるのね。。
0272名無しさん＠お腹いっぱい。
2006/03/30(木) 16:49:270273名無しさん＠お腹いっぱい。
2006/03/30(木) 18:22:17AMD、インテルの「Itanium」設計者を引き抜き
ttp://japan.zdnet.com/news/hardware/story/0,2000052523,20099773,00.htm
AMD の目的が何かも気になるね。ポスト amd64 か?
0274名無しさん＠お腹いっぱい。
2006/03/30(木) 18:33:330275名無しさん＠お腹いっぱい。
2006/03/30(木) 18:48:200276名無しさん＠お腹いっぱい。
2006/03/30(木) 19:52:31IntelはItaniumへの興味を失っていて、Itaniumは実質死んでいるということじゃない。
これは後数年でItaniumは消えるね。
0277名無しさん＠お腹いっぱい。
2006/03/30(木) 19:56:09Itaniumを消滅させて、X86系の64bitはX64アーキで決まりにするためだろ？
0278名無しさん＠お腹いっぱい。
2006/03/30(木) 21:58:080279名無しさん＠お腹いっぱい。
2006/03/30(木) 22:23:040280名無しさん＠お腹いっぱい。
2006/03/30(木) 22:53:290281名無しさん＠お腹いっぱい。
2006/03/30(木) 23:13:510282名無しさん＠お腹いっぱい。
2006/03/30(木) 23:46:000283名無しさん＠お腹いっぱい。
2006/03/30(木) 23:51:550284名無しさん＠お腹いっぱい。
2006/03/31(金) 00:10:34PA-RISCを１０年はサポートするつもりなのかしら？
もうすぐver2のエンハンスでccNUMAやらPCI hotplugがサポートされて
エンタープライズ向け機能が出揃う。
Linux/ia64より台数多いが、Windows2003/ia64より少なめの売れ行き。
0285名無しさん＠お腹いっぱい。
2006/03/31(金) 00:14:45状況次第でまだ可能性あるんじゃないかなぁ。
どっかと違って、金とリソース注ぎ込みまくったのにダメだった訳じゃないから。
ただ、VLIW というキーワードはもう宣伝材料にはならんかもね。
0286名無しさん＠お腹いっぱい。
2006/03/31(金) 00:17:45確かに、NetBSDの方針は耳への聞こえが良く
誰もが理想とするところだとは思うが、タイムリーに
実装を行っていくにはリソースが足りないのが残念。
話がそれてしまうが、
「SMP実装迷宮入りしてしまった」のはFreeBSDの方では？
6.0が出て期待できるかと思ったが、結局もたついている。
Linuxも、現状以上のスケーラビリティとなると、
壁にぶち当たるのかもしれないけど。
0287名無しさん＠お腹いっぱい。
2006/03/31(金) 01:22:31気合い入った人間がいるかどうか、あと、ジャマするやつがいないかどうか。
Minix が進展してきてるようだから、ひょっとするとダシ抜いたりしたりして。
「ジャマされる」要因を排除するという意味では、マイクロカーネルで切り分けられてる方が
有利と思うし。
0288名無しさん＠お腹いっぱい。
2006/03/31(金) 05:55:370289名無しさん＠お腹いっぱい。
2006/03/31(金) 08:45:340290名無しさん＠お腹いっぱい。
2006/03/31(金) 10:12:00エンディアンにも構造体のパディングにもベタベタに依存してたの今は直ったのか?
0291名無しさん＠お腹いっぱい。
2006/03/31(金) 11:02:14いずれにせよ、インターフェースとして固定するしかないわけだけど。
0292名無しさん＠お腹いっぱい。
2006/03/31(金) 11:03:49AMD64の延長じゃなくて、その次のアーキテクチャなのかな?
AMD64の延長だとちょっとプロジェクトとして魅力低そうだから…
0293名無しさん＠お腹いっぱい。
2006/03/31(金) 11:54:07FR-Vはどうなった?
0294名無しさん＠お腹いっぱい。
2006/03/31(金) 14:33:06画像処理系とか
0295名無しさん＠お腹いっぱい。
2006/03/31(金) 14:34:25富士通から、このチップを使った超並列機が出てたんだけど、
育てればBlue Geneまでといかないものの
成功したのでは？と思う
で、トランスメタのCPUが失敗した要員は性能だろう
CRUSOE機もってたけど、苦行に感じるくらい遅かった
0296名無しさん＠お腹いっぱい。
2006/03/31(金) 14:45:090297名無しさん＠お腹いっぱい。
2006/03/31(金) 15:06:050298名無しさん＠お腹いっぱい。
2006/03/31(金) 15:06:35Crusoe、変換結果をdiskにcacheしたらどうだったろうなあ。
0299名無しさん＠お腹いっぱい。
2006/03/31(金) 16:16:43AMD64の延長でいいんじゃない？ 64bitとしては、Itaniumよりきれい。
（というか、Itainumが汚すぎ）
正直言って、あの汚いX86がItaniumにいくと別な意味でややこしいなと
思っていたので、それをきれいにまとめたAMD64の64bitアーキがでてきて
嬉しかった。
0300名無しさん＠お腹いっぱい。
2006/03/31(金) 17:24:15良くわからない。何をもって「汚い」って言ってるの？
0301名無しさん＠お腹いっぱい。
2006/03/31(金) 17:51:010302名無しさん＠お腹いっぱい。
2006/03/31(金) 17:52:42パターンだよ
0303名無しさん＠お腹いっぱい。
2006/03/31(金) 18:26:27> 良くわからない。何をもって「汚い」って言ってるの？
あの巨大で複雑な仕様と、サフィックスをつけまくるアセンブラが嫌い。
最初に仕様をみたエンジニアは、まずため息をつくと思う。
それを比較すると、AMD64は美しいって思う。
0304名無しさん＠お腹いっぱい。
2006/03/31(金) 18:57:470305名無しさん＠お腹いっぱい。
2006/03/31(金) 19:04:33仕様をみればみるほど、alphaやらpaやらx86やらvaxやらmipsやらをサポートするために
混ぜこぜにしたあげく、Unixサーバー, Hirayama, VAX向けのRASを加え、最後にVLIWの
味付けをしったって感じで目まいがするアーキ。単独プラットフォームで、あの全仕様
を使うものってあるのだろうか？
0306名無しさん＠お腹いっぱい。
2006/03/31(金) 19:28:250307292
2006/03/31(金) 19:50:43いや、AMD64自体はいいと思うんだけど、
既にAMDにはそれぞれのチームが居るわけだよね。
そういうところに1+8人のチームが乗り込むわけだから、
何か新しいプロジェクト立ち上げると思うんだよね。
AMD64の新しい系列であっても、
何か新しい基軸がないとこれだけの人間が一斉に移籍することないと思う。
チャレンジングなテーマだと思ったから行くんじゃないのかな。
それはたとえばマルチコアのコア増大程度じゃないと思うんだけど。
0308名無しさん＠お腹いっぱい。
2006/03/31(金) 19:53:24ふーん、そうなんだ
こりゃItaniumの普及は絶対に阻止せねばならんね
■ このスレッドは過去ログ倉庫に格納されています