Sun Microsystems 最期の落日
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2009/06/06(土) 20:00:02ITの未来はどっちだ！？
【前スレ】
Sun Microsystems 最期の神託
http://pc12.2ch.net/test/read.cgi/unix/1242038454/l50
0472名無しさん＠お腹いっぱい。
2009/06/14(日) 12:38:26伝統的にRISCのほうがメモリ性能が高かったのは、そうせざるをえなかったからっていう側面もあるぞ。
x86サーバのコストパフォーマンスが良いのは、パソコンと同じだからではなく、オープンアーキだから。
XeonやXeon向けのチップセットは、パソコンとは別に作られていて、値段が高いんだが、それでも、
Sunと富士通の、実質一社のみのクローズドなSPARCよりは安くなる。
SPARCはオープンだとか言ってるけど、x86に比べればクローズドだよ。
0473名無しさん＠お腹いっぱい。
2009/06/14(日) 13:00:13このプラットフォーム戦略によってIntel様はx86サーバ市場を年間1000万台規模まで成長させました
0474名無しさん＠お腹いっぱい。
2009/06/14(日) 13:04:08オープンアーキテクチャやクローズドアーキテクチャの意味を間違えてるわけだが
0475名無しさん＠お腹いっぱい。
2009/06/14(日) 13:15:46IBMもhpもNECも、ミドル以上は自前のチップセットを使ってきた。
かつては2P以上をServerWorks(RCC)に任せていた時代もあったし。
0476名無しさん＠お腹いっぱい。
2009/06/14(日) 14:26:51>そのうちCPU性能をいくら上げてもメモリ性能がボトルネックになって性能が伸びなくなるときがくる
>サーバ用に専用設計されたサーバ向けRISC CPUならメモリバス性能を上げることも可能だろうが
笑った。
こんな幻想を信じている馬鹿がいるとはな。
Intelだって4ソケット以上は独自設計されてるが。
そもそもCPUにサーバ用でなければならない設計上の絶対的理由ないぞ。
0477名無しさん＠お腹いっぱい。
2009/06/14(日) 14:31:06久しいというのに、無意味なアーキテクチャ原理主義、アーキテクチャ幻想をひきづって
他アーキテクチャの話題で頓珍漢な発言で粘着してくるアフォの集まりって話だ。
別に好きならそれでいいんじゃあないか?
他を無理に否定しようと必死になるから、逆に叩かれるんだが。
大人しくROMってろってかんじ。
0478名無しさん＠お腹いっぱい。
2009/06/14(日) 14:37:33見事に後半部分が前半部分を全否定しててﾜﾗﾀw
0479名無しさん＠お腹いっぱい。
2009/06/14(日) 14:39:58○○は糞だとかいうSPARC房が暴れ初めて、15年くらい前の認識で
他人を攻撃し始めるからあれるんだが。学習能力の低い奴は素直に消えろよと。
0480名無しさん＠お腹いっぱい。
2009/06/14(日) 14:58:19荒れるから、そうやって他人を攻撃するなよ。
0481名無しさん＠お腹いっぱい。
2009/06/14(日) 14:59:050482名無しさん＠お腹いっぱい。
2009/06/14(日) 15:04:360483名無しさん＠お腹いっぱい。
2009/06/14(日) 15:06:250484名無しさん＠お腹いっぱい。
2009/06/14(日) 15:10:190485名無しさん＠お腹いっぱい。
2009/06/14(日) 15:46:57流石に今更Sgi使いたいという気分にはならないわｗ
0486名無しさん＠お腹いっぱい。
2009/06/14(日) 17:01:25って言われて、それはお前だろ、って返すのが、病気の証拠。
0487名無しさん＠お腹いっぱい。
2009/06/14(日) 17:28:060488名無しさん＠お腹いっぱい。
2009/06/14(日) 17:42:21ﾜﾗﾀw
もっと面白い踊りをｷﾎﾞﾝﾇ
0489名無しさん＠お腹いっぱい。
2009/06/14(日) 18:06:24そう遠慮するなよ
0490名無しさん＠お腹いっぱい。
2009/06/14(日) 18:36:130491名無しさん＠お腹いっぱい。
2009/06/14(日) 20:36:120492名無しさん＠お腹いっぱい。
2009/06/14(日) 20:37:16わかった、もっと広い所に住むようになったら買うわ
0493名無しさん＠お腹いっぱい。
2009/06/14(日) 21:09:180494名無しさん＠お腹いっぱい。
2009/06/14(日) 21:10:15ノートPC上の仮想マシン群に負ける、
なんてことも多々あるしなぁ。
0495名無しさん＠お腹いっぱい。
2009/06/14(日) 23:37:47AMDもIntelも８CPU用までしか出してないような
>>473
逆に言えば数の出ないハイエンドサーバについてはIntelの出る幕はない
Intelはあくまでも部品メーカーであってサーバを売って儲けてる企業ではないので
チップ製造が赤字になるような分野には進出しない
0496名無しさん＠お腹いっぱい。
2009/06/15(月) 00:01:59ちゃうちゃう
SPARCが絶対性能でもコストパフォーマンスでも圧倒的に劣るという
明快な事実を10年以上も受け入れずに現実逃避をつづけてきた精神障害者が問題なだけだろw
ありえんw
0497名無しさん＠お腹いっぱい。
2009/06/15(月) 00:04:00主観や趣向の問題とは到底呼べない格差があるからな。
0498名無しさん＠お腹いっぱい。
2009/06/15(月) 00:04:03出来ればチラシの裏にお願いしたいところだがｗ
0499名無しさん＠お腹いっぱい。
2009/06/15(月) 00:23:13どんな珍発言が飛び出すがレスが毎度楽しみ。
0500名無しさん＠お腹いっぱい。
2009/06/15(月) 00:34:53IA-64を忘れないでやってくれ。
0501名無しさん＠お腹いっぱい。
2009/06/15(月) 00:38:1932nmから先どれだけ微細加工が進むか、1世代移行する期間がどうなるかこの先見ものだな
0502名無しさん＠お腹いっぱい。
2009/06/15(月) 00:44:05AMDは?
0503名無しさん＠お腹いっぱい。
2009/06/15(月) 00:52:27AMD64とIA-64どっちが脅威かといえば後者だから、
Sunが前者を採用してIA-64を劣勢に立たせたのは、
なりふりかまわない保身としては、インパクトがあったね。
0504名無しさん＠お腹いっぱい。
2009/06/15(月) 00:53:28富士通、世界最速のSPARC64 CPU「SPARC64 VIIIfx」
ttp://pc.watch.impress.co.jp/docs/news/20090514_168533.html
0505名無しさん＠お腹いっぱい。
2009/06/15(月) 01:02:04まあ、結果をみればわかるが、
IA64が成功しようが、x86が成功しようが、SPARCに勝ち目はなかったけどね。
Intelが壊滅したと仮定しても、AMDかIBMの方に分があったくらいだ。
それくらいSunのSPARCには力がないのが現実。
0506名無しさん＠お腹いっぱい。
2009/06/15(月) 01:04:48富士通製の新しいSPARCのSPARC64VII搭載の
新しいハイエンドサーバが発売されたと思ったら金融恐慌勃発
Sunかわいそう
0507名無しさん＠お腹いっぱい。
2009/06/15(月) 01:10:07その点、x86は安全だ。
IntelとAMDが互いにダメな時期をカバーし合ってるからね。
0508名無しさん＠お腹いっぱい。
2009/06/15(月) 01:11:5132bitから64bitへのジャンプでx86のダメなところを一掃するチャンスだったのに、継承しちまった。
0509名無しさん＠お腹いっぱい。
2009/06/15(月) 01:29:57K8/AMD64がちょっと注目されただけで、むしろ脚の引っ張り合いだよな。
x86=Intelの牙城であって他は取り巻きみたいなもん、RISCサイドから見るとな。
0510名無しさん＠お腹いっぱい。
2009/06/15(月) 01:32:26互換性より重要な物があればそれ以外の物が広まる。
移行はいつだっていいんだよ。
0511名無しさん＠お腹いっぱい。
2009/06/15(月) 01:38:03自社の目先の売り上げしかもちろん考えていないサーバ屋にとっては
魅力的だったのだが、64bit x86をあえてやらずに、こらえて移行の機会とする
長期的な戦略で投資を回収したかったIntelの思惑は成功し、
x86がなくなっていく可能性はあった。
0512名無しさん＠お腹いっぱい。
2009/06/15(月) 02:04:53その取りまきのAMDよりも・・・な、RISCサイドって・・・
0513名無しさん＠お腹いっぱい。
2009/06/15(月) 02:07:35互換性ではなく、x86命令の実行速度、だろ。
Itaniumはx86命令も実行できるんだから。
また、64bitのモードで32bitのバイナリがそのまま走らないのは、AMD64も一緒。
0514名無しさん＠お腹いっぱい。
2009/06/15(月) 02:47:500515名無しさん＠お腹いっぱい。
2009/06/15(月) 06:19:28IA64がx86バイナリを実行できるつってもエミュレーションだったよな？
0516名無しさん＠お腹いっぱい。
2009/06/15(月) 06:35:55嘘を言うなよ。
AMD64は64bitモードで32bitバイナリを普通に実行できるぞ。
0517名無しさん＠お腹いっぱい。
2009/06/15(月) 06:58:53http://202.218.223.135/docs/2004/0219/kaigai063.htm
0518名無しさん＠お腹いっぱい。
2009/06/15(月) 07:26:1464bit「の」モードとでも言えば良かったか？そのくらい脳内補完してくれよ。
AMD64上で64bitカーネルのOSを動かす場合はLongモードなんだから、32bit
バイナリを実行できることに何ら変わりはない。
0519名無しさん＠お腹いっぱい。
2009/06/15(月) 10:00:22そんなわけない。それなら IA-32eなんて出してきた時に AMD64と互換にする
必要なんか全くなく、非互換にして AMDを潰せた、という理屈になる。
実際はビビリまくりで「ごめんなさい、互換にするからユルシテちょーだい」。
Intelは Pen-4でクロック上げることのみに集中して周りが見えなくなっていた。
0520名無しさん＠お腹いっぱい。
2009/06/15(月) 12:50:30最初の頃はソフトウェア・エミュレーションではなかったよ。
AMD64と同じように、16bitあるいは32bitのOSがそのまま走るようになっていたし、
64bitのOS下でも、16bitあるいは32bitのアプリを走らせるためのモードを持っていた。
つまり、互換性という点ではAMD64と同じ。
速度も含めて上位互換かというと、違うがね。
0521名無しさん＠お腹いっぱい。
2009/06/15(月) 12:58:33AMD信者っぽい気持ち悪い文章だなぁ。
Pentium4のアプローチは、RISC的で良いものだったと思うんだがねぇ。
消費電力の大きさはアーキテクチャの問題ではなく、製造プロセスの問題だった。
それに、Northwoodと競合していた頃のAMDはK7だが、
そのK7は省電力機能も封印されていたので、常に大電力を食いまくりで論外だった。
0522名無しさん＠お腹いっぱい。
2009/06/15(月) 14:03:14> 消費電力の大きさはアーキテクチャの問題ではなく、製造プロセスの問題だった。
それは違うだろ。NetBurstマイクロアーキテクチャの設計思想として、パイプラインを
深くしてクロックを可能な限り上げたい、というのがあったのだから製造プロセス
だけの問題じゃない。
0523名無しさん＠お腹いっぱい。
2009/06/15(月) 14:59:12それはNorthwoodとThoroughbredで、処理能力あたりの消費電力を比較しての話?
当時のAthlonXPは、
パイプライン段数を増やさずに電源電圧を上げることで動作クロックを高くしていて、
電力効率が悪かったという印象があるよ。
さらに、省電力機能がないに等しく、
アイドル状態が続いても湯水のごとく電力を浪費してたこともあって、とても印象が悪かった。
そんな消費電力の大きさを誤魔化すために、IntelのTDPの数字がインチキだとか工作してたなぁ。
IntelのTDPはAMDのTDPよりも低いが、最大電圧×最大電流を計算するとAMDのTDPよりも
格段に高くなる、とかいって。
0524名無しさん＠お腹いっぱい。
2009/06/15(月) 15:17:30俺は一言もAMDの話題を出してないんだが、レスの内容がすべてAMDに関すること
になってるぞ。
0525名無しさん＠お腹いっぱい。
2009/06/15(月) 15:21:05製造プロセスの問題だったんなら、やめなきゃよかったな、バカだな、Intelはww
0526名無しさん＠お腹いっぱい。
2009/06/15(月) 15:24:51そりゃAMD信者のプロパガンダが酷いって話だからな。
Pentium4は消費電流が増えるとコア電圧が下がる仕様なんだわ。
だから最大電圧と最大消費電流をかけ算するのは間違ってるんだ。
しかも実際のピーク消費電力は、
AMDはTDPに近い値だが、IntelはTDPよりも10Wくらい小さな値だった。
しかし、AMDのCPUの消費電力の大きさは批判されることは少なく、
IntelのPentium4のアーキテクチャが消費電力が大きいと騒いでたのよ。
0527名無しさん＠お腹いっぱい。
2009/06/15(月) 15:27:07AMD信者の大合唱が、各国で行われてな・・・
0528名無しさん＠お腹いっぱい。
2009/06/15(月) 15:31:10Intelが NetBurstやめたのは AMDのせいなのかwww
Intelが書いてることよく読んだ方がいいぞ?
周りをよく見ないとポッツーーン取り残されてたりして気の毒ww
0529名無しさん＠お腹いっぱい。
2009/06/15(月) 15:34:03だからAMDを批判したいなら他でやれ。俺はNetBurstの設計思想を問題視しただけだ。
あまり信者だプロパガンダだ言ってると胡散臭く聞こえるぞ。
0530名無しさん＠お腹いっぱい。
2009/06/15(月) 15:36:00Intel支持の主流派に相手にしてもらえないんでしょう、こんなとこで
想いをぶちまけるのはww
多分高額はたいて Pen-4買っちゃったんだろーなーkk
0531名無しさん＠お腹いっぱい。
2009/06/15(月) 15:43:50NetBurstよりも、もっと良いものを得たからだろう。
>>529
NetBurstの設計思想のどこが、どのように問題なの?
当時必要とされていた、
シングルスレッドのMPEG2エンコーダでリアルタイムにD1解像度をエンコードする
っていう目的には、最適なアーキテクチャだったと思うのだが。
>>530
お前みたいなガキの思考で他人を測るな。
0532名無しさん＠お腹いっぱい。
2009/06/15(月) 15:52:40> NetBurstの設計思想のどこが、どのように問題なの?
> 当時必要とされていた、
ぎゃはははっははは
> シングルスレッドのMPEG2エンコーダでリアルタイムにD1解像度をエンコードする
> っていう目的
げははははっははははっはー
その「目的」を仮定しない場合、性能がわるかったからだろ。
そういう「目的」をデッチ上げる行為を手前味噌とか我田引水とか言うんだけど
知らないのか?
で、今 Intelはそんなこと言ってるか? もう「エンコード目的」は終了しちゃったの?
> お前みたいなガキの思考で他人を測るな。
よくそんなことが言えるもんだ。どんな顔してんのか覗いてみたいわww
0533名無しさん＠お腹いっぱい。
2009/06/15(月) 16:07:10> NetBurstの設計思想のどこが、どのように問題なの?
>>522で書いた通りだ。その手法が立ち行かなくなっていくつか製品をキャンセル
する羽目になり、NetBurstマイクロアーキテクチャ自体消えたわけだからな。
> 当時必要とされていた、
> シングルスレッドのMPEG2エンコーダでリアルタイムにD1解像度をエンコードする
> っていう目的には、最適なアーキテクチャだったと思うのだが。
これ当時のIntelの宣伝そのままだろ。いい加減にしてくれ。
0534名無しさん＠お腹いっぱい。
2009/06/15(月) 16:13:15今はそんなことないけどさ
0535名無しさん＠お腹いっぱい。
2009/06/15(月) 16:21:32あたり、やっぱり単なるIntel厨なんだなww
0536名無しさん＠お腹いっぱい。
2009/06/15(月) 16:33:090537名無しさん＠お腹いっぱい。
2009/06/15(月) 16:35:00ほとんどの用途で性能出てないのに、「動画エンコード」とか持ち出して
クロックブームに便乗してたんだからな。もちろん、社員みんなわかってて
邁進してたわけで。無知なユーザーに対するいちぢるしい背信行為だわな。
無知なユーザーは、悪くないわな。知識があるのに目をつむった連中は、
どうかなww?
Pen-Mやってた連中がいたにしても、あれだけのヘマやったら Intel以外なら
一巻の終りなんだがな。
0538名無しさん＠お腹いっぱい。
2009/06/15(月) 16:52:58Sunの「用途」って、そもそも何なの？
そして、「そのための性能」は十分にあったの？
0539名無しさん＠お腹いっぱい。
2009/06/15(月) 16:54:50キミには理解無理。
0540名無しさん＠お腹いっぱい。
2009/06/15(月) 16:55:39全くだ。NetBurstはmarchitecture（マーケティング用のアーキテクチャ）と
揶揄された位だからな。低IPCなのを無視して高クロック＝高性能という
嘘を一般大衆に浸透させようとしたのは他ならぬIntel。
0541名無しさん＠お腹いっぱい。
2009/06/15(月) 17:15:31説明する知識も無く、日本語も不自由な奴は黙ってなさいw
0542名無しさん＠お腹いっぱい。
2009/06/15(月) 17:17:30>嘘を一般大衆に浸透させようとしたのは他ならぬIntel
後にIntel自身がその呪縛に苦しんだのは、あまりに皮肉だよなw
0543名無しさん＠お腹いっぱい。
2009/06/15(月) 17:28:01だからさー、正当派 Intel支持者のいるとこでやれよー。
ここは Sunの話するとこなんだよ。
Intelはマルチコアに舵切って以来、おどろくほど Sunと同じこと言ってるから、
よく調べな。シングルスレッド性能を主張するのはむしろ AMD。
知識も間違ってるが顔出す場所も間違ってる。あんた大間違い。
0544名無しさん＠お腹いっぱい。
2009/06/15(月) 17:31:150545531
2009/06/15(月) 18:23:32>>532
当時の状況を経験していないのなら、人の話は素直に聞けよ。
>>533
もし製造プロセスに問題がなければ、消費電力は抑えられ、クロックはもっと上がっていたと思う。
Pentium4の180nmから130nmへの移行では、同一クロックでは劇的に消費電力が減って、
同じ消費電力では劇的にクロックが上がったでしょう?
もし、それと同じことが90nmへの移行でも実現していれば、かなり違った結果になっていたと思うよ。
とはいえ、MPEG2のハードウェア・エンコーダが安価になってくると、CPUへの要求も変ってくるし、
ましてや、マルチコア時代にもなれば、取るべきアプローチも変ってくるのは当然のことで、
ある時点での最適解が、別の時点ではそうではなかったからといって、ある時点でも間違っていた
というのは、ちょっとナンセンスだと思いますよ。
> これ当時のIntelの宣伝そのままだろ。いい加減にしてくれ。
当時のIntelの主張は妥当だと思うよ。
ワープロや表計算は十分な速度が得られているが、メディア処理はまだまだ不十分。
ゆえに、メディア処理とくにMPEG2エンコードがリアルタイムで可能かどうかの境界線を越えるために、
偏ったパフォーマンスのアーキテクチャにする、っていう設計方針を説明したものでしょ、宣伝は。
ベンチマーク好きなマニア層は、全方位で性能向上が得られないと、気がすまないようで酷評してたが。
インテルは、彼らの発言の影響が一般人にどのように及ぶのか、軽視していたようだ。
0546名無しさん＠お腹いっぱい。
2009/06/15(月) 18:29:53Pentium4を失敗・・・当時を経験していれば、そんな断言はできないと思う。
まぁAMD信者とか、彼らの言動で眼が曇ったら、また、話は別か。
>>537
その、ほとんどの用途では、すでに性能が足りてたんですよ。
事実、Pentium4が主流になってからも、Pentium3愛好家の人たちがいて、
彼らは 「Pentium3で十分」 と言ってたんですよ。
>>540
速度が求められていた処理では、Pentium4はPentium3とIPCが同程度でしたよ。
2GHzのPentium4が、1GHzのPentium3のキッチリ2倍の速度が出ていましたからね。
それでも、クロックが性能を示していない、とでも?
0547名無しさん＠お腹いっぱい。
2009/06/15(月) 18:32:09Intelが130WのTDP上限を反省して方針転換した後に、
AMDが130WのTDPのCPUをいくつも出しているんだよねー。
0548名無しさん＠お腹いっぱい。
2009/06/15(月) 18:34:380549名無しさん＠お腹いっぱい。
2009/06/15(月) 18:40:140550名無しさん＠お腹いっぱい。
2009/06/15(月) 18:41:26狂気の沙汰だと思ったよ3桁は。
ありえない、と。
0551名無しさん＠お腹いっぱい。
2009/06/15(月) 18:51:04> 製造プロセスに問題がなければ、消費電力は抑えられ、クロックはもっと上がっていた
製造プロセスの問題とは具体的に何だ？解決可能な問題なら、わざわざNetBurstを
葬り去る必要は無かったはずだが。
> 当時のIntelの主張は妥当だと思うよ。
だからどれだけの一般人がMPEG2のエンコードをしたがってたんだよ。そもそもそんな
需要が無かったじゃないか。マーケティングのためにCPU-boundな処理を必要としていて
それがたまたま動画のエンコードだっただけ。
HPC分野で言えば、Pentium3やOpteronと比べて最適化の方針が変わるのが問題視されて
NetBurstのXeonは嫌われてたんだよ。
0552名無しさん＠お腹いっぱい。
2009/06/15(月) 18:53:04知ってねーわけねーだろここに居るのは SPARCstation2がどうのって連中だぞ?
それと_今現在_ NetBurstがないのはプロセスの問題じゃないことを
如実に表してるだろが。どんな女々しい言い訳並べんねん。
でさ、ここそういう話するとこじゃねーんだよとっとと出てけよ。来るな、しっしっ!!
0553名無しさん＠お腹いっぱい。
2009/06/15(月) 18:53:590554名無しさん＠お腹いっぱい。
2009/06/15(月) 18:58:24> 速度が求められていた処理では、Pentium4はPentium3とIPCが同程度でしたよ。
何の処理で実際にPentium3と同等のIPCだったのか具体例を出してくれ。
必死にSSE3のintrinsicを手で埋め込んで最適化してやっと出たんじゃないのか？
0555名無しさん＠お腹いっぱい。
2009/06/15(月) 19:00:13> 2GHzのPentium4が、1GHzのPentium3のキッチリ2倍の速度が出ていましたからね。
> それでも、クロックが性能を示していない、とでも?
ウソこけ。1.5倍程度のクロック数で同程度か、もしくはそれ以下だったよ。
0556名無しさん＠お腹いっぱい。
2009/06/15(月) 19:07:05世間のパソコンユーザーも毎日動画エンコードしてると思ってたんだろ。
キショいなw
0557名無しさん＠お腹いっぱい。
2009/06/15(月) 19:12:01フリしてるだけかな?
0558名無しさん＠お腹いっぱい。
2009/06/15(月) 19:17:150559名無しさん＠お腹いっぱい。
2009/06/15(月) 19:22:560560名無しさん＠お腹いっぱい。
2009/06/15(月) 19:31:450561名無しさん＠お腹いっぱい。
2009/06/15(月) 19:41:240562名無しさん＠お腹いっぱい。
2009/06/15(月) 19:42:55それ以上に Intelにヘコヘコお追従うれしがってるやつってキショ過ぎ
0563名無しさん＠お腹いっぱい。
2009/06/15(月) 20:07:54話し相手を求めてここに来てるんじゃないかな
煽ればレスして貰えるからね
0564名無しさん＠お腹いっぱい。
2009/06/15(月) 20:43:590565名無しさん＠お腹いっぱい。
2009/06/15(月) 20:51:090566546
2009/06/15(月) 20:58:19> 製造プロセスの問題とは具体的に何だ？
リーク電流
> 解決可能な問題なら、わざわざNetBurstを葬り去る必要は無かったはずだが。
時が進めば状況も変り、ゆえに最適解も変るわけで、
NetBurstよりも、より良い選択肢に乗り換えたのだろう。
SIMD命令を上手に使えるコンパイラが出てくれば、
クロックを高めるよりは演算ユニットの幅を広げるほうがいいし、
ソフトウェアがマルチスレッド化されていけば、
シングルコアの性能を高めるよりは、複数のコアを詰め込んだほうがいい。
> だからどれだけの一般人がMPEG2のエンコードをしたがってたんだよ。
当時、一般人には、「テレパソ」などというケッタイな略称が広まっていた時期だったと思う。
> HPC分野で言えば、
一般人の話なのに、HPCですか・・・
>>552
時代は流れて移り変わるものですから、いまNetBurstがないからといって、当時それが間違っていたとは言えない。
昔のSPARCに固執してはいけないですよ。Sunがx86サーバを売るようになってから、久しいですしね。
>>554
MPEG2エンコードと暗号処理だよ。
SSE2命令をintrinsicで使ったが「必死」なんて大げさなことはしてない。
ごくふつーに演算の流れ通りに書いて、あとはコンパイラの最適化任せ。
0567名無しさん＠お腹いっぱい。
2009/06/15(月) 21:02:59それは、Pentium3でも十分なアプリの速度じゃありませんか?
>>556
Pentium4のNorthwoodなら、事務仕事で使ってる間は、消費電力は低かったですよ。
一方、AthlonXPだと、事務仕事で使っていても、爆熱・大消費電力でしたね。
>>564
ずいぶん昔の話ですが、空冷だっていう話を読みましたよ。
空冷でも行ける、十分な信頼性が得られる! 画期的な冷却ソリューションを開発した!
とかいうのを、読みましたよ。
0568名無しさん＠お腹いっぱい。
2009/06/15(月) 21:32:01http://www.4gamer.net/games/065/G006503/20090610054/
Piednoel氏「Sandy Bridge世代では，シングルスレッドの性能を向上させる」
0569名無しさん＠お腹いっぱい。
2009/06/15(月) 21:47:170570名無しさん＠お腹いっぱい。
2009/06/15(月) 21:47:20SIMD命令のベクトル長が倍になるか、演算器が倍になるんじゃね?
0571名無しさん＠お腹いっぱい。
2009/06/15(月) 21:56:17> Sun SPARC Enterprise サーバでCOOLに行こう（=移行）！
なんつー駄洒落だ。
■ このスレッドは過去ログ倉庫に格納されています