また重複か。
γ γ ∧__∧ もうダメポ・・・ γ (::::::::::: ) ................................... .(○::::::: ) .::::::::;;;;;;;;;::::........ ~"''"""゛"゛""''・、 ...:::;;;'' ';;;:::::....... "゛""''""""゛゛""''' "j' ...::::;;;'' '';;;::::::........ ::::ヘ :::::....ヽ :::;;;ノ ::( ....::::::;; '';;;::::::....... : ゝ :::::......ノ:;;../ ~~^^~~~~~^^~^^ ~~^^ ~~~~~^~~~~^
支持!
SPARCさえ使っておけば多い日も安心。 こうですか?わかりません!
12 :
名無しさん@お腹いっぱい。 :2009/06/06(土) 23:24:11
HPにはプリンタがある! Sun+Oracleなんて恐くないやい
13 :
名無しさん@お腹いっぱい。 :2009/06/07(日) 02:15:31
OracleがSunを買収した事により、コア係数は変更になるだろうな。 Itaniumのみ0.5だったが、これからはSPARCの係数が低くなると 思われる。 特にT2/T2+の係数が0.25以下になれば、影響は大きい。
14 :
名無しさん@お腹いっぱい。 :2009/06/07(日) 02:21:37
そうかなあ おれはSun以外のベンダのサーバのコア係数を上げると思うよ 既にPOWER6が0.75->1になってるよね ドル箱のSPARCのコア数を下げたら大損だろう あのおっさんがそんなことを許すわけがない まあRockは0.25にしてやってもいいかぐらいは思っている んじゃないかと
富士通に将来のSPARCの開発を支援して欲しいと言っているのだから その程度の手土産は希望してもいいだろう
どうなることやら
>>12 HPのプリンタの大半はキヤノンが作ってるよ
18 :
名無しさん@お腹いっぱい。 :2009/06/07(日) 13:52:52
>>14 そうすっと、Itaniumも0.5→1かな?
Itaサポートのゆくすえについてですか?wwww
Itaniumって、そんなに酸っぱい葡萄なの?
低脳がスレ立てるの禁止できないのか? 下品なタイトルのは即削除してほしいな。
>>21 一応は向こうが先に立っているのを、スレ住人の総意で無視してるだけ
だから即削除ってのは穏やかじゃない。
過去にもSunスレで強引にItaniumがらみのタイトルをつけたスレが無視
されつつも存在だけは長期間残留し続けたりした。
>>21 ガキじゃないんだから、削除して欲しいと思うのなら、削除依頼してこいよ、自分で。
俺は放置すればいいと思ってるから、削除依頼しないでいいと思うが。
「スレ住人の総意で無視」されてるのなんか存在する必要ねーだろ。消えろ消えろw
空気のよくなる話題をふればいいじゃん、自分で。そんだけのことだろ?
下品スレ立てた低脳はいっさい気の効いた話題をふれないけどなwwwwwwwwwwwwwwwww
だらかといって
>>28 がスレを荒らしてよい理由には、ならんな。
自分よりも下等な人間がいるからといって自分が堕落することを許すのは人としてどうかと思う。
だからといって
>>29 ..
空気のよくなる気の効いた話題をすればいいんだよ、今すぐ。
>>29 書かずにさ。
メタやってる限りあんたもおんなじ。
というか、自演だろ? 低脳くんw
Oracle NetBookは省電力な OpenSPARCと OpenSolarisの上に Androidの皮、だなたぶん。
あっ.. Androidじゃなくて、JavaFXか? 独自性強くなっちゃうけど..
Snapdragonの上でJavaを動かします
AndroidのLinuxをSolarisに置き換えるわけか
>>36 今 MIPSなんて特定用途向けでやってるとこはそんな潤沢なリソースはないわけで、
ざばざばリソース使える x86がいかにマルチコア作りにくいか証明してるね。
>>37 それの後継製品だよ。
16コア500MHzから32コア1.5GHzに強化されたの。
>>38 x86のコアが大きいのは、それだけ機能が豊富だから、なんだよ。
そのMIPS64と同じ程度、
つまり、2issueでin-orderで、SIMD命令なしの、特定機能専用ブロック付くらいなら、
32コアを集積して1.5GHz動作させるくらい、なんとか、なるだろう。
ていうか、Larrabeeは2issueでin-orderで、SIMD命令ありで、
32コアとか48コアとか言ってるんですよ。
>>39 > x86のコアが大きいのは、それだけ機能が豊富だから、なんだよ。
ああ、もうない方がいいのに互換性のために必要な機能、だろ?
> 32コアを集積して1.5GHz動作させるくらい、なんとか、なるだろう。
なんでそうしないで
> ていうか、Larrabeeは2issueでin-orderで、SIMD命令ありで、
> 32コアとか48コアとか言ってるんですよ。
とかいうわけわからん使う気もないもん作るの? 並行して作れないの?
>>40 > ああ、もうない方がいいのに互換性のために必要な機能、だろ?
違う。
out-of-order実行、多issue、たくさんの実行ユニット、レジスタリネーミング、
SIMD命令、高速で倍精度のFPU、高速な乗除算、高クロックのための深いパイプライン・・・etc・・・
こういった、RISCの末裔たちにも共通な機能が、トランジスタを食うのですよ。
> なんでそうしないで
現状でx86を使っている多くのアプリケーションでは、
たとえ1コアから32コアまでリニアにスケールしたとしても、
効率が良くないからだろう。
じゃぁなんで組み込み用でMIPSを32コアも集積した製品があるのかというと、
組み込み用途では、コードおよびデータのローカリティが高いので、
コアあたりのキャッシュが小さくても破綻しないのよ。
>>41 お、近づいてきたぞw
> こういった、RISCの末裔たちにも共通な機能が、トランジスタを食うのですよ。
ほんとの RISCの末裔たちにもそれあるじゃん。MIPSにもさ。で、なんで x86には
できないの?
> たとえ1コアから32コアまでリニアにスケールしたとしても、
> 効率が良くないからだろう。
おー、まさに。OS含めたソフトウェアの作りが古典的だから、そういうことだな。
> 組み込み用途では、コードおよびデータのローカリティが高いので、
> コアあたりのキャッシュが小さくても破綻しないのよ。
あれ? んじゃ、Atomも同じ構成にした方がいいじゃん。
>>42 > ほんとの RISCの末裔たちにもそれあるじゃん。MIPSにもさ。で、なんで x86には
> できないの?
RISCの末裔たちで、それらのトランジスタを食う機能を満載したものは、x86と同程度のコア数だね。
> そのMIPS64と同じ程度、
> つまり、2issueでin-orderで、SIMD命令なしの、特定機能専用ブロック付くらいなら、
> 32コアを集積して1.5GHz動作させるくらい、なんとか、なるだろう。
ってのが読めていれば、そんな疑問は出てこないと思うんだがなぁ。
いつものビョーキなので仕方ない
>>42 >> たとえ1コアから32コアまでリニアにスケールしたとしても、
>> 効率が良くないからだろう。
> おー、まさに。OS含めたソフトウェアの作りが古典的だから、そういうことだな。
古典的とか、そういうことではなく、ワーキングセットの大きさが違うのよ。
同じキャッシュサイズで、コア数を1から32に増やすと、コアあたりのキャッシュサイズは1/32になっちまう。
> あれ? んじゃ、Atomも同じ構成にした方がいいじゃん。
Atomがターゲットにしているアプリは、ワーキングセットが大きいから。
>>43 そんな話してるんだっけか? また途中でねじ曲げてるなぁ...
> RISCの末裔たちで、それらのトランジスタを食う機能を満載したものは、x86と同程度のコア数だね。
それだとぜんぜん >38を否定したことにはならないんだが。
x86じゃやっぱり作れないんじゃん。
> ってのが読めていれば、そんな疑問は出てこないと思うんだがなぁ。
なぜそれを商品で出さないのか、と聞いてる。
なぜ、Larrabeeみたいな申し訳程度のもんを見せる必要があるの?
>>45 > Atomがターゲットにしているアプリは、ワーキングセットが大きいから。
なるほどね。組込みは組込みでも、ワーキングセットが大きいものだけを
ターゲットとしている。...それ、RISCだと、新規にコア起こしたりしないよね。
既存のものを流用する。
そういやSunはNiagaraを組み込み向けに外販するって息巻いてたけど、 組み込み用OSでSPARCをサポートしているのは、増えたのかな。 ちなみにWind RiverがIntelに買収されちまったよ。
>>48 だから何?
SPARCだって組み込み向けにはSPARCliteっていう別のコアを作ったじゃないか。
やっぱ作れないんだな。作れてもクズが出てくるww
>>50 SPARCliteはワーキングセット大きいの想定してないと思うよ。MMUないしね。
>>48 > それ、RISCだと、新規にコア起こしたりしないよね。既存のものを流用する。
たとえば?
俺の知ってる組み込み向けRISCは、ワークステーションなどで使われているのとはコアが別だぞ。
クロックを止められるようになっていたり、省電力のために数々の変更が加えられていたりするぞ。
SPARCで組み込みなんて流行らないよなぁ 信者はごく一部の例外的な事例を持ち出すけどさ。 組み込み向けOS各社の製品がSPARCをサポートしてない。
マルチコアってのは自慢にならんのだよ。 シングルコアで性能が延びなくなったので、苦肉の策で転進する先だからな。 x86のマルチコアの性能がスケールしにくいのは、 それだけコア単体の性能が高いってことなんだよ。
4GB/sの帯域幅のメモリがあった場合、 2GB/sの帯域幅を必要とする高性能コアなら、2コアまで、それ以上はスケールしない 0.5GBの帯域幅を必要とする低性能コアなら、8コアまで、それ以上はスケールしない コアの性能が低いことを忘れて、 2コアまでしかスケールしないものよりも8コアまでスケールするもののほうが優れている というのは、ちょっとねぇ。
>>56 > x86のマルチコアの性能がスケールしにくいのは、
そうそう、そこは認めるわけね。
>>57 > 2コアまでしかスケールしないものよりも8コアまでスケールするもののほうが優れている
そんなこと言ってないが..www
そうなのか? 2コアまでしかスケールしないのかよカワイソー知らんかった..w.w.w
>>54 どういう意味なんか知らんが、>57 みたいなやつのこと? あ、同じ人? こりゃしつれーwwww
>>57 SPARC64 IVが大幅にIntel CPUに比べて劣っているとは考えらえないんですが?
>>55 > 組み込み向けOS各社の製品がSPARCをサポートしてない。
無知のご披露もほどほどで。
現行製品でおながいします
>>60 そういうツッコミは小学生でもできるよね。
何も知らなくても、とりあえず言ってみることはできる。
>>58 話を部分的に切り取るなよ。
>>59 SPARC64 VIは2スレッド2コア、
VIIは2スレッド4コア、ただしL1キャッシュはVIの半分、L2キャッシュは据え置き
これってx86よりもコア数が多いとは・・・言えないよね。
>>62 そういうツッコミは小学生でもできるよね。
何も知らなくても、とりあえず言ってみることはできる。
いや〜、今日は収穫があったよ。はじまって以来だね。 『x86のマルチコアはスケールしない。』 本日の合意w
敢えて書かなければ気が済まないほど追い詰められたか。南無。
>>65 石原都知事の発言を途中でぶった切った某放送局のような馬鹿な真似はよせ
組み込みで、 ARMではなくSPARCを使うべき理由って何? MIPSではなくSPARCを使うべき理由って何? x86ではなくSPARCを使うべき理由って何? ついでに、SunRayのクライアントが、SPARCを使っていないのは、なぜ? SPARC信者よ、答えられるか?
>>68 x86については、ある程度低消費電力な品目はないから、移植性の低いクソ
プラットフォームをサポートする必要がなければ論外だろ。
RISC群では、PowerPCや SH含めて、都合のいい品目があるかないかだけの問題。
たいした違いはない。
同じシリーズの機器でも途中平気でアーキが変わるのはそのため。茶飯事。
そもそも開発・稼働環境がマルチプラットフォームなのが常識だから、
互換性縛りみたいな虚構は某環境とは違って存在してない。
> SPARC信者よ、答えられるか?
あ、別に SPARC信者じゃないけど。
>>69 ならばx86で都合のいい品目があれば、x86でもいいんだな。
ていうかSPARCで都合のいい品目がないのか。
なぜ?
バークレーRISCがプリンターエンジンに向いてるの証明したのが AMD Am29kと Intel i960ね。それと SPARClite。
プリンターも現行品でお願いします。
>>70 リソースが足りないから。
Sunや Fが芽を摘んだ、あるいはフォローが足りなかった、という可能性はあるかも。
その点、Intelは以前から組込みやる気満々だけど、うまくいかんなw
Atomはまだうまくまとめた方だけど、とっとと NetBook用になって廉価版と
競合しちゃってるしww まあ x86である程度以下の消費電力はムリなんだな。
XScaleもうまく扱えなかったし、i960やめなきゃよかったのにーww
>>63 コアの話なんてしてないんですけど
システムとして現行のIntel CPUで64CPU(256コア)程度までスケールする製品は、ありますか?
Altixシリーズにのってるのとか
えっと、次はエンプラとかの話に行くんでしたっけ?
>>76 Intel CPUは単体でも動くンか?糞が
>>73 > リソースが足りないから。
ARMやMIPSって、本家よりも、サードパーティが熱心に開発したよね。
なんでサードパーティは組み込み向けにSPARCを開発しなかったんだろうね。
> その点、Intelは以前から組込みやる気満々だけど、うまくいかんなw
Intelは組み込みを、一度は捨てんたんだよ。
8048、8052というベストセラーもあるし、
8086&88や80186&188も良く使われた。
NECのV30やその派生製品群も良く使われた。
Intelは486GXまでは組み込み向けをやっていたが、
セカンドソースをやめ、互換CPUを締めつけるにつれ、
組み込みからも手を引いていった。
そして再び、組み込みに戻ってきた。
VIAが低消費電力の組み込み向けx86 CPUで市場を開拓したから、
その後を進んでる。
>>77 >
>>232 >ブラザーの現行製品では5年前に発売されたHL-6050DNだけ
>それ以降はMIPS系だし最近のローエンドではARMが載ってる
>製品仕様を確認してから書けよクズ
>>74 お前、36から読み直せ。
それとも、わかっていてワザと話題を逸らしにかかってるのかな。
>>77 お得意の、例外的な事例ですな。
>>76 ああ、エンプラの話はしないでください
Intel CPUはエンプラで使えないですからという話か
それを泣きが入っているというのだがw
合意2『x86はエンプラで使えない。』
で、お次はNehalem EXとやらの話か?w
どーせユダヤ系IBMの工作員だろSun/SPARCスレを荒らすのは ハエのようにタカってくるから直ぐにわかる Powerを出すとすぐにばれるからなw
>>79 > なんでサードパーティは組み込み向けにSPARCを開発しなかったんだろうね。
それは知らんだけ。国際スパークとか、以前の資料調べれば、SPARC作った
会社はいっぱいあるのがわかる。
> 8048、8052というベストセラーもあるし、
> 8086&88や80186&188も良く使われた。
> NECのV30やその派生製品群も良く使われた。
今度は極端に遡るな.. i960の話だしてるのにさ。
> Intelは486GXまでは組み込み向けをやっていたが、
> セカンドソースをやめ、互換CPUを締めつけるにつれ、
> 組み込みからも手を引いていった。
だから i960は? XScale(StrongARM)は?
> VIAが低消費電力の組み込み向けx86 CPUで市場を開拓したから、
今の話と、「x86にしては比較的低電力」を混ぜるなよ。全然違うんだから。
>>82 Intelはどんな場合も冷静沈着で無表情な感じさえするが、
あんたはテンパりまくりだなwwwwww
>>82 Sunの主戦場のエンプラで、x86に大幅に侵蝕されて涙目なのにな。
>>83 はいはい、話題逸らし。
スレを荒らして誤魔化そうとしているのは、お前だ。
えっと、気合い入った RISCなみの省電力 x86は作れることは作れるんですが... ..80186互換でいいですか?
>>84 > それは知らんだけ。国際スパークとか、以前の資料調べれば、SPARC作った
> 会社はいっぱいあるのがわかる。
そんな昔の話なら、8080やZ80、8086を作った会社のほうが多いかもしれん。
> 今度は極端に遡るな.. i960の話だしてるのにさ。
相手の話をちゃんと読んでる?
Intelが組み込みを捨てた理由と、再参入の理由の話してるんだよ。
ARMやMIPSが組み込みでメジャーなのは、IPコアとして使えるとか、
いざとなれば自分たちで設計したものを使えるからなんだよ。
x86がメジャーではないのは、完成品のチップしか使えないから。
Intelが組み込みを捨てて、互換CPU封じを選んだからよ。
ところが、完成品のチップでも済むようになりつつあるので、
組み込みのパフォーマンスの上のほうからシェアを広げようとしてるの。
> だから i960は? XScale(StrongARM)は?
i960は失敗したプロジェクトの残したものを再利用したもので、
組み込み向けに使われるようになった時点で、もう開発は打ち切られてる。
XScaleはDECとの裁判で手に入れたもので、Intelが自分から始めたプロジェクトじゃない。
>>84 > 今の話と、「x86にしては比較的低電力」を混ぜるなよ。全然違うんだから。
VIAの低消費電力のCPUは、他のアーキの組み込み向けの消費電力とも遜色ないけどなぁ。
>>87 茶化すなよ。
それにARMはRISCじゃねーぞ。
CISCにRISC的な工夫を施したものだ。
だから、コードサイズが小さく、低いクロックで高いパフォーマンスを得られるわけ。
RISCじゃ無理。
>>86 >x86に大幅に侵蝕されて涙目なのにな。
FUDはblogだけで漫遊しとけ
話題逸らしな〜w
図星突かれて痛いんだろ?w
Sun自体がx64サーバをプッシュしてるのに…
何いってんだ。 WebサーバといえばSun、 メールサーバといえばSun、 ていうかインターネットといえばSun、 ファイルサーバだってSun、 そういう黄金時代があったろ。 そこから、どれだけx86に侵蝕されたのか、反省しろよ。
>>88 ま〜しかし、よくそんだけ「ねじ曲げ」られるねぇ話題を。感心するわ。
> そんな昔の話なら、8080やZ80、8086を作った会社のほうが多いかもしれん。
知らんがな。SPARC作るとこが少ないってあったから、そんなことないって
言っただけ。Intelのがどうとか、知ったことか。
> Intelが組み込みを捨てた理由と、再参入の理由の話してるんだよ。
知らんちゅーねん。アホか。
> i960は失敗したプロジェクトの残したものを再利用したもので、
> 組み込み向けに使われるようになった時点で、もう開発は打ち切られてる。
>
> XScaleはDECとの裁判で手に入れたもので、Intelが自分から始めたプロジェクトじゃない。
なんの言い訳なんだか。たいがいにしてくれるか?
反省も何も、客がSunでまとめるだけのカネがなくなっただけじゃん サポートだって中国で手抜いてるDELLみたいなのやシマンテックみたいな扱いだと 切れてたんだろ? カネは出さずに口を出す 一番下品なやつだな
まあ、個人的にはNehalem EXを採用したSunのサーバが今から楽しみです
>>93 x86? 別に要らんけど。ぜんぶ消えてもなんの問題もないが。
肝心なとこには使われてないもんなww
>>97 楽しみだねぇ。
ところで、x86の現行機種でいいんだが、リニアスケール自慢の記事は、ないもんかね?
ねぇよ。ねぇ
8ソケット機は出すのかなあ
えっ? なんで、出さないの?
自社ではチップセットを開発できないんだろ もういいから
Nehalem EXの真の実力を引き出せるのはSolarisだけ! とかなったらいいよね
知らんがな
現行最新の x86の、真の実力は、どうやって引き出せばいいの?
>>102 SPARCが売れなくなったら困るとか言って出さない可能性はあるんじゃね?
>>103 8ソケットまではチップセットというかノードコントローラはいらないよ
真の実力は、出ません。
>>106 WindowsとかLinuxでいんじゃね?
スケール(笑)しないんでしょ?
結局出ないのが、「真の」実力。仮の実力で我慢してください。
うんうん、そうだねw
まあ、Sandy Bridgeが出る頃にはSPARC終了だろうな
Windows+Nehalem EXでいいじゃん 転んでも泣かない
エリソンが NetBook出す、って言ってんだから、それに全力投球、だろう。
Sandy Bridgeねw エンコが速くなりましたってかwww
UNIX板でエンコとか
ぢゃあSandy BridgeでAVX以外の何が売りなのよ
またぞろ「コンパイラががんばる」って話なんだよなぁ。懲りんねぇ..
GPU統合とかw エンプラに全然関係ねぇw それでSPARC終了とかwww
相変わらずループしてんな
>>118 絶対に懲りんよw
Tick Tockモデルで振り回される客悲惨w
というかそういうアフォ客(カモ)しか相手にしてないわけだが
>>119 いやいや、エンプラな問題も分解してベクトルに展開してだな...
がんばっちゃうぞ、コンパイラーw
>>94 ねじ曲げてるのは、そっちなんだがなぁ・・・
>>122 それは凄い
Intelのお手並み拝見だなw
痛ニウムにだまされた客にも買ってもらえそうだwww
>>96 つまり、Sunにとっては莫大なシェアを失っても、もともと利益の出ない部分だから、痛くもかゆくもない、と。
>>121 それ考えると、Transmetaのコードモーフィングはまともだったよね。
資金繰り的に間に合わなかっただけで、ちゃんと最後には Efficeonで性能出てたから。
うは、ちょっとスレから目を離した間に、30レスも進んでる。 しかも、たった一人が自演してgdgdな雰囲気にしてるな。
頭のおかしいアンチx86が居るからな
散々脱線工作されたので、ここいらで話をまとめるぞ ・多マルチコアはSPARCよりもMIPSが先行している ・マルチコアはシングルスレッド性能に行き詰まっての苦肉の策で誇るようなものではない ・マルチコアで容易にスケールするのは、コア自体の性能が低いからである ・SPARCは組み込みでも採用例が少なく、ワークステーションでは終息、エンタープライズも下からx86に食われまくり
x86でマルチコアがスケールしないのは当然 コアが2倍になっても、メモリが2倍になってないから
>>129 そんなの全部否定されたぜ。どこ読んでたんだ。
今日のまとめは一点だけ。
>65
『x86のマルチコアはスケールしない。』
あわれ...w 『x86のマルチコアはスケールしない。』
>>128 頭がおかしいというか、頭がおかしいふりして煽ってるだけでしょ
x86で、リニアスケールする、って記事は、ないの? 現行機種でいいんだけど。
>>131 ほほう。
それぞれの項目が、どこで否定されたのか、示してもらおうか。
えー、今日のまとめは 『Nehalem EXの真の実力を引き出せるのはSolarisだけ!』 にしようよー
>>130 帯域幅は前のモデルに対して倍以上になってるじゃない
なんでそんなウソつくの?
今日のbot君は現行の使い方を覚えたみたいだな
>>136 「そんな、『真の実力』とかわけわからんこと言われてもなぁ...」(Solaris談)
>>139 レジストリ(笑)いじったり、秘密のAPI(笑)とかTweak(笑)があるんじゃないの?
じゃあ 『Nehalem EXの実力を引き出せるのはSolarisだけ!』 でいいよー
そんな出てもないものの話されても… IBMのFUDじゃないんだからさw
でも、RockよりNehalem EXの方が筋が良さそうじゃない
確かにPowerよりNehalem EXの方が筋がよさそうだよな COFF(笑)
ああ、Rock忘れてた
Power/AIXからNehalem EX/Solarisにリプレースした方がいいかもしれない 先のないAIXと違ってSolarisはオープンテクノロジだからな
DB2とAIXなんか捨ててさっさとOracle/Solarisに乗り換えようぜ
>>137 帯域幅なんて、どうでもいいんです。
大切なのはレイテンシ。
コアが倍になったら、
レイテンシを半分にするのは無理なので、
(独立した)メモリコントローラを倍にする必要がある。
Oracle(DBMSね)要るんかな... 合併して最初になくなるのは Oracle DBMSだったりして。
>>148 えっと、まともな SMPやってる会社はそんなことしてませんよ?
1990年代の問題ですね? そういう風に洗脳されてるんですか?
DB2はこの瞬間に消え去ってもいいけどOracleとMySQL/PostgreSQLは非常に困る
パチョコンのメモリコントローラはビット幅を増しただけで実質的にシングルチャネル。
>>150 なるほど、SunのNiagaraは、まともじゃないんだね。
144bit幅のメモリコントローラを4つも積んでるんだもんね。
おかしいよね。
>>152 だからマルチコアでスケールしないんですね、わかります。
「ほらみろ。おれのせいじゃねーじゃん(ぼそっ)」(Solaris談)
そんなこと言わないで 犬糞とは違うってことを見せつけておくれよ
Nehalem EX量産の暁には…
「じょーだんじゃねーよ、オレしかいねーだろーがよ、まともにチューニング 付き合えるのさ、外部にさらしちゃう前にちゃんと詰めをやれってんだよ。 オレぁやだぜ、こんなんは。Itaんときだってそうっだったろ、恥かくのは こっちなんだからな。やなこった。」(談)
Solarisタソ、がんがれ!
SolarisのIA64へのポーティングって、Mercedでやったんだろ? Mercedは、まぁ、あれだ、FSBが弱すぎたんだ、ありゃ。
Sunは技術に関しては先見の明があるな ピンチに陥ってもOracleに拾ってもらえたし、ある意味 データベースコア技術の獲得といえるかもしれない
AMDだっけ? シングルコア時代のOpteronに比べて、 今度の6コアOpteronは、 ソケットあたりの性能が15倍になったって 言ってるのは。 ソケットあたりの性能が6年で15倍ですよ。 それに対してメモリのレイテンシは殆ど変らず。 これでスケールするなら魔法だよ。
データベースコア技術は PostgreSQLのエンジニア、MySQLのエンジニア、 さらに他にもなんか買ってたっけ、たくさんいるんだからもーいらねーだろw
>>163 > これでスケールするなら魔法だよ。
『x86のマルチコアはスケールしない。』
-- 大・団・円 --
へえ。SMP的にはダメ CPUなんだ。
合併したら、会長と、社長は退社しちゃうの?
しちゃうんじゃね?
171 :
名無しさん@お腹いっぱい。 :2009/06/09(火) 23:41:34
そもそもSPARC自体がリニアにスケールなんてしてないがな。 x86は8コア以上は主流じゃないのでスケールの議論にそもそもなりにくい。 HPCを見る限りは別段悪いわけじゃない。 Niagaraもスケーラビリティ全然悪いし、なにしろシングルスレッド性能が低すぎる。
Niagaraはスジは悪くないけど、多数の負荷をかけないとスループットががた落ちになるのがなー ということで Web 関連ぐらいしか使い道が見いだせん
173 :
名無しさん@お腹いっぱい。 :2009/06/10(水) 00:23:24
>>164 三次元CGアプリとかならともかく
データベースなんてローテクはオープンソースで十分だよな
ショボすぎて笑える
>>171 かわいそうに。そう考えないと精神が安定しないんだね。
> ..、なにしろシングルスレッド性能が低すぎる。
x86の SMPがろくでもないのとはなんの関係もないね。
>>175 ローテクとまでは言わんがw プンソでも十分高度なことやってる。
>>178 おまえさ、
>>57 を読んでみ。
スケールするっていうのは、バスに対してコアの性能が低いことの裏返しなんだよ。
バス、って、コア間インターコネクトのことなのかな? それ、飽和してんじゃね? 他の方法考えた方がいいと思うよ? あれ? QPIは? ..ww
エリソン、x86機維持するのかな? 利幅薄いし、差別化むずかしいし、やめちゃうかもね。
>>180 >57 ってさ、インターコネクト等の工夫ではどうしようもない、そういう主旨だよな?
もうダメってことか、x86は。もちろん、SMP的には、だがw
残念だな。Nehalem-EX期待してたのに。ダメなんだ?
SPARC信者の言ってるx86ってのは、Pentium3くらいまでの事かもな。 Pentium3の高クロックのSMPはスケールしなかったね。 1CPUでさえメモリがボトルネックになる場合があったのに、そのまま同じバスに2CPUですよ。 相互関係が希薄な2つのスレッドでさえ、メモリアクセスが競合してパフォーマンスが低下した。 コードにもよるが自分の場合は、CPUを2個にしても速度が1.33倍だったな。 たぶん半分のクロックのCPUなら、もっと2倍に近かったんだろうな。
当時はmp3エンコード花盛りだったが、きっちり2倍出てたけどな。
>>186 がどういうタイプのジョブを投入した時のことを
言っているのかよくわからんが、
流石にmp3エンコードでスケールしないシステムは売ってないだろ。
CPUセントリックなジョブだから。
>>181 飽和するほど単体コアの性能が高いんですよ。
>>182 それ、SPARCとの比較じゃないな。
何度も同じURLをコピペすんなよ。
>>184 ちげーよ。
コアの性能に見合ったものがあれば良いってことさ。
>>187 mp3エンコードってキャッシュのヒット率が高いんじゃね?
あるいはCPUが遅かったか。
>>187 計算主体で OSの資源競合にあんまり関係ないタスクは、少々手抜きな作りでも
性能出るのよ。SPECrateしかり。HPC_だけ_得意なのはそう難しくない。
エンプラ向けはそうはいかん。
>>189 なんの反論にもなってねーよ....
>
>>181 > 飽和するほど単体コアの性能が高いんですよ。
じゃ、もうずっと飽和しとけや。
オレはいちおう QPIに少し期待してる。
エンプラ出ました
>>191 IntelとAMDどちらも、飽和対策を継続的にやってますんで。
きょうびSMPなんて流行んないんだよ とっくにCMPの時代に入ってる 1ソケットや2ソケットのサーバが主流だろ スケールアップは手抜き、スケールアウトしろ
>>195 コアインターコネクトが飽和してるのに CMPなら性能出るとでも? アホですか?
>>194 自演すんなよ。
ていうか、お前、読まずに貼ってるだろ。
そのURLのレポートは、NICがボトルネックだって書いてあるんだが。
>>197 あっはっはっは。NICがボトルネックだけど CPUによってコア数で頭打ちなんだ?
オカルトか?w
>>198 意味わかんねーのかよww これだからパソコンしか使ったことないやつはww
>>199 って恥ずかしくないの? 読んでないって指摘されてるのに、読まずに話を続けるのは。
そんなに殊勝な奴ならこんなにスレを消費しない
なんでGoogleのサーバは、SPARCじゃないんですか? インターネットのサーバといえばSunでSPARCというのは定番ですよね?
Google持ってる機種全部知ってんの? すごいね。
>>205 いいかげんにしろよ。1台でもSPARCがあれば、GoogleのサーバはSPARCである、ってか?
馬鹿みてぇ おれのパチョコンがx86だから全世界のコンピュータはx86であるべき、ってか?w
つうか、金融やってるからって銀行全部がユダ公IBMのメインフレーム使ってるわけじゃねーだろ? それとおんなじだよw
>>206 そうか、1台だけ SPARCなのか。よく知ってるな。
>>209 x86は 4コア以下の構成だけだろうな。なんせ頭打ちしちまうからw 飽和飽和!!
あっ、>194 のグラフに注目!!!
入れ食いだなx86野郎 おじさんたちに昼間から遊んでもらえて もっと喜べよ?w
スレをgdgdにして誤魔化すなよ、糞信者 Googleがx86を使っているって話は、もはや常識として知っていて当然の話だ。 電力効率が最も優れたものを選んだ結果、カスタムメイドのx86の2CPUマシン。
バーカ パチョコンー
つーかIBMのFUD野郎はスパコンにタカるハエだからSPARCが本命になったからこっちにも来るようになった 業務かなんか知らんが迷惑な話だ 頼むから黄色いブログでやってくれよw
>>211 うむ、SPARCは比較対象にも、なってないな。論外ってことだ。
>>214 そのパチョコンに駆逐されつつあるSPARC哀れ
>>194 はSPARCも比較対象にしたグラフ出せよ。
>>218 テメーで出せよ乞食の分際で頭がたけーんだよ
何で試せないの?そっちの方が分からんわ
試す価値もないわ。
そらIBMが頼めるわけないもんなw 惨めwww
>>213 へぇ〜、そりゃすごい。
で、Googleは何台マシンもっててそのうちの何台がその「カスタムメイドのx86の
2CPUマシン。」なの?
すごいね〜。2CPUでリニアな性能wwww
女にもモテないし自分のガキにも言えないよな お父さんの仕事はFUDですなんてなwww
>>224 Googleは数値を公表していないが、推定で40万台と言われるサーバ群の大半だろうな。
え? 大半て、何台? 20万台? あと残りは、何?
大半!、な。すごい数だな。で、SPARCは何台あるんだ? やっぱり 1台?
Powerは何台だよ? Itaniumは何台だよ? いちいち絡んでんじゃねーぞクソガキが しばくぞ
>>227 ほとんど全部だろうな。
残りが何かは、どうでもいいだろ。
SPARCは誤差のうち
Niagara3は、まだか? T2は80Wくらいだったと思うが、T2+になると120Wくらいに跳ね上がってしまうし、 AMBチップの消費電力がデカいFB-DIMMを使うT2シリーズは、もうダメぽ。
>>230 ,231
...なんだよ。知らねーのかよ? あてずっぽうかよww
>>229 > Powerは何台だよ?
> Itaniumは何台だよ?
何台なんだよ。なんだよ知らねーのかよ知らずに言ってんのかよカスかおまえは。
> しばくぞ
返り打ちじゃボケw
知るかボケ ネタを振ったのはテメーだろ テメーで収拾付けられないなら出てくんな つーか会ったらボコボコじゃテメーわ
ネタ振ったのは >204 だ テメー >204 じゃないんならすっこんどけこのスットコドッコイ >204 ならテメーのケツぬぐえ! しばきまわす。
あーあ、気が狂って4連投かよ
>>236 どうどう
そう熱くなるなってw
別人だ
今度酒飲みに行こうぜ
キムチ臭ぇ 在日だなwww
話題逸らし必死だな
結論は SPARC 信者はスケールするってことですね。
スケール(笑
ここは平日昼間に限り賑わうインターネッツですね
売れないから仕事が無くて暇なんだろ
245 :
名無しさん@お腹いっぱい。 :2009/06/10(水) 22:29:54
>>194 >SPARCだと 0.9や 0.85くらいの傾斜で直線で(でこそリニア)いくけどな。
それはスケールしやすいプログラムでの話な。
ちゃんと同一アプリでSPARCがスケールするかのソースを提示しなさい。
正直、ここのSPARC信者はコンピュータの性能を語れるレベルの知識に
30%も達してない。
追加で、OSはLinuxで。バージョンも揃えること。
>そのスレ、言っちゃ悪いがパット見駄レス比が高くて、開いて10秒で閉じた。 > >Sun・Sparcマヌアって、ITバブルの時のStarFireの売れッ振りと高級そうなイメーシに魅せられて >いまだ幻想と憧れを捨てられない人々なのだろうか、よーわからン。 まさに、このスレSPARC信者って"幻想と憧れ"で昔のイメージ引きずってるだけだよな。
そもそもリニアに近いスケールなんてプロクラムによっちゃどんなアーキテクチャのCPUでも 期待できるが、今の今までどんなプログラムでもスケールすると信じていたのだろうかw
250 :
名無しさん@TeraDrive :2009/06/10(水) 22:57:59
まあ確かに、SS20に20人くらいぶら下がって仕事しても どうともなかったのは、当時としては画期的だった。
最期の落日って変だよね。
SunとDECはとてもよく似てるね
>>246 あ派ハはハはハハハハハハ。Linuxじゃダメだよ、Solarisじゃないと。
しらじらしい。自信ないんならそう書けよぉww
>>249 それは違うぞ。計算(CPU消費)オリエンテッドなベンチマーク「のみ」しか
性能が出ないのが x86。SPECrateとかな。
カーネル管理資源競合をうまく調停できてリニアにスケールするのが
SPARC+Solaris。
古いとこでは DG-UX、Curt Schimmelが手を入れた IRIXとかがエンプラ対象で
スケールするシステムとして有名。
まぁ、意味わかれという方がムリだろうがな。知識レベル的にも、姿勢的にも。
>>254 でも、QPIで改善されるんだろ? ほんと楽しみだよなw
まぁこれも仕事でやってると思ってみれば、哀れというしかないよな。
>>252 大型のいいのが作れるようになったら、そっちの方が儲かるもんだから
どうしても薄利の商品には力が入らない、ってのは多少あったかも。
Ultra2まではまだ手抜き感はなかったけど、Ultra5以降はもうどんどん
PC化していくしかなかったから納得のいく製品にはならなかった、と。
けど、JavaStationや SunRayという方向へ展開もしたし、結構がんばってたとは
思うけど。
DECは結局 PCを作って、結構売れたんだけどダメだった。DELLみたいに
なって会社が残っても、彼らにとっては意味はなかったんじゃないかと。
DECも MIPSも PCも Multiaも NCもやったんだけどね。
>>254 ふむ。
x86 + Solaris だと、どうなるんだ?
>>256 「自演」じゃないよ。追記しただけ。ちょっと切口違うから、分けた方がいいだろ?
自演てのはな、別人のフリして書くやつだよ、誰かさんがよくやるだろ? 涙目でさww
見当違いなリンク何回も貼ってる低脳は何なの?
>>263 要約でも載せた方がいいんじゃない? 誰も信じないかもよ?w
信者のフリした英語もできないドザーだったのか。迷惑な。
>>262 じゃぁ同一人物の追記だって、わかるように書けよ。
>>264 NICがボトルネックの話だって書いてやっても、スルーされたんで、日本語で要約しても読まれないと思うぞ。
>>265 なんでそこでドザーが出てくるんだよ。
誤魔化し方が下手にも程がある。
あれ? 要約載せりゃいいのに。なんでやんないの? ...ひょっとして...wwwwww!w!w
269 :
名無しさん@お腹いっぱい。 :2009/06/11(木) 10:40:06
>>268 NICがボトルネック
これでOK
>>269 勝手にどうぞ
ていうか、英語を斜め読みできない人は、高卒以下?
XeonもNICがボトルネックなのか?w それはちと厳しいなwww
このスレのアンチx86(推定1名)はなんだか可哀相な奴だな
は?お前以外全員アンチx86だけど? つーか、お前誰?w
読まないどころではなく、読めないんだよ。 英語はおろか日本語もあやしい。
>>275 読めよも何も、それはヲレの出したURLだけど?
頭おかしいな
>>277 つまり、
グラフだけ見てスレに貼った、文章は読んでいない
ってことか。
文章も読めよ。
斜め読みでいいからさ。
夢見ガチな人なんだよ。Intelの言ってないことまで捻出するからね。かわいそーw
>>278 どこまでバカなのお前?
グダグダほざかずにさっさとx86でスケールする記事貼れば?
communities.intel.com
>>281 要約、NICがボトルネック。
解説、SPARCとの比較ではないので無意味
>>280 あれあれれ? SPARCの記事は「Sun関連以外で」とか言っといて、思いっきり
intel.com かよ、ひでえ二重基準ーーww ひきょーものープw
>>284 Opteron vs Xeonの記事としてはXeonがスケールしないってことじゃねぇか?w
>>280 よしっ、じゃあ、おじさん要約しちゃうぞw
UltraSPARC T2+ 4発と 128GBで 15万ドル
Xeon 7400 64GBで 3万 2千ドル
Xeonの方が安い!
以上
Intelがスケールするなんてそのintel.com(笑)の記事のどこを読んだら書いてあるのかな?w
290 :
名無しさん@お腹いっぱい。 :2009/06/11(木) 13:57:31
>>287 いや、あれは NICドライバーの飽和(back-null)とスケジューラーのせい(back-hdb)で、
『改良された OpenLDAPのせいではない』、と言ってる。
根拠は特に示してなく、憶測。
しかし、あんなテストをなんでネットワーク越しにやるかな。127.0.0.1向いて やればいいのに。
結局Xeonがスケールしない事実には変わりないねぇ
いや、きっとスケールするさ、きっと。ボクらが見つけられないだけなんだ。 たとえもしよしんばとりあえずそうだったとしても、もうすぐ QPIが出るよ、夢の QPIがw
だよな Intel凄いしパチョコン最強だもんな おれら情弱だからぐぐり切れてないだけだしな
NICドライバが悪いLinuxのスケジューラが悪い でもOpenLDAPとXeonは悪くないんです!!!
別に、intel.com(笑)の記事でもイイと思うんですよ?w Intel(笑)のことを一番よく知ってるのはIntel(笑)の中の人だろうしw スケールするかどうかすら書いてないのも、 ユーザには分からない何か深い理由があるんだろうwww
SPECjbbでええやん
>>295 OpenLDAPは悪くない。あいつはいいやつだ。Xeonが、悪い。
安価なCPUでシェアを得られるように努力せよ そして無学な民衆にXeonがスケールするかどうかや エンプラでなにが大切かを教えてはならない
>>283 と
>>285 URLしか読んでないんだな。
その先に何が書いてあるのか、読んで見ろヨ。
>>289 SPARC信者が英語を読めるかどうかのテストなんだわ。
いまのところ、読めてないようなレスが多いな。
ま、URLだけ見て鬼の首を取ったかのような言動しているので、
それ以前って感じだが。
>>291 127.0.0.1でいくら性能が出ても、ネットワーク越しで性能がでなければ、
LDAPサーバの構築・運用っていう観点では、あんまり意味がないと思う。
>>292 条件を書かずに、ただ「スケールする」「スケールしない」って言うのはナンセンスだよ。
客は価格しか見てないんです! バーゲン!バーゲン!大バーゲン! SPECJbb-2005でXeon 7400がUltraSPARCT2+に負けてもXeonが電気代では勝つる! あれ?SPARC64VIIとの比較は?w 負ける戦をしないのがIntelのいいところ 売れない製品ラインは即売却w バカにするのもほどほどにしたまえよw
>>301 > SPECJbb-2005でXeon 7400がUltraSPARCT2+に負けてもXeonが電気代では勝つる!
Sunが主張していたよな。
サーバの価格よりも電気代のほうが重要、だから、CoolThreadsサーバを使うべきだ、と。
そのSunの主張に従って判断したら、Xeonのほうが優れてる、ってことになったんだわ。
> あれ?SPARC64VIIとの比較は?w
> 負ける戦をしないのがIntelのいいところ
この言葉を引用しよう
The absence of a result certainly says something very clear to me - no story.
信者も何も、そのintel.comの一番下のコメントにすべて代弁してあるじゃん ちゃんとx86気違イのお仲間が書いた記事ならそこまで読もうよ
>>300 > URLしか読んでないんだな。
はぁ。URL指摘するのに、その先に何が書いてあるのか知ってないといかんの?
> SPARC信者が英語を読めるかどうかのテストなんだわ。
なるほどなるほど。で、英語が読めるとお気に入りの CPUがスケールするわけかよ?
英語の読めるバカもいるんだな。感心するわ。
話題逸らしに必死だな スケールするかの話なのにいつの間にか電気代の話になってる ATOMでOracle走らせてろよw
SPECjbb-2005の、SPARC64VIIの4ソケットの結果、ないな。
>>304 一番下のコメントって、
SPARCには、UltraSPARC T2+なんかのローエンドだけではなく、メインフレーム代替のハイエンド機がある。
そういうアップグレードパスの存在を無視して、ローエンドの性能の低さを批判するのは良くない、ってことだろ。
それはその通りだ。
そこまでの信頼性が必要な客は、UltraSPARCなんか買わずに、初手からSPARC64いっとくべきだ。
>>305 指摘しなくたって、みんなわかっとるよ。
誰のどこでの発言か、ということよりも、発言内容のほうが大切だってのは、言われなくても、わ・か・れ。
ベンチマークで良好なスコアを出てるのは、必要な領域ではスケールしているってことじゃないか?
実用上、問題がなければ、それでいいじゃないか。
たとえばメモリのピーク帯域幅を調べるようなベンチマークでスケールしなかったら、何が問題?
もっかい読んでみたけど >288 以上のことは特に書いてなかったぞ。 つーか、Intelや MS周辺の文書って、なんでこんなに中身がないんだ? うっすーーーーいw
というか別の製品ラインがあるのは使い分けるためであって 今更そういうことを書くのって、本当に素人なのなとうんざりするが
必要な領域ではスケールって、それって敗北宣言だぜ? それ以上は無理ってことなんだから もう今更過ぎてorz
>>309 おまえなー、もったいつけてないで、さっさと要点書けよ。何様のつもりなんだよ?
立派な英文学の知識で、さぞかしすごい訳文さらしてくれるんだろーな? 期待してるぞ。
10年以上前からIntelがスケールしない状況は全然変わっていないわけで 今更どうしようもないっすよ 議論してもムダです それが分かってるから違う分野で勝負かけてるわけで 全部失敗してるけどなw
>>310 から
>>314 まで、またもや5連投か。
ほい、16ソケット対決! SPARC64 vs Xeon
ttp://www.spec.org/jbb2005/results/res2008q3/jbb2005-20080713-00510.html SPECjbb2005 bops = 817,158, SPECjbb2005 bops/JVM = 51,072
Model Fujitsu SPARC Enterprise M8000
Processor SPARC64 VII
# of Chips 16
# of Cores 64
# of Cores/Chip 4
ttp://www.spec.org/jbb2005/results/res2009q1/jbb2005-20090206-00568.html SPECjbb2005 bops = 2,150,260, SPECjbb2005 bops/JVM = 134,391
Processor Intel Xeon processor X7460
# of Chips 16
# of Cores 96
# of Cores/Chip 6
参考、Opteronの8ソケット
ttp://www.spec.org/jbb2005/results/res2008q4/jbb2005-20081202-00562.html SPECjbb2005 bops = 1,037,851, SPECjbb2005 bops/JVM = 129,731
Model Sun Fire X4600 M2
Processor AMD Opteron 8384 (2.7GHz, 6 MB L3 shared)
# of Chips 8
# of Cores 32
# of Cores 32
Memory (MB) 131072
Memory Details 32 x 4GB DDR2-667 DIMMs
いいよ、もう、x86はスケールしないってことで。 スケールするSPARCよりも性能が高いんだから、スケールしなくたって十分だ。
最近スレの流れ速過ぎ。 Sunの人が行き場を失って、管を巻くしかやること無いのか?w
性能が高い、ねぇw Vista SP2ならCeleronで十分だなw
>>316 いいよ、もう、x86はスケールしないってことで。
オレはパチョコンしか使わないんだから、スケールしなくたって十分だ。
>>319 どうした? 話を逸らすにしても、ネタが愚劣すぎるぞ
そんな まだ諦めんなよ QPIが来れば、勝つるんだから
そうそう、QPIで大逆転するんだからさ、今までのはカスでも。
で、>280 にはなんて書いてあったんだ? 隠れた意味があるんだろ? 一文字おきに読んだりすればいいのか? それともどっかをタテ読み??
>>321 逸らすも何も、適材適所でいいじゃん
ESXのGUI版管理コンソールはWinでしか動かないんだしさぁ
便利な方、楽な方に流れればサーバはSolarisだし
開発はVMware上のLinuxだし、x86使うならホストOSはWindowsでしょ
SPARC使った方が楽ならそっちの方がいいよ
ムリしてx86なんて辛すぎる
>>324 画面から 8inch目を離してロンパリで遠焦点にすると仏像が浮かび上がる。
この文字配置かつ意味のある文章を組み立てるのに Xeon7400がスケールしないので
4週間かかったらしい。
もうグダグダ
>>322 から
>>326 まで、またまた5連投ですか
たしかにx86はスケーラビリティが悪い
6コアXeonの1ソケットのデータがないんで、あれだが・・・
ttp://www.spec.org/jbb2005/results/res2008q3/jbb2005-20080812-00518.html SPECjbb2005 bops = 185,899, SPECjbb2005 bops/JVM = 92,950
Model PRIMERGY RX100 S5, Intel Xeon X3370, 3.0GHz
Processor Intel Xeon X3370 (3.0GHz, 2x6MB L2, 1333MHz system bus)
# of Chips 1
# of Cores 4
# of Cores/Chip 4
ソケットが16倍コアが24倍になっても、性能は11.6倍だもの。
ソケットで見れば72%、コアでみれば48%だ。
ttp://www.spec.org/jbb2005/results/res2008q4/jbb2005-20081027-00554.html SPECjbb2005 bops = 60,853, SPECjbb2005 bops/JVM = 60,853
Model Fujitsu SPARC Enterprise M3000
Processor SPARC64 VII
# of Chips 1
# of Cores 4
# of Cores/Chip 4
ソケットが16倍で、性能は13.4倍。
x86とは比べ物にならない、リニアなスケールですな。
>>327 > Model PRIMERGY RX100 S5, Intel Xeon X3370, 3.0GHz
> Processor Intel Xeon X3370 (3.0GHz, 2x6MB L2, 1333MHz system bus)
これって QPI?
>>315 あ、こっちか。これって違う機種なんだな..
> SPECjbb2005 bops = 2,150,260, SPECjbb2005 bops/JVM = 134,391
> Processor Intel Xeon processor X7460
これって QPI?
Penrynを3つ搭載 多分FSBと思う
X3370 X7460 どちらも45nmの、QPIになる前の製品だよ。
んじゃ、QPIで大幅に改善、だw
おっとX3370は3.00GHzで、X7460は2.66GHzか。 コアが21.3倍で性能は11.6倍・・・つっても54%だな。
>>332 QPIを導入するまでもなく、SPARC64 VIIよりXeonのほうが性能が上なんですが。
1ソケットなら3倍
16ソケットでも2.6倍
改善ではなく、さらに差を広げる、だろう。
>>334 16ソケットと比べると、コア4倍で性能2.15倍か。
64ソケットも注ぎ込んでも、Xeonの16ソケットに追い付かないんだな。
>>335 なんでそう話をごちゃまぜにするかな...
> 改善ではなく、さらに差を広げる、だろう。
スケーラビリティが「改善」する。4コアとか FSBでスケールしてる規模では
むしろオーバーヘッドになる。
>>336 まあ、x86この先もせいぜい性能が伸びるといいけどな。
Sandy Bridgeで AVXな。ベクトルベクトルw
x86のスケーラビリティを高める、いちばん、簡単な方法は・・・ ズバリ、コアのクロックを下げる SPARC64 VIIと同程度の性能になるまで、コアのクロックを下げる それだけでスケーラビリティは良くなりますよ。 逆に言うと、 SPARC64VIIのコアのクロックをXeonと同程度の性能になるまで上げることができれば、 スケーラビリティが下がるでしょうね。
>>339 そんな単純なもんじゃないだろ。
帯域幅がボトルネックならともかく。
そうやってコアのクロックを下げた製品がXeon MPじゃん
あたま悪いねー。インターコネクトの飽和は相対的な問題だっての。 絶対値の問題ではない。
バスの概念しか頭にない限りいくら絞ってもムダ。理解はムリ。
で、Xeonよりも高性能なSPARCはどれ?
CPU単体では売ってませんから
Xeon採用サーバよりも高性能なSPARC採用サーバ、って意味だろが。
>>315 > SPECjbb2005 bops = 2,150,260, SPECjbb2005 bops/JVM = 134,391
> Processor Intel Xeon processor X7460
> # of Chips 16
> # of Cores 96
> # of Cores/Chip 6
こいつは 4ソケット 24コアを 4筐体 HSIで接続したもんらしいね。
NUMAになるかな?
16ソケット 96コアでスケールするんならたいしたもんだ。
>>347 QPIだとどういう構成が可能になる? 16ソケット 96コアを超えれそう?
SPECjbb以外の公表値はないの?
SPARCの結果を貼って楽しいのは、他にはSPEC CINT2006rateくらいかな。
353 :
名無しさん@お腹いっぱい。 :2009/06/11(木) 19:23:18
ちょっと胸焼けする。 そろそろZFSやProject Crossbowとかも語って欲しい
>>357 あの6000シリーズ(だよね?)のブレードにXeon 4発か。すげーな。
Sunってさ、SPARCよりもx86のほうが、高密度なブレードを製品化してるよね。
6000シリーズだとSPARCだと1発しかなかったと思う。
SPARCじゃ性能出ないし
>>359 忘れた頃に2ソケットの出たよ
いまだに4ソケットは出ない
過去スレに貼られていたPDFでは、
4ソケットならOpteronやXeonよりもスパコン性能高いよ
ってな計算があったが、いまだに4ソケットは作られず。
>>362 下のグラフはMySQLが悪いってことで無視するとして、
上のグラフを見ると、T1のほうがスケールしているよ。
Concurrencyを増やしていって飽和した部分の縦軸の数字を見ると、4コア→8コアで、ほぼ倍になってるから。
Opteronだと2コア→4コアで、倍よりも小さい。
しかし、どちらが優れているかといえばOpteronだ。
T1はConcurrencyが高くないと本領を発揮しないし、
たとえ本領を発揮しても、
T1 4コアよりOpteron 2コア、
T1 8コアよりOpteron 4コア
のほうが全領域でパフォーマンスが上なのだから。
jbb2005のスコアが示すように、 スケールしなくてもSPARCよりXeonのほうが性能が高い、ゆえに、スケールしないのは問題ではない っていうことで、スケールするかどうかは、どうでもいいんだわな。
>上のグラフを見ると、T1のほうがスケールしているよ。 お前が言ってるのはスループット。 スケーラビリティって言葉の意味わかってるか? コア数が増えたときにどれだけ性能が伸びてるかだぞ。 もう一度グラフとにらめっこして出直してこいw
スケーラビリティでいうと、上のグラフは両者互角。 下のグラフではSPARCがぼろぼろということになる。
もしかしてこんなグラフも読めないやつが多いようなので念のためいっとくと スループットでSPARCが粘っているのはハードウエアマルチスレッディングがあるから。 つーか、このくらいは直ぐ見てわからんとスループットコンピューティングの意味理解できんぞ。
>>364 メモリ=DRAMに関してはCPUメーカーの技術差が出にくいので
基本的にはCPUコアが速いほどメモリがボトルネックになる度合いが大きく、
スケーラビリティをあげるのは難しくなる。
むしろ単体コアで圧倒的でもこれだけのスケーラビリティを維持して、絶対性能で圧勝しているので
議論する意味もない。
Xeon最強!
>>365 おまえ、グラフろくに見てないだろ。
横軸はコア数ではないぞ。
>>367 SPARCが粘ってる? 何を言っとるんだ。
Concurrencyが低いと性能が出てないだけじゃないか。
>>363 確かに差はよくみないとわからないが、
SPARCの方がスケールしているよな。
それにしても俺が書き込んでいるときはSPARC厨が静かなんだよなあ。 次の日会社で仕事している時間帯によっぽど暇なのかニートなのか知らないが、 SPARCマンセー書き込みで暴れている不思議w
じつは君の裏の姿がSPARC(ry
>>327 の前後とか日中こいつら一体何してるんだろうかと思う。
まあ、こんな単純な現実の性能話も理解できないようでは
少なくともコンピュータ関係の仕事は続けられないだろうが。
>>298 > OpenLDAPは悪くない。あいつはいいやつだ。
ちょっとスレ違いだが、
例えばback-sqlなんか使うとスケールしているベンチマーク結果とかあるの?
スケールとリニアの言葉通りの意味さえわからん馬鹿がいるようだが.. まさか「英語ななめ読み」とか言ってたやつじゃないよな? 早く訳文がみたいぜww
Nehalemって、涅槃でレム睡眠?
>>364 「x86はスケールしない、したがって SMP用 CPUとしてはクズ」
という命題について議論しているのに、
> っていうことで、スケールするかどうかは、どうでもいいんだわな。
こんなこと言うやつは鼻つままれて外へ放り出すべきだな。
典型的バカ。サル以下。ひとりで暮らせ。ここへは来るな。
9時になって、工作員が出社してきたか。
>>378 わけろって話だろ
「x86はスケールしない」
「x86はSMP用 CPUとしてはクズ」
>>376 正直にいってごらん、英語わかりませんって。
>>378 なぁ、
>>364 は皮肉だろ、どう見ても。
スケールしてるものに対して、スケールしないって言ってるんだから。
>>380 0と1の両極端で考えるのは、やめれ。
問題は、スケールするか否かではなく、スケールするにしても、スケーラビリティの良さの程度。
うわ。英語よりはるかに難しいなwww これも皮肉なんか?
いくらスケーラビリティが良くても、絶対的な性能が低ければ、意味がない。
スケーラビリティがあれば増設でいくらでも性能あがる いわゆるパーマンの法則
>>386 が正しければ、SPARC64にはスケーラビリティはなさそうだな。
388 :
名無しさん@お腹いっぱい。 :2009/06/12(金) 13:45:15
>>386 ただし、必要なコストも目ん玉が飛び出るほどあがる。
いわゆる、Sun + Oracle の法則。
Oracle「10億くらいケチケチせずにポンと出せや」
>>386 だな。ある規模以上は逆立ちしても増やせないアーキに対して、
増設でそれの性能以上を出すシステムの価値は、小規模の場合の掛け算にはならない。
..って、こんなあたりまえのこと解説する必要があるとはwwwwwwww
Sunのミドル以上の SMP機のユーザーって、ファッションで買ってたとでも
思ってるのか?
>>348 QPIだとどういう構成が可能になる? 16ソケット 96コアを超えれそう?
高々256Coreスケールで済む程度の話なら苦労はないはな
そうなのか。じゃ、とっとと出せば、いいのになww
軍とか政府系のスパコンなどを除いて、現状の民需で最上のハイエンド案件って どういう用途で予算幾らくらい?
なるほど。パソコンみたいに一定の相場があると思ってるわけだな。ダメだこりゃw
>>394 Itanium売れたとこに聞いてみれば?
>>390 M9000の最大構成よりも大きなものが欲しければ・・・Itanium2搭載のAltix4700しかないな。
相変わらず独り問答しているキチガイがいるな。
M9000の最大構成も、HPCしか出番ないしねぇ。
月曜日には出てたネタの上、わざわざ情報のないページを示されても
そうか、それはすまん
>>402 月曜に紹介されてたのはOpenSolarisスレだったわ
ここじゃなかった。すまん
>>396 では、少なくともSunでの民需ハイエンド最高峰だと、どういう用途?
>>395 一定の相場が「無い」ってことは、まだ未成熟なヤクザ業界なのか、
ハイエンドは。
またハイエンドコンプレックスか
kabu.comはx86なんだよねー
現実が見えていないのか、 それとも、 Sunスレでくらい夢を見ていたいのか。 まぁSunのワークステーションで幸せだった時代が、懐かしいのぉ。 いま、x86なPCを使っても、何もかもが普通すぎて、面白くないわ。
410 :
名無しさん@お腹いっぱい。 :2009/06/13(土) 04:28:44
>>408 その昔、SUNのSparc-WSに憧れるも高価なため手が出ずに、後に金銭的に
余裕が出るもののx86自作PCで満足してしまう。
「これでいいのか、やはりSparc-WSを入手しよう。」と思い去年
Sparc機をヤフオク購入したが、「、、、こんなものか」
と感じで拍子抜けしてしまった。
たまに起動してSolarisでサイト見るぐらいにしか使ってない。
そんな俺はSUNのSparcマシンなど不釣合いなのかもしれない。
x86の自作以上に満足できる環境は、ないぜ? 金額的にも構成的にもな Sunの純正WS(x86機含む)で満足できるのは ドライバに頭を使う必要がないくらい
>>410 「去年」は、ちと遅すぎる..
>>411 バカにでもできるし、トラブるとこ汚いシガラミのせいだし、満足度最低 x86。
コストパフォーマンス悪くないし十分満足いくよx86
馬鹿にでも出来るってのはストロングポイントだし
EFIってどうなったんだ? 増えてんのか消えたんか。
>>414 バカにでもできるのは組立てて「動きそうな」とこまでで
その先トラブったら専門家にも理解不能。BIOSゲロゲロ。
現行 Intel Mac miniに加えて省電力 PowerPC G5な Mac miniが出て、 省電力な UltraSPARC T2の 4コア版くらいな Mac miniも出て、 どれも MacOS Xと Solarisが選択可能だとするとどれ買いますか?
Intel
>>416 人柱がいっぱいいるから地雷回避余裕です
Sunのx86なワークステーションは、 I/Oプロセッサとか、 豪勢なビデオサブシステムとか、 積んでるン? CPUが面倒みてたら、 割り込みが大量に入って パフォーマンス出ないよな。
割り込み大量の基準が分からんが、構成はパソコンと同じだろう
>>420 それは知ってるけど、それだけ? 一時期サーバーとかにも搭載されてたようだけど。
まあ、やらかしてくれたね。あのどーしよーもない BIOSからさえ
移行する気の起きないようなもん新規にこしらえてどーすんねんと。
>>423 で、Sunのx86機には、何積んでるの?
>>422 なんだよ、DELLと同じかよ。
まさか、チップセットまで汎用品使ってるんじゃないんだろうな?
Intergraphのアレとか、SGIのVWSのアレのように、
DELLのパソコンとは別次元の製品に仕上げろよ、Sunは。
HPでさえ、PA-RISCをグラフィックス・サブシステムに積んだx86ワークステーションを作ってたのにな。
客は安くて速いものを求めてるんだからそんなの積んだって意味ねーよ Sunのx86 WSで有り難いのは汎用コンポーネントを使いながらも Solarisのドライバも準備してもらえること
じゃぁ、SPARCのワークステーションでIOP積んでたのは、 SPARCのコンテキストスイッチが重いから、ってだけか。 x86なら軽いから問題ない、と。
なんか、面白くないなぁ。 US T2をTOEエンジンとして搭載したNICが付いてるとか、 US T2をXサーバとして搭載したビデオカードが付いてるとか、 なんか、ないのかね。
どーせ買わねー買えねーのにガタガタぬかすなってw unixhonpoの特価ultra24すらまだ店晒しじゃねーか
フラッシュメモリを使ったブースターが採用されてるじゃないか。
>>430 買う価値がないんだよ。
ただのCore2 QuadのPCなんだから。
最低でも2ソケット以上。
2ソケットが必要なら、Appleでいいじゃん。
DELLのT7400にopenSolarisが入らないと泣きが入っていたやつもいたじゃねーかw
>>432 Ultra27だって単なるi7のシングルソケットPCじゃねーか
受け狙いっすか?w
MAJC使ったグラフィックプロセッサ、ってのはもう終ったのか? ぢつは MAJCよかったらしいね、互換性出せなかったからやめたらしいけど。
437 :
名無しさん@お腹いっぱい。 :2009/06/13(土) 15:01:54
>>436 Bledeシリーズの上位モデルに搭載されてる、フレームバッファがMAJC搭載だったと
思ったけど。
互換性って OpenGL + Vendor 拡張じゃないの
>>428 IOPつーのはRAIDコントローラのことか?
x86機に3041Eでも載せときゃいいんじゃね
ぢゃ80219みたいなもんか?
>>406 単に知りたいだけ。
ローエンドを投げ出しておいて、じゃあハイエンドは本当に売れてるの?
って話。
そもそもハイエンド市場て用途は何?
というところからしてよく知らないから、Sunという会社は何のための何を
作って売っていたのかと言う事を詳しい人に教えて欲しい。
ハイエンド市場も知らないとは・・・リアルで学生なのか
学生とか言えば煽ってるつもりになってる脳無し社会人って笑える
445 :
名無しさん@お腹いっぱい。 :2009/06/13(土) 16:23:44
>>442 ハイエンド市場⇒EWS(エンジニアリングワークステーション)大規模サーバ/
スーパーコンピューターなどの市場
SUNはEWSの会社
EWSか、懐かしい言葉だな。 ローエンドからハイエンドまで同じだからこそ、ユーザーにとってのスケーラビリティがあるんです。 その点、ローエンドでかなり失地したSunは、ハイエンドもヤバいね。
EWSはローエンドだよね ハイエンドは…大学とかのデータセンターで使われるとかかな
>>441 ちゃうちゃう
いまでいう、TOE付NICみたいなもん。
入出力って、細かい やりとりを頻繁にやるので、それを別のプロセッサに移すもの。
といっても、SparcStationに積まれてたのって、普通のインテリジェントなSCSIホストブリッジだったような。
当時のパソコンの、IDEに比べれば雲泥の差ではあったが、パソコンもすぐにインテリジェントなSCSIホストブリッジ使えるようになったし。
>>448 > といっても、SparcStationに積まれてたのって、普通のインテリジェントなSCSIホストブリッジだったような。
そうだよ。NCRのやつ。(Symbios Logic経由して現 LSI Logic)
もしくは Qlogic。
> 当時のパソコンの、IDEに比べれば雲泥の差ではあったが、パソコンもすぐにインテリジェントなSCSIホストブリッジ使えるようになったし。
PCIまではバスがね... Adaptec 1542とかww
486パソコンはSSの敵じゃなかったが、Pentiumパソコンになって同じ土俵に乗り、PentiumProで追い越したって感じかな。
451 :
名無しさん@お腹いっぱい。 :2009/06/13(土) 18:44:48
>>450 整数演算なら互角じゃなかった?486PCvsSS
>>448 単なるSCSIホストブリッジをIOPと書くメリットがよくわからなかったけど、まぁいいわ
わざわざ返事どうも
IOPが乗ってたのは、SunのNEWSの68Kじゃない?
>>452 単なる・・・というが、RISCコアとメモリを内蔵していて、かなりインテリジェントよ。
ドライバが初期化時にファームをダウンロードするスタイルなので、色々できる。
ふぅん 詳しいね SS5とか20を使ってたけどOS使うのにいっぱいいっぱいで そういうところまで目が届かなかったわ
ちょっと待てSun4cの頃に使われていたNCR53C90Aに、RISCコントローラなんか内蔵されとらんぞ。
実はISAバスのSCSIホストアダプタと一緒だったという。
結局、ハイエンドの具体的な用途を誰も答えられないw
Oracleのベンチマークを走らせることだろ?
>>457 いや、ちょっと違うんだわ。
SCSIやEtherのI/Fチップ自体は、まぁ、
ISAっていうか、マイコンバスっていうか、8bitあるいは16bitパソコン向けの既存のLSIを使ってる。
肝心なのは、それをSBusに繋ぐ部分のLSI Logic印の賢いDMAエンジンなのよ。
I/Fチップがダラダラと低速で転送し続けても、DMAエンジンが高速かつ短時間の
SBus上のバーストアクセスに変換するんで、システムのボトルネックにならないのよ。
しかも、SCSIとEtherのI/Fチップは個別に直接にDMAエンジンに繋がっていて、
それぞれ互いに独立して転送ができる。
つーわけで、同じチップをパソコンのISAバスに直結した場合とは、わけが違う。
まぁ、足回りとか信頼性に関しては、Sun辺りはメインフレームからバカにされ、 x86(PC)はSunからバカにされってところだな。その辺ケチって安く作ってるんだから 仕方ないけど。
CPUがPIOで転送するように作られてるチップでも、 外付けのDMAエンジンによってバスマスタに化ける。 それって、パソコンでも使われてる技術だよね。
PCIと何が違うの?
PCには、EISAってのもあったんだが。 UNIX系でもEISAを採用した製品あったような記憶があるぞ。
SgiのIndigo^2が採用してたと思う あれ、欲しかったなぁ
中古で売ってるから買ってやれ>Indigo2
PCサーバはPC向けのCPUをサーバに応用することでコストパフォーマンスが高いのだけど そのうちCPU性能をいくら上げてもメモリ性能がボトルネックになって性能が伸びなくなるときがくる サーバ用に専用設計されたサーバ向けRISC CPUならメモリバス性能を上げることも可能だろうが PCサーバには限界があると思う PCサーバがサーバ用に専用設計したメモリバスを導入すれば 価格は高騰してコストパフォーマンスは低下するはず
>サーバ用に専用設計されたサーバ向けRISC CPUならメモリバス性能を上げることも可能だろうが 帯域について言えば配線の密度的に制限がある レイテンシについて言えばメモリの種類と配線長で制限がある 物理的制約条件が変わるわけではないのでRISCであるかどうかなんて関係ない RISCに夢見すぎ
1個数百万で売るプロセッサなら そりゃメモリ帯域増やせるよね ISA関係ないし
Sunが、自らが推進していたオープンシステムとダウンサイジングによって 駆逐されるのを見るのは実に面白いものですね。IBMみたいにライトサイジング とかやり返せば良いのに。
合い言葉はサンライジング
>>467 伝統的にRISCのほうがメモリ性能が高かったのは、そうせざるをえなかったからっていう側面もあるぞ。
x86サーバのコストパフォーマンスが良いのは、パソコンと同じだからではなく、オープンアーキだから。
XeonやXeon向けのチップセットは、パソコンとは別に作られていて、値段が高いんだが、それでも、
Sunと富士通の、実質一社のみのクローズドなSPARCよりは安くなる。
SPARCはオープンだとか言ってるけど、x86に比べればクローズドだよ。
Xeonのチップセットが安いのはIntel様が作っているからです このプラットフォーム戦略によってIntel様はx86サーバ市場を年間1000万台規模まで成長させました
>>472 オープンアーキテクチャやクローズドアーキテクチャの意味を間違えてるわけだが
Intelが作るXeon向けチップセットは、ボリュームゾーンのローエンドだけだよ。 IBMもhpもNECも、ミドル以上は自前のチップセットを使ってきた。 かつては2P以上をServerWorks(RCC)に任せていた時代もあったし。
>PCサーバはPC向けのCPUをサーバに応用することでコストパフォーマンスが高いのだけど >そのうちCPU性能をいくら上げてもメモリ性能がボトルネックになって性能が伸びなくなるときがくる >サーバ用に専用設計されたサーバ向けRISC CPUならメモリバス性能を上げることも可能だろうが 笑った。 こんな幻想を信じている馬鹿がいるとはな。 Intelだって4ソケット以上は独自設計されてるが。 そもそもCPUにサーバ用でなければならない設計上の絶対的理由ないぞ。
SPARC厨は当のSunが今やCPUのアーキテクチャに執着しないメーカーに転身して 久しいというのに、無意味なアーキテクチャ原理主義、アーキテクチャ幻想をひきづって 他アーキテクチャの話題で頓珍漢な発言で粘着してくるアフォの集まりって話だ。 別に好きならそれでいいんじゃあないか? 他を無理に否定しようと必死になるから、逆に叩かれるんだが。 大人しくROMってろってかんじ。
>>477 見事に後半部分が前半部分を全否定しててワラタw
今までもの流れを見ても、普通にCPUの話題がでると ○○は糞だとかいうSPARC房が暴れ初めて、15年くらい前の認識で 他人を攻撃し始めるからあれるんだが。学習能力の低い奴は素直に消えろよと。
>>479 荒れるから、そうやって他人を攻撃するなよ。
いい加減、しびれ切らしたんだよ。
話し相手が欲しいのか?
UNIX板もID導入して欲しいな。
コテハン付ければ
>>466 流石に今更Sgi使いたいという気分にはならないわw
>>478 のように、病気の人は自分が病気だとは思わず、周囲の人間が病気だと思うようです。
って言われて、それはお前だろ、って返すのが、病気の証拠。
自分も彼氏も病人ということで、自覚はあるようだなw
>>486 ワラタw
もっと面白い踊りをキボンヌ
>>488 って相手の書き込みを読んでないんだな・・・読んでいたら・・・頭が正常なら・・・そういうコメントしないよな。
ここまでのスレッドの要約:自分以外のお前らみんな死ね。
>>489 わかった、もっと広い所に住むようになったら買うわ
古いUNIX WSなんて、ハードあるいはソフトに何らかのシガラミが無い限り、ゴミだよ。
古いマシンを詰めたラック1本分が、 ノートPC上の仮想マシン群に負ける、 なんてことも多々あるしなぁ。
>>475 AMDもIntelも8CPU用までしか出してないような
>>473 逆に言えば数の出ないハイエンドサーバについてはIntelの出る幕はない
Intelはあくまでも部品メーカーであってサーバを売って儲けてる企業ではないので
チップ製造が赤字になるような分野には進出しない
>>491 ちゃうちゃう
SPARCが絶対性能でもコストパフォーマンスでも圧倒的に劣るという
明快な事実を10年以上も受け入れずに現実逃避をつづけてきた精神障害者が問題なだけだろw
ありえんw
これは、通常の、信者vsアンチ論とは質が異なります。 主観や趣向の問題とは到底呼べない格差があるからな。
そう思ってれば心の平穏が保てるならそれでもいいんじゃね 出来ればチラシの裏にお願いしたいところだがw
つーか、ここって過去のイメージに縋ってる精神的難民を虐めて楽しむスレだろw どんな珍発言が飛び出すがレスが毎度楽しみ。
IntelのCPUが高性能なのは他のCPUに比べて1世代先の製造プロセス使ってるからだろ 32nmから先どれだけ微細加工が進むか、1世代移行する期間がどうなるかこの先見ものだな
皮肉だよね、x86という負の遺産を継承したOpteronを、Sunが採用したのは。 AMD64とIA-64どっちが脅威かといえば後者だから、 Sunが前者を採用してIA-64を劣勢に立たせたのは、 なりふりかまわない保身としては、インパクトがあったね。
>>503 まあ、結果をみればわかるが、
IA64が成功しようが、x86が成功しようが、SPARCに勝ち目はなかったけどね。
Intelが壊滅したと仮定しても、AMDかIBMの方に分があったくらいだ。
それくらいSunのSPARCには力がないのが現実。
富士通だってがんばってるんだ 富士通製の新しいSPARCのSPARC64VII搭載の 新しいハイエンドサーバが発売されたと思ったら金融恐慌勃発 Sunかわいそう
たまにスマッシュヒットがある・・・ってんじゃ困るんですよ。 その点、x86は安全だ。 IntelとAMDが互いにダメな時期をカバーし合ってるからね。
AMD64は失敗だったと思うよ。AMD信者には悪いけどね。 32bitから64bitへのジャンプでx86のダメなところを一掃するチャンスだったのに、継承しちまった。
まあ、Pentium 4が熱で頭打ちになっているときに、 K8/AMD64がちょっと注目されただけで、むしろ脚の引っ張り合いだよな。 x86=Intelの牙城であって他は取り巻きみたいなもん、RISCサイドから見るとな。
互換性が必要だったからAMD64が広まったんだろ。 互換性より重要な物があればそれ以外の物が広まる。 移行はいつだっていいんだよ。
今思えばx86を64bitにそのまま拡張という目先の解が 自社の目先の売り上げしかもちろん考えていないサーバ屋にとっては 魅力的だったのだが、64bit x86をあえてやらずに、こらえて移行の機会とする 長期的な戦略で投資を回収したかったIntelの思惑は成功し、 x86がなくなっていく可能性はあった。
>>509 その取りまきのAMDよりも・・・な、RISCサイドって・・・
>>510 互換性ではなく、x86命令の実行速度、だろ。
Itaniumはx86命令も実行できるんだから。
また、64bitのモードで32bitのバイナリがそのまま走らないのは、AMD64も一緒。
将来を取るか、今を取るか・・・っていったら、今だろう。
>>513 IA64がx86バイナリを実行できるつってもエミュレーションだったよな?
>>513 嘘を言うなよ。
AMD64は64bitモードで32bitバイナリを普通に実行できるぞ。
>>517 64bit「の」モードとでも言えば良かったか?そのくらい脳内補完してくれよ。
AMD64上で64bitカーネルのOSを動かす場合はLongモードなんだから、32bit
バイナリを実行できることに何ら変わりはない。
>>509 そんなわけない。それなら IA-32eなんて出してきた時に AMD64と互換にする
必要なんか全くなく、非互換にして AMDを潰せた、という理屈になる。
実際はビビリまくりで「ごめんなさい、互換にするからユルシテちょーだい」。
Intelは Pen-4でクロック上げることのみに集中して周りが見えなくなっていた。
>>515 最初の頃はソフトウェア・エミュレーションではなかったよ。
AMD64と同じように、16bitあるいは32bitのOSがそのまま走るようになっていたし、
64bitのOS下でも、16bitあるいは32bitのアプリを走らせるためのモードを持っていた。
つまり、互換性という点ではAMD64と同じ。
速度も含めて上位互換かというと、違うがね。
>>519 AMD信者っぽい気持ち悪い文章だなぁ。
Pentium4のアプローチは、RISC的で良いものだったと思うんだがねぇ。
消費電力の大きさはアーキテクチャの問題ではなく、製造プロセスの問題だった。
それに、Northwoodと競合していた頃のAMDはK7だが、
そのK7は省電力機能も封印されていたので、常に大電力を食いまくりで論外だった。
>>521 > 消費電力の大きさはアーキテクチャの問題ではなく、製造プロセスの問題だった。
それは違うだろ。NetBurstマイクロアーキテクチャの設計思想として、パイプラインを
深くしてクロックを可能な限り上げたい、というのがあったのだから製造プロセス
だけの問題じゃない。
>>522 それはNorthwoodとThoroughbredで、処理能力あたりの消費電力を比較しての話?
当時のAthlonXPは、
パイプライン段数を増やさずに電源電圧を上げることで動作クロックを高くしていて、
電力効率が悪かったという印象があるよ。
さらに、省電力機能がないに等しく、
アイドル状態が続いても湯水のごとく電力を浪費してたこともあって、とても印象が悪かった。
そんな消費電力の大きさを誤魔化すために、IntelのTDPの数字がインチキだとか工作してたなぁ。
IntelのTDPはAMDのTDPよりも低いが、最大電圧×最大電流を計算するとAMDのTDPよりも
格段に高くなる、とかいって。
>>523 俺は一言もAMDの話題を出してないんだが、レスの内容がすべてAMDに関すること
になってるぞ。
衝かれてもないところを必死で庇ってあわれなこった。 製造プロセスの問題だったんなら、やめなきゃよかったな、バカだな、Intelはww
>>524 そりゃAMD信者のプロパガンダが酷いって話だからな。
Pentium4は消費電流が増えるとコア電圧が下がる仕様なんだわ。
だから最大電圧と最大消費電流をかけ算するのは間違ってるんだ。
しかも実際のピーク消費電力は、
AMDはTDPに近い値だが、IntelはTDPよりも10Wくらい小さな値だった。
しかし、AMDのCPUの消費電力の大きさは批判されることは少なく、
IntelのPentium4のアーキテクチャが消費電力が大きいと騒いでたのよ。
>>525 AMD信者の大合唱が、各国で行われてな・・・
>>526 Intelが NetBurstやめたのは AMDのせいなのかwww
Intelが書いてることよく読んだ方がいいぞ?
周りをよく見ないとポッツーーン取り残されてたりして気の毒ww
>>526 だからAMDを批判したいなら他でやれ。俺はNetBurstの設計思想を問題視しただけだ。
あまり信者だプロパガンダだ言ってると胡散臭く聞こえるぞ。
いえいえ、これ以上ないくらい胡散臭いです。 Intel支持の主流派に相手にしてもらえないんでしょう、こんなとこで 想いをぶちまけるのはww 多分高額はたいて Pen-4買っちゃったんだろーなーkk
>>528 NetBurstよりも、もっと良いものを得たからだろう。
>>529 NetBurstの設計思想のどこが、どのように問題なの?
当時必要とされていた、
シングルスレッドのMPEG2エンコーダでリアルタイムにD1解像度をエンコードする
っていう目的には、最適なアーキテクチャだったと思うのだが。
>>530 お前みたいなガキの思考で他人を測るな。
>>531 > NetBurstの設計思想のどこが、どのように問題なの?
> 当時必要とされていた、
ぎゃはははっははは
> シングルスレッドのMPEG2エンコーダでリアルタイムにD1解像度をエンコードする
> っていう目的
げははははっははははっはー
その「目的」を仮定しない場合、性能がわるかったからだろ。
そういう「目的」をデッチ上げる行為を手前味噌とか我田引水とか言うんだけど
知らないのか?
で、今 Intelはそんなこと言ってるか? もう「エンコード目的」は終了しちゃったの?
> お前みたいなガキの思考で他人を測るな。
よくそんなことが言えるもんだ。どんな顔してんのか覗いてみたいわww
>>531 > NetBurstの設計思想のどこが、どのように問題なの?
>>522 で書いた通りだ。その手法が立ち行かなくなっていくつか製品をキャンセル
する羽目になり、NetBurstマイクロアーキテクチャ自体消えたわけだからな。
> 当時必要とされていた、
> シングルスレッドのMPEG2エンコーダでリアルタイムにD1解像度をエンコードする
> っていう目的には、最適なアーキテクチャだったと思うのだが。
これ当時のIntelの宣伝そのままだろ。いい加減にしてくれ。
RIMM+Pentium4は正直羨ましかった 今はそんなことないけどさ
Pentium4の失敗は明らかにIntelの黒歴史なのに、是々非々で判断出来ない あたり、やっぱり単なるIntel厨なんだなww
とはいうもののPen3からは良くなってたし今でも使ってる環境は多いのでは?
>>535 ほとんどの用途で性能出てないのに、「動画エンコード」とか持ち出して
クロックブームに便乗してたんだからな。もちろん、社員みんなわかってて
邁進してたわけで。無知なユーザーに対するいちぢるしい背信行為だわな。
無知なユーザーは、悪くないわな。知識があるのに目をつむった連中は、
どうかなww?
Pen-Mやってた連中がいたにしても、あれだけのヘマやったら Intel以外なら
一巻の終りなんだがな。
結局は、まず「用途」が先にあって「そのための性能」が必要なんだと思うんだけど、 Sunの「用途」って、そもそも何なの? そして、「そのための性能」は十分にあったの?
>>537 全くだ。NetBurstはmarchitecture(マーケティング用のアーキテクチャ)と
揶揄された位だからな。低IPCなのを無視して高クロック=高性能という
嘘を一般大衆に浸透させようとしたのは他ならぬIntel。
>>539 説明する知識も無く、日本語も不自由な奴は黙ってなさいw
>>540 >嘘を一般大衆に浸透させようとしたのは他ならぬIntel
後にIntel自身がその呪縛に苦しんだのは、あまりに皮肉だよなw
>>541 だからさー、正当派 Intel支持者のいるとこでやれよー。
ここは Sunの話するとこなんだよ。
Intelはマルチコアに舵切って以来、おどろくほど Sunと同じこと言ってるから、
よく調べな。シングルスレッド性能を主張するのはむしろ AMD。
知識も間違ってるが顔出す場所も間違ってる。あんた大間違い。
Pentium4全盛期こそIntelのTDPが最悪だった時代だろ
545 :
531 :2009/06/15(月) 18:23:32
雨後のタケノコのごとく誰かが連投したようなスレの進みようですな。
>>532 当時の状況を経験していないのなら、人の話は素直に聞けよ。
>>533 もし製造プロセスに問題がなければ、消費電力は抑えられ、クロックはもっと上がっていたと思う。
Pentium4の180nmから130nmへの移行では、同一クロックでは劇的に消費電力が減って、
同じ消費電力では劇的にクロックが上がったでしょう?
もし、それと同じことが90nmへの移行でも実現していれば、かなり違った結果になっていたと思うよ。
とはいえ、MPEG2のハードウェア・エンコーダが安価になってくると、CPUへの要求も変ってくるし、
ましてや、マルチコア時代にもなれば、取るべきアプローチも変ってくるのは当然のことで、
ある時点での最適解が、別の時点ではそうではなかったからといって、ある時点でも間違っていた
というのは、ちょっとナンセンスだと思いますよ。
> これ当時のIntelの宣伝そのままだろ。いい加減にしてくれ。
当時のIntelの主張は妥当だと思うよ。
ワープロや表計算は十分な速度が得られているが、メディア処理はまだまだ不十分。
ゆえに、メディア処理とくにMPEG2エンコードがリアルタイムで可能かどうかの境界線を越えるために、
偏ったパフォーマンスのアーキテクチャにする、っていう設計方針を説明したものでしょ、宣伝は。
ベンチマーク好きなマニア層は、全方位で性能向上が得られないと、気がすまないようで酷評してたが。
インテルは、彼らの発言の影響が一般人にどのように及ぶのか、軽視していたようだ。
>>535 Pentium4を失敗・・・当時を経験していれば、そんな断言はできないと思う。
まぁAMD信者とか、彼らの言動で眼が曇ったら、また、話は別か。
>>537 その、ほとんどの用途では、すでに性能が足りてたんですよ。
事実、Pentium4が主流になってからも、Pentium3愛好家の人たちがいて、
彼らは 「Pentium3で十分」 と言ってたんですよ。
>>540 速度が求められていた処理では、Pentium4はPentium3とIPCが同程度でしたよ。
2GHzのPentium4が、1GHzのPentium3のキッチリ2倍の速度が出ていましたからね。
それでも、クロックが性能を示していない、とでも?
>>544 Intelが130WのTDP上限を反省して方針転換した後に、
AMDが130WのTDPのCPUをいくつも出しているんだよねー。
どこぞの250W CPU に比べたら可愛いもんだ
130Wという数字は、メーカーやアーキテクチャによらず、空冷で信頼性と耐久性を確保できる限界だと思う。
俺が最初に見た130WはItaniumだな、初代の 狂気の沙汰だと思ったよ3桁は。 ありえない、と。
>>545 > 製造プロセスに問題がなければ、消費電力は抑えられ、クロックはもっと上がっていた
製造プロセスの問題とは具体的に何だ?解決可能な問題なら、わざわざNetBurstを
葬り去る必要は無かったはずだが。
> 当時のIntelの主張は妥当だと思うよ。
だからどれだけの一般人がMPEG2のエンコードをしたがってたんだよ。そもそもそんな
需要が無かったじゃないか。マーケティングのためにCPU-boundな処理を必要としていて
それがたまたま動画のエンコードだっただけ。
HPC分野で言えば、Pentium3やOpteronと比べて最適化の方針が変わるのが問題視されて
NetBurstのXeonは嫌われてたんだよ。
当時を知ってるとか知ってないとか、なんなんだよそれ? 頭大丈夫かよ? 知ってねーわけねーだろここに居るのは SPARCstation2がどうのって連中だぞ? それと_今現在_ NetBurstがないのはプロセスの問題じゃないことを 如実に表してるだろが。どんな女々しい言い訳並べんねん。 でさ、ここそういう話するとこじゃねーんだよとっとと出てけよ。来るな、しっしっ!!
ノラが寄るな。害虫が。ww
>>546 > 速度が求められていた処理では、Pentium4はPentium3とIPCが同程度でしたよ。
何の処理で実際にPentium3と同等のIPCだったのか具体例を出してくれ。
必死にSSE3のintrinsicを手で埋め込んで最適化してやっと出たんじゃないのか?
>>546 > 2GHzのPentium4が、1GHzのPentium3のキッチリ2倍の速度が出ていましたからね。
> それでも、クロックが性能を示していない、とでも?
ウソこけ。1.5倍程度のクロック数で同程度か、もしくはそれ以下だったよ。
パソコン上げてる間はずっと動画エンコードしてたんだろ。 世間のパソコンユーザーも毎日動画エンコードしてると思ってたんだろ。 キショいなw
Intelの言うこと 100%ウノミにしてるバカってほんとにいる...のかな? フリしてるだけかな?
Slot1と Pen-4だけはまったく買う気起きなかったね。見るからにインチキっぽかったw
盛り上がってますね
アム厨は過去の栄光にすがるしか能が無いんだから適当に相手しておけ
スルー力が足りない
Pen-4なんて毛針 CPUに食いつくアホ魚がいっぱいいるのは信じれん。 それ以上に Intelにヘコヘコお追従うれしがってるやつってキショ過ぎ
>>561 話し相手を求めてここに来てるんじゃないかな
煽ればレスして貰えるからね
そういえば Rock は空冷でいけるのかな? RISC ベンダー初の水冷? w
IBMはRISCベンダーには含まれないのか?
566 :
546 :2009/06/15(月) 20:58:19
>>551 > 製造プロセスの問題とは具体的に何だ?
リーク電流
> 解決可能な問題なら、わざわざNetBurstを葬り去る必要は無かったはずだが。
時が進めば状況も変り、ゆえに最適解も変るわけで、
NetBurstよりも、より良い選択肢に乗り換えたのだろう。
SIMD命令を上手に使えるコンパイラが出てくれば、
クロックを高めるよりは演算ユニットの幅を広げるほうがいいし、
ソフトウェアがマルチスレッド化されていけば、
シングルコアの性能を高めるよりは、複数のコアを詰め込んだほうがいい。
> だからどれだけの一般人がMPEG2のエンコードをしたがってたんだよ。
当時、一般人には、「テレパソ」などというケッタイな略称が広まっていた時期だったと思う。
> HPC分野で言えば、
一般人の話なのに、HPCですか・・・
>>552 時代は流れて移り変わるものですから、いまNetBurstがないからといって、当時それが間違っていたとは言えない。
昔のSPARCに固執してはいけないですよ。Sunがx86サーバを売るようになってから、久しいですしね。
>>554 MPEG2エンコードと暗号処理だよ。
SSE2命令をintrinsicで使ったが「必死」なんて大げさなことはしてない。
ごくふつーに演算の流れ通りに書いて、あとはコンパイラの最適化任せ。
>>555 それは、Pentium3でも十分なアプリの速度じゃありませんか?
>>556 Pentium4のNorthwoodなら、事務仕事で使ってる間は、消費電力は低かったですよ。
一方、AthlonXPだと、事務仕事で使っていても、爆熱・大消費電力でしたね。
>>564 ずいぶん昔の話ですが、空冷だっていう話を読みましたよ。
空冷でも行ける、十分な信頼性が得られる! 画期的な冷却ソリューションを開発した!
とかいうのを、読みましたよ。
250Wで空冷だったら本当に画期的だと思う
>>568 SIMD命令のベクトル長が倍になるか、演算器が倍になるんじゃね?
まさかSunのスレでPentium4持ち上げる奴がいるとはSunも凋落したもんだ・・・ てかもうなくなるのか
quicktransitさえあればsparcなんていらないのに。ゴミなのに。クズなのに。IBMじゃまくせー
凋落どころの話じゃないからな
>>572 まぁ冷静に曇りなき目で、過去を振り返ってみなよ。
Pentium4ほどRISC的なx86は、ないと思うぞ。
??? ? ? ? ?? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ?■ ? ?? ?? ?? ?? ? ? ? ● ● ? 馬鹿にはコピペできないの。 ? ? ?? ? ?? ????? ?????? ?? ????? ?? ???? ???? ???? ???? ??? ??? ?■?????■?? ????▲?????
ここはSunスレではなくIntelスレです
NetburstのXeonは1コア2ソケットが cinebenchでも1.2-3倍程度にしかならないから面白かった
>>575 RISC的ってより、DEC残党が必死で Alphaの要素を再実装したんだろ。
やつらは実際には Intelも x86もどーでもいーからな。
「オレ達の持ってた技術をナメんなよ。」って感じだろw
>>566 > リーク電流
.....まるでなんの説明にもなってないけど... もちろんわかって書いてんだよな?
> 昔のSPARCに固執してはいけないですよ。Sunがx86サーバを売るようになってから、久しいですしね。
もののたとえとか、そういうことわかんないわけ? おまえいくつだよ? 未成年か?
そんなもん直接結びつけてどーすんだ。
> MPEG2エンコードと暗号処理だよ。
...そりゃ「一般用途」じゃないって.. これもわかって書いてんだよな。
焦点なんかあわせる気毛頭ないわけね。最初から。場所もまちがってるが
会話も不自由なんだな。匿名掲示版なんて来ない方が身のためだぞ?
Rockこそが世界最強
dead lock
メタボロックシンドローム
Niagara2もディスコンかなぁ
ああやっぱハードは切捨てか エリソンならIBM潰してくれると思っていたのに
「情報筋が匿名条件」とかあるからな。 Oracleにゆさぶりをかけたい某ライバル会社 買収条件有利にしたい Oracleのゆさぶり Oracle買収を機に開発投げ出したい Rock開発メンバー 以前レイオフされた元 Rock開発メンバー 実際はできかけてる可能性もあるぞ。 開発中止発表の前フリの可能性もあるけどw
>>578 FSBがボトルネックになるくらい、1つのコアの性能が高かったんだよ。
>>580 > .....まるでなんの説明にもなってないけど... もちろんわかって書いてんだよな?
リーク電流
だけじゃ、わからないよな。
リーク電流がとても大きかった
って書かないと。
>> MPEG2エンコードと暗号処理だよ。 > ...そりゃ「一般用途」じゃないって.. これもわかって書いてんだよな。 MPEG2エンコードは一般用途だろが。 当時、ソフトウェア・エンコードのTVキャプチャが主流だったんだから。 暗号処理はユーザーに対して透過的に行われるから、意識されてないだけ。
>>587 Rockって、動作するデモ機すら、お披露目してないよね。
16コアで250Wの消費電力なら、 8コアで130Wの消費電力を2チップ繋げたほうが、 いいと思うんだけどなぁ。 Rockは、ほぼリニアにスケールするってSunの人が言ってるから、 分割しても性能的には問題ないでしょう。
>>588 > リーク電流がとても大きかった
...プロセス微細化した時にリーク電流が問題にならないことなんか、あるのか?
正味バカ? そんなもん実験段階で各社が報告してるじゃん。寝てんの?
>>589 > 当時、ソフトウェア・エンコードのTVキャプチャが主流だったんだから。
ダメだこりゃ。このオタク野郎ww
> 暗号処理はユーザーに対して透過的に行われるから、意識されてないだけ。
はぁ。それがどうしたの? Intelの社員だろオマエ。来るなしっしっ!!
>>588 同じ時期に買った競合他社のSMP機は1.85倍で動いた
全く同じシングルチャネルのReg PC2100 DDRなのになw
1.85倍のA社はP2Pバスだが
>>592 > ...プロセス微細化した時にリーク電流が問題にならないことなんか、あるのか?
180nmのWillamateから130nmのNorthwoodへの移行では問題にならなかったぞ。
> ダメだこりゃ。このオタク野郎ww
TVキャプチャ = オタクって発想が、すでにオタクだな。
テレビ兼用パソコンとか、テレビ対応パソコンとか、
普通に量販店で一般人向けの売れ筋だったんだがな。
> はぁ。それがどうしたの? Intelの社員だろオマエ。来るなしっしっ!!
思い込みに支配されてるから、そう思うのかな。
>>593 だから何?
1コアだけでもメモリの77%を使うほどの性能が出ていれば、2コアにしても1.3倍にしかならない。
一方、
1コアだけでメモリの54%を使う程度の性能しか出ていなければ、2コアにすれば1.85倍になる。
この1.3倍と1.85倍という数字だけみて優劣は決まらない。
>>595 バカか?メモリの77%を使うほどの性能って何の話だよww
お前何も分かってないだろ
> この1.3倍と1.85倍という数字だけみて優劣は決まらない。
完全に論理が破綻してるぞ。同じベンチマークを動かしてparallel speedupに
これだけ差が出てるということはアーキテクチャの優劣を論ずるには十分だ
>>596 メンドクサイから、ベンチマークのスコア、出してみ。
何倍とかいうんじゃなくて絶対値をさ。
>>596 たとえばさ、そのXeonのコアクロックの倍率を半分に下げたら、どうなると思う?
>>597 メモリ集中タスクっぽいので、たぶん、
Xeon 1P = 77
Xeon 2P = 100
A社 1P = 54
A社 2P = 100
こんな感じのスコアだろうな。
>>598 メモリ集中タスクなら、コアクロックを半分にsageても、あまり変らんぞ。
新しいディベート訓練かなんかですか? ぜんぜんつまんないんでもうやめてください。中身がゼロです。
>>594 「洗脳」されてますよ。マインドコントロールの域に達してます。
ここまでの人は初めて見ました。
>>566 頭の悪い回答ばかりだな。もう少し頭を使って書けよ。
> リーク電流
やっぱり予想通りの回答だな。
リーク電流は物理的な現象であって製造プロセスの問題ではない。混同しないように。
そしてリーク電流の問題を顕在化させたのがNetBurstアーキテクチャだ。
> 時が進めば状況も変り、ゆえに最適解も変るわけで、
> NetBurstよりも、より良い選択肢に乗り換えたのだろう。
そもそもアーキテクチャってのはそんなにコロコロ変えるようなものではない。
新規アーキテクチャを起こすのにはバリデーション等も含めて相当なコストが掛かる
からな。高々数年で葬り去るようなアーキテクチャなんてロクでもないのは自明だ。
> ソフトウェアがマルチスレッド化されていけば、
> シングルコアの性能を高めるよりは、複数のコアを詰め込んだほうがいい。
前提と結論が逆。今頃になってやっとスレッド化を進めないと、と騒ぎ出してる
んだろうが。論理的な思考も出来ないのか?
> 当時、一般人には、「テレパソ」などというケッタイな略称が広まっていた時期だったと思う。
それはメーカーとIntelが結託して売り出していただけで、実際に録画してPCで番組を
見てる奴なんてごく一部のオタク位だっただろうが。そもそもあんなファンがうるさい
マシンが横にあったら落ち着いて見れないだろうが。嘘もいい加減にしろ。
> 一般人の話なのに、HPCですか・・・
IntelはXeonを出してHPC分野にも必死に売り出していたのだから持ち出しても
何の問題もないだろうが。むしろNetBurstアーキテクチャをMPEG2エンコード向け
なんて言う方が大問題だ。だったら同じアーキテクチャでHPC向けに出す必要は
無いからな。
> MPEG2エンコードと暗号処理だよ。 > SSE2命令をintrinsicで使ったが「必死」なんて大げさなことはしてない。 > ごくふつーに演算の流れ通りに書いて、あとはコンパイラの最適化任せ。 随分と特殊な用途だな。一般人はエンコードも暗号処理もほとんど使わないから。 intrinsic埋め込む時点で十分必死だ。 そんなほとんど使わないような用途で必死に最適化してやっとIPCが並んでも 絶対的にIPCが低いということは変わらないぞ。 > Pentium4のNorthwoodなら、事務仕事で使ってる間は、消費電力は低かったですよ。 > 一方、AthlonXPだと、事務仕事で使っていても、爆熱・大消費電力でしたね。 お前はやたらとNorthwoodとAthlon XPを比べるな。これが一番Intelにとって有利な 比較だからだろ?Athlon 64とPrescottを比べてみろよ。
「たのむからもうそういう話題には触れないでほしい」と思ってるのは Intelだろなwwww
>>600 ディベート訓練がつまらない、やめて欲しいというのなら、とっととベンチマークのスコアを出せよ。
あーだこーだぐじゃぐじゃ言うことを選ぶな。とっとと話にケリを付くデータを出せ。
>>601 はいはい、レッテル貼り。
>>602 > リーク電流は物理的な現象であって製造プロセスの問題ではない。混同しないように。
言葉遊びで逃げるなよ。
リーク電流の有無の話なんかしてない。その大きさが問題なの。
そして、リーク電流の大きさは製造プロセスで決まるの。
当時のIntelの90nmプロセスは、リーク電流が大きかったんだ。
> そもそもアーキテクチャってのはそんなにコロコロ変えるようなものではない。
> 新規アーキテクチャを起こすのにはバリデーション等も含めて相当なコストが掛かる
> からな。高々数年で葬り去るようなアーキテクチャなんてロクでもないのは自明だ。
5年はもったろ。
この業界、5年も持てば十分だと思うが。
それに、
1.4GHzから3.4GHzまでスケールしたしな。
> 前提と結論が逆。今頃になってやっとスレッド化を進めないと、と騒ぎ出してる
> んだろうが。論理的な思考も出来ないのか?
CPUのマルチコア化とソフトウェアのマルチスレッド化は両輪だと思うぞ。
> それはメーカーとIntelが結託して売り出していただけで、実際に録画してPCで番組を
> 見てる奴なんてごく一部のオタク位だっただろうが。そもそもあんなファンがうるさい
> マシンが横にあったら落ち着いて見れないだろうが。嘘もいい加減にしろ。
ごく一部のオタクなら、それこそ、Pentium3にハードウェア・エンコードのTVキャプチャだろ。
動作音? ビデオテープのハンドリングの手間に比べりゃ、PCの動作音なんて問題じゃない。
HDDに録画することの便利さは画期的で、金銭的に余裕のあるサラリーマンが結構買ってたぞ。
野球中継を予約録画しといて、帰宅したらCMや不要な部分を飛ばしながら見るんだって。
>>602 > 一般人の話なのに、HPCですか・・・
> IntelはXeonを出してHPC分野にも必死に売り出していたのだから持ち出しても何の問題もないだろうが。
話が繋がってない。
> だったら同じアーキテクチャでHPC向けに出す必要は無いからな。
HPCで必要とされる直線的な演算能力こそ、NetBurstの得意とするところだね。
>>603 > intrinsic埋め込む時点で十分必死だ。
必死って・・・あんたのスキルを基準にして評価すんなよ。
> そんなほとんど使わないような用途で必死に最適化してやっとIPCが並んでも
> 絶対的にIPCが低いということは変わらないぞ。
速度が必要な用途で速度が出る
速度が必要ではない用途では速度が出ない
これの、どこが問題ですか。
> Athlon 64とPrescottを比べてみろよ。
製造プロセスの問題で消費電力が大きすぎたPrescottは論外ですよ。
ちょっとのぞいてみたら何だこれは。 スレタイ100回読んでもう来るな。
だれか回収に来てくんないのか。この壊れてゴミ垂れ流すガラクタの。
>>606 > ...、とっととベンチマークのスコアを出せよ。
ベンチマーク「だけ」いいのが Pen-4だって言ってんのにベンチマーク出して
どうすんだよ?
Pentium III Wikipedia:
| 特にPentium III-S 1.4Gの処理速度や体感スピードはPentium 4の2GHz程度と
| 比較しても遜色ないものとされ、PowerLeap製の変換ゲタ等を...
(中略)
| ...から、自作および改造マニアの間では現在も高値で取引されている。
こんな話は当時から山ほどあったし、実際オレが使った IBMの Pen-4マシンも
ひどいテイタラクだった。まったく速くなかった。
そんなことも知らずにただただビデオエンコードに邁進してたとはなんとも哀れな..
> リーク電流の有無の話なんかしてない。その大きさが問題なの。 お前は「リーク電流」とだけ書いておきながら随分と偉そうな物言いだな。 IPCを犠牲にしてでもクロックの大幅な向上というNetBurstの設計思想がリーク電流の 問題を顕在化させ、先行かなくなったんだろうが。そもそもリーク電流の増大は 既知だったわけで、そこを過小評価したのが失敗の大きな原因だ。それを無視して 製造プロセスだけに罪をなすりつけるのは筋違いも甚だしい。 > この業界、5年も持てば十分だと思うが。 > 1.4GHzから3.4GHzまでスケールしたしな。 5年でほぼ完全に葬り去られるのは珍しいぞ。 お前はマーケティング所属か?技術の話をするならクロックじゃなくて性能差を論じろ よ。 1.4GHzなんてPentium3に性能で負けてただろうが。 > 動作音? ビデオテープのハンドリングの手間に比べりゃ、PCの動作音なんて問題じゃない。 Pentium4マシンの使いすぎで難聴になったか? ここまで来ると擁護厨を通り越して単なるバカだな。
だからもういいから。 お前らどっちもどっちだよ。他でやれ。
>>608 > 話が繋がってない。
ちゃんと話は繋がってるから
>>545 から読み直せ。
> HPCで必要とされる直線的な演算能力こそ、NetBurstの得意とするところだね。
それがそうでもない。HPCではOpteronの方が圧倒的に人気があったからな。
> 必死って・・・あんたのスキルを基準にして評価すんなよ。
話を逸らすな。
移植性を失うような汚いことをしなければ性能が出ないのが大問題なんだよ。
> 速度が必要な用途で速度が出る
> 速度が必要ではない用途では速度が出ない
> これの、どこが問題ですか。
そんなことも分からないバカだったのか?
速度にムラがあるCPUを使ったらそれ専用にチューニングする羽目になるだろうが。
世の中はPentium4だけじゃないんだよ。
> 製造プロセスの問題で消費電力が大きすぎたPrescottは論外ですよ。
いくら悪夢のようなCPUだったからと言って無かったことにするな。
作ってみたら消費電力が大きすぎたり性能が出なかった CPUを「クロック最高」って ホイホイ売りさばく会社って、もう武器商人と同列だな。
unix板で勢いダントツのスレだなあ 何がお前らを熱くさせるのか
Intelのインチキ
アム厨死ね
>>612 > ベンチマーク「だけ」いいのが Pen-4だって言ってんのにベンチマーク出してどうすんだよ?
おいおい、ベンチマークを持ち出したのは、そっちだろ。
それとも、別人か?
> こんな話は当時から山ほどあったし、実際オレが使った IBMの Pen-4マシンも
> ひどいテイタラクだった。まったく速くなかった。
だから何?
全方位での性能向上を求めるようなマニア視点の話なら
>>545 で既出
>>613 > お前は「リーク電流」とだけ書いておきながら随分と偉そうな物言いだな。
普通はリーク電流の問題といえば、その大きさの問題だろ。いちいち言わなくても。
> IPCを犠牲にしてでもクロックの大幅な向上というNetBurstの設計思想がリーク電流の
> 問題を顕在化させ、先行かなくなったんだろうが。
リーク電流はプロセスの微細化によって増大するもの。
たとえPentium3のままシュリンクしていったとしても、リーク電流は問題になっただろう。
事実、CoppermineとTualatinを比較すると、
ダイナミックではTualatinのほうが消費電力が少ないが、
スタティックでは逆にTualatinのほうが消費電力が大きいのだ。
>>613 > 5年でほぼ完全に葬り去られるのは珍しいぞ。
x86は競争が激しい上に、マルチコア化もありましたしね。
> お前はマーケティング所属か?技術の話をするならクロックじゃなくて性能差を論じろよ。
妄想で決め付けるなよ。
何度も言ってるように、
当時、とくに速度が必要とされていた用途では、クロック比の性能比が得られていたんだよ。
速度が必要とされていない用途での性能向上がなかったから、何だというのだ。
> 1.4GHzなんてPentium3に性能で負けてただろうが。
IntelのCPUは、新しいアーキテクチャの最初は、前のアーキテクチャよりも、若干遅いのが通例です。
しかしそれでも、とくに速度が要求されていた用途では、同時期のPentium3よりも性能が良かったでしょ。
それほど速度が要求されない用途では、多少性能が劣るとしても、許容範囲内ですよ。
それに、Pentium3も併売されていたのだから、使う側が選べばいいんですよ。
> Pentium4マシンの使いすぎで難聴になったか?
> ここまで来ると擁護厨を通り越して単なるバカだな。
話を逸らすなよ。
NetBurstもマルチコア化しましたが消えてしまいました
>>615 > ちゃんと話は繋がってるから
>>545 から読み直せ。
読み直しても、わかりません。
簡単に説明してもらえませんか?
>> 必死って・・・あんたのスキルを基準にして評価すんなよ。
>話を逸らすな。
>移植性を失うような汚いことをしなければ性能が出ないのが大問題なんだよ。
intrinsicで移植性を失ったり汚くなったりするのは、スキルが低いからですよ。
> そんなことも分からないバカだったのか?
> 速度にムラがあるCPUを使ったらそれ専用にチューニングする羽目になるだろうが。
質問に答えていませんね。
速度が必要な用途で速度が出る
速度が必要ではない用途では速度が出ない
これの、どこが問題ですか。
速度が必要な用途では、チューニングで速度が出るのなら、チューニングすることは問題ではないし、
チューニングしても速度が出ないよりは遥かにマシ。
> 世の中はPentium4だけじゃないんだよ。
Pentium4用にチューニングしても、Pentium3やK7、K8で顕著な速度低下は見られなかったよ。
>>622 だから何?
状況が変って別の選択肢のほうが良くなった、ただそれだけのことです。
いつまでも同じものに固執しては、いけません。
それよりRockだ
>>570 ある意味どっちも正解。
ただしベクトル長は増えるが演算ユニットあたりのスループットは増えない。
128ビットの浮動小数ユニットの搭載数が2倍になる。
あるアプリケーションでは、机上シミュレーションだと2オペランドの128ビットSSE命令を
3オペランドのAVX命令に置き換えるだけでも1.2倍程度性能は上がる。
Sandy BridgeはNew Microarchitectureの世代だからSIMDだけではなく他にも色々やってくるだろうな 激しく気になるが今更HOTCHIPSでWestmereの詳細を明かすのがIntelクオリティ 1年後にでも明らかになっていれば御の字だな
Rock が駄目になったら、ぼらくるてきには魅力的なハードが無くなっちまうから 富士通にストレージ共々売却になるんだろうなぁ
>>623 > Pentium4用にチューニングしても、Pentium3やK7、K8で顕著な速度低下は見られなかったよ。
はぁ?
Pentium4用にSSE2使ってチューニングしたコードをどうやって動かすんだよwwww
アホなことばかり言ってんじゃねーぞ
おーこわいこわい
チューニングZEROとかソースネクスト製品でも作ってたんだろう
>>629 最適化と命令セットを混同するな。
いい加減どこまでスレ違いを続けるんだ。出て行け。
>>629 SSE2命令を直にハードコードすると思ったら、それはスキルが低いぞ。
SSE2での拡張の多くは、MMXやSSEに対してベクトル長を2倍にしたもので、
SSE2の1命令は、機械的に、MMXやSSEの2命令に展開できるのよ。
ゆえに、同一のコードから、両方のコードが得られるわけ。
おーこわいこわい
そもそもPentium4の高性能っぷりが必要な用途では、 Pentium3やK7は論外、K8でも力及ばずだろう。
いったいどんだけ
>>599 から脱線するんだ? よほど痛いところを突かれたと見える。
>632 このPentium4厨はSSE2を使うような状況だけで速ければ問題ないって 何度も言ってるだろうが、ボケ
>>633 口では何とでも言えるからな
御託はいいからP3,P4,K7,K8のいずれでも性能低下のほとんど起きないコードを見せてみろよ
つーかこのアホ以外でPentium4を熱狂的に支持するやつなんているのか?
Sunさん、Rockが完成しないからスレッドが荒れてますよ
Rock is dead!!
No Future!!
何だ。こいつら火病っぽいなと思ったら韓国人なのか。やっぱり。 じゃあしょうがないね。好きなだけやってくれ。
そもそもA社って何だよ。AMDか? 比較対象のCPUすら伏せるって、何か弱みでもあるのか。
>>644 無関係なレスを理由に出し渋るな。さっさとコードを見せろよ
>>646 見ても理解できまい?
当時リアルタイムに、そういう仕事をしていれば、常識的な話なんだが。
それに疑問を持つってことは、門外漢なんだろう。
>>649 理解出来るから安心しろ
御託はいいからさっさと出せよ。それとも口だけの知ったかなのか?
スレを辿ってみるとcinebenchのスコアらしいな。
最初の
>>578 に書いてある。
ちょっとググってみたが、こんな感じだな。
ttp://www.tabsnet.com/index.php?option=com_benchmark&task=list&bid=4&sysid=0 なんか話がおかしいぞ。
このスコアを見る限り、
1.2〜1.3倍ってのは、2ソケットのSMPではなく、1ソケットのHyperThreadingのこと・・・なんじゃね?
Xeonの2PはHTとも相まって2.1〜2.2倍のスコアになってるし。
ちょっと数字を拾うと、
シングル
Pentium3 1GHz、102ポイント
Pentium4 2GHz、197ポイント
AthlonXP 2GHz、243ポイント
デュアル
Pentium3 1GHz、210ポイント(1.85倍)
Xeon 2GHz、420ポイント(2.13倍)
Opteron 2GHz、525ポイント(1.86倍)
>>652 仕事で書いたコードを出せるわけないだろが。
>>654 誰が仕事のコードを出せと言った?その場でさっと書いてみろよ
スキル(笑)が高いんだろ?
うるせー。すれ違いだから消えろよ
自演乙
ど、どれが自演?
654==657だろ 結局P4厨も知ったかだったわけか
>>656 いまさら? うぜー。
それに開発環境が、ない。
スキルってのは属人的なものだけでなく、
適切な道具を揃えた組織ってのも含まれててね。
フリーのツールだけで書けって言われたら
馬鹿馬鹿しくて、やってられんですよ。
>>661 はいはい、知ったか乙。本当に何も知らない馬鹿だったんだな
誰がコンパイルしろと言った?テキスト書くだけに大層なツールなんていらねーよ
それでスキルだとか笑止千万だな
>>663 > テキスト書くだけに大層なツールなんていらねーよ
いまさら一般的なテキストエディタでコードなんか、書いてられないよ。
どーみても 2007/01/19 の記事です
>>666 そのテープアウトね、失敗したんだわ。
1年くらい後に、テープアウトやり直してるんで。
> いまさら一般的なテキストエディタでコードなんか、書いてられないよ。 厨房レベルの言い訳するな、見苦しいぞ 高々サンプルコードを書くのにエディタを選ぶとは余程の知的障害持ちだな
朝からお勤めご苦労様です
>>669 Intelの受け売り並べてるだけなんだから、書けるわけがないwwww
技術的知識も皆無、論旨はデタラメ、同じこと延々繰り返してるだけ。
ほんと迷惑。存在が迷惑。
>>671 100歩譲ってお前がすべて正しいとしても、
存在が迷惑だというのは変わらないな。
願わくばAppleがSunの後を追って倒産しますように
もうパソコン屋でもOS屋でもなく、iPod/touch用端末屋だろ。
> 高々サンプルコードを書くのにエディタを選ぶとは余程の知的障害持ちだな
これが紙に鉛筆で書くような生産性の悪い低スキルなプログラマの発想です
>>671 自演乙
「サンプルコード」に固執するように見せかけてスレを荒らして流したい話題は
>>665 ですな。
>>583 SunはCPUは富士通まかせでいくのかな
現在のハイエンドサーバにはSPARC64 VIIがつかわれてて
富士通は
>>504 のSPARC64 VIIIfxも開発してるからな
こんなバカにプログラム書けるわけがねー!ww
Pen-4は動画エンコードと暗号処理用の CPUだからね。プログラミングはしないよ。
gigazineで見て泣きそうになった なんとか頼みますオラクルさん SPARCだけ生かせて下さい
オラクル「Sunのエンジニアに問題があるから無理」
もうSPARCは富士通のメインフレームとHPCだけだろ。
ということに(ry
サーバのハードは富士通に任せてSunはそのほかでがんばればいいのに
RockはUltraSPARC Vと同じ運命か 量産出荷が何年も遅れるようではそれも当然だな
>>653 なんだよ、Pen4はPen3に対して
ほぼクロック比
の性能向上が得られてるじゃん。
SunSoft, Inc.
もう死んだ子の年を数えるのはやめようか。
>>519 >そんなわけない。それなら IA-32eなんて出してきた時に AMD64と互換にする
>必要なんか全くなく、非互換にして AMDを潰せた、という理屈になる。
IntelはIA64をサーバで売りたかったので、x86の64bit化には泣く泣く対応したとはいえ、
当初は消極的だった。つーか、積極的になったのはつい最近。Nehalem-EXが4S以上で
はじめて積極的になったあとにチューニングされた製品だよ。
それから、MSがAMD64版と、IntelのCT(もう一つのx86-64)に両方対応するのは嫌だったので、
先行していたAMD64にしか対応しなかったのが勝敗の分け目。
IntelがIA64を気にせずに最初っからx86-64に本気で作り込んだら、
普通に勝てていたのは想像に難くない。AMDは、それが出来ないのを知っていて、
わざとAMD64をベタな拡張にしぼって、少ない開発期間で用意したのだが。
IA64って何が悪かったんだろ
AMDを潰して後顧の憂いを絶たなかったこと 3面作戦やって勝てると過信したこと 以上
>>692 IA64が失敗した理由はあげたらきりがないほど色々あるが、
x86が想定していたより速くなった(特に98年〜2000年の間で競争激化してやたら性能が伸びた)。
蓋を開けてみればIntelも互換性のないところでは昔の速かったはずのRISCがx86の牙城を崩せなかったのと
同じ結果だった。IA64の場合は、同じIntelなのでx86サイドの64bit化やサーバ向けの機能強化を
わざと遅れさせたりもできたが、タイミング悪くAMDが調子よくて、x86-64を出してきてとどめになった。
また、IA64は元々命令レベルの並列性を重視したアーキテクチャだが、開発が遅れすぎた。
処女作のMercedが97年頃に登場の予定が結局伸びまくって2000年になって、第2世代で完成度があがった
McKinleyがでた2001年(1年差って時点で既におかしいw)には既に命令レベルの並列性から
マルチコア/マルチスレッドと電力削減の時代の変化の兆しが出始めていた。
とまあ、この辺の解釈が最も妥当です。 あとおれに異論を唱えるやつがたくさんでてくるだろうが、 多分おれよりも正しい認識を持っている奴は出てこないであろうから無視してよい(わらぃ
今となっては皆忘れているが、Montecito(元々2004年予定)と その後継のChivanoってのは元々新マイクロアーキテクチャで、 デュアルコア/マルチコアではなかったんだよ。 Intelはデュアルコアに舵を切ったのは、RISCサーバ陣営に比べると遅かった。 MontecitoはMcKinley系のデュアルコアにあとから設計し直したからな。 開発おくれた。Tukwilaは計画が二転三転してもはや何も語ることはないほど遅れまくった。
プログラマなら過去の遺物を捨てて全く新しいものをスクラッチから作ってみたくなる そして世間に受け入れられない それを考えると win95/98/me を捨てられた ms は偉いなあ
>>697 え?
Windows 3.1
↓32ビット化
Windows NT
↓サブセットを逆ポーティング
Win32s
↓
Windows95
じゃない?
32bitに関しては最初からNTなんですよ
>>694 なるほど、IA-64悪くないじゃん。
まぁ、たとえ良いものでも、開発が遅れたら、それだけで台無しだから、なぁ。
Rockなんかも、開発が遅れたというだけで、失敗は明らかだろう。
社内競争と派閥争いは常に紙一重だ・・・
IA-64って高い理想を唱えるだけで結果を出せないお前らみたいなもんだろ
(´;ω;`)ブワッ
>>701 つUltraSPARC-V
つRock
>>701 ,/ 一 ヽ:::::::::/..:::::::/..:::::::/!::::l::::!:::.. .::',
生 ,ゝ:/.::::::::/..:::::::/ //!::ハ::!::... ..::::::i
呪 i::::::l/l:::;イ=ミ<´ 'く_j:廴」ハ:::..:::::::::|
わ !:::::::://|0 l゛ ィf==ミ l::::::::::::::|
れ 7.::::l,'。Oー' | 0 ,! l::::::::::__,!∧_)ヽ _,ハ、
ろ i'.::::::/ 、\\\\\\ゝ--O。:::/}/ 呪 .休 貴
| |:::::/ヘ r ー‐ - 、\\ /.:::/〃 い .日 様
| |::/.::::..ヽr−、 ヽ /.::::::´〈. を .に に
| 〉:::::::::::/ __ ト _ __ ノ _/.:::::::::::::! か .縁 は
. !! ,、j::::, -‐' 〈` −-r‐ォ.:´/.:::::::::::::::| け が 一
ヽ ,、 /.::::ノ ヽ ー' ヽ / /.:/..:::,:::-―く .て な .生
::::V.::.ー'.::::/、ヽ、 yー‐' }'7、/.:´.::::r−-r 、:::::! .や く
::::::/.:::::::::人 ヽ _>´、 // ,'.:::::::::::>‐く`ヽ ∨ る .な
::::;'.::::::/..:::.ヾー..'.:::// : : i /.:::::/.:f^ヽ ハ ぅ る
::;'.::::::'..:::::::::::::..\_// : : : レ'.:::/..:::l ノ.:.ゝ!
IA-64が普及してたらIntelの独占状態になりPC向けのIA-64は競争原理が働かないため 今のx86-64よりも高価または低性能になった可能性もあり
>>676 お前いい加減にしろよ
さっさとコード出すか黙って精神病院に入院しろ
スレの内容が完全にスレタイに負けてる
>>710 クソガキは出てけよ。荒らすのも大概にしろ。
>>710 コード書けないクズだというのは分かった
>>712 と
>>713 ってさ、
相手がガキあるいはクズだと思うのなら、黙ってろよ。
そういう人間を暴れさせないようにスルーするのは大人の義務だぞ。
なんじゃそら 手加減してください、ってことか? それこそ敗北宣言じゃないかw
開発環境がないと、なんて書かれたのを読んだ瞬間に分かったけどね ぐぐるやMSの面接ではホワイトボードに手書きでやってるよw
最期の反省
>>716 あんたここで面接試験でもやってるつもりか
Sun Microsystems 最後の面接
>>709 見苦しいやつ。ケツふけ自分でこのクズ。
>>699 ヴァッカじゃねーか。あんだけ金も時間も人間もかけまくってダメなのに、
もう何やろうがダメじゃんか。なにが「悪くない」だよ。これ以上最悪はないだろ。
「良いもの」なわけがない。絵に書いたような『思考停止』。批判能力ゼロ。
722 :
名無しさん@お腹いっぱい。 :2009/06/18(木) 10:30:02
gigazineて、東スポみたいなもんか? 並んだタイトル読んだだけで..ww
ここは幼稚園か?
レッテル貼りしてもムダでしょ コード書けない86クンw
誰が幼稚園児なのか指定してもいないのに真っ先に登場したということは 自覚があるようだな。 私は両者に対して言ったのに。
誰がレッテル張りしてるか指定してもいないのに真っ先に登場したということは 自覚があるようだな86クン。 私はパチョヲタの寝言をもっと聴かせてほしいと思っているがw 真に受けてるヴァカも居るみたいだが
245 名前: Socket774 [sage] 投稿日: 2009/06/18(木) 13:03:04 ID:X2imb4nz
>>242 理解できないなら妄想扱いでかまわないけど、その場合はIntel自身も妄想認定してね(はぁと
Intel様自身による必死なFSB擁護レポート
ttp://www.sstc.co.jp/biz/report/FSB_Comp_White_Paper.pdf 要約すると
・FSB周波数/転送レートは格段に増加してるのでボトルネック解消です!
CPUクロックは2倍にもなっていないのに、FSB速度は過去4年間で3倍に達しました。
→FSB転送レートをCPU速度の増加以上に増やさないとやってらんない
・AMD比2倍以上のオンダイL2/L3・キャッシュ内蔵でバスを劇的に帯域削減!
→キャッシュで稼がないとFSB帯域たりません
・Xeon用チップセットはスヌープフィルタ搭載で大量のIO要求があってもメモリアクセスを圧迫しません!
→一般ユーザ用はスヌープトラフィックで埋まるのでIO負荷あげたら負けです
・Xeon用チップセットとIntel製NICでIOAT使えばコピートラフィックも激減に!
→一般ユーザ用はネットワークトラフィックで余計なメモリアクセスが大量に発生
・IntelFSBは片方向バスなのでバス帯域を最大限に使えます!
→だから上のような問題が発生するわけで…逆方向が待たされるのでレイテンシも増大
・FSB方式はNUMAではなくSMPになるのでプロセッサ毎の性能が均一!
→そのわりにHTTとか導入して結局均一にならない駄目さ加減
・アーキテクチャ改新によりFSBトラフィックを削減しました!
→結局FSBたりてないんじゃn(^ω^;)
でも安心してください。Core i7ではQPI導入によりCPU間のインターコネクトをより高速に行い、
独立したメモリコントローラ内蔵により問題は一気に解決です!
→ちょwwwおまwww 上のレポート書いたインテルのScott Huckさん超涙目wwww
「良い」システム・アーキテクチャーを決めるための最高の基準は、 個々の機能ではなく、アプリケーションのパフォーマンスです。 このpdfの見どころ つまり、アーキは糞だけどコーダーは頑張って魔法でも何でも使って性能上げてねwってこと コード書けないで86擁護ってもうね…アホかとバカかと
>>727 いやいや、私が先に両者に対していったのじゃよ。
>>730 その糞アーキにあきれるほど資源をつぎこんでね... こんなムダ前代未聞かつ
後世の笑い草よね。人類ほとんどバカだった、尻馬にのった無責任な大量の技術者、
そしてみじめなコード書けない 86擁護...
>>709 おまえ一人で冒頭埋めてるキショいとこなんか使えるか。さっさと消せ。
モノ作ってるところが製品にベストを尽くさずに商売第一で 性能出ないのはお客様の走らせるコードが悪いはマズイよなぁw まぁIntelはバグのあったBIOSやドライバをリリースノートから 抹消するような会社だからしょうがないな
うちのアーキが良いかどうかはお客さんの走らせるコード次第 アーキは悪いんですよ、その粗が見えないコードならアーキ的に問題ないでしょ? って開き直ってどうすんのさwww
で、悪いアーキを延々と放置したのがチップセットビジネスを 温存したいからというのが泣ける
連投ウザい
>>729 のコピペって、対象を知らずに叩いてるんだな。
そんなのをコピペする時点で、批判能力ゼロだな。
どこが間違っているのかは、目印がなくなってしまうから、教えないよ。
くくく 恥知らずめ
はやくプログラム書けよ〜ー〜ー。
連投ウザい
>>741 なぁ、
>>653 を見ろよ。
クロック比の性能が出るコードなんてありえない、ソースを見せてみろ
っていうお前の要求は、もはや、必要なくなったんだが。
? オレは元々ソースを見せろと言った人じゃないが... ありえない、つまり、Pen-4はクロックの割に性能でない、そういうことだな?
サンプルコードを書かなくても → Pen-4はクソ たとえサンプルコードを書いても → Pen-4はクソ よかったよかった。
で、Sun Microsystems との関係は?
>>746 このスレのSunの狂信者一名は、
RISC的なアプローチで設計されたx86であるNetBurstを理解できない
つまり、RISCの何がキモなのか、出来ていないのにSPARCはRISCだマンセー(意味不明
してるってことだな
キモヲタ86バカはコードが書けない空気も読めない 全然ネトバと関係ないSunのスレでスレ違いを当然と思っているクズ
>>749 がNetBurst批判をやめれば馬鹿も黙るんじゃね?
最後の園児
>>747 アハハハハハハハハハハハハハハハハハハハハ、ばか?
もうちょっとマシな言い訳を... いやしなくていいや。
さすがに以前から Intel x86使ってる人間(オレ含むわけだが)で
よっぽど思い入れがあっても、それはないわ。
Intelの人間だって、Pen-4作ってた連中だって、そんなことは言わないぜ?
地球でおまえだけなんじゃないか?
>>748 オレここんとこそんなに書いてないし。まちがいなく複数人ですが。
あんた以外はww
内部が RISC構造なのと ABIが RISCなのと、ぜんぜん違うんですけど...
そんなところへ戻らないとケムリに巻けなくなったのか?
RISCのキモ... 教えてくれんでいいよ、それ臭いだろ、オマエのはwww
>>750 NetBurstは...カスだ!! オレは >749 じゃないけどww
SunのSPARCはカスだ!! 適切な性能で適切な価格のプロセッサを適切な時期に出荷できない点で そういう意味ではPentium 4にも劣るよな・・・
2chの投稿も、Pen-4でやると高速だよな。エンコだけじゃなくてさ。 Pen3のほぼ倍wwww
あー、オレも買っとけばよかったなぁ、Pen-4。最近毎日エンコするしさー。 ドライブ暗号化してるから、暗号処理もしまくりなんだよなー。 失敗したなー。え? もうないの? Pen-4。ざんねんーー
>>750 なんて面白すぎる
>>749 でネトバ批判なんてひっとことも書いてないのになw
スレ違いを延々引っ張る86ヲタがキモいといわれてるのに
何を勘違いしてんだか
ひょっとしてネトバと一体化しちゃったんじゃねーのか?
このヴァカはwww
連投ウザい
SPARC信者はもっとキモいです
SPARC信者はコテかトリップつけてほしいよな ID非表示をいいことに都合の悪い話はごまかしてるつもりみたいだからムリか
こういうの見るとUNIX板にもID導入して欲しくなるな
アフォのスレ違い86野郎を追い出すのにわざわざID導入か? 寝言も大概にしやがれ
このスレ荒らし耐性ない人多すぎ 荒らしにマジレスしたりしてれば面白がって荒らしまくるよな 荒らしはスルーするのが一番
何日もスルーしてくれない人ばかりでもううんざり
>>761 普通の人はあっても困らないがお前は困るんだろ?
トリつける勇気もないんだろ?
せいぜい今後も中身のないことばかりキャンキャン吠えてるがいいさ
Niagara3はマダか? もはやNiagara2はXeonよりコストパフォーマンスが悪い。これは非常にピンチだぞ。 このままでは新規の客は掴めないし、リプレースではXeonに乗り換えられてしまうぞ。
昨年の今ごろには、2009年末の予定 16スレッドの16コアで256スレッドのモンスターで、しかも、8ソケットまで対応 CPUは1チップに集積できても、それに見合うメモリは・・・問題だろう T1でDDRのデュアルチャネルの4系統、 T2でFB-DIMMのデュアルチャネルの4系統、 T2+で 2系統に半減 T3(?)ではFB-DIMMからDDR3に戻るだろうから、デュアルチャネルが8系統・・・無理だ。 ってことは、巨大なL3キャッシュを別チップで持つことになるのかな・・・Rockのように。
お前ら仕事しろ ニートの俺がこのスレみてビビったわ
>>763 あなたのそのセリフ、そっくりそのままお返ししますわ
オホホ
なんかさー、この「スルーしろ」っての、決まったタイミングで出てくるよな。 ウソくさいな。自演なんじゃない?
>>733 マジキショいな.. 一人で増やしてるし。ほんの少しだけどwwww 内容キショ〜〜
構ってチャンがウザい
その展開も同じだなwwww なるほどなー。そんな生活してたんかよ?
どうやら図星らしいぞ... ほんとに気持ち悪いぞ
釣れますか?
ぼちぼちです。
SunBlade6000はSPARCチップのほかにINTEL,AMDのCPUが搭載可能ということでしたが、 ・LAN,FC,電源などの配線はブレード毎にすべて外だし ・200V電源4系統必須 ・SPARC系ブレードはシャーシからの電源ON/OFFが不可能(T6300だけ?) ・数年後ディスコンが決定済み(いつかは忘れてしまいましたが・・・) とブレードサーバのメリットをあまり享受できないシロモノでした。 配線はぐちゃぐちゃになるわ、ALOMにバグがあって/var/adm/messages(Solaris)にNEM 0がはずれた(Ethernetボードが取り外された!)と誤検知を1日に数回出力されてしまって、ログを汚されるわで。。。 1Uのサーバを台数分並べたほうが絶対楽だと思いました。。。
こぴぺ乙
正直サポートがなぁ.
ディスコンにならないサーバーなんてあるのか?
779 :
名無しさん@お腹いっぱい。 :2009/06/20(土) 04:10:38
最期の落日ってw 日本語DE OK!
>>778 普通のサーバは、保守契約が終了した時点で、廃棄。
ブレードの場合は、シャーシはそのままで、中身のブレードだけ交換していける
・・・って話だったのに、ディスコンされると交換するブレードがなくなっちまう
って話じゃね?
要するに期待はずれだったってことね
ブレードサーバっていうジャンル自体が、絵に描いた餅。 熱密度が上がる→冷却コストが高くなる→何のために? 高密度実装→床面積を節約→しかし床面荷重が大きいので疎らにしか設置できず→何のために? アメリカなら広い建物を使えばいいだけ 日本だとデータセンターは重量だけでなく電力的にもブレードは無理 いったい誰が必要としているのか。
IntelがSossamanみたいな製品を継続的に出していればもっと流行ったと思うんだ・・・
>>780 そんなウソついて売っていたのか。知らなかった。
他の会社のブレードサーバーも出る度に形が変わって互換性もなにも
無いなとは思っていたが、中身だけ入れ替えるような客がいなかった
から気にしていなかったよ。
>>782 クラウド祭りに乗せてデータセンターの寡占が進めばまた使い道が
出るんじゃないか?
>>783 2コアでよければTDPが30W程度の製品も作れるが、
それを2ソケット構成で使うのであれば、
4コアで50W程度のTDPの1ソケット構成でいいと思うぞ。
>>785 色々なプロセッサのブレードが同じシャーシに載るのは面白かったね。
熱と電源と重量もだけれど冷却騒音もなんとかならないものか。
NEC製の空を飛びそうなブレードサーバーよりはマシだったけれど。
狭いところに均等に空気を流そうと思ったら、小口径・高速回転のファンを大量に付けなきゃいけない。 X4500のような発想で、ブレードを上から挿入するようにすれば、大口径のファンで横から冷却できるかも。
>>787 クライフ先生がNECに興味をもたれたようです
>>789 ラックが走り出すかもしれないって言えば興味でない?
vyattaスレが欲しいのだけど、UNIX板で立ててもいいだろうか?
Linux板じゃだめなんだっけ?
ネット技術板かな、とも思ったけど この板も腕いいのがそろってるかと
通信技術とここと別のアプローチがあるだろうから 好きなほうに立てれば? ここよりLinux板だとは原理理的には思うけど
「両社のどちらかを選ぶとすれば、間違いなく Oracleを選ぶでしょう。 わたしは IBMで働いた経験があります。」
Q: Did you have a preference [in terms of suitors], IBM versus Oracle? A: If it were between those two, I would certainly prefer Oracle. I used to work for IBM. なるほど
−− 我慢できることとできないことがあるということですね。 ゴ: その通りです。
「見知らぬ宿主に寄生するウイルス体になったのです。」 ...こわすぎ〜ww ある意味 DECがそうなってるかもね。
このインタビュワーは、なかなか良い所を突くよな
Sunは幼稚園だったんだ…
そうじゃなければ海のものとも山のものとも付かないソフトなんて どんどん生み出せないよな 業務が固定化硬直化していってやがて死を迎える
>>801 研究開発とか革新的分野をやるにはそういう社風が必要だとよく言われるでしょう。
江崎玲於奈も"organized-chaos"などと言っているが、「いじめが起きないように監視
された幼稚園」とは、それと全く同じ意味。
>>802 考えてみるとマイクロソフトは独自の技術なり製品なりあまり出したことないね
どこかのパクリばかりで
×考えてみるとマイクロソフトは独自の技術なり製品なりあまり出したことないね ○考えてみるとマイクロソフトは独創的な技術なり製品なりあまり出したことないね
>>804 独創的な技術出す人はみんな飼い殺し。だって、土台に問題があるから
独創的な技術は載らないww
互換性と継続性が重要だから、しょうがないべ。 MS-Officeなんか、作ろうと思えば、もっと違うものも作れるが、 前のバージョンとの互換性がネックで、あんな中途半端なものになってるらしいぞ。
>>807 互換性と継続性が「重要」なんじゃなくて、それが「全て」、だろ?
後発なのに激汚いw
unixだって互換性が全てだろ。 Windowsよりも昔のものを引きずってるぞ。
いまだに creat があるしな
奇麗とか汚いとかじゃお金にはならんのだよね。使えるかどうかが
問題なのであって。Windows/DOSは、そこそこ使えるものを安く提供
した点は評価すべき。汚いとか言ってお高く止まってみたところで、
UNIXが普及するわけじゃないし。むしろそういう意識がUNIXの普及を
妨げて来たんじゃないかね。
>>804 独創的な技術って金になるのかい?二番手商法が一番賢いのは松下が
証明してる通りだろ。
> ―― しかしJavaエコシステムの市民としての同社の経歴をどう評価しますか。 > ゴスリング 華やかですね。 Jinitiaterはどうなったコラ!某Nグループの新経理シス*ムはえらい事になっとるぞ
>>800 確かにね。面白いインタビューになってる。
>>812 「同社」ってOracleのことだよ?
突っ込みどころおかしくない?
説明すると長くなるんだけど、ゴスリングの華やかという表現が皮肉なのなら別にかまわないが まじめに答えてるのならoracleのjinitiaterがjava1.3だか1.4で止まったまま、かつ vistaに非対応な現状をどう説明してくれるんだ、という事。 あー、まじめに説明したらつまらないじゃないか。
説明しなくてもつまらないから安心汁
>>814 > java1.3だか1.4で止まったまま
> vistaに非対応な現状
まさに
> They kind of are what they are.
じゃないか。その分より「Colorfull」でいられる。
そんな動作環境がやたらと限定されていて先行き不透明な製品を 長期間運用される重要なシステムに採用した時点でどうかしてる
SunRay使えば大丈夫って・・・
>>817 Jinitiatorって最近の環境では要らないものだから。
古いブラウザ環境で当時としては新しいJREを使うためのもの。
Sun一座を贔屓しないと 好きな役者(フィールド技術者)はリストラで切られる 好きな題目(製品群)も切られる ホントに好きならサービスなり新品なり買ってやるしかない それしかない
それよりも何よりもサーバ関係のサポートをなんとかしてほしい。 ディスク壊れたっつってんだからさっさと代替え品持って来いよ。
動いてる時は感謝もされないのに壊れたらキーキー騒ぐ 全く報われない商売だw
デル、インテル、レッドハットの3社がLinuxサーバへの移行プログラムで協力
http://sourceforge.jp/magazine/09/06/23/1014202 >デル、インテル、レッドハットの3社は2009年6月23日、SPARCベースのSolaris環境からIAプラットフォームへの企業システムの移行・普及を協力して促進すると発表した。
>Red Hat Enterprise Linux/デルサーバへの移行にフォーカスしており、同日、デルが移行プログラムの提供を開始した。
>移行プログラムは、とくに初期費用に着目したもので、SPARCベースのSolarisシステムから、Red Hat Enterprise Linux 5.XベースでXeon 5500番台搭載のデルの「PowerEdge」サーバへの移行を促す。
>これによって、消費電力と設置面積を半分に削減し、3年間の保有コストも最大で 11分の1まで圧縮できるという。
>移行プログラムは、とくに初期費用に着目したもので、 このへんが爆笑 ダメならSPARCに戻る費用も保証します、なら本物かもと思うけどなw
>>823 年間600万も払ってるんだから当たり前だろ!!
というか、他のベンダーさんは「アラートのLED点いてます。ディスク12が壊れたみたいです。」
という電話で遅くとも次の日にはディスク交換に来るんだけど、SUNはそうはいかないんだよ。
普通、アラートランプが点いてたらすぐ交換しに来ない?「これこれこういうソフトを起動して、
こういう操作をして、ステータスデータを取ってメールしてください。」って言われて作業すると
そのソフトがバグってたりするんだよ。しかもアラーとリスト見ると「リブートの可能性があります」
なんて書いてある。
ストレージのディスク交換で1週間もかかるんだよ?サポセンは日本語ろくに通じないし。
ちょっと閣下した書き方ですまんかった。
すまんかったが、ちょっと酷いと思うよ。「機能縮退」から「正常」に戻るまで何週間も
かかったりするんだよ。お客様に謝るのはこっちなんだよ・・・orz
827 :
826 :2009/06/24(水) 03:49:21
うわあ。誤字とかすまん。察してくれ・・・もう寝る。
>>824 これは、SPARC鯖の更新のときに、ついてにx86で再構築しませんか? っていう弱いお誘いでしかない。
だから無視してOK
まさか、
QuickTransitをIBMから買い取って、移行ツールを走らせるだけで引っ越し完了
あとは、ひたすら検証して、不具合があったらQuickTransitを無償で修正しますよ
みたいなことをやるのならともかく。
>>826 Sunから直に買うのをやめたほうがいい。
SunのOEMを売って、保守をSunとは別に自前でやるところ、あったと思う。
>828 無視したいんですね
>>826 バカじゃねーの.. サポートのいいとこから買えよ。そんだけのことだ。
>>811 あんたはずっとその「二番手商法」の製品買っとけよ。
単に「そこそこ使えるもの」なんだったらなんの問題もないんだが、
メインフレーマーが昔囲い込みに使ったのと同じ手法が随所に仕掛けられてて
吐き気もよおすようなシロモンじゃねーか。そんなことがわからないとでも
言うんかよ、Unix使ってた人間じゃねーだろあんた?
unixのほうが、よっぽど微妙に違っていて、面倒だったな
ちゃんと話聞けよ 微妙な違いの面倒で逃げられるシロモノなんだよ 囲い込みとは無縁だよ
話聞け? はぁ? 誰の? おまえ何もんだ?
おまえから逃げた客だよ
>>834 MS-DOSガリガリ書いてた頃は、ハードウェアがまともになる将来は Unixと
統合するつもりだった。OS/2開発してた頃は OS/2に移行するはずだった。
なにもかもユーザーを囲い込むために方針変更して来ている。
そんなことさえ知らずに寝惚けたことを言っているわけなのか君は一体全体。
知らねーんだったら顔洗ってべんきょし直してこいこのガキンチョ
841 :
名無しさん@お腹いっぱい。 :2009/06/24(水) 15:51:19
金さえかければいいものが生まれるとおもってるやつは頭湧いてるんじゃないん?
>>845 バグでまともなステータスデータを送れないっていってんだよ。
脳味噌お花畑ちゃうか。
>>843 せめて金すらないよりは、金さえかければ力技で何とかなる事が多い。
決して金の量に比例してよくなる訳ではないだけ。
IBM and Cray claim victory in battle for supercomputer supremacy
http://www.tgdaily.com/content/view/42962/135/ Meanwhile, a total of 399 systems (79.8 percent) on the Top500 list use Intel processors.
IBM Power processors are found in 55 systems (11 percent),
followed by the AMD Opteron family with 43 systems (8.6 percent).
Knupffer also noted that 33 of the top 500 systems were Nehalem based "only three months after launch,"
>>832 結局、金になってないUnix陣営の負けが結論ですね。
Microsoftのそういう商売を許したのも、Unix陣営が信じられない
ほどのヘタれだったから。だから全部Microsoftにかっさらわれる
ようなブザマな結果になったんだよ。
Unix陣営が信じられないほどのヘタれだったからではなく、 Unix陣営が信じられないほどのつぶしあいをしたからだろ。
>>846 ステータスデータが取れるか取れないかを
HDD壊れる前に事前チェックしてないのか?
そもそもRecommend当ててあるのか?
どっちがお花畑かわかんねw
拝金主義者=M$支持者
なにそれ 現実主義者だろ
ろくに互換のない混沌とした状況をAT&TとSunが統一しようとしたら IBMやDECなどが横やり入れまくったからな
855 :
826 :2009/06/25(木) 02:07:49
>>831 それがSUNそのもののサポートなんだよ。
買ったとこ(セットアップもそこでやってもらった)でのサポートって
できないんだよ。
SUNのプラチナ、ゴールド、シルバー、etcから選ばざるを得ないのよ。
あんまり契約内容とか書けないんでこれまでにするけど、ストレージの
ディスク交換(アラートLED点滅状態で、ステータスモニタにも異常が
でてるのを伝えてる)ぐらいで何日もかかるってのは初めて。
殿様商売で有名な某巨人だってこんなことなかった。
>>855 富士通やNECのSun OEMを買えって。
>>855 ほんっっっっっっっっっっとに、バカじゃねーか?
昔から Sun売ってたとこで買え、って言ってんの。
Sunの直販なんて最近の話。まともにサポートできるとは到底思えん、
もともとそういう会社じゃないし。
自力でなんとかできないもんは直販で買っちゃダメだろ。
Enterprise一万台製品のサポートは日本Sunもまともだったよ。 富士通使ったことあるけど駄目だった。日本Sunよりも。 まあEnterprise百番台の製品の標準サポートだったから仕方ないかも。 サポートも金かけないとどうにもならないよね。
859 :
名無しさん@お腹いっぱい。 :2009/06/25(木) 09:30:35
TOP500 出たけど、富士通頑張ってるねw 22 JAMSTEC SX-9 122.4 131.07 NEC SX-9 地球シミュレータ 28 JAXA FX-1. 110.6 121.28 富士通 SPARC64VII QC 2.52GHz : 40 RIKEN Xeon 87.89 96.75 富士通 PRIMERGY RX200S5, Xeon X5570 2.93GHz [Nehalem EP] 41 Titech Opt/Xeon. 87.01 163.19 TSUBAME/TSUBASA (ClearSpeed + Tesla) 42 U-Tokyo Opteron 82.98 113.05 T2K 日立 Opteron QC 2.3GHz, Myrinet 10G 47 Tsukuba Opteron. 77.28 95.39 T2K Appro Xtreme-X3 Server - Opteron QC 2.3GHz
>>849 ,850
いや、ヘタレだったのは間違いない。なにせ何が欠点なのか大昔から
自己分析できてたのに、ほとんど対策してこなかった。
Solaris Liteとか言ってたけど、ほんの NeXTや MacOS Xや最近の Linuxが
やってた上っ面だけ載せられてれば実現してた。
オブジェクト指向環境もそう。
Motif+CDEみたいなクソのせて「統一」とか言ってて勝てるわけがない。
Motif+CDEはOSF勢に押し付けられたんだけどなw
OpenLookはC++時代に突入しようとしていたのに、 アホの子、CDEにやられてしまったな。 OpenLook+独自Display Postscriptで突っ走れば良かったのに。
>>849 「全部」なんかぜんぜん持ってってないよ。クズ以外選択肢がない状況を
演出してまともな技術を潰してってるだけ。なんて不幸なんだ。
864 :
826 :2009/06/25(木) 14:07:45
>>856 ,857
あ、やっぱりSUNのサポートってだめなんだ・・・
他に切り替えられないかなぁ・・・
・・・とおもったら
>>858 まともかぁ・・
例えば、ストレージのディスクのアラームLEDが点いてたとして
どんな対応?
もしよければどういうサポートをつけてるかも教えてほしい。
一万台なんかそれ専用で下請け出したり人雇ったりできる額だから。 それ以外だとちゃんと仕組み用意してなきゃ無理。 まともなとこ丸投げなら大丈夫だけど、それ維持するのにもノウハウがいるよ。 あたりまえでっせ。
866 :
826 :2009/06/25(木) 15:22:59
>>865 すまん。一万台とか百番台(百万台?)ってどういうことを意味してる?
Sun Enterprise 10000とか Fire 12000, Fire 15000, Fire E20000, Fire E25000。 クレイから来た連中が作ったやつ。
百番台は、Fire 880とか、そういうやつだろ。
869 :
826 :2009/06/25(木) 18:19:48
>>867 ,868
THX
>>867 そのクラスじゃないとまともに相手されないってことかなぁ・・・
入れたのはサーバが千番台x3と16ディスクのストレージなんだよな。
>>864 あまりの必死さにネタかもと思えるがマジレスする。
単に切り替えるだけならサポートは簡単に切り替えることができる。
切り替えたいヤツが決裁権限を持っているか権限者を説得できるかそれだけが条件。
ステータス拾うソフトがバグだというのが確かだとしてもだ、1システムで600万の
サポートを買っているのに一週間も機能縮退で放置されるというのは契約的にも
ありえん対応。筋を通して解決できなきゃ嘘だし、実はその壊れたストレージは
600万の契約内に含まれてはいませんでした。ってのはよくある話。
>>869 妙に小出してないで、ストレージとソフトの名前とバージョンを出して
しまえばいいんだよ。そうすりゃネタを思いつくやつがここにも沢山いるだろ。
呼んだらハードディスクを持ってすぐに来るサポートもいいけど。持ってきた
中学生が壊れたところ引っこ抜いたらループが全部落ちたとか洒落にならんぞ。
後で親が誤りに来てもどうにもならん。サポートは慎重に選ぶべし。
交換用の予備のディスクを先渡しでストックしておいて、自分で交換できる保守契約ってないの? 置き薬売りみたいな感じで。
ある。
873 :
826 :2009/06/26(金) 02:13:14
>>870 マジレスありがとう。
ハード、ソフトのスペック書こうかとも思ったんだけど、
どこのシステムだかバレちゃうとまずいと思って・・・
何しろ、ディスクが壊れたことを証明しないと(”サポートデータ”ってのを
渡さないといけない)交換してくれなくて、そのサポートデータを取るGUI
がバグっててストレージがリスタートされる可能性がある(SUNのアラート
リストに載ってる)のに担当者がやっちゃったり・・・
送ってきたリカバー用のスクリプトがエラーで落ちたり酷かったんだよ。
とりあえず、上とお客さんと相談してみるよ。
長々とありがとう。>レスくれた人
本番稼働っていうかサービスインする前に、ディスク障害時の対処の予行演習をすれば、 もし問題があれば、そこで発覚するので、サービスイン前に対策を済ませることができるよ。
>>873 中の人や関係者にはもうバレてると思うぞ。それはおいといて
不具合があるのがわかっているならツールのアップデートをしなよ。
それはお客の面倒を見ているYOUの責任。
>>874 それで問題を全て潰せると思うのは甘い。
不具合が発生する状況というものは変化していくものだし、826が心配している
トラブルが数回くらいのテストで発現するような問題とも限らない。
えー、いちいち書かないと、すべて潰せると言ってるように誤解されちゃうのー 予行演習すれば、すくなくとも、Sunのサポートがどんなもんだか、わかるでしょ。
>>873 Sunの場合はGUIでなければ取れない情報を要求することないでしょ。
一連の情報をメールにして叩き送るシェルスクリプトにしていたが?
GUIなんかでよくルーチンワークができるね。
>>877 ルーチンワークになるほど頻発するのか?
つーか そもそもアラームがチカチカしてりゃその日のうちにディスク持って
駆けつけるんじゃねーのか??? どういうサポートなんだ?
ペタクラスだとルーチンワークになるくらいは壊れるんじゃね?
ペタでなくても、ストレージ鯖ならディスク故障なんか別に珍しくも何ともない。 その度にいちいちマニュアルをあちこちひっくり返さなければ判らないって程度に 頻度が少ないってものではないな。
すぐに保守員が来る契約じゃなければ、 一度やらされた情報取得はもう一度やらされると思い、 historyからshell scriptを書いておくのは当たり前のこと。 そんなこともできない人は金を払うか、 能力に見合った時給の低い自分の時間を使えばいい。
だからさ ディスク障害で毎回スクリプト流してデータとってメールせんといかんのか? なんか感覚が違うな。
感覚じゃなくてスキルだろ。 スクリプトも書けない奴は面倒だわな。 スキルない奴は金払えばいいんだよ。
なんか通じてねーなw ディスク障害 ー> 電話かメール ー> サポートがディスク持ってくる (ここまでせいぜい2−3時間) じゃなくて ディスク障害 ー> GUIだかスクリプトだかでデータとる ー> メールで送信 ー> サポートがディスク持ってくる (ここまで1週間) になってるのが俺の感覚と違うっての。どこで1週間もめてるのかは知らんが。
サービスは金次第であると見抜ける人でないと(サンを使うのは)難しい。
ディスク障害とかの記録取りなんかは、 最初からメンテナンススクリプトとして用意されてるんじゃなかったのか。
既に消滅が予定されているメーカのサポートが良かろうはずもなく
889 :
名無しさん@お腹いっぱい。 :2009/06/26(金) 23:54:35
落札者がnec*****だな。
多分うるさくて電源入れられないんだろうな V880が糞うるさかったのを思い出した
今日はSun休み?
896 :
名無しさん@お腹いっぱい。 :2009/07/01(水) 16:36:38
昨日の事故ってサンの社員じゃなかったの? >東急田園都市線は30日午後2時5分頃、 >用賀駅で発生した人身事故の影響で、 >上下線とも一時全線運転を見合わせたが、 >午後3時半、全面復旧した。
話題、ないな。
サポートでもめてた話はどうなった?
最近創刊された月間アスキードットテクノロジーズで SPARCの記事が8ページに渡って載ってた 歴史から最新情報までなかなかいい記事
901 :
名無しさん@お腹いっぱい。 :2009/07/03(金) 16:47:42
次に記事になるのは10年後。
メインフレームのCPUの特集が組まれないのと同じで ハイエンドサーバ向けのCPUの特集は徐々に組まれなくなるのは当たり前 それよりも高機能携帯などの影響でARMなど組み込み向けのCPUに興味を持つユーザが増えて 組み込み向けのCPUの特集が組まれるようになったりして
それもない CPUもOSも興味が持たれなくなって久しい
確かにその方が売れそうだな
少なくともSPARCの特集記事組むよりは PS3でのCellプログラミングの特集組んだ方が売れるのでは?
今更か 新型では犬を走らせないようにするという情報も出ているというのに
犬が走らなくなったところで、Cell搭載ハードはもうあるからどうでもいいんじゃね? フィクスターズ的? には。
SPARCっつーか他の石も載ってるんじゃん
またスレタイを考える時期がきたか
SPARCよりもSolarisに力入れてほしい SPARCは正直どうでもいい ハイエンド向けだけでなくもっとユーザに近いところで普及してほしいところ
Sunの普及戦略なんてバラマキ位しかないんだから ハイエンドの手を緩めたら悲惨なことになりそうだが
SPARCでハイエンド市場を奪回するのは絶望的だが Linuxの市場を奪回するのは不可能ではないように思える
Sun社員の希望的観測まで否定するなよw 可哀想だろw
社員はもっと冷静だろ 移行のスキルもなく、Sunのサーバを盲信して使い続けている信者ユーザ様 だろ
Linuxはもううんざりと思ってる客に、Sunにアクセスしやすくさせる試みとして openSolarisもSolarisの無償配布も十分に役立っていると思う あとはSunからH/Wを含め上手にフルサポートを結んでもらうための分かりやすいアプローチが必要だ
SPARC Solarisさようなら
Linuxはもううんざり → やっぱりMS-Windowsですね!
ジレンマがある LinuxにウンザリなユーザにSolarisに乗り換えてもらうためには、 Solarisを無償で提供するだけでなく、 簡単に使えてトラブルが生じにくい、いわゆる「手離れが良い」OSでなければならい。 しかしそうなると、SunはSolarisのサポートでは飯が食えない。
手離れというのが管理のアウトソースも含むとすれば、そこにフォーカスすればよい 機械は手元に置いておきたい、でも管理に人はさきたくないというケースは決して少なくない ハードウェアもOSも、全く手をかけずに動かし続けるということはできないのだから
管理をアウトソースしなければならないほど使いにくいOSってことでダメだと思うぞ。
>>921 > 簡単に使えてトラブルが生じにくい、いわゆる「手離れが良い」OSでなければならい。
使いやすい → サポート不要 てのは違うと思うぞ。
フトコロが浅いシステムはサポート不要だが。
>>923 いや、いまあなたの会社で動いてるLinux鯖を「即」アウトソース出来ますか?って言えば
ノーだと思う
それはLinuxの問題なのだ
Solarisならその点、管理を即アウトソース出来るサーバも多いだろう
今の管理者には別のよりカネになる仕事をしてもらって、後ろ向きの仕事はSunに外注というのが美しい姿
>>924 0/1で考えたら、そうだが、しかし、実際は程度問題だ。
完成度が高いほどサポートに金を払う機会が減るんですよ。
某なんて完成度は低いわ中身グチャグチャだわで、とても使いにくい。
まともに使いこなすには、専門の認定試験をパスした技術者が必要だよ。
・・・Oracleのことね。
技術者だけでなくサポート契約も忘れちゃいかん>神託 忘れるとセキュリティパッチすら入手できないし 後で気付いて契約すると遡及分は割増請求・・・
>>926 どこもかしこもみんなにたようなことしてるやん。
まあ、だからこそプロプラなものは使いにくい
そう思えば以前、Apache のセミナーに参加したとき Apacheユーザ会の人が、「I/O周り等の関係でApacheが一番パフォーマンスが 出るのは Solaris だ」と言い切っていたけど、今どうなんだろ。 もう4、5年前の話だけど。 Apapche本ソースにパッチ送ったりしているApacheユーザ会の人なので 間違ったことは言ってないと思うけど。
4,5年前よりLinuxのIO周りが劇的に改善したという話はないから今も同じじゃね
SaaSなんて..ww バズの典型w
Apacheって、パフォーマンスが要求されるソフトなのに、個別のOSへのチューニングが、ばらばら。 Windowsでは遅いとか、Windowsの流儀に沿わない実装すりゃ、そりゃ遅いに決まってる。 単なる「利用者」からすれば、Apacheが一番速く走るOSを選べばいいだけの話だが、ね。
>>931 Linuxはもう何年も前から同じところをグルグルぐるぐる..
「若い」とか言われてたのも今は昔、現在のほんとの若者は素養がなくて
役に立たんし、10年前の若者はすっかり思考停止(もしくは燃え尽き)ww。
>>932 ,933
つーか、TCP/IPののった Unixと RDBMSでこんなもんが実現できない
組み合わせなんか、ないだろw
>>930 よいといってもLinuxに比べて 1%〜3% 程度ぐらいなもんなので
ハードウェアをリプレイスした方がよかったりとか
ベンチマーク用の設定を知らないだけだろ
ぶっちゃけApacheは旧世代のWebサーバ
>>936 でも商品として売り出して、値段付けないとやっぱりお客さんは不便と思うよ
>>940 はぁ? 商品として売り出されてて、値段付いてる組み合わせでもなんぼでも
あるだろが。
なんのスリ替えだ?
>>938 ,939
そういうくやし紛ればっか言ってるから Linuxまでレベル低いと見られるわけだな。
ま、事実だw
Solarisに力を注ぐのかSPARCに力を注ぐのかは Oracleが何を求めて74億ドルもの金をつぎ込んでSun買収に走ったか次第だろうな Solarisが目的だったなら今後のSolarisには期待できるかもな
Oracleの売り方になるよ?
やっぱSPARCとSolarisとOracleの組み合わせは最高だよね
SybaseとSunは割と仲が良かったと思ったけど、 今後どうなるだろ?
>>934 Windowsチューニングのapacheなんて、
手間かけてメインテナンスする価値ないじゃん。
できあい買うてきたもん動かすのがWindowsの利点だからでないの?
x86でパフォーマンス出すには、腐ってもx86で長年やってきたWindowsに分があったりしないの?
>>950 少量のメモリでGUIアプリを動かすような用途に関しては、Windowsに分があるな
そういう場合ではLinuxですら太刀打ちできない
Windows+IISが速すぎるんだよ
単純に画像のようなスタティックなコンテントを投げるだけならその組み合わせが手軽だろうな モアパワーとか言い出せばキャッシュアプライアンスが欲しくなるだろうが
>>951 それは GTKや Qt、ひいては Xのせいであって、Unixの問題じゃないわな。
この文脈だとそれ含んで Linuxと言ってるんだろうが。
GTKやQtもそれほどリソース食う訳でもない Qt embedded や framebuffer GTKを使った組み込みGUIが Windows CEの対抗馬になっているから
ここまでの話を総合すると、WindowsではApacheよりも良いものがあるので、Apacheを使う意味がない。 unix系にはApacheよりも良いものがないので、Apacheを使い続けている、と。
どこからここまでの話を総合するとその結論になるんだw
ApacheよりもIISのほうが上っていう事例あるもんなぁ。
>>951 アプリに必要なメモリは少なくて済むかもしれないけど
Windowsを動作させるのに大量のメモリが必要なのですが・・・
全然メンテされてないように見えるが、気のせいか
Solarisにはずいぶんと前からNCAというアクセラレータ機能があったけどな ベンチマーク用という感じだったが
キモはカーネルモードでズルをすることではなく、 プロセスやスレッドなどの重量級のリソースの生成・破棄を繰り返さないこと、 なんだがなぁ。 あと、Apacheのワーカープロセスやスレッドをプールするやりかたは、設定が必要でよろしくない。 何らかのリソース制限は必要だが、しかし、パフォーマンスのチュニーングのために設定が必要なのはオカシイ。
Rockっていつの予定だっけ?
最大の巌窟
2009年内
先月下旬のISCA2009で、 Simultaneous Speculative Threading: A Novel Pipeline Architecture Implemented in Sun's ROCK Processor Shailender Chaudhry, Robert Cypher, Magnus Ekman, Martin Karlsson, Anders Landin, Sherman Yip, Hakan Zeffer, Marc Tremblay (Sun Microsystems, Inc.) っていう発表があったんで、いちおう、まだ、打ち切りには・・・なってないよな。 少なくとも発表した人は、まだSunにいると思われ。
伝統のおかげで食ってけてるんだから過去を否定するわけにはいきません
>>969 x86 vs ARM
SPARCなんてカケラも言及されてない
一応釘さしとくが、ARMはRISCじゃないかな。
ARMはDragonBallと同じように、元々はCISCで、そこからコンパイラが生成しないような命令を削ったもの。
>>970 読んでから書けゴミw
ARMの Chrome OSマシンは、是非 Open Firmwareをつんでほしいね。
>>972 ARMはバークレー RISC IIベースだよ。どこ方面掘ってもそう書いてある。
6502の一部機能を参考にしているに過ぎん。
人物特定できるぜ、あわれなこった。
おまいら次スレのスレタイを考えるんだ
976 :
名無しさん@お腹いっぱい。 :2009/07/10(金) 13:50:27
最高の岩礁
最大の磐屋
>>974 wikipediaには、書いてないな。
最高の岩登 最硬の岩磐 最硬の岩床 最硬の岩壁 最硬の岩脈
ARMはデコーダベタベタの設計ありきだろ、元は
>>982 全部の命令の特定位置に指示ビットがあるのに、なんでデコーダーベタベタになんか
なるんだ? 根本的に勘違いしてるなww
最強の石閃
Rockで SPARC、ってことなら、火打ち石か?
みんなクソだってわかってるのに目つむって使ったり作ったりしてるわけだ x86、 儲かるから。歪んだ産業構造で社会利益が膨大に喪失されてる。是正の必要がある。
シリウマに乗るバカが多いからな。乗せられて便乗宣伝するバカが。
連投乙 使う側からすればプロセッサなんて何だっていいんだよ。 ただ、SPARCよりもx86のほうが使いやすいんだよ。 関数の引数はスタックに積まれているんで、いつでも簡単に参照できるしな。
え? Paul Maritzは「何だっていい」とは言ってないけどな。 押しつけるなよ、勝手な妄想をさ。みんなゴミだって思ってんだよ、x86を。
携帯電話には不向きって言ってるだけだろ。
ARM向けに開発してたことがありますが、ぶっちゃけ、x86パソコンでクロス開発でしたね。 基本的にはx86上で実装してテストして、それからARMに移植してたよ。 そのほうが、やりやすかったからね。
「とにかく複雑なのだ。これは長年にわたって積み重ねられたもので、 そのため電力を大量に消費する。電気食いなのだ」 現在ではほぼ全否定に等しいね。
996 :
名無しさん@お腹いっぱい。 :2009/07/10(金) 17:58:34
>>993 初期のパソコン OSは VAXや PDP-11とかでクロス開発だよ。
なにが言いたいんだか知らんが。
>>994 その電気食いのx86よりも電気を食うUltraSPARC T2って・・・
>>996 初期のパソコンは使いにくかったからね。
8bitはメモリが少ないし、16bitになっても8086なんかセグメントがウザかったしね。
998 :
名無しさん@お腹いっぱい。 :2009/07/10(金) 18:06:52
>>997 そういう時期の違う製品を並べてみたりするのも典型的な
インチキシリウマ野郎の特徴だな。
999
>>998 あーすまなかったな、T2じゃなくてT2+な。
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。