1 :
名無しさん@お腹いっぱい。 :
2009/07/10(金) 19:13:24
またスレタイに文句をつけるバカが立てたか
いやー、navi2chでも立つね。初めてやったw
『岩望』じゃなくて『最後の岩願』がよかったかな?
QEMUの SPARCエミュレーションて、どれくらい動くようになった? SunOS 4は上がる?
こんなときでもプレミアムモルツ試飲会はあるわけですね
重複スレの残骸に間違って書き込まれたレスを、こちらにコピペしときますね
112 名前:名無しさん@お腹いっぱい。[] 投稿日:2009/07/10(金) 18:05:54
まあ、普通、組み込み系はクロス環境で開発するわな
113 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:09:58
ARMでネイティブに開発しているとこなんかあるのか?
114 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:10:52
昔はx86は、電卓からの成り上がりだって馬鹿にされたもんだよ。
もともと組み込みマイコンみたいなものだったからね。
115 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:12:17
SPARCですらクロス開発だろ。
116 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:13:30
>>115 さすがにそれは無いんじゃね?
117 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:16:13
ARMとかMIPSとかって、makeにやたら時間がかかるからクロスコンパイルするんじゃね?
SPARCは流石に時間がかかることはないだろ?
118 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:19:02
どっかで読んだぞ
Oracleが開発をSPARCからx86に切り換えたって
119 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:20:19
make時間が問題なのではなくデバッグの容易さが問題だろう
マイクロソフトの中の人がIA64にブチきれた最大の理由が、それ
120 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:20:53
>>118 Rockを捨てた、じゃなくて?
121 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:21:16
OracleがSun買収するよりも何年も前の話
122 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:24:00
>>119 結局、ターゲットのCPUで動かすことが目的だから、デバックは対して変わらねーよ
123 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:25:14
>>122 まぁ、そういう人もいるでしょうな。
124 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:25:20
>>119 MSが問題にしたのはコンパイラの出来だろ?
125 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:29:02
>>124 そのコンパイラはマイクロソフトの自社製だったりするんだわ。
126 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:31:07
>>125 いや、だからコンパイラ開発部門が良いものを作れなかったってことだろう。
127 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:32:43
まあ、ありもので作る方が楽だわな
別にコピペせんでも
128 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:32:59
いや、マイクロソフトのIA64のコンパイラは、悪くないよ。
コンパイル時間は長いものの、同クロックのx86よりは速いコードを出すよ。
129 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:36:19
x86とIA64、それぞれの上でデバッグしてみれば、すぐにわかるよ。
130 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:46:22
>>129 それはx86でクロスと、IA64のネイティブでということ?
131 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:47:40
x86ネイティブとIA64ネイティブの比較
132 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:52:11
ああ、ターゲットが違えばデバッグも違うわな
133 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 18:54:37
MSはx86ベッタリなコードを書いてそうだし。
134 名前:名無しさん@お腹いっぱい。[] 投稿日:2009/07/10(金) 19:18:46
過去のコード資産は捨てられんわな
135 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 19:25:50
マイクロソフトはx86と心中する気がする。
136 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 19:28:22
たしかに
WMでMIPSに手を出したが、鳴かず飛ばずだし
相当にアイデンティティを傷つけられたらしいな
137 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 19:33:51
windowsって、x86_64でも散々だろ?
売れてんの?
138 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 19:41:47
>>132 違うとか、そういう話じゃないぞ。
>>133 それはないだろ。
現実にx86、x64、IA64の3つをサポートしてるんだし。
>>134 WindowsNTは最初からマルチプラットフォームだったので、むしろ過去のコードほどプロセッサ非依存かもしれんぞ。
>>136 MIPSだけでなくSHもARMも・・・
139 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 19:44:34
x86と心中ってのは、x86が主流ではなくなっても、x86のみ対応でやる場合だな。
むしろSPARCと心中するのは誰かな。
140 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 19:50:43
>>138 確かにNTは素晴らしい、マルチプラットホームなカーネルだったな。
でもその路線は捨てたみたい。
141 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 19:53:16
>>139 Oracleはハードウェアと心中する気は無いだろうな
心中するとすれば不治痛かな?
142 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 21:02:05
>>140 やっぱりDavid Cutlerのすごさは偉大
それに対し現在のマイクロソフトの体たらくぶりは酷い
143 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 21:04:42
でもカトラーが現役だった頃のWindowsNTは、使えたもんじゃなかったぞ。
144 名前:名無しさん@お腹いっぱい。[sage] 投稿日:2009/07/10(金) 21:17:03
出て間もない頃じゃ仕方ないだろう
ーーーーーーーーーーーーーー
以上。
隔離対象は
>>20 なんだがなぁ・・・・
大昔のSolaris壁紙で 丸にギザギザっぽいデザインの奴捜してんだけど誰か知らない?
昨日の官僚たちの夏とかってドラマに 富士通?のリレー計算機が登場してたw
>>24 oracle11g の solaris x86版を用意しないオラクルはインチキ会社。
ライセンス料が割高なsparcで客をだまして金儲け
そもそも x86 solaris 使ってるとこなんてあるの? x86 なら Linux になるんじゃないかね
Sunの x86機もそこそこ売れてるらしいからな。そいつらはほとんど Solarisだろ。
pu Windowsだよ。何夢見てんだ。
x86のsolarisはかなり使われてるでしょ。サポート期間も長いし。 Oracleのサーバとしてどうかってことなら、Oracleが出しさえすればx86の方が メインになるんじゃない? でもまぁ、WebStackにoracle clientを入れてくれればうれしいわな。
>>30 MS-Windowsで使うの? Sunのサーバー機を? DELLにしとけば?...wwwwwwwwwwww
>>31 > x86のsolarisはかなり使われてるでしょ。サポート期間も長いし。
うん。昔、Red Hatのプロジェクトに参加した時、調達担当が Red Hatの
サポート期間の短さに頭かかえてたよ。Solarisならまだ何年も大丈夫だったのに。
>>33 おもしろいけど、SUN は Sun にしてほすいw
傾きまくりの Novellに行った時は、いったいどうするんだろ? って思ったけどね。 あんま「ロマンチック」という印象は、ないけどw
Sunの理想って、ネットワークがコンピュータ、とかいう奴?
The Network is the Computer.
その理想を貫くため、 NFS鯖はデフォでworld wide mountableになります。 rlogin/rshなどのr系コマンドはデフォで世界中から有効です。 NICが2つ以上あると勝手にルーターになります。 止めるにはadbでカーネルメモリをいじる必要があるため、素人には止められません。
>>39 シロートだな。
そんなことより sendmailが NISと同じドメイン名勝手に使ってくれる方が
よっぽど大変だったよw
DNSは NISに統合してしまうつもりだったんだろうな。NIS+はそうならなかったが。
>>39 時代背景とそれぞれの出自について無知だ、という意味しかない発言だな。
「Unixって、telnetしたら生パスワードがそのまま見えるじゃないですか〜ぁ?」って
喜々として言ってたバカあんちゃん思い出したわww
sendmailだけじゃなくて、 通常の名前解決の際に、 resolv.confのdomainやsearch行に書いてあるドメイン名とは別に NISドメイン名を勝手にTLDに付けて名前が引かれてたよ。 だから、名前を引く一般のアプリすべてに影響。 あと、Sun的にはNISドメイン名としてDNSドメイン名と同じ名前を付けることを 推奨していた。
KerberosのレルムもLDAPのベースDNもDNSドメイン名に合わせないか?
>>43 その書き方は違うと思うが..
そもそも Sunが OSに含めてたもので直接リゾルバ引くやつはおらんかっただろ?
で、引くやつ入れるんなら BINDも自分で入れるのが作法だった。
Sunの姿勢としては首尾一貫してたよ。
> あと、Sun的にはNISドメイン名としてDNSドメイン名と同じ名前を付けることを
> 推奨していた。
これは NIS+がなかなかできなくて BINDが無視できなくなって以降だと思う。
なんかUNIX板みたいな流れだ
>>45 揚げ足取りではないが、
当時はnslookupもYP経由だった?
そういえば、OS付属のnslookupは何か変で、(実行してもcore dumpするだけ) すぐにbind-4あたりに入れ替えた記憶が、、
SunOS 4の時代?
>>47 BINDは NISの下請けでしか動かんかった。これ SunOS 4の常識。
>>40 すげーなw
「PRIMERGY BX900」が採用され、
2,157ノードからなる大規模システムの
理論ピーク性能は200テラフロップス。
>53 > 理論ピーク性能は200テラフロップス。 「200テラワロス」に空目してしまった orz
だから論理ピーク性能なんてのは単体 CPU性能の掛け算になるに決まってるって なんべん言えば... サル以下?
こんなに手間がかかるようになってしまった ..と取るか、 引続き SPARCアーキの実作業やってるんだな ..と取るか。
ようやく 1.6GHz かよw
T2の実力はクロック数じゃ測れないぜ。 使ってみればわかる。
最後のアップグレード
>>59 今まで、無数の会社が幾度となく繰り返してきた言葉だな。
Niagara3は、まだか? 1.6GHzにクロックを上げるよりも、歩留まり改善して、8コア全部生きてるのを安く売れよ。
あとL2キャッシュを増やしてほしい。
Niagaraのネックはメモリ いくらCPUが省電力でも、性能を出すには大量のメモリモジュールが必要っていうのは痛い。 しかもFB-DIMMだと、それが電力を食う。T2は省電力だったが、T2+は電気バカ食い。
>>61 一社だけ、逆の主張をして永遠のハジをかいたなwwwwwwww
>>61 そして、クロックが速いプロセッサに負けて消えていったんだよな。
SPARC64は2.5GHz前後だ。
それに比べて、Niagaraシリーズは遅すぎだろ。
そういやインテルの痛いのは2GHzすら越えられてないな。
IBM、MS、インテル、グーグル この業界ユダヤ系じゃないと生き残れないの?
資本家にユダヤ人が多いというだけで・・・
>>68 インテルっても
イスラエルとオレゴンの
2箇所でやってんじゃないの?
Sunも研究所があるんだか、提携してるんだか、関係があったと思うが。
今日の日刊工業新聞にこんなコラムがあったw >経営ひと言/日本オラクル・遠藤隆雄社長「太陽を食べる!?」 日食とはサンを食べることですw
日食グラス使って見ないと目がつぶれますよ
食べたって数分後には出てきちゃうじゃないの
ウ*コということですか
ウン
おまえは食べた後数分でウンコ吐き出すのか、しかも口から?? 変ってるな。
Rockって、いつだっけ?
2009年末
Rock is dead
年末に出るならそろそろ、何か情報がリークされても良いはずだね 早く情報が出てこないかな
82 :
名無しさん@お腹いっぱい。 :2009/07/28(火) 23:19:02
出るならね...
便りがないのは無事な証拠
Atmel AT697F SPARC v8で放射線につよいらしい。LEONベース。
あれLEONなんだ
宇宙用はほとんどが PowerPCか SPARCで、OSは VxWorksらしい。 JAXAと SJACの去年の資料に書いてあった。
ギャグとか言ってるのはお前だけだよw
Intel CPUなんかこの世にいっこもなくてもなんも困らんし。消えてくれや。
ハイハイワロスワロス
4004は、必要だったな。8008と 8080も。で、Z80に席巻された後は... もイラネんじゃね?w
MIPS石の NetBookモドキと ChromeOSがおもしろい展開してくれるといいが。 廉価SPARC+SolarisLiteの夢をかなえるかも。 ARM+Android, ARM+MacOSX(iPhone, MacTablet)
Solarisは、ないだろ。 Windows Mobileにも劣るだろうから。 世間一般では評判が悪いWindowsCE系列だが、その原因は パソコンと同一のソフトが走らない偽物な代用品で、何をするにしても不自由である ってことにあると思う。 APIを同一にせず、それ用に作り直さねばならないようにしているのは、 省電力やメモリ節約はOSだけではなくアプリでも作り込みが必要 ということだから、ということを理解すると、かなり見方がかわってくる。 とはいえ、なんでこれが欠けているの? というような不可解なものもあるが。
CEは Richard Rashidがやったもんだろ、Machの。全く別もんだよ。 むりやり APIをパソコン Winにあわしてあるだけだろ。 Solaris劣る? おつむ大丈夫か? ちゃんと使ったことないんだろ?ww
SolarisとかARMとかそういう糞が流行るならもっと早くに流行っているからw PCやモバイルとシームレスじゃないと駄目なんだよ いい加減解れ
本気でバカなんだな... ARM流行りまくりなんだが。 PCとシームレスだ? アホか。いらんお世話にもほどがある。PCな、消え失せろやww
ARMで走っているソフトは、パソコンのソフトとはUIからして違う。
>>95 SolarisのGUIって、Windows Mobileのそれより、優れてるの?
Solarisにはシリアルコンソールしか存在しません
なんの話してんの? Solarisの GUI? どれ? Gnomeのやつか? バカ?
特定の GUI環境に依存した「フルインターネット環境」、かよ? カスだな。 この世から消え去ってくれたのむから。
>>103 名前ばかりのオープン(笑)よりマシ
つかx86もオープンじゃねえかw
文句あるなら自分で書けよwww
>>101 が端的にSolarisが論外であることを示していると思うね。
SolarisではなくLinuxでも同じだね? って話になっちまうからね。
>>103 フルインターネット環境っていうのは、おそらく、技術的な用語ではなく、
PCでインターネットを使うのと同じことが可能、という意味だろう。
たとえばWebでFlashをサポートしているか否か、とか。
>>104 > つかx86もオープンじゃねえかw
x86はまったくオープンじゃない。BIOSもオープンじゃない。
リバースエンジニアリングしなくちゃ作れないし、ヘタなことしたら訴訟ざたになる。
...そんなことも知らねーで言ってんのか。ARMのことも知らんらしいし、
Solarisは使ったことないし。なにしにここきてんだオマエ。
おっちゃんからかいに
無知蒙昧もこもまでくると呆れるな。
>>107 それでまたオープンの定義論争始めるのかw
>>107 SPARCもSolarisもクローズドだった頃から、オープンシステムって言ってたんだがなぁ。
>>106 x86はトップダウンでARMはボトムアップ
直接的な競合が発生するまではまだ若干の猶予があるということだ
.∩∩ ∩| || |∩ | .|| || || | | __| | (__.|. ∧_∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ヽ.___.丿\(・∀・ )< はいstop! うんこレスはここまで! . \ ) \________ | | | .(_(__)
>>111 オープンソースとオープンシステムの区別がついてないようだな。
顔洗って出直してこいガキ。
>>112 x86はクズアーキなので ARMのような省電力は不可能。
今のレベルで既に奇跡。
アーキ下品すぎ。
Solarisのデスクトップ環境なんて10年以上使ってないんだが、 いまどきのFlashメインのWebページとか普通に閲覧できるの?
117 :
名無しさん@お腹いっぱい。 :2009/07/30(木) 20:23:36
このスレに僅かに生き延びた恐竜達は今日もx86を叩いているのか x86 everywhereの時代は目前だというのに
>>115 ∧_∧
⊂(#・ω・) ワロスっつってんだろうがっ!!
/ ノ∪
し―-J |l| |
人ペシッ!!
__
\ \
 ̄ ̄
>>114 混同してるのはどっちだ?
x86はオープンだろ、互換プロセッサだって作られてるしな。
>>115 で、SPARCは? SPARC採用の携帯電話、ないよね。
SPARCはx86を笑える立場にないと思うが。
>>119 Sunはその出自からしてオープンだっつーの。
SPARCのライセンスとかちゃんと調べてから書けよ、このクズが。
OpenSPARC以前のやつな。1980年代のだぞ。
> x86はオープンだろ、互換プロセッサだって作られてるしな。
ボケ。んじゃなんで Intelと AMD等の間で訴訟やってんだよ。
SPARCでライセンスにからんだ訴訟なんて聞いたことないが。
無知蒙昧!!!! 念のためもっかい書いといたるわ。無知蒙昧!!!! デタラメ!
>>120 アホ。プリンタエンジンやデジカメにさんざん使われとるし、
宇宙事業にも使われてる。火星行ってきたらしいなw
x86? 大笑い、わーはははははははっはh
携帯に対する返答がプリンタとデジカメw 宇宙線で脳がバグったか?
ああ、RISCの中でも、なぜ ARMが携帯電話分野で独占的地位を取れたかは、 それはプロセッサー技術要素だけじゃないよ。 もちろん x86は技術要素的に門前払いだが。 プリンターエンジンとしては i960もよかったんだがな。なんで消し去るかな、 有望な芽をさ。クズ残してw 見識ないよな
プリンターとデジカメだと何が不満だ? 組込みの要件って、意味わかるか? とてもじゃないけど、ムリか、ここまでの話からしてwwwwwwwwwwww
凄くスレが伸びているから Rock の情報が公開されたのかと wktk したら、これか w
ぎじゅちゅようそw
>>125 面白そうだ。素朴に知りたい。
プリンタコントローラーとしては最新のAdobe CPSIが提供されるかどうかがキーだと聞いたが。
>>121 > んじゃなんで Intelと AMD等の間で訴訟やってんだよ。
特許侵害だろ。
ただし、x86そのものが特許で排他ってわけじゃないぞ。
>>122 プリンタとデジカメは過去の話だって、スレで散々突っ込まれてるのに、学習せんのか。
絶好調だな
>>124 IPコアとして組み込める・・・ただそれだけの理由でARMが選ばれてる。
>>125 そのプリンタもデジカメも富士通のSPARCliteの話だろ。
しかし、その富士通はSPARCliteをやめたよ。終了。
134 :
名無しさん@お腹いっぱい。 :2009/07/30(木) 22:45:04
アンチx86の恐竜クンは相変わらず元気だなあ
Googleさん曰く 歓迎への SPARC 国際スパーク株式会社 このサイトはコンピュータに損害を与える可能性があります。
あれ、ほんとに sparc international が攻撃サイトになってて firefoxでアクセスできない。 | www.sparc.org の現在のステータス | 疑わしいサイトとして認識されています。このウェブサイトにアクセスすると | コンピュータに損害を与える可能性があります。 | 過去 90 日間に、このサイトの一部で不審な動きが 1 回報告されています。 IEでアクセスしたら、Avastがトロイ検出した(´・ω・`)
ププププ
>>119 x86がオープンだったとしたら日本のコンピュータメーカーも互換プロセッサ作ってる
日本のメーカーは386以降の互換プロセッサ作れなくなってるからな
特許で縛られてるからオープンとは言い難いが要所のライセンスを受ければ可能だろ SPARCがオープンというだけで持ち上げる気は皆無だよ SPARCだろうがx86だろうがSolarisが動いてりゃそれでいい 廉価で高性能なプロセッサとシステムが提供できないなら消えてもらってもかまわん
>>138 なんで、そこで日本メーカー限定なんだ?
> 日本のメーカーは386以降の互換プロセッサ作れなくなってるからな
ソースは?
NECはV30系列で裁判になって32ビットは独自アーキにシフトした。
作れなかったではなく、作らなかった。
それと、日本でもアスキーが386互換CPUを作ってたよ。
CPUはコストも演算能力も工夫より力技が効果的な分野だから 日本レベルの工業国がセカンドソースする価値無いっスよ
x86がオープンだとよwwww サル以下だな。
オイオイ、セカンドソースって、オープンかどうかとカケラも関係ないんだが。 まさか、セカンドソースが出てればそのアーキはオープンだ、とか思ってんじゃ ないよな?
>>132 SHが内部に ARMを抱き込んだのはなぜだ?
(ただしソースはwikipedia[ja])
x86はそんなひどいクソチップだったんですね。すぐに窓から投げ捨てます。
おっそろしく知識の乏しくておツムの弱い x86しがみつき人間が ノコノコとこんなところへやってくるのはなぜだ? 金出ててやってんのか? そういう仕組みか?
>>147 Intelがひどいというよりも日本メーカーがやりすぎたんだよ
もともとIntelは半導体メモリのメーカーだったのに半導体メモリでやっていけなくなり
CPU専業メーカーになったがそのCPUでもセカンドソース品で大暴れ
そりゃIntelだって頭に来る
それに386は当時の中型コンピュータ並の性能をもった高性能CPUだったので米国政府の意向もあったのだろうな
>>148 いやいや
君がもう絶滅寸前の恐竜なだけだよ
x86 everywhereの時代は目前さ
>>149 > それに386は当時の中型コンピュータ並の性能をもった高性能CPUだったので
ここ、爆笑するとこですよね? わかりますw
>>151 言っておくがそのころのコンピュータの性能は全般的に低かったんだよ
普及したのが遅かったから勘違いしてる人もいるが386が出荷されたのは1985年だぞ
>>153 そうか。最初の RISCと同じ頃だな。16MHzで 3MIPSだっけか? 12MHz? 遅いねw
>>154 SPARCはあの時代衝撃的なデビューだったらしい
SPARCを使ったワークステーションの10倍の価格だったDECのミニコンと同等の性能だったらしい
DECの経営を圧迫したのはSun そのSunの経営を圧迫したのがIntelのCPUを搭載したPCサーバ DECは経営が悪化しCOMPAQに買収されその後COMPAQがHPに買収され事実上解体 Sunも経営が悪化しORACLEに買収される よく似てるよな
>>154 80386は 16MHz 5MIPSだな。同クロックなら 68020より MIPS値いいんだな。
知らんかった。
158 :
名無しさん@お腹いっぱい。 :2009/07/31(金) 17:51:40
>>156 DECと Sunは技術的にはきわめてまともな会社。Intelはインチキ。そこが違う。
>>156 DECは囲い込みもやったがシステムの資料等は非常に充実してた。
Sunはオープンという言葉を初めて全面に出した会社。
Intelは全くクローズドな旧い体質の会社。
DECが巨人になった頃、Sunは駆け出しの弱小企業。
Sunは巨大にはならなかったが、Intelは従前からの超巨大企業。
> よく似てるよな
まったく似てない。
>>159 もうひとつ前がある。IBMのシェアを DECのミニコンが食った。
Intelや MSは、企業体質的には昔の IBMによく似ている。
ネタが汎用機/CPUアーキ/OS という違いだけ。
互換性だの幻想「レバレッジ」を駆使して囲い込み。セコい。
一つだけ言えることはIBMだけは別格ですごいということ 優良顧客をガッチリつかんでるのかな
DECのミニコンとUNIXは切っても切れない関係
>>161 以前の所業が脳裏に焼き付いてる人はどんな条件だろうがいくら性能がよかろうが
_絶対に_買わないけどなww
あんなのと Sun混同してるバカって、いったいどういう情報入手の仕方してんだろ。
>>144 セカンドソースの話なんかしてないんだが。
PDP-8、PDP-11、VAX11 これらの機種を調べると1980年頃までのUNIXととても深い関係だったことがわかる
>>159 ある観点で似ているという話をしているのに、
別の観点を持ち出して似ていないというのは、
なんていうか、頭だいじょうぶ?
SPARC、本家のSunと、互換の富士通、その他はパフォーマンスが低い組み込み向け x86、本家のIntelと、互換のAMD、その他はパフォーマンスが低い組み込み向け 結果的には同じだな。
>>165 調べなくても Sunや Unix使ってる人間はみんな知ってるっつーの。
何しに来てるんだ? お金もらったのか? あ?!
会社クビになって、よほど金に困っていると見える。
170 :
名無しさん@お腹いっぱい。 :2009/07/31(金) 18:31:16
>>166 そうか。じゃ、はっきり書くな。
あらゆる観点で、まったく似てない。
で、金もらってんだな? 誰から? どういう狙いで?
Intelは今が絶頂でしょ そのうちシンクライアントやWebに特化した端末が普及したらサーバ側はIntelのCPUが必要だけど 端末のCPUはIntelである必要ないのだから だからAtomとかに力注いでるのでは?
172 :
名無しさん@お腹いっぱい。 :2009/07/31(金) 18:36:50
>>165 ,168
これじゃさ、コイツには Bill Joyの記事引用したって、まーーたく意味わからんわな。
そもそも Bill Joyが誰だかも知らないんだろ? 話にならんわ。
ここで何してんだ?!
>>140 > それと、日本でもアスキーが386互換CPUを作ってたよ。
書籍に付いたとかいうCyrixのCPUでなくて?
>>172 Bill JoyはBSDからだろ
それ以前のUNIXには関係ないしBill JoyもDECのミニコン使ってたわけだし
今のSunはBill Joyに見捨てられたわけだが
>>174 もう帰れや、ウザいぞ。
cshは V6 sh派生だ。viもな。意味解らんだろ? とっとといね。
>>173 おおかた AXの ECGAボードのことかなんかだろ。クズはほっとけ。
逆に荒らしてるのはどっち? Sunのスレだからしょうがないけど DECのPDP-11のアーキテクチャはC言語にも影響を与えてるわけですが
C言語のインクリメントなんてまさにPDP-11のアーキテクチャからとったものだろ
1BSD, 2BSDは PDP-11対象な。3BSD-4.2BSDは VAX。 中心人物は Bill Joyな。BSD同様、Sunの重要人物な。もういいか? もう帰れ。 もう来るなよ。お互い用はない。
UNIX知ってるやつでBill Joyを知らないやつなんていないぞ
以後無視
DECの話を持ち出しただけで何でここまで嫌われるのかがわからない 別にSunを否定したわけでもないのに
>>154 1985年といえばMIPSのR2000
これはワンチップではなく、プロセッサ・ボードだった。
当初8MHzで5MIPS
後に、
16MHzで12MIPS
20MHzで16MIPS
SunのSPARCは1987年かな。
やはりワンチップではなく複数のLSIで実装されてた。
当初16MHzで10MIPS
後に、20MHzで12.5MIPS
80386は当初12MHz、最初からワンチップ。
1987年に20MHzキャッシュ無しで5MIPSくらいだったかな。
33MHzで外部にキャッシュが付くと11MIPSちょい。
SPARCってMIPSより遅いんだな。
そして、キャッシュ無しでワンチップの80386は頑張ってるほうだと思う。
>>171 で、Atomに競合は居ないからこれから一層独占になるわけですがw
>>186 Atomのせいで非 NetBookなノートが売れなくなってる。
結果 Intelの利益率を下げる方向へ行っている。最近記事で出てるよ。
ARMとはぜんぜん勝負になってないし。
>>185 ここの住人じゃないのがバレバレなんだが。
SPARCがベンチマーク的にトップを取ったことってほとんどないよ。
少なくともオレは記憶にない。
何度ここで言われてるんだと。
x86支持の言ってることは全て見当違い。 x86自体の知識も皆無。事実をまったく理解できてない。あわれ。
>>177 AXのECGAってなんだよそりゃ
>>140 V30で訴訟になったから独自路線にシフトとかアホ?
V60は386と同時期に開発やってるんで最初から互換もクソもない
互換CPU作ってたのはアスキーじゃなくてブイ・エム・テクノロジーだし
出資してただけでCPU作ったとか言わねえよ
なんでこんなシッタカぶったバカが涌いてくるんだ
>>173 違う。
アスキー・ヴイ・エム・テクノロジーっていう会社があってね、
インテルを辞めた(2度目)の嶋正利さんのCPU開発会社。
>>188 Niagara出たときSPECwebで取ってなかったか?
日立、富士通、三菱電機、沖電気はTRONチップのGMICROシリーズ出してたな なつかしい
>>187 (ARMと比較して)消費電力と価格が高い現行のAtomでも組み込み向けに10億ドルのシェアを持っている
そしてこれからもどんどん微細化してコストも消費電力も下がる
>>195 TRONって、本当に癌だったよな。
もしTRONにリソースを浪費させられなければ・・・と思うと・・・ねぇ。
TRONの32bitマイクロプロセッサはNEC Vシリーズと並んでいいCISCだったよな 中途半端な680x0とは違う綺麗な命令セットで当時は使ってみたいと思ってた OSのB-TRONもなかなか面白かったから米国のクソどもが茶々入れてなけりゃ もうちょっと違った世の中になってたかもしれん
いよいよ腐ってきたな、このスレ
SPARCにしがみついたままの連中がいるからな
>>198 いや、TRONは絵に描いた餅だったってば。
坂村の言うことを真に受けて洗脳された人たちはヨイショしてたけど、
実際の開発をしていたメーカーの人たちはボロクソに叩いていたよ。
坂村は旗振り屋なのに、あたかも自分が設計したかのように吹聴して回るし、
しかも、その設計が一流あるいは新規性があるならともかく、二番煎じでダサい。
きな臭くなってまいりました
TRONの仕様を無償公開した、メーカーは自由に使うことができる そんな恩着せがましいことを言ってたが、その仕様が酷いシロモノだった 見たことない人はググってみ アメリカの外圧で潰されたとか以前に、WindowsやMacOSに対抗できる実力がないことがわかるから。
G-MICRO出た当時はDOSが幅きかせてた頃だよな? なかなか出なかったOSはともかくCPUは悪かったのか?
RISC CPUに性能面で差をつけられてたからな TRONチップは開発したメーカーですら採用しなかったようなCPU
そういえば、坂村氏が自画自賛していたTRONチップの命令セットは洗練されてたのか?
なわけないじゃん。 アトミックな文字列操作の途中に割り込みが入るのは良くない なんて言うような人だぜ?
> アトミックな文字列操作の途中に割り込みが入るのは良くない > なんて言うような人だぜ? へー。アトミックな操作中に割り込みが入ることが許されるんだw アトミックって言葉の定義がおかしくね? おまえの頭。
普通の人
「アトミックな文字列操作」に呆れる
>>208 の人
「アトミックな操作の途中に割り込みが入るのは良くない」のは当たり前だ、どこがオカシイの? と相手を罵倒する
文字列操作がアトミックである必要がないという話なんじゃないの?
V60とか懐かしいね
もしかしてTRONチップのストリング操作命令がアトミックだと信じてる バカがいるのか?
俺はTRONチップの命令セットよりも680x0系の命令セットの方が好き
いまさら墓を暴いて死体に鞭打ってもなぁ。
アセンブリ言語で書くならVシリーズがずっと良さそうに見える 68kとは違って本当の汎用レジスタだし本数多いし 性能はどうだったのか知らんけど
レジスタの本数が多いと、その割り当ての管理が面倒なんだよ。
だからといってレジスタウインドウは?
レジスタが多いほうが楽しいと思ったんだよ!
SPARCもレジスタの数を増やせるアーキだったらよかったのにね (レジスタウィンドウ数じゃなくて・・)
レジスタの割り当て管理が大変・・・?
アセンブラで書いていた時代の話、今の人には、わからんだろう。 RISCとCISCでは、レジスタと言っても、それは別物だったのだし。
多すぎるなら必要数だけ割り当てておけばいい話 そんなことを大変だとか意味不明
知っているなら大変な点を説明してみれば?
聞く気がない人に説明してもなぁ ていうか 経験がない人には説明しても無駄
根拠が曖昧だから説得力のある説明ができないと?
「めんどくさくなる」この一言で説明おわりなんだが、
>>228 には理解不能だろ?
うまく説明できないということですね、わかります
そういうものなんだよ、わかれよ、とか 説明したってわかんねーよと言い張ってごまかす人を思い出した
232 :
名無しさん@お腹いっぱい。 :2009/08/02(日) 16:51:12
chaitin graph-coloring register allocator 位は学校でならなかった?
手間が増える。 なぜか、レジスタが多いから。 門外漢には意味不明だが、アセンブラでコーディングしている人には良くわかる。
234 :
名無しさん@お腹いっぱい。 :2009/08/02(日) 17:07:19
x86 の欠陥はレジスタ数が決定的に足りないところw
その分高速だけどね
C言語で言うならば、レジスタというのはグローバル変数のようなものなの。 C言語でauto変数を使わずに、g0〜g31という名前のグローバル変数を、 うまくバッティングしないように人間が「管理」して使いまわす・・・考えただけでゾッとするでしょ。 レジスタが少なければ、レジスタとメモリあるいはスタック間でのやりとりの手間は増えるが、 しかし、スタックはグローバルじゃないし、メモリは複数の用途に使いまわすようなことは (よほどメモリに窮する場合でなければ)しない。
レジスタが豊富→レジスタの内容をメモリに退避する頻度が低くて高速、しかし、動作クロックは遅い レジスタが少ない→レジスタの内容をメモリに退避する頻度が高くて低速、しかし、動作クロックは高い 一長一短だね たとえば128本のレジスタと演算器との接続、レジスタからのロード命令が欲しくなるくらい、通るゲートが重そう。 かといって、汎用レジスタではなく演算器の付属物なのは、勘弁してほしいが。
238 :
名無しさん@お腹いっぱい。 :2009/08/02(日) 17:17:17
その辺は20年以上前にグラフ理論をベースに技術は確立されてる。職人芸を否定はしないが、 新しい(そんなに新しくもないが)技術を学んでいかす事も大切。
239 :
名無しさん@お腹いっぱい。 :2009/08/02(日) 17:20:36
RISC のクロックが伸び悩んでたのはスーパースカラのための命令の依存性のチェックに 手間取るためで、その辺割り切るとクロックは CISC よりあげやすい。Alpha しかり。 Power は 4, 5GHz で x86 より高クロックだと思うが。
>>236 g0〜g7にしとけよ
あとその例だとレジスタウィンドウ万歳じゃねーの?
今はそういう流れじゃないよ、残念ながら
そのときはそう思ってたんだよ!
>>241 んー、SPARCのレジスタ・ウィンドウよりはIA-64のレジスタ・スタックだな。
まぁ、レジスタ・ウィンドウは必要ないっていうのは、かなり早い時期に実証されてる。
にもかかわらず、IA-64がレジスタ・ウィンドウの発展形を実装したのは、どういうことなんだろうね。
レジスタ本数の少ないx86では、スタック操作を高速に行う必要があってさ。 その延長線上で考えると、スタックの先頭をレジスタに割りつけてしまえ、ってなるのさ。
今夜の官僚たちの夏は「電算機」話だよw
テレビドラマで勉強しちゃいかんよ。
>>243 > まぁ、レジスタ・ウィンドウは必要ないっていうのは、かなり早い時期に実証されてる。
実証されてねーよ。実例示してみろ。
レジスタウィンドウが不利な状況があり得る、ということに過ぎん。
状況は時代の変遷でコロコロ変わる。
>>247 MIPS
MIPSはレジスタウィンドウを持たないが、しかし、レジスタウィンドウを持つプロセッサよりも速かった。
>>248 ...でさ、その速ぁ〜い MIPSが出た後で、レジスタウィンドウを持つプロセッサーが
出てないのか?
オマエ真性だなwwww
MIPS MIPS言ってるバカは、MIPSをおとしめるためにやってるんだろうな。 技術的な話なんか一切ないしな。セコいやつだな。恥しくないんかね、人として。
>>249 それは、SPARCにバイナリ互換を切れと言ってるのか?
>>250 はいはい、ファビョらない、ファビョらない。
>>249 レジスタウィンドウを持つプロセッサーで最新なのは・・・痛ニウムだな。
現存でレジスタウィンドウを持つもの SPARC IA64 持たないもの ARM x86 レジスタウィンドウを持たないほうが主流だね。
SPARCやi960のレジスタウィンドウには欠点があり、am29kはそれを解決していた。 しかしSPARCのレジスタウィンドウは、am29kのようなものに改善されなかった。 なぜか。バイナリ互換が損なわれるから。 SPARCのアーキテクチャがイマイチだっていうのは、もう明らかなんだよ。 でも、バイナリ互換のために、使い続けているんだよ。 それはx86も一緒だな。
なんの証左にもなっとらん。MIPS使うやつって、アホやねんな。
>>255 MIPSの後で Alpha出たよな? で、その技術構成要素の差は全て「劣悪」て
ことになるのかよ。幼稚園児かおまえは。
レジスタウィンドウの話は繰り返し繰り返し出てるが、具体的な問題点は 一度も明示されたことはない。 今回のは特に、話にならん。 ない、ってことだな、要するに。 「クロック上げにくい」だの、「使い切った時のペナルティ」だの、アホ話ばっかり。 そんなもん初期の設計時点からわかりきったことで、トレードオフ検討した上で メリットありと判断してるから盛り込んである。 おいアホ、少しはまともな理由付けをしてみろ。
>>256 >>257 アホだの幼稚園児だのとレッテル貼りしなきゃならんほど、ぐうの音もでないのか。
>>258 > 「クロック上げにくい」だの、「使い切った時のペナルティ」だの、アホ話ばっかり。
あんたが認めたくなくてアホ話と言ってるだけで、それが具体的な問題点だよ。
こういう FUDのたぐいって、やればやるほど自分が支持するものの評価が 下がって行くんだけど、わかんないのかね? どうせ「おつむよわい」ってここでさんざん言われてるやつだと思うけど。
>>262 それは技術の一側面を表してるだけで、問題点の実証でもなんでもない。
第一、それを上回る手続き呼出しの高速化というメリットがある。
ほかに何もあげられないんだな、問題点。みじめなこった。
>>264 現実に、SPARCがベンチマークで遅いのは、どう説明するの? 実証ではないと?
エンタープr
>>265 ...おまえがバカだということばかりが、実証されまくり。
昔ならともかく今のソフトウェアはプロシージャコールのネストが深い 8レベル程度では頻繁にトラップが発生する トラップハンドラ自体は短いのだが、その移行のコストが馬鹿にならん かといってレジスタを増やすわけにもいかない レジスタウィンドウの行き詰まりである
>>268 あのー.. レジスタウィンドウだとウィンドウ数は実装で好きなように
増減できるんだけど。手続きからの見かけ上のレジスター増やすんじゃなくて。
で、ウィンドウ数増やすのがモロに対策なんだけど。
> レジスタウィンドウの行き詰まりである
何も行き詰まらないんだけど。
そもそも、「8レベル程度では」って、v7とかの頃の話?
# レベル低〜。本気か?
もうひとつ言っておくと、短に呼出しのネストが深いだけなのが問題じゃなくて、 ウィンドウ数超える深さの行き来が頻繁に起こる場合メリットが相殺されるので あって、深い段階に行ってもその時のウィンドウ数の範囲内で留まるのであれば 高速化の効果を十分に享受できる。 短い手続き呼出しが瀕出するプログラムにおいても、一概に不利とは言えない。
>>270 ウィンドウレジスタがうまく働く場合はたしかにそうなんだけど
平坦にたくさんレジスタ使えるほうがやりやすいよね、
てのがその後の方向性かと
むかしの貧弱なハードでは資源節約のため
細かい関数コールが多かったんだけどね…
>>271 > 平坦にたくさんレジスタ使えるほうがやりやすいよね、
ほう、多段にネストした手続きに多数のレジスタを効率良く割り振る手法は、
例えばどんな方法?
> てのがその後の方向性かと
そんなことないと思うね。Itaniumは?
むしろ舞い戻ってきつつあるのがトレンド。>247に書いたとおり、
どういう手法が有利かは状況によって変わっていく。
> むかしの貧弱なハードでは資源節約のため
> 細かい関数コールが多かったんだけどね…
またそんな適当なことを。
オブジェクト指向言語が普及して手続き呼出しのネスト具合は深くなる傾向だろ。
昔は資源節約で細かい関数コールだぁ? ウソこけ。C言語でそんな配慮して
書いてたなんていう事実はない。
突っ込んでほしいのか Itaniumがトレンドって、どこのトレンドだよ! 多段にネストした手続きって、ウィンドウレジスタ有利前提かよ!! つか、お前ディスクもメモリも少ない時代にプログラム作ったことないだろ!!!
そんな時代に生まれなくって良かったと 心からそう思う今日このごろです
今はビットフィールドなんてほとんど使わなくなったしな。 本当にいい時代になった。
レジスタウィンドウだからOoO実装しにくいの? それともSunの実装が悪いの?
SPARC64はOoOだよ
富士通の実装にはあって、Sunの実装にはない理由はなんでしょう?
279 :
名無しさん@お腹いっぱい。 :2009/08/04(火) 09:00:40
>>273 > 多段にネストした手続きって、ウィンドウレジスタ有利前提かよ!!
なるほど。手続きを多段にネストさせないわけだな? そいつはすごい。
...ところで、MIPSの取ってる手法をご披露いただけるかと思ったんだが、
違うんだなww 知らないわけ?プ
> つか、お前ディスクもメモリも少ない時代にプログラム作ったことないだろ!!!
わはははははははははは。アセンブラで? 商用 RISC以降で? 知識ないんだねw
>>273 > Itaniumがトレンドって、どこのトレンドだよ!
Itanium以降で新しい ISAって、あんまりないと思うけど。
SHくらいじゃない? あとはマイナーなやつしかないでしょ。
そんなにレジスタウィンドウが問題なら、レジスタウィンドウなくした
ISAが新規提案されて意味があるだろうしね。
>>275 ジャンルによるよね。OSやネットワークプログラミングだと使いまくりだよ。今でも。
ふつーのアプリだと確かに皆無。
>>280 SH1が 1992年、SH3でも 1995年出荷。
Itaniumは 1994年共同開発を発表、詳細の発表が 1999年だから
SHの方が古いね。
ちなみに、i960は非常に優秀で売行きも堅調だったが、 DECから StrongARMを入手したことで部隊を PenProに移し、打ち切られる。 Am29kも優秀なアーキで多数出荷されており、後継にスーパースカラーや OoOを 計画されていたが、K5を開発(中身は結構 Am29k)するために打ち切り。 レジスタウィンドウの CPUで自滅したのは正味 Itaだけ。
米Appleは8月3日(米国時間)、 米GoogleのCEO、Eric Schmidt氏が自社の取締役を辞任すると発表した。 Googleの事業領域拡大でAppleとの競合関係が強まっているためという。 Schmidt氏は2006年8月からAppleの取締役を務めていた。
>>272 > そんなことないと思うね。Itaniumは?
普段はItaniumを貶しておいて、こういうときだけ持ち出すのは卑怯だな。
>>269 > レジスタウィンドウだとウィンドウ数は実装で好きなように増減できる
> ウィンドウ数増やすのがモロに対策なんだけど。
SPARCの名前のスケーラブルというのは、まさにそれなんだが、
ウィンドウ数を増やすのは性能を上げるためではなく、性能低下を防ぐため。
ソフトウェアに合ったウィンドウ数が「必要」なのであって、誇るポイントじゃない。
> そもそも、「8レベル程度では」って、v7とかの頃の話?
いま13レベルだっけ? どんどんレジスタを増やさないといけないね。
128本もレジスタがあっても、そのうち頻繁に使われるのは32本だけ。
しかも、用途が限られていて、自由に使えるわけじゃない。
>>272 > ほう、多段にネストした手続きに多数のレジスタを効率良く割り振る手法は、例えばどんな方法?
具体的な手法を知りたければ、しかるべき論文に当たるべきだろう。
俺はIEEEの会員じゃないんで、当れない。
で、結論だけは周知なわけで、
MIPSは、そんなに多数のレジスタは必要ない、そこそこの数のレジスタを使いませば良いという話。
同時期のSPARCよりもMIPSのほうがレジスタの数が少ないのは、そういうこと。
> Itaniumは?
あれはレジスタウィンドウというよりはスタックのレベル0キャッシュのようなものだよ。
それを操作する命令は、スタック操作そのものだよ。
>>277 SPARC64のOOO実行は、何か無理をしているって話をどこかで読んだ。
そもそも、RISCにOOOは邪道だ。
1命令を1クロックで実行するのだから、コンパイラが上手に命令を並べれば、OOOは必要ない。
それに、OOOはトランジスタと電力を浪費するので、マルチコア時代には不適切な技術だろう。
>>283 > ちなみに、i960は非常に優秀で売行きも堅調だったが、
嘘を付くな。
i960は本来の用途がポシャって、しかたなくI/Oプロセッサとして再利用されたのよ。
メインプロセッサとしてi960が積まれたシステムなんて、ないに等しい。
Am29kが優れていたのは、その通り。x86のために打ち切られたのも、その通り。
そのAm29kよりも劣っていたSPARCが現在まで残っているのは、Sunが固執したからだね。
ていうかさー、ここSunスレなんだよ。i960とかAm29k、少し前にはARMの優秀さを主張していたが、
それらが優秀だとしても、SPARCが優秀だってことにはならんのですよ。
>>290 「クロックを上げることを選択」したくせに、富士通がSPARC64で実現したクロックにさえ
追いつけていないが…
>>292 それはSunがダメダメだから。
最先端のプロセッサは、その製造を他社に委託してちゃ、クロックは上げられんのですよ。
>>285 はぁ? 普段けなしてると例に持ち出しちゃいかんのか? 却下。バカ?
>>286 はぁ... めんどくさ。仕様上は 32セットまでいけるわな。
> しかも、用途が限られていて、自由に使えるわけじゃない。
意味不明だな。レジスタ足りないの?
>>287 > 具体的な手法を知りたければ、しかるべき論文に当たるべきだろう。
> 俺はIEEEの会員じゃないんで、当れない。
あははははははははっははははははははははははははははははははははははははははははははははははははははははははははは
IEEEの会員? ひーーww なにそれー??ww IEEEが元締めで決めてんのかー初耳ー
> で、結論だけは周知なわけで、
とんでもない押しつけ論だな。そういうの「結論ありき」つって常識ある人からは
気嫌いされるんだけど、知らないの?
>>289 いや。ウソなんかつかん。Intel上層が取り合わなかっただけ。
i960はきわめて優秀だった。典型的な戦略ミス。
> それらが優秀だとしても、SPARCが優秀だってことにはならんのですよ。
レジスタウィンドウは優れた技術。今そういう話してんだぞ? 文脈わかってるか?
アホ過ぎて話にならんわ。最初から勉強してこいや。
>>290 そうだよ。性能上のトレードオフでその都度選択してるだけ。
レジスタウィンドウのメリットを取れば共存の難しい手法を見送る、
別になんの変わったこともない。
他の手法のメリットを取って、レジスタウィンドウの実装にシワよせが来たところで、
わかってやるんならそれもまたいいだろうし。
最初の UltraSPARCは SuperSPARC IIまでの反省をいろいろ盛り込んで
設計されたが、コアのシンプルさを損なうものはできるだけ避けている。
レジスタウィンドウを悪者にしたくてしょうがないバカが 1名いるが、
とてもそんなことを理解できるレベルではない、ということがここまでで
はっきりした。
あまりにバカ話でレベル低すぎるのでもう相手はしない。
> あまりにバカ話でレベル低すぎるのでもう相手はしない。 約束を守れよ
>>294 > はぁ? 普段けなしてると例に持ち出しちゃいかんのか? 却下。バカ?
SPARC > Itanium > SPARC
ほら、何かオカシイだろ。
>>294 > はぁ... めんどくさ。仕様上は 32セットまでいけるわな。
32セットだとレジスタ何本だ? 280本か? 多いな、とてつもなく多いな。
> 意味不明だな。レジスタ足りないの?
その前の行の
> 128本もレジスタがあっても、そのうち頻繁に使われるのは32本だけ。
ってのがあるんだから、レジスタが無駄に余るって話をしてることくらい、わかれよ。
1回のプロシージャコールで、入力8本出力8本ってのは、多すぎるんだよ。
それに、何でもかんでもレジスタ変数にできるわけじゃないしな。
> IEEEの会員? ひーーww なにそれー??ww IEEEが元締めで決めてんのかー初耳ー
その手の論文の投稿先は、たいていIEEEなんだよ。
> いや。ウソなんかつかん。Intel上層が取り合わなかっただけ。
> i960はきわめて優秀だった。典型的な戦略ミス。
売れ行きが堅調だってのが嘘なんだよ。
敗者復活戦のI/Oプロセッサ転向前に、いったいどれだけ売れたというのだ?
i860のunixワークステーションはクボタの製品を見たことがあるが、
i960のunixワークステーションなんて見たことないぞ。
> レジスタウィンドウは優れた技術。今そういう話してんだぞ? 文脈わかってるか?
Am29kのようなレジスタウィンドウが優れているのであって、SPARCのそれはイマイチだって話だ。
>>298 わかった。じゃ、あとは IEEEに出しとくから、IEEEからもらって読んでくれ。
...ぷ .kkkkkkkひーーひーーwwwwwwwww
IEEEって、会長志村けん?
ACM じゃだめかよw
いえええ
IEEEれカス
自社で半導体工場を持たないメーカーがサーバー向けCPUを開発するのは無理 成功してるメーカーはもう残ってない SUNはSPARCの開発をやめて富士通に一任すべきだよな
富士通も半導体工場持つの止めるよ
「ムーアの法則の前に投資規模が..」云々いうやつは、Intelでさえ軽く 耐えられないから、何も心配ないよ。 だいいち、サーバー向け CPU作ってる会社が既に数社しかないのに、 以前の方法論当てはめてみたって意味なんかないし。
>>299 査読のあるやつに投稿しろな。
査読が通ったら知らせてくれや。
IEEEって、論争になった時、卑怯な手に使えるんだね。知らんかった。これは便利
いいかげん見苦しいぞ
次はセグメント方式ではじまりそうだ。
>>310 お前が見苦しいって言われてるの、わかってないでしょ
>>310 セグメントは IEEEで禁止されている。作った CPUは回収命令w
キチガイって、すぐ IEEE言うやつだろ?w
連投がなぜ見苦しいのか、 具体的な理由を知りたければ、しかるべき論文に当たるべきだろう。 俺はIEEEの会員じゃないんで、当れない。 で、結論だけは周知なわけで、 連投は見苦しいので、 そんなに多数の投稿は必要ない、そこそこの数の投稿を使いませば良いという話。 オマエよりオレのほうが投稿数が少ないのは、そういうこと。
すっかり過疎化しましたな
Software Design 5月号の Les Kohn氏の UltraSPARC, Niagara開発記事、 やっと入手して読んだよ。面白かった、参考になった。 なんで PDF DVD付きの号に載せるかな。一瞬で入手難やんけww
まあ、Afaraが起業時に SPARC選んでる時点でアーキへのイチャモンは却下だな。 IBMで RS/6000やったおっさんが HAL起業した時も SPARCを選んでる。 最も当時オープンな RISCアーキは SPARCしかなかったそうだが。
Cobaltも SPARCつっこみゃよかったのにな。
SPARCは価格競争が進んでおらず、高くても売れる = 参入する価値あり、だろう。 Cobaltは安いプロセッサを使わなきゃならんかったので、SPARCは採用できんかっただろう。
「SPARCが」価格競争するの? おつむだいじょうぶ?
商用UNIX向けとしては一番安い。というか安っぽいと思う
Jupiter+まだー?
そのまえに Rock まだー、でしょ。
もうRockのことは忘れろよ…
Rock死すともSPARC死なず
「死せず」の方がいいんじゃないか?
>>323 は曖昧な日本語が通じないようです。
プロセッサ開発には莫大な費用がかかるわけで、
x86のように薄利多売状態になっているところには、
後発の参入は不可能。
SPARCはプロセッサ自体の薄利多売は行われておらず、
用途によって住み分けも行われており、後発の参入が可能。
世界一売れてるCPUはi8051とそのコンパチ 最近みた例だとデジタルのVRMコントローラに入ってた。 8051だけど、処理能力は50MIPSとか書いてあったな。
>>330 SPARCが高かったら、他のアーキの CPU使うだろ。
SPARC内での競争が起こるなんて想定は滑稽。
例えば、Sunが hyperSPARC採用する以前の富士通や、当時の互換機メーカーは
複数社の SPARCを選ぶ状況にあったが、SPARCが高けりゃ SPARC機をやめるという
選択肢があった。
曖昧な日本語? ご都合主義もたいがいにしてくれ。
>>332 あなた、日本語がわからないか、相手の発言を読む気がないのね。
x86ほどの熾烈な価格競争がない = 高い
って読めるだろ、ふつう。
>>333 そりゃこっちのセリフだ。
そんな比較に意味がない、「SPARC内(という壁の中)での価格競争」など
ありえない、と言ってる。
そんな概念捏造して誘導しようなんざ最低の人間のすることだ。
あれ、SPARCが高くて価格競争もないから、新規参入しやすいって話じゃなかったっけ。
そうだよ。 SPARC内での価格競争がないなら、なおさら、参入しやすいね。 事実、富士通は(買収によるとはいえ)SPARC64に後発で参入したしね。
SPARCが高いからSPARCやめるだと? アホか。 人はプロセッサで選ぶんじゃない。 ワークステーションあるいはサーバのパッケージで選ぶんだよ。 SPARCが割高だろうと、 それを積んだワークステーションが魅力的ならば、 SPARCを積んだワークステーションが作られるんだよ。
> SPARCが高かったら、他のアーキの CPU使うだろ。 POWERはSPARCより高いけど? あんたの言うことが正しければ、IBMはPOWER捨ててSPARC64に乗り換えてるだろ。
>>337 囲い込まれた環境しか使ったことない人間は、無条件にそういう考え方するんだよな。
洗脳されまくってるよ。アホはおまえ。
もはやどうでもいいことを熱心に語り合ってるのな
>>338 へぇ。POWERはいくらで、SPARC64はいくらなんだよ? 差額はなんぼなの?
342 :
名無しさん@お腹いっぱい。 :2009/08/20(木) 21:09:20
プロセッサで買う顧客もいれば、 OSで買う顧客もいて、 値段で買う顧客もいる どれかひとつに決めようとするから変な議論になる
343 :
名無しさん@お腹いっぱい。 :2009/08/20(木) 21:15:58
Oracleの考えているロードマップが不明なんで議論しても無駄。 存続か死か。ゆっくりと待ちましょう。
【Flash Memory Summit 2009】
Sun「SSDオワタ」
http://pc.watch.impress.co.jp/docs/news/event/20090820_309421.html Sun Microsystemsのキーノート講演では、フラッシュメモリ担当
リードテクノロジストを務めるMichael Cornwell氏が発表した。
同氏はNANDフラッシュメモリのベンダーはコンシューマ用製品の
開発と製造に力を入れており、エンタープライズ用製品にはあまり力を
入れていないと述べた。また記憶容量当たりの単価を下げることに夢中
になるあまり、エンタープライズ用製品では不可欠な書き換え可能回数、
書き込み速度、読み出し速度といった性能を犠牲にしていると批判した。
例えば書き換え可能回数は3年前に比べて10分の1に減少し、書き込み
速度は2年前に比べて4分の1、読み出し速度は2年目に比べて6分の1に
低下した。このままではNANDフラッシュメモリのレイテンシ(最初のデータ
を読み出すまでの時間)はHDDの2世代遅れになってしまう。そして50nmを
切るような微細加工技術でエンタープライズに適したNANDフラッシュメモリ
を提供できるベンダーは、ほんのわずかになってしまうだろうと展望した。
それよりSPARC/Solarisの心配でもしてろよ
ねえ、Jupiter+まだなの?
>>344 Sunはビジネスが下手だなぁ。
SLCがなくなったら、MLCを使う良い口実になる。
MLCだと消耗での交換頻度が高くなるので、ストレージへの書き込みによる従量課金が可能になる。
これ、ビジネスチャンスだよ。
このスレはビジネスの上手な
>>347 氏の今後を見守るスレになりました
従量課金で割高になるなら大半の利用者はHDD使うだろうから終了 フラッシュメモリの先行きが不透明なのは今に始まった事じゃないんで MLCチップを高速な不揮発メモリと組み合わせてなんとかしようと動いてるし 内部情報取得や書き込み制御などOS側から歩み寄る動きもある 色々工夫してそれなりにやっていくだろ
場当り短絡な「狂争」が分野によっては(場合によっては全ての分野で) デメリットを生じる、という典型だな。 みんなしてダイエーでカラーボックス買ってたようなもんだ。 PCはゴミ。
司法省買収承認。
> 例えば書き換え可能回数は3年前に比べて10分の1に減少 その代わり、大容量になったよね。 ブロックあたりの書き換え可能回数が1/10になっても、 容量が10倍になれば、チップあたりの書き換え可能回数は同じ。 コントローラ次第で、3年前の製品と同等の機能・性能を実現できる。 コンシューマだと、 耐久寿命よりも性能寿命のほうが短いという判断されやすいから、 どうしても、寿命よりも容量が優先されちゃうね。 > 書き込み速度は2年前に比べて4分の1、読み出し速度は2年目に比べて6分の1に低下した。 それは1台のドライブで使うフラッシュメモリのチップ数が増えたから、だよ。
>>352 > 容量が10倍になれば、チップあたりの書き換え可能回数は同じ。
詭弁の典型だな。メーカーの関係者なんだろうが。
10倍になる意味がないわな。
不揮発メモりやすくならないかな。MRAMでもなんでもいいから
>>353 書き換え可能回数と容量のあいだのトレードオフを、
メモリチップのメーカーではなくユーザーが選択できるのよ。
>>355 なるほど。カタログにもそう書いてあるといいんだけどな。
>>354 東芝のFeRAMどうよ。
128MビットでDDR2互換
>>356 チップ自体が持つ機能じゃないから。
ユーザーの用意するコントローラ次第だから。
で、Rockはいつ出る予定だっけか?
おととい
Rockって中止されたんじゃなかったっけ?
米司法省が期間を延長していた調査を打ち切り、OracleによるSunの買収を承認した。
ロック・ウィル・ネヴァー・ダイ
367 :
名無しさん@お腹いっぱい。 :2009/08/21(金) 23:25:57
enum nis_error { NIS_SUCCESS = 0, /* A-ok, let's rock n roll */
Rockは儲の心の中で今も生きています
たとえRockが死んだとしても、Rainbow Fallsがあるじゃないか
370 :
名無しさん@お腹いっぱい。 :2009/08/22(土) 16:21:09
発表は?
なんの発表だよ
SPARC事業は富士通に移管します発表
まじで?
そんな発表を待ってます、ってことじゃないの?
どっちに転んでも十年後サーバー・ワークステーション向けプロセッサとして SPARC が製品ラインナップに残ってる可能性はミジンコだから どうでもいいよ
Oracleの製品群ってさ、 XeonとSPARC64の信頼性の差が 問題になるようなもの、あんまりないよね。
>>376 Niagara3って本当に製品化する意味があるのか?
Niagara2の時点で既に、プロセッサ性能に見合う大量のメモリスロットの配置で基板が一杯だった。
Niagara3で性能が2〜4倍になったら、それと同時にメモリも2〜4倍が必要になる。
つまり、Niagara2の4ソケット構成のプロセッサだけが4つから1つに減らせる・・・あんまり嬉しくないな。
>>377 信頼性はCPUだけで決まるものじゃないのでは。 ただ個人的には開発者がもっとも長く触れている
開発環境を選んだ方が良いのではないかと思ってる。それ以外はいわゆるポーティングとなるので。
うろおぼえだが 8 までは開発が Sun SPARC Solaris、高パフォーマンス用に Alpha で、
9からはx86 Linuxへ変わってローコスト&unbreakableを標榜したような希ガス。
Oracleの開発現場でSPARC64は使ってるのかな? テスト環境としてはあるだろうけど。
>>379 > 信頼性はCPUだけで決まるものじゃないのでは。
CPUではなくサーバで捉えて
>>380 サーバっていうと機種やOSも入るよね。そうなるとハードメーカに依存するし、
Oracle 社がコントロールできるものではないから信頼性を問うのは難しいと思う。
しいて言えば Oracleのマーケティングでは Intel/Linux や Windows がエントリー
向けの売り方をしてることから推測して、テストや検証の規模で差があると考えられ
るかもしれない。
>>381 Xeon、SPARC64
いずれもSunのサーバってことで
これ以上は知っていても言えないんだ。ゴメンね。
>>374 他社に買収されたブランドにここまでビビってる連中というのも、珍しいよなww
どういう意味?
Xeon最強!
昔amigaでxenonというゲームが出てたな
>>384 ここは他社に買収されたブランドをおちょくるスレなんですが
そうなの?
>>388 そんな余裕のなさでは「おちょくってる」とは思ってもらえませんよ?www
じこしょうかいおつ
>>388 昔 Sunに敗れた salesが未練たらしく恨みを晴らそうとして(失敗して)ますwwww
あわれさ満載です。
毎度おつ
次は草5つでくるのかな
レインボウフォオオオッル
Niagara2って、インテルのFB-DIMMなんだよな Niagara3は、DDR3になるのだろうか、それともFB-DIMMなのだろうか 個人的には、失敗したFB-DIMMを最も必要としているのがNiagaraシリーズだと思う。
DDR3用のAMBを自前で作る 無理ならFB-DIMM
DDR3のがいいな 俺が中古で買ったときに使いまわしやすいから
DDR3にすると、 ・Niagara3内蔵のメモリコントローラのチャンネル数が減る ・積めるメモリ容量が減る ・メモリの帯域幅が減る ってことで、マズーだと思う。
UltraSPARC T3、で出荷直前に UltraSPARC T10 に変更w
Hot Chips。
なるほど。トン! >富士通のペタスケールコンピューティング向けの新しい8コアプロセッサである「SPARC64 VIIIfx」がある。 >Sunは同社の「次世代マルチスレッドプロセッサ『Rainbow Falls』」について解説し、 >AMDは同社の12コアチップの「Magny Cours」プロセッサについて詳しく説明する予定だ。
Rainbowなので、スレッド数は当然 7。
虹の色が7色というのはそれほど広い範囲の花井ではない
The Rainbow Colors
ttp://www.zianet.com/rainbow/frcolor.htm | Are there only seven colors? Newton believed in numerology and thought
| special numbers governed all natural phenomena.
| Seven is a very special number.
>405
7色以外って、たとえばどこの国で?
# ま、どーでもいいがww
>>406 ttp://en.wikipedia.org/wiki/Rainbow > Newton originally (1672) named only five primary colours:
> red, yellow, green, blue and violet.
> Only later did he introduce orange and indigo,
> giving seven colours by analogy to the number of notes
> in a musical scale.
ttp://ja.wikipedia.org/wiki/%E8%99%B9 > 虹の色の数は現在の日本では一般的に七色(赤、橙、黄、緑、青、藍、紫)と
> 言われるが、地域や民族・時代により大きく異なり、ドイツでは五色、
> スウェーデンでは六色(赤、黄、青、緑、桃、藍)である。
> 日本でも古くは五色、沖縄地方では二色(赤、黒または赤、青)とされていた。
> なお現代でもかつての沖縄のように明、暗の2色として捉える民族は多い。
実際の虹はそれほど大きくもクッキリとも見えないことが多いので
7色よりも5色程度の方がしっくりくる気がする
犬には2色
虹か Sunつまり太陽の光のスペクトルのことだな 原理的に連続ではないものの、太陽のそれは極めて連続に近い びっしり詰まっている、っていう意味なのかな
単に有名な滝の名前なだけ。 考えすぎw
Niagara → victoria falls → rainbow falls だね。 だんだんレベルが下がってる気がしないでも
最初に世界一有名な滝の名前にしてしまうから。。。
KegonとかNachiとかマダーチンチン
>>411 世界三大瀑布の中でもっとも有名なのはナイアガラだが、
もっともしょぼいのもナイアガラだ。
ただ、ナイアガラ・ビクトリアと三大瀑布できたのに、3世代目が
残るイグアスじゃなかったのは肩すかし。イグアスを名乗るほどの
物ではないと言う表明か・・・
Niagaraくらいになると、性能はプロセッサ・コアではなく、メモリシステムで決まる。 プロセッサの集積度を上げても、メモリシステムが同一なら、性能は上がらない。 大量生産されるプロセッサなら、同一性能をより面積の小さなチップで実現するのは、確実にコスト削減になる しかし、ニッチなプロセッサだと開発費と相殺しきれるかどうか心配っていう領域 さらに、従来なら4チップだったものが1チップに収まるといっても、 パッケージのピン数は1/4にならないわけで、むしろ配線が大変だ。
Naiagara Victoria の次はRockって決まっていたからその後の滝は考えてなかったんだろ。
>>414 商品名てのは、言いやすいとかスペルの見てくれとか、あと他で使われてないかとか
イメージとかあるから一概には..
Rockは別チームだから関係ない
Rock→サイケ→グラムロック→プログレ→パブロック→スカ→パンク→ ニューウェーブ→テクノ→フュージョン→AOR→オルタナティブ→ラップ→ ドラムンベース
Rock is dead.
ドラムンベースの前にジャングルが抜けてる
ブレイクビーツも抜けてる
To be a rock and not to roll..
424 :
名無しさん@お腹いっぱい。 :2009/08/28(金) 22:42:11
CPUを発表出来るだけでもマシ。 Itaniumなんざ。。。
Itaniumも論文だけはいっぱい出ているんだぜ?
やるだけのことは全てやって、かけらるだけの金ザバザバかけて、 時間もこれでもかというほどかけて、そんでうまくいかなかったんだから さぞかし満足だろうよ。
発表だけで、モノが出ない
>>426 いやいや
心中してないって事はどこかでブレーキ踏んでるんですよ
下を見て安堵するってのは、ろくでもないぞ。 それに、とっくに死に体のItaniumよりマシだってのは何の慰めにもならん。
>>428 な、なんのブレーキ? # 心のブレーキ?
>>429 まあ、Rockという意味ではなんとも暗中だが、SPARC ISAという意味では
まるで比較にならんし。並べてみてると思う方が変w
>>432 ? もちろん、Sun(と IBM)が Itaサポート離脱した時から見下してるが。
なんか期待してたの? まさかね...w
え? だって、もう退場した Alphaや HP-PAだって、あれくらい金ヒマかけりゃ ずっと速くなってるだろ。MIPSもエンプラ向けテコ入れしたら現役と思うよ。 格下も格下、ず〜〜〜ーっと、下の方だろ Itaは当然ww i960にも Am29000にも負けるんじゃねーか?www
日本語が書けない方ではなく 日本語が読めない方でしたか
・・いらんだろ
>>437 そっちは Ita採用したバカ企業、だろ? うへw わらかす
この板で草を生やしたがる連中はたいてい頭がお菓子い
HPもゴミはいらんだろ w
ww
今のMIPSはほぼネットワーク機器用途向けだからなぁ でもそれなりに性能が要求される(かつ省電力な)ところで生き残ってくれてるのは嬉しくもある
SH、MIPS、ARM・・・PDAで使われました SPARC・・・使われてない デジカメ? ありゃ一瞬のブームで、後に続かなかったな
PA-RISCってもう退場したんだっけ?まだだったような SHは今は国内向け携帯電話用CPUだし、MIPSはネットワーク機器、 ARMは相変わらずPDAや省電力方面に強い&Nintendo DS向け PPCはパッとしないけど玄箱で使われ続けてるね SPARC(笑) SPARCはエンタープライズ向けと今や数少ないWorkstationの分野で生き残っているから吉
え? SPARCなワークステーションなんて、Sunすら作ってないぞ。
Java、.net、Java ScriptなどのJITコンパイラ技術の進歩によって CPUなんて何でもいい時代になってきてるのに未だにアーキテクチャでもめてるのかこのスレは。 将来的には実行性能がよほどシビアなもの以外は 仮想マシンを使った言語やスクリプト言語で書かれるようになるんだろうな
つまり将来の約束されているIntel以外は全滅するとw
448から449という結論に至れる人って、やっぱりoh!no!
SPARCの将来は暗いけどな・・・
互換性という縛りがなくなれば、マルチスレッドのスループット優先ということなら、 シングルスレッドのパフォーマンスのためのレジスタウィンドウや遅延スロットなんて必要ないものな。
全日本SPARC党に投票してきた
>>452 それ以前に製造も設計もできないからなw
457 :
名無しさん@そうだ選挙に行こう :2009/08/30(日) 19:04:21
>>457 使うサーバ、何だろう。
M9000には、見えないのだが。
SPARCとは書いてあるな。 何だろ? 新製品か?
ROCKだな
だったらビックリだ
画像では極めて不明瞭だし、ただのアイコンでしかないのだろうが、ラックに4Uのサーバが並んでいるな。
T5440かT2plus使ったブレードかね
>>457 SPARCと明記してあるな。10/14なら、もう動いてるってことだ。
>>460 システムとして IBMのやつに勝つってことだから... なのか?
Rockなんて都市伝説だろ
Rock is dead!
ほうれビビれビビれ!ww
POWERオワ…オタワ
SPARCのロゴが赤いな。FujitsuのSPARC64だな。
普通に、オラクルだから赤、だろ
だめってレベルじゃねーな
らめぇー
だめって、何が? Oracleをどっかが買う、とか? ほんとビビりなんだね、君たちwwww
いや憑かれている
はぁ? 全く意味不明ww なにがだめなのかって聞いてんだけど..w
合併の過渡期に製品を買い控えるのはあたりまえなんだけど.. サルでもわかるんじゃない? それくらい。
>>480 つまり代替可能な製品群を提供している、消滅しても構わないメーカーだってことだな。
カンファレンスコールやプレスリリースがないのも当たり前なのかなwwwwww
>>482 単独企業としての Sunブランドは、消滅確定なんだから、当然だろ?
この先サポートがどうなるか、今までのオープンな姿勢はどうなるか、
ぜんぜんわからんので様子を見るだろ。期間も切ってあるし。
製品の内容とは全く関係ない。
...そんなこと本気でわからんわけか? びっくりだわ。
あんた高いもんは買わない方がいいぞ。ムリだしwww パソコンだけでやめとけpp
全部オラクルのせいだ! wwwwwwwwwwwwwwwwwwwwwwww
...こんな簡単なことが理解できないなんて... xxxだわ。
アナリストの予測を下回る悲惨な業績の言い訳が合併の過渡期 相変わらずこのスレに粘着している惨営業は低脳だな
もう何回も言われてると思うけど.... ほぉんっっっっっっと、おつむよわぁぃねw
アタマ悪いアンチしか来ないスレって、悲惨だよね。
裸の王様だな
>>484 いやいや、代替不可能な製品群を提供している消えては困るメーカーの場合、
買収や合併の話があっても、製品は普通に売れ続けるものだよ。
491 :
名無しさん@お腹いっぱい。 :2009/09/01(火) 19:49:54
ヤミカラー
いくらなんでも減りすぎだよねえ 買収が落ち着いた後に復活するとは思えないな
あと 5 年ぐらいは合併の過渡期が続きそうだな w
494 :
sage :2009/09/01(火) 21:46:49
これからは、powerとitaniumをsolaris x86でリプレースするのだよ。
そもそもOracleにとって、x86よりも高い信頼性なんて、必要ないんだよな。
Yes
ハードのメーカーとかCPUのアーキとか気にする人がいつまで生きているか
ロートルが現場に口出ししなくなるまで
Sunってあれだろ ドコモのiモードのサーバで 大失敗したところだろ
よりにもよってHP-UXに取られちゃったんだよね、確か
あれはSolarisが悪かったのかCTCが悪かったのか…
またお通夜っぽくなってきた
ハードウェアの信頼性は、最優先事項ではない、ってことでしょ。 当時、何から何まで冗長化・多重化されたフラッグシップ案件として、密かに販促ツールになってた。 だから、その後の展開で真っ青ですよ。
____ / \ / _ノ ヽ、_ \ / o゚((●)) ((●))゚o \ やる気の問題だお… | (__人__) | \ ` ⌒´ /
>>502 バカのひとつおぼえの典型。
つーか、おまえその後クビになったんだろ? Sunに文句いうのはサカウラミってもんだw
>>495 だけど、エリソンは SPARCやりたいんだよ。しょーがねーじゃんw
10/14発表のやつは、SPARCだって書いてあるんだから。
>>503 まぁCTCだろうね
今月の日経コンピュータでもSI系でまったく顧客満足度ランクインしてないし
510 :
名無しさん@お腹いっぱい。 :2009/09/02(水) 11:07:43
>>508 アンチIBMの象徴としてあげるアドバルーンみたいなもんだと思うがね
競争力を考えるとリソースの配分は
エリソンは、どっかのアホどもと違って元はちゃんとしたエンジニアだからな。 技術的な裏付けなしで適当なこと言ってたりということはないよ。 それに、仮にアドバルーンだったとしても、あとから引っ込めるわけには いかなくなるぜ? 本気で IBMの規模までノそうと思ってるのかどうかは 知らんけど、まあ、おもしろいね。だいぶ減っちゃったからな、そういう人間はww
512 :
名無しさん@お腹いっぱい。 :2009/09/02(水) 11:32:05
まあオラクルがDQNなのは今に始まったことじゃないし
>>508 だからさ、エリソン正気か? って言われてるんだろ。
>>509 日経なんちゃらをソースにするなよ。
>>513 エリソンが正気かどうかなんて、どうでもいいじゃん。
Sunが本業でやってたほとんどのことに対するスポンサーがついた。
IBM他よりずっとマシだろ。
> 日経なんちゃらをソースにするなよ。
それは言える。アホかとw
スポンサー? 正気か?
またビビッてんのか?ww
次は Fab買うぜ。
518 :
名無しさん@お腹いっぱい。 :2009/09/02(水) 15:06:38
おお、それは面白いw
そして次は SPARCulv+EasySolaris $199のネットブック
そして新ファイルシステム OraFS
そして新しい仮想記憶システム OraVM
なんか、歯ブラシとか歯磨き粉のような名前だな。
デスクトップ環境 OraDE
3D OraGL
Sun Microsystems 最後の決算
延期されて買収前に消えてしまうことはないよな
エリソンってさあ、アドバルーン上げるのが好きだよな。 500ドルPCとか。くっくっく。
もうしばらく過渡期が続きそうだから、決算が悪くても平気だね
Sun Microsystems 最悪の決算
オラオラ100連発。そいでもって無駄無駄100連発。
いっそアメリカのOracleではなく、ヨーロッパの企業に買収されたら、良かったのにね。 イタリアのOlivettiとか, イギリスのVirginとか、 オランダのPhilipsとか、 フランスのSafranとか、 フィンランドのNokiaとか、 ドイツのSiemensとか。 Siemensは富士通とも関係があるので、悪くないと思うんだけどなぁ。
Siemensはサーバ事業を富士通に売ったんだから Sunを買うわけがないだろ
しょーがねーなぁ。じゃ、オレが買うか。
>>533 富士通が買って、活かした企業って、なんかあるか?
それは活かしてない方の、代表例だろ?
SPARC64ってHALだろ?
今のはもう違うんだけど。
HAL, ROSS を始め全然だめだめ
UltraSPARCの Sunと、HAL SPARC64の富士通と、64bitかかえてたから 両方して ROSSの 32bit潰してしまった。あれは別で 32bitのまま高速化という 線を残してもよかったのに。結局 SPARC全体としての選択肢を狭めて 勢いを削いだと思う。
32bitと64bitって、そんなに違うものなのか?
PCはx64は段違いに高速化するけど、SPARCはどうだろうね どっちもカメって感じ
x64は大差無いって聞いてたけど UltraSPARCも大差なかったし
出た。使ったこともないバカw
なんでパソコン知識しかないの丸だしなのに恥しげもなくこんなとこに書けるのかね? 気が知れんわ。
>>543 32bitと 64bitというよりも、SPARCv8と SPARCv9で仕様が劇的に違う。
特に SMP関連。
けどカタログスペック的には 32bit/64bitがキーワードとしてきゃっちーだから、
内部クロックだけ上げた v8 32bitにかき回されたくなかった、というのは
わからんでもない。まあ、どのこ会社もいっしょだが。
けど、SPARCv8の HyperSPARCや TurboSPARCがもっと伸びてもそれはそれで
おもしろかったんじゃないかと思う。
>>546 何が癪に障ったのかな?
>>547 何でそう決め付けるのかな?
UltraSPARCなんか、ちょっと速いだけの32bit CPUとしてしか使わなかったよ。
>>548 SPARCstation5の 200MHz ってやつか?w
今や 1GHz、2GHz が当たり前だしなぁ。
初代UltraSPARCはバグ持ちで64ビットは封印、32ビットCPUとして使え、だったような
SPEC CPU95 TurboSPARC 170MHz CINT95 3.41 / 3.53 CFP95 2.72 / 3.00 HyperSPARC 150MHz CINT95 3.77 / 4.02 CFP95 4.73 / 4.71 UltraSPARC 143MHz CINT95 4.52 / 4.66 CFP95 7.73 / 7.90 HyperやTurboがUltraの2倍くらいのクロックを叩き出さないと・・・
>>551 たしかI-Cache周りのバグだったような
32ビットと64ビットを速いか遅いかでしか計れないのが 噂のパソコン脳ですか
また例の人キチャッタ
556 :
名無しさん@お腹いっぱい。 :2009/09/04(金) 20:48:04
しっ
そのうちパソコン脳なんていっていると馬鹿にされちゃうよ
よほどパソコンにコンプレックスがあるんだろうな
Pentiumと性能比較されるところまで凋落したのが、
>>552 の頃だし。
V8plusは?
昔は面白かったな パソコンとは比べ物にならないほど高速な演算、フラットで天国のようなメモリ 文字どおり、比べものにならない別物だった いまじゃ似たようなもので面白くない
パチョコンでも面白いことできるようになったんだ 喜べよ
他人の金使って、他人と違うことが出来たのが嬉しかっただけ。
誰かと比べたって仕方がない 昨日の自分と比べないと
あんまりかわってない。
>>560 >パソコンとは比べ物にならないほど高速な演算、フラットで天国のようなメモリ
その昔、それを実感したかったがSparcマシンなど買える金も使えるような環境も
なかった。後年Blaede2000を購入したが、「この程度か、、、」と拍子抜け
してしまった。
>>565 自分は、今は信頼性が重要なんじゃないかって思ってる。原因不明のトラブルや、
ソフトの保守の度に再起動したり、高負荷だと何も出来なくなるなんてことがより少ない。
仕事においてはサーバは空気みたいなものだから、手間がかからないのが一番。
>>566 そういう観点では、部品の選定さえ正しければ、HW は x86 でもよいと思う。
OS は、Solaris の安定性は飛び抜けていると思う。
窓信奉者は、こんなことは気にしないのだろうか?
SPARC好きな人は10年以上前の話題で盛り上がり 如何に昔の時代のCPUかがわかるな 少しは最近のSPARCの話題で盛り上がれよ
Rock is dead !
SPARC載せたBladeサーバ作ればいいのに 今
>>567 本気で使ってない人、あるいは現場を知らない人が騒いでるだけだと思う。
スルーでいいんじゃないかな。
>>570 SunBlade 6000 じゃだめなん?
UNIXなら再起動しなくて良い、Windowsなら再起動が必要、っていうのは誤解だと思う。 WindowsでもUNIXのように当該のサービスだけ再起動させることができるし、 UNIXでもOSごと再起動させるべき理由はWindowsのそれと同じだよ。 Windowsは何度も再起動が必要だと文句を言うような人は、 本質的にはUNIXでも何度も再起動するようなヘタレだよ。
>>573 MS-Windows... 正真正銘のクソだよ、ありゃ。
OSの再起動回数はインストールするエロゲー、じゃないパッチの数に比例する。
>>575 その糞NTよりも劣るUNIX系OSの多いこと・・・もう淘汰されたから、現存してないが。
え? LinuxやFreeBSDなんかはNTよりも劣ってると思うんだが。
Windows 7 でいいじゃん。
>>580 なんか、ろくでもないことになりそうな計画だね。
各社の既存の製品ラインを置き換えるのではなく、既存の製品ラインをすべて包含するような、
統一規格に準拠しているけれども細部は違いますから・・・みたいなことになりそうだな。
統一すべきなのは規格じゃなくて製品。
性能や用途別のセグメントに分けて、一社の製品だけを残して他社のは廃止、
ってことをしないと。
日経の記者がアホなのか、 プレスリリースが虚飾たっぷりなのか、 わからんが、 これ実態は、 みんなでOSCARを使ってみようよ、 各社、自分ところのCPUに、OSCARとの親和性を良くする機能を追加してみようよ、 とりあえず試作して様子をみてみようよ、っていう話だね。 CPUの規格を統一するのではなく、並列化コンパイラを統一しようって話だね。
584 :
名無しさん@お腹いっぱい。 :2009/09/06(日) 22:26:59
本気でIntelに対抗する意思が無いのは明白
IntelのCPUに対抗するのではなく、 Intelの並列化コンパイラに対抗する、 っていう話だよね。 それをCPUの話にすり替えるって・・・
富士通ってSPARC64VIIIfxをマイクロソフトに売り込んだらどうよ。 Xbox360の次のゲーム機用にさ。
なんでこういう無知な奴が急に増えたんだ?
ARM → 任天堂DSで大活躍 PPC → WiiとXbox360とPS3、据え置きゲームコンソール全制覇 ↑勝ち組 ↓負け組 x86 → Xboxで使われたが、後に続かず SPARC → 採用例すらなし ゲーム機って数が出るから、シビアに実力が評価されるんだわ。 そこで採用されてないSPARCって・・・
『シビアに実力』..ppp バカっぽいねw
うむ。朝から巡回ご苦労。
仕事しながら2chするなカス
2chするのが仕事です
なんだ俺と同じかよ。
>>586 SPARC64VIIIfx はスパコン向けしか用途がないんじゃないの?
>>587 無知な奴が居なけりゃ政権交代も無かった
IBMはPPCをゲーム機だけでなくスパコンでも使ってますな。 PPCといっても、演算アクセラレータがゴッチャリ付いてて、そっちでflopsを稼いでいるけど。
ISAと CPU実装をいっしょくたにしてるバカはもう来ないでくれないかサル。
>>597 IBMのスパコン、PS3のCELLの強化版なんだがなぁ。
同一品ではないが、かなり近い。
で、なんでゲーム機メーカーは、半導体メーカーにSPARC ISAを実装したプロセッサを注文しなかったんだろうな。 国内だと、富士通だけでなく、東芝や日立、NECあたりに、作る能力はあったはずだ。 かつてSEGAは家庭用ゲーム機で使えるような値段ではなかったMC68000を、 モトローラがビックリするほど大量発注することで、単価を下げることに成功したぞ。 ゲーム機というのは、CPUをカスタムで作れるほど、数が出るんだよ。 SPARC64 VIIIfxをカスタムしてゲーム機用に作ってくれという注文があれば、作れるはずだ。
600 :
名無しさん@お腹いっぱい。 :2009/09/07(月) 22:27:06
602 名前:水先案名無い人[sage] 投稿日:2009/09/07(月) 11:16:38 ID:w/Fpeutu0
△ 「蹴るの!?これ、蹴るの!?ねぇ!FK!FK蹴る!?」
中村俊「あぁ、蹴るよ」
△ 「本当!?大丈夫なの!?外すんじゃない!?」
中村俊「あぁ、アディダスの広告塔だから大丈夫だよ」
△ 「そうかぁ!僕一人だから!一人だから世相わかんないから!」
中村俊「そうだね。わからないね」
△ 「うん!でもFKなんだ!そうなんだぁ!じゃぁ蹴っていいんだよね!」
中村俊「駄目だよ。俺のボールだよ」
△ 「よかったぁ!じゃぁ蹴るね!FK蹴る!」
中村俊「・・・・・・・・うん、蹴ろうね」
△ 「あぁ!ナイキボールだから無回転蹴れるね!ね、10番様!」
中村俊「うん。前見てていいよ」
△ 「あぁー10番様は今FK横取りを狙っているよー!気をつけようねぇー!」
ttp://www.youtube.com/watch?v=LE6me7MzjNc
>>599 採用するメリットがなかっただけだろが
妄想ばっかぶっこいてないで現実みろや
602 :
名無しさん@お腹いっぱい。 :2009/09/07(月) 23:44:30
>>599 セガがメガドラにMC68000採用したのはアーケード移植をしやすくするため
じゃなかったか?(当時のアーケード基板は68CPUが多かった)
個人的にはSparcはPC・ゲーム機なんていう庶民の道具に搭載するんじゃなく
あくまでも選ばれしエリートのためのコンピューターである、ハイエンド
サーバ スーパーコンピューターのみに採用して欲しい。
デジカメやプリンタなんて屈辱だよな
んなこたない
>>601 その通り。
SPARCよりも優れたISAがあった、ってこったな。
>>602 当時はアセンブラで書いていたからね。
移植だけでなく新作であっても、68Kは色々と有利だった。
ただ、当時の68K、パソコンには使われはじめていたが、
それすらもモッタイナイというくらい高級なプロセッサだった。
そういえばSunの昔のワークステーションも68Kだったね。
> それすらもモッタイナイというくらい高級なプロセッサだった。 ふーん
電卓を大きくした86系 ミニコンを小さくした68系
>>606 開発環境も問題もあるねw
HP64000 とか使ってたんだっけ?
SPARC-LTはそんなにゴツゴツした形状じゃなかったはず
おらも角張すぎてる気がする 形から言えばJ3100GXとか
613 :
610 :2009/09/08(火) 03:39:42
画面がプラズマで正方形に見えたから、早合点したでごrざる
あんまりメリットある製品とは思えんが… ネットブックにOpenSolaris面白いかなと思ったりしたけどさ
DELLに抜かれたw
>>614 普通に東芝のノートPCの北米モデルに、OpenSolarisをプリインストール、ってだけ。
まぁそこそこ頑張ってんじゃないの?>Sun 売上高のベンダー別シェアは、 米IBM(シェア32.5%)、 米Hewlett-Packard(28.9%)、 米Dell(13.3%)、 米Sun Microsystems(10.8%)、 富士通/Fujitsu Siemens(3.3%)の順 出荷台数ベースのシェアは、 HP(31%)、 Dell(23.9%)、 IBM(13.4%)、 Sun(3.8%)、 富士通/Fujitsu Siemens(2.9%)の順。
こういう状況で買ってる人達がいるってこと自体、すごいと思うね。 オレはよー買わんけど。 しっかし、唯一日本企業の要領の悪さは天下一品だなw
富士通はSunにOEM供給してるから・・・
そうか。以前は 1%とかだったっけ? 伸びてるのか?
そうじゃなくて、Sunのシェアのいくぶんかは富士通のOEMだってこと。
いやいや、もちろんわかって書いてるよw
富士通のOEM分は、Sunのシェアとしてカウントされてる、と。 逆に、SunのOEMで富士通ブランドで売られているものは、富士通のシェアとしてカウントされてる、と。
Sunブランドで数出た結果、Fブランドの台数も伸びるのよ。そういうもん。
68000 不正コードを実行すると割り込みが発生するが、戻りアドレスを忘れるナイスなCPU。 なのでSUN1は68000を2つ使用していた (豆知識)
>>626 それは当たり前じゃないの?
今のSun/Fujitsuみたいな相互OEMな関係じゃなくても
>>628 ファミリーの特徴ならともかく、そんなアラあげたところでなんの役にもたたんがな。
そういうのは豆知識などとは言わないと思うな。
632 :
628 :2009/09/09(水) 19:50:32
>>631 うろ覚えなので適当に書いておけば誰か訂正してくれると思ったが
そういうつっこみしか無いのは残念でした
>>632 うろ覚えとかそういうことじゃなくて、『主旨』がダメ。
>>628 そう言えば、
「2つのCPUの片方を常に1クロック遅らせて実行していた」
という嘘情報がかなり広範囲に広まってたよね。
(正しくは、メインの1CPUが普通に稼働していて、
不正コードなどの例外が発生した時のみ2つ目のCPUが代理で処理をするというだけ)
Sun3以降しか使ったことないや Sun3は普通〜のワークステーションだった。 その普通ってのが、どれだけ大変で価値のあるものだったのか、ってことだ。
68000で仮想記憶やるのは、 i860のパイプラインモード中の割り込みからの復帰処理なんかに比べれば、 えらく簡単だな。
2ちゃんで主旨とはおそれいった
おそれイリアのジューシーフルーツ
Sun1が68000を2個しか積まなかった理由は何だろう。 68000は非力だし、バスよりもMPUクロックがボトルネックだったのだから、 思い切って3個つんで、2プロセッサのSMPにすれば良かったのに。
当時のOSはSMPに対応してません。
>>638 クソ文書くなや。←こっちの方がいいか?
>>635 2個のCPUを使って常に1命令遅らせて実行、という都市伝説の起源ってどこなのかな。
複数の本や雑誌でそういう記述を見かけたことがあるけど。
オレオレ
初出かどうかはわからんが、1995年3月初版の256倍悪魔本25ページに 「SUN1では、2つのCPUが同時に少し前後にずれたところを走っていて、」 とあるな。
フォルトトレラントとか宇宙用とかといっしょくたにしてるな。
256倍悪魔本捨てちゃった…orz また読みたいなー
>>635 アポロの Domain のが先だったのね。
1981年 DN100
1982年 SUN-1
もちろん。
しかもApolloは、ページフォルト処理だけでなくグラフィックス処理も、2個目の68000にやらせてた。 仮想メモリが必要ない、物理アドレスで動作するデバイスドライバ関係は、ページフォルトしないもんな。
なんか体が熱くなってきた
We're in it to win it.
>>655 どうもSun-1は68000は1つのようだね。
Sun-1は数百台未満しか出荷されていないし、後に68010にアップグレードされたそうだから、
コンパイラがメモリアクセスの命令を、例外から戻れるタイプのものだけに制限して回避してたのかもね。
その文書でも、後に出るであろう68010とコンパチだから置き換えできるぞっていうようなこと書いてあるし。
> どうやってアドレスとかレジスタとかの情報交換してるんだろう?
メインのMPUにとっては透過的に処理されるので、情報交換必要ない。
サブのMPUはMMUから、メインMPUがアクセスしようとした論理アドレスを受け取る。
サブのCPUはMMUにアクセスしてフォールトしたページにメモリを割当することさえ できれば良いので、68000以外のCPUでもいいんだよね。 メインとサブが違うCPUなら、2つのCPUが命令をずらして同時に実行していたという説は 完全に否定される。
オラクルの交戦的な所は流石だな。これでソフトウェア世界二位の会社だもんな。 でもラリーも遠くない将来ジョブズみたいによぼよぼになっちゃうと思うと、さびしいな。 IT業界は普通の業界になっちゃうんだろうな。
>>655-657 Sun1のボードを見たことがあるけれど、68Kは1個しか見あたらなかったよ。
ボード2つ積んでいるのでないなら、別のプロセッサが例外処理してるのかもね。
>>652 だから、最初っからそう言ってるじゃねーか。
「征服」のために、ハードと OSを入手したんだよ。やつは完全に「その気」。
誰か Andy が生きてるうちに Sun-1 の真相を聞いといてくれw
ああ、Andyだが。68000? 使ってないよ。Sun-1はディスクリート。
コーラ缶とマリリンモンローは傑作だったろ?w
スティングはボーカル集中しちゃうとベースがお留守でさ。
>>659 他社と違ってSunは、68000でちゃんと仮想記憶をやろうとはせず
68010が出たら差し替えることを前提に、暫定で68000を積んでいた。
ただでさえレアなSun1のユーザで、68010に差し替えなかったユーザは、極めて希だと思う。
じゃ、例外処理の問題で68000を2台積んだって、別のマシンの 話なのかねぇ?
だから Sun-1 神話はどこからでてきたんだろうって話w
英語と日本語で若干記述が違うな> Wiki The Sun-1 systems ran SunOS 0.9, a port of UniSoft's UniPlus V7 port of Seventh Edition UNIX to the Motorola 68000 microprocessor, with no window system. Sun-1のシステムでは、Seventh Edition Unix の移植である UniSoft の UniPlus V7 が動作した。 これは、時には Sun UNIX 0.7 とも呼ばれている。
>>668 68000を 2コって機械は、複数あったって読んだ覚えがある。
>>669 Sun-1は違うようだね。
オレ的には Sun-1でどうだったかはあまり問題じゃなくて、 M68k x 2コのCPUを、命令クロックをずらして同時に走らせた、という伝説の出どころが 知りたい。
>>672 2つに実行させると、サブの方の CPUにデータぶっこわされないように
ある程度のメモリも余分に必要になるから、メモリが安くなかった当時では
ちょっとありえない構成だと思うけど。
>646 が妥当かと。
I/Oもメモリアクセスも同期も取らないフォールトトレラントや宇宙用ってどんなの?
もしかしたら 2個の6809を位相をズラしたクロックで駆動させて、互いにサイクルスチールさせる っていう話と混同してるのかもな。
Rockはどれ?
ありません
本当にRockないんだ なんなんだ
Rock is dead!
えらく現実的な選択だな。 つまらん。
New VT Coreの3つは十分野心的なスペックだと思うがなあ 特に後ろの2つ、4コアで192ソケット対応のチップと 16コアで8ソケット対応のチップを同じような時期に リリースするだなんて、ちょっと信じられない
あ、Cascade FallsはYellowstone Fallsを4つMCMに載せたやつだったりして
コア数の増加を抑えて高クロック化を狙っている辺りにSPARC64イラネって気持ちを感じる
DEC Alphaだってロードマップはあった。
>>689 Itaniumだってロードマップはある。
>>688 このロードマップなら、SPARC64もういらねえだろ
>>693 > 富士通はサンのCPU開発力を甘く見ていた節があり、
> 16コアで、1コア当たり16あるいは32スレッドとされる
> Rockの開発がうまくいかないだろうと踏んでいた。
結局これは当たってたわけか
> Jupiter後の富士通は、APL提携時の約束に従い > Rockを売ることになるはずである。 おかげでAPL2は出そうにも2012年まで出せませんと SunのSPARC部隊は見事に生き残りに成功したわけだ
どっちみちNehalem EXが出ればSPARCいらなくなるんだし 富士通ももうやる気ないんじゃないの?
エンタープライズ用途で1割程度のクロック向上って、やる価値あるの?
少しはあるから、やるんじゃないの?
漸進は一度きりじゃないですから
2年もかけて、やることなの?
2年?
また自分の世界に入ってる様です
また?
早く買ったお客さんにはさっさとそれ使って儲けてもらう 遅く来たお客さんには少し速いのを渡してやる Sunはどっちのお客さんも喜ばせることができる
つか、Jupiter-EってRock潰れたときのBプランぽくね? US-Vに続きRockでもケツ持ってもらって、自分たちは 新コアで新しいチップ作りますんでAPL2はいりません だったとしたら、ちょっとひどくね?
Sunなんかと組んだのが運の尽き!
Sun側がAPL2イラネと言ってるのか、 それとも 富士通側がAPL2なんて作るもんか と言ってるのか。 2度も同じ手口で痛めつけられるほど富士通はバカじゃないよ。
Jupiterを2.5GHz→3.0GHzでバックアッププランになりますか、と。 バックアッププランならVenusのfxの付かないモデルだろう。
Yellowstone Falls があれば APL2 イラネ ってのが妄想でしかないわけでして
4コア×8スレッド192ソケット対応で3GHzならAPL2いらないんじゃね?
ってことは富士通にそっぽ向かれて慌ててベーパーウェアを用意した可能性もあるわけだな
APLだってイラネとか言ってたが、APLべったり依存ですよ?
3GHz 4-192ソケット 4コア8スレッド Yellowstone Falls は、メモリ大盛り向け 3GHz 1-8ソケット 16コア8スレッド Cascade Fallsは、CPU大盛り向け ってことかな Yellowstone Fallsが最低4ソケットから、というあたりからして、 どちらも同一のコアで、 Yellowstoneを4チップMCMしたのがCascade Fallsかな もはやボトルネックはパッケージのピンカウントって感じだな。
ボトルネックは製造
ボトルネックは「机上の空論」
>>715 > Yellowstoneを4チップMCMしたのがCascade Fallsかな
それだと消費電力も4倍になるぞ
元が低ければ4倍になっても許容範囲内だと思う
元が低いって、Yellowstoneがたとえば50W未満で出せるってことか? 28nmで4コアとは言え、3GHzだぞ?ちょっと信じられないなあ
Yosemite以降は絵に描いた餅
怪文書レベル
>>720 コア半分→電力半分
クロック倍→電力倍
微細化2段階→電力半分
さらに、電力食いなのはメモリコントローラやSMPバスなどの、外部との通信。
4チップMCMした場合に、チップ上のメモリコントローラを全部使ったらピンカウントが足りなくなるので、そこで削減される。
SMPバスも、プリント基板上を隣のソケットまで走るのに比べれば、MCM基板上の配線のほうが短くて軽いので、そこで削減されよう。
というわけで、200Wくらいで収まると思う。
> コア半分→電力半分 コアあたりのトランジスタ数を増やさずにクロックを倍にできるかな? > クロック倍→電力倍 高クロックを実現するために低Vthのトランジスタを使ったりするだろうから 倍で済むとは思えない > 微細化2段階→電力半分 微細化するとリーク電流が増えるんだよね TSMCもHKMGを導入するようだけど 微細化だけで電力を半分にできるとは思えないな > さらに、電力食いなのはメモリコントローラやSMPバスなどの、外部との通信。 通常の使い方だと、なんだかんだ言って一番の電力食いはコアの部分だよ 非コア領域殺すことで可能な電力削減なんてたかが知れてると思う というわけで、Rock以上に爆熱の悪寒
>>724 > コアあたりのトランジスタ数を増やさずにクロックを倍にできるかな?
> 高クロックを実現するために低Vthのトランジスタを使ったりするだろうから倍で済むとは思えない
同一プロセスでクロックを倍にしようとすれば、そういう話になるだろうね。
戦争末期の大日本帝国やナチスドイツの妄想兵器レベル
単なる、Rockの延期処置だろ。Rockというラベルにすると延びすぎでカッコ悪いから。
>>708 富士通も Suncleもがんばって、SPARCのパイが増えれば両方とも出荷が
伸びるんだから、並存でなんの問題もないよ。
性格性能が近くたってサーバ機で特色出せばいいし。
HyperSPARCの時みたいに品種絞った方がまずいと思う。
ユーザーが多品種で迷う程ならともかく、現状それはない。
>>728 富士通とSunがそれぞれ開発できずに一本化するほど、SPARCのパイは小さくなってると思うのだが。
でなければ、SunがMシリーズを自社ブランドで売ったりはしないだろ。
伸びるよ。エリソンが広告費使うからね。 富士通も Itaにつっこむようなバカはもうしないし。 しっかし、日本企業ダメだな。社内のわかってる人間をぜんぜん活かさない。
金勘定ばかりで現場を把握するつもりのないお偉いさんは多いからな そのくせ経済誌などの煽りを真に受けてバカな事に力を入れたりする
>>727 じゃあ、Yosemite Falls以降は Rock改め、ってことで。
欧州委員会がケチつけてるから、結局ほんとに合併するのは来年? MySQLをいい形で救いたいんかな。もともと欧州もんだから。 有料の、Oracleと共通のストレージエンジンしか使えなくなったりして。
Rockとその後継に〜Fallsなんて開発名は使ってませんが
水じゃなくて、岩が落ちてくるんだろな。
すくなくとも、開発資金、強引な販売、高飛車なもの言い、強気な「押し」、等 創業以来これまで Sunになかった要素が SPARCと Solarisに強化された。 Openさや技術のエレガントさはこの先どうなるかはわからんが。 まあ、アンチ諸氏、せいぜいビビってくれたまえww
Kegon Fallsはまだか
>>739 自分で計算しろよ。
計算する気がなければ、
日本時間で9/16の午後1時よりも前に通過する時間
だと思って、それまで待ってれば?
まぁ、どうせ日本語に翻訳された記事がでるのは、それよりもずっと後だ。
オラクルが日没に灯す最後の光輝?
>>725 同一プロセスじゃなくても
65nmではハイエンドとは言えない周波数(1.6GHz)から
28nmでもほぼハイエンドに近い周波数(3GHz)に上げるんだから
何そのPoulson
>>743 Rock plus とかあったみたい。Topaz も関連?
全部 cancel みたいだけどね。
あと何回キャンセルするんだろうか
Topazって黄色い石だから
Nazi Falls
もっと夢のある話はないのか。
Oracle傘下になった暁には
現在のSun以上の資金を投入して (
>>651 )
NiagaraのときのAfara Websystemsのような
有望な企業を買収して新型SPARCを作ります
夢があるだろ
お爺ちゃんには夢がないね
>>752 テコ入れする限りは、取捨選択が大胆に行われ、そして、結果がでなければザックリと切られる。
従来ならSPARCは仕方なく保守〜みたいな感じでダラダラやれたのが、できないってことだよ。
買収対象としてAzulとかどうなんだろ IBMの息がかかってるが
藍屋の白袴だな。
うわぁ〜。願望フルスロットルですね。言っててみじめじゃないですかw?
AzulってSunと訴訟してなかったっけ?
760 :
756 :2009/09/15(火) 09:54:06
すまん、こちらの回線が障害発生してた。
買収された企業の製品にビクついてるアンチあわれww 情けなさ満開pw
>>686 ,715
Yosemite Fallsは New VT Coreにはなってるけど、Rainbow Fallsと同じ
プロセスでクロック上がる代わりにコア数減で、新コアでの無難な再構築という感じ?
Yellowstone Fallsと Cascade Fallsが同一チップなら、後者は 192/4→ 48ソケット
いけてもいいような気がするけど。Yellowstone Fallsの方が廉価版てことなら
まだわかるけど、そうじゃないだろうし。
Yellowstone Fallsは、4core x 8thread x 192socketだと OSから見て 6144コの CPUがあるように見えるわけね。ふへ〜 でも、NUMAだよね。
OSから見て4096CPUマシンは稼働してるけど、 こっちはいつ稼働するやら
>>762 > 192/4→ 48ソケットいけてもいいような気がするけど
SMPのための信号線が、MCM内接続に食われて、MCMの外には少ししか出てなくて、8ソケットまでしかスケールしないのかも。
>>765 でもそれだと、CascadeF 8発 128コア機の方が YellowstoneF 32発 128コア機より
安い、ってこと?
なんかコンスタントに製品出してるように見えるけど、2009年の Victoria Falls+ は 1.4GHz → 1.6GHzの単なるクロックアップだなw プロセスもいっしょだし。
Sun Oracle Database Machine ..とりあえず今回は SPARC使ってないような。
>>766 たぶん、そう。
Yellowstoneのほうはメモリのチャネル数も多く、ソケット間のレイテンシも短く、巨大なサーバだと思うよ。
>>769 Oracle効果かな。
もうSunはx86サーバ作らなくていいよ。
>>773 Andy デザインの Galaxy シリーズだけは残してくれw
とりあえず、Galaxy から売却か
778 :
名無しさん@お腹いっぱい。 :2009/09/17(木) 01:03:30
>>778 以前、Exadataは続行、ってなことをOracleは言ってたよな。
Sunを買収しても従来のパートナーシップは推進していくとか八方美人なことを。
Exadataは、x86とソケット互換のFPGAモジュールを使っていたと思うが、
x86の日進月歩に対して追従せず、なんか放置されてたような。
そういうわけで、新モデルの開発しないで打ち切るのは、まぁ妥当だろうな。
HPはSNonStop SQLもってるんだから別に困らんやん
それ以前に、 Oracleがハードウェア製造をHPに委託していたってだけで、 ExadataはHPの製品ラインには含まれてないと思う。
>>779 それはExadataではなくNetezzaじゃね?
HP-UX、x86に移植するのはムリもしくは時間のムダという判断だな。 加えて Linuxではダメだと。やっと飲み込めたか。 Itaとともにしゅーりょー。さいなら。
HP-UXをx86に移植しない理由は、Solarisがフル機能をx86に提供しない理由と一緒でしょう。 といっても、x86もRAS機能を持ちつつあるので、いつまでも状況が同じではないが。 x86 + Solaris for x86 では、HP-UXを置き換えることは、まだまだ、できない。
そもそもPA-RISCの方向性からして、x86とは別世界だよ。 HP-UXをx86に移植して欲しいというユーザはいないだろう。
>>784 > HP-UXをx86に移植しない理由は、Solarisがフル機能をx86に提供しない理由と一緒でしょう。
全く意味不明だな。フル機能じゃない HP-UX/x86があるわけでもないのに。
なにが「一緒」でなにが「理由」なんだ? 根拠皆無。脈絡ゼロ。
>>785 いないね。イラネぽいっ。別世界とやらへどぞーw
>>786 あなたの考えが至らないだけ、だな。
>>787 なぜクロックが低いPA-RISCが売れ続けたのか、そこんところを考えてね。
しかし、SSDで数字稼ぐってセコいなw
http://image.itmedia.co.jp/enterprise/articles/0909/16/yu_exadata.jpg >Exadataの前バージョンの「HP Oracle Database Machine」より2倍速
>TeradataやNetezzaより5倍、IBMの“最速のコンピュータ”より20倍速
・Intel Xeon 5500
・6Gbpsの600GバイトSASディスク、DDR3メモリ、
・40Gビット/秒のInfiniBand
・1ラック当たりSSDは5Tバイトまで、DRAMは400Gバイトまで、
・SASディスクでは100Tバイト、SATAドライブでは336Tバイトまで
(Sun Fire X4170、Sun Fire X4275、InfiniBand Switch)
じゃすぱーふぉれすとがでたらしょうでんりょくもあぴーるするんだろうなこれは
>>790 OracleのロゴをSunの「下に」持ってきたのが凄い
こりゃ完全に本気だな
楽しすぎる
>>789 もいっぺんだけ言っといたるわ。「なんのいいわけにもなってない。」
せいぜい別世界とやらへ行ってくれ。もう帰ってくんなよw
794ゲット
平安京?
>>786 「x86になくてSparcにある機能を活用したSolarisの機能があるように、
たとえHP-UXのx86版を作ったとしても実現できないHP-UXの機能がある。
Sunはそれでもそれ以外の部分でビジネスになると判断をしたが、
HPはビジネスにならないと判断したのが違うだけで、
x86にSolarisやHP-UXがウリとする機能が備わっていない点で同じ」と
言っているように読めるが。
それがどんな機能なのか知らない俺が言うのもなんだが。
このキチガイいつもいるよな
>>796 インチキ企業の方がもっとずっとマシな言い訳するよなww
別人のフリして連投するやつ、サイテーだな。というか、もうずっとやってる バカだって見え見えなのがバレないとでも思ってるのか。 想像もつかんww w
みじめなやつ.
このキチガイいつもいるよな
狂儲
sparcとx86ではras機能をインプリメントするレイヤーが違うんです。 sparcでは、障害発生の信号はすべてOSに通知されるのでrasの対応は OSの機能になります。(たとえばメモリでのビット化け多発によるページ 単位の縮退など) x86では、windowsにras機能がないので、障害発生はOSで対応できません ので、biosでやります。 だからsolaris sparcのrasがsolaris x86に移植されていないといっても 当たり前のことなんですね。x86ではbiosとサービスプロセッサががんばる んです。
【続き】 ということで、x86では、biosとサービスプロセッサでRASをきちんと実現すれば、 powerやitaniumをリプレースするマシンになります。
exadata v2って、enterpise linux + x86ですよね。 sparcでもsolarisでもない。今のoracleの商売ってほんとにsunが いらないんですね。こんな状況でどうするのでしょうか?笑うどこ ろか、力が抜けちゃいましたよ。
【続き】 だいたい oracle 11g はsolaris x86用にリリースされていないですよね。 solaris x86にフル機能を提供していないのは、sunじゃなくてoracleなん です。まじめにやる気があるんだったら、まず oracle 11gをsolaris x86 にリリースしなさい。それがこの買収がうまくいくかどうかの判断ポイント と思っています。
米国HPは、数年前からSolarisサポートしてたので、今更感があるのですが...
>>809 OracleだってSPARC売りたいのではないですか?
>>806 >>807 >x86では、windowsにras機能がないので、障害発生はOSで対応できません
windowsにrasが無いことをSolaris x86にrasが移植されないことの理由に
されてもねえ。どこで実現してもよいrasが条件ならx86 solarisである必要
すらないじゃないの。
>>811 儲かるなら?でも自ら作る必要はないかも。
>>812 会社買った以上は買ったものをおカネに換えていきたいじゃないですか
欲しかったのは会社じゃなくて SUNの中の一部の人だろ
大企業倒産を嫌う米政府がOracleに買い取らせただけでしょ
市場のプレーヤーを減らすために、時には欲しくない会社を買収することもありますよ。 前にHDDで、そういう買収があった。
別にSPARCとSolarisだけの会社じゃねえしなぁ。
>>816 それはIBMがSunを買収しようとしたやつのことだな
SunはOracleにとって直接の競合メーカーではない気がするが
>>812 solaris x86では、boisとサービスプロセッサでsparc以上のrasを
実現していますので問題ありません。
>>814 日本とちがいアメリカでは人材確保が買収の目的にはならないですよ。
必要な人間は金で引っこ抜けばいい。会社を買収しても優秀な人材は
辞めちゃうかもしれませんよね。
手に入るのは商標
822 :
819 :2009/09/21(月) 09:48:02
>>812 なぜx86か?といわれれば、linux/windowsに比べてsolaris sparc
のアプリをx86サーバ上に移植する手間が一番少ないからですよ。
>>818 SunがOracleと競合するDB持ってたような・・・
MySQLだね。
MariaDBの開発が進みますように… でも最近、Postgreでいいやー、みたいな気もしてきた
PostgreSQLをPostgreと略すバカ
MariaDBって初めて知りました。オープンソース魂ここにあり、って 感じで良いですね。早くoracleなんか蹴散らして欲しいです。
FireBird
大規模で使えると思ってんのか
>>819 あなたの言うx86 biosで提供されるrasとはどの部分のことですか。
サービスプロセッサで提供されるrasはエンクロージャー部分だけだと思いますが。
>>822 は
>>809 とは別人?
x86の他のプラットフォームで既存のOracleがあるならそれを使えば
よいじゃない。
>>807 のx86リプレース となる対象が、powerやitaniumじゃなくて
SPARCだと言うならそうかもしれないけれど。
>>817 自社ハードウェアでLinuxとWindows serverもサポートしているしねぇ。
>>829 そうおっしゃるお客様がたくさんいるのでとても助かります。
>
>>819 >あなたの言うx86 biosで提供されるrasとはどの部分のことですか。
>サービスプロセッサで提供されるrasはエンクロージャー部分だけだと思いますが。
俺も完全には調査を終えていないが、こんな感じだと思うぞ。
・メモリのビット化け
sun4vではhyperviserがログ取得しているように見える
sun4uでは、solarisカーネルが異常発生アドレスのログ取得
x86ではbiosがログ取得、OSには通知されないように見える。
・メモリスクラバ
sparcではカーネル内のスレッドが周期的にメモリアクセス
x86ではメモリコントローラがHW的に周期アクセスを実施
・cpu内の異常(レジスタのビット化け)
sparcではtrap発生 −>パニック
x86ではmachine check発生 ->パニック
・演算結果のパリティ予測
sparcでは富士通のsparc64のみ実施、sun製のプロセッサはチェック無し
(powerもitaniumもチェックナシ)
x86はチェックなし
・CPUキャッシュスクラバ
sparcではカーネル内のスレッドが周期的にメモリアクセス
x86ではやっていないように見える。これはsolaris x86の手抜きか?
・システムバスエラー系
sparcではint15発生→パニック
x86ではmachine check発生?
>>822 は
>>809 とは別人?
x86の他のプラットフォームで既存のOracleがあるならそれを使えば
よいじゃない。
同じ人だよ。漏れはsolarisのファンであるので、x86でもsolaris
を使いたい。linuxの信頼性は最近は問題ないと思っているがソースコ
ードが汚いので嫌い。
>>807 のx86リプレース となる対象が、powerやitaniumじゃなくて
SPARCだと言うならそうかもしれないけれど。
当然sparcもリプレース対象ですが、それだけではx86の躍進は終わらない
と思います。あと4,5年で生き残るunix機は、いずれのCPUであっても
32-64cpu以上のハイエンド機だけと思っています。
【つづき】 unix機がなくなると考えている根拠はspac2006のintrate値。 core当たりでざっと見てみると、 nehalemが30、power6が29、itaniumが12、sparc64viiが9。今年の 年末にnehalem-exで8コア8ソケット対応になる。まともなパッケー ジングとOSが用意できれば、コストパフォーマンスでpower, itanium、 sparcの中級機まで蹴散らされるのは目に見えていると思う。
まともなパッケージとOSはまだないの? ないなら用意できる見通しはあるの?
linux/windowで良いのでしたらご自由に
と夢想する狂信者であった
>>832 詳細ありがとうございます。
カーネルがハードウェアをパトロールしてもエラーを通知できないならば
実装しても無駄ですね。
ハードウェアエラーをOS、というかSolarisでハンドリングできるように
ならなければうれしくない。
>>834 なくなるUNIX機とは専用ハードという意味で理解。
>>839 その記事の一番右下にはなんてかいてある?
>>835 そこでSunのx86サーバとSolarisですよ。
Oracleにとって、ハイエンド案件のために差別化するのは、そんなに旨味がないだろう。
SPARCサーバを売るよりも、 x86サーバにSolaris乗せて売ったほうが、 薄利多売で儲かるでしょう。 Oracleはハードウェア屋ではなくソフトウェア屋なのですから、 作ったものを数売ってナンボですから。 SPARCにこだわってると、下からシェアを食われてしまう。
はてSunもソフト屋だったような・・
業績落ち目の …でしょ?
ソフト屋としても中途半端、ハード屋としても中途半端。 まさに二兎を追うものはなんとかの例えそのまま。 それがSun。
オラクルさまに買収していただいたので いろいろ悩む必要はなくなりました。
>>844 Sun はもともとハード屋だろw
高いサーバーが売れないと儲けが出ないw
やっぱ素直にx86のlinuxに行くしかないのかな。 linux使って困ったことのある人いますか?
いっぱいいるだろw
Linuxなんか使うくらいならWindows使うぞ。 Windowsの認証を使わなければCALも必要ない・・・だったよな。いや、今は違うか。
>>848 思考はソフト屋だよ
派手好みで堅実性がない
>>851 Windowsの認証を使わなくてもWindows上のアプリなどで何らかの認証をした場合にはCALが必要
>>851 2003から変って、インターネットからの匿名アクセス以外は全てCALが必要
逆に言うと、2000以前はWindowsの認証メカニズムを使うとCALが必要になった
>>849 そりゃ、どんなもの使ったって困ったことはあるだろう。
変わったところでは、
コストパフォーマンスが劇的に改善して大したトラブルもないので、
今までどんだけ高いものを使わせてきたんだと勘違いした経営陣から
怒られたというのはある。
まあ、ようやく機が熟してきただけなんだが。
Windows Serverの普及を考えるとWindows ServerのCALも支払えない貧乏会社は少ないということだ
必要のないカネは支払わないと言うこと
Windows Serverのほうが妥当だという判断をして必要な金を払ってるんだろ
SUN = ソフト屋 の連想で思い出したもの NeXT
つーかエンタープライズ版のサブスクリプションって、 Linuxの方が高いし。
他の Linux 機との取り回しを考えて Solaris を辞める事にした。 みんなすまない…
藻前もか…
マローニ氏は「Itaniumアーキテクチャはすでに重要な目標を達成した。 すでに数カ月前にSPARC系のシステムの売り上げを上回ったのだ」と述べ、 Itaniumのビジネスが好調であることを強調し、さらにその路線を強化 するためにTukwilaを2010年の第1四半期に出荷開始すると述べた。
Itaniumはコア数少ないしクロックも遅いのに、なんで現役でいられるんだろ
知らん、PA-RISC時代からの顧客に聞け
Sunと違って高いハードが売れるからだろうね
無意味に高いものが売れるはずもなく、なにか付加価値があるのだろ
>>865 フォルト・トレラント関係じゃないかな?金融関係とかミッションクリティカルな所で生き残ってるって聞いたことある。
日本だと富士通だけじゃないか、金融にSPARC売ってるの Sunのハードじゃ話にならなかったので、富士通がプロセッサを筆頭に何から何まで手を入れて、よーやく肩を並べた
そもそも客はハードを買ってるってわけじゃないしねぇ。
>>871 だけど、某ビッグユーザーに、Sunを使った提案をしようものなら、出入り禁止を食らう勢いで門前払いされるよ。
どこだよ
Sunの紫色の筐体を見た瞬間に、顔をしかめて帰った人もいたな
875 :
名無しさん@お腹いっぱい。 :2009/09/24(木) 22:30:12
大丈夫いまは銀色か黒だから。HPよりも壊れないし。あ、CMTとX64以外ね
NECが富士通のSPARC64サーバを売ってるんだよな。
NECはHPのサーバーも売っていなかったか?節操がないな。
また昔話がはじまったぜ。事業部の名前も言えない又聞きが念仏唱えてるだけ。さむさむ
Sunを使うなってのは全社的なコンセンサスだったな。
安売りで入れた HP-9000/7xxはおもしろいくらい遅かったけどなwwww
データエントリー用の端末じゃないか。
883 :
名無しさん@お腹いっぱい。 :2009/09/25(金) 17:00:05
え、NTTってSun好きな人多いイメージだったんだけど
事業部はHPを好み、研究所はSunを好む。
IBMやHPがOracleを載せてSIしてくれてたのは、
ハード部門が競合しなかった面が大きかったと思うが、
Sunを買収して、
>>679 みたいなことで、本業の方は大丈夫だろうか…
NTTはSUNたくさん使ってると思うけど。武蔵野にも横須賀にもたくさんある。 SUNの最新鋭機はまずDOCOMOの電子メール(ケータイメール)サーバとして納入されてた というフォークロアがある。E10Kの頃の話。
いや、フォークロアというか事実だよ、それは。 でもそれ、最大の汚名の元なんだ…
武蔵野も横須賀も研究所だろが。
>>882 NTT用のシステムの開発に使われてたわけだな。もう遅くて遅くてゲラゲラw
オペレーションシステムの端末だろ?
何くいさがってんのこのバカは
トラブルにつけ込んで安売りで台数さばいたのがそんなに自慢なのかね、 低レベルなこった。 技術で取る、なんて発想は皆無なわけか。 しかも太古の昔の話だろ。i-mode導入時期の話。カビ生えまくり。
>>885 逆にさ、RDBMSだけじゃ、先はないからね。
894 :
名無しさん@お腹いっぱい。 :2009/09/26(土) 11:43:19
このスレでクダ巻いてる奴が技術とか言っててワロスw レベル高杉だわな。
おいおい、本当にSunで大丈夫なの? まっかせてください、しっかり多重化しますから、Sunでも大丈夫ですよ 信頼性に偏執に神経質になるよりも、最新のシステムによる柔軟性を取るべきですよ ↓ Sunのハードの信頼性のダメさよりも先にシステム設計がダメだめで崩壊したという
某modeシステムでの失敗は設計と実装に問題があったんでしょ? なのにハードウェアへ責任転嫁する人って・・・
大昔の話はもうどうでもいいんですけど... その後クビになったかわいそう君はもう来ないでね。傷口が広がるだけだよ
HPの PA-RISCのワークステーションいやいや使ってたけど。サイテーだったねw
HPは最低のソリューションだ ただしSunを除けばだが
>>896 そんな人いるの? 具体的にレス番どれ?
>>898 ワークステーションとしてはSunが優れてた
サーバとしてはHPが優れてた
だから
>>884 なんでしょ
上の方で、レジスタウィンドウの話出てるけど、 Crusoeはレジスタウィンドウなかったんじゃない?
話の繋がりが見えない
バカだからな
>>896 wikipedia(ja)は、Sun一社でトータルソリューションを出してなかったから、
と書いている奴がいるな。要するにSIの検証不足って事だが。
一社に閉じているから安心していいような規模のシステムじゃねーし。
GRIMMの問題点は2つあると思う。 1つは、発注側のNTTドコモの考え方が古かったこと インターネットでサーバといえばSunが一番、UNIXといえばSunという時代で育ったオタク技術者 もう1つは、ハードウェアのスケーラビリティ特性への理解が足りなかったこと 思わぬところにボトルネックが生じて、溢れる寸前でも余裕が十分にあると誤解するなど。
人の失敗見たからこそ考えを改められるし、理解も広がるもんだよ。 メンツも合わせて金と人もかけることができる。あとは中間搾取と如何戦うか。 前が成功したからと言っても次が約束されるわけでもなかったでしょ。
>>865 ハイエンドサーバーってoracleを動かすぐらいしか仕事ないんだけど
下手にcore数が増えるとoracleのcpuライセンスの料金が上がる。
ライセンスに掛かるcore係数は、itanium 0.5, sparc 0.75で、
core当たりの性能はitaniumのほうが数割高いにもかかわらず、oracle
のライセンス料はお得。
そこのあたりはいじってくるんじゃないかな
そりゃsparcのcore係数が下がれば嬉しい。0.3-0.4ぐらいが妥当と思う。 ただ、あのガメツイoracleが単なる値下げをするとは思えんよ。
ガメツイoracle -> ボラクル
じゃぁitaniumのほうを値上げすりゃいいのよ、適当な理由が付けられるタイミングで しかしitaniumは化け物だな 1.6GHz動作のitaniumが、2.4GHz動作のSPARCの数割も高い性能を叩き出すのか
914 :
名無しさん@お腹いっぱい。 :2009/09/27(日) 17:13:32
それが今のIntelにとってはいらない子の実力なのであしからず。 Nehalem-EXの絶対性能はさらに凄まじい差をみせてくれるでしょう。
今だにクロックで比較するバカ発見
>>913 話はそう簡単ではない。power6のcore係数は、春に0.75から1.0に値上げ
したんだが、これはitanium 0.5に対して妥当だ。ここでitaniumのcore
係数を上げると、またpower6が割安になってしまう。
コア係数とかやめてソケット数とメモリの量で計算しろよ
>>913 そんなにすごいんならどっかが買ってあげたら? 喜んで手放すと思うよw
あれだけ巨大な体力を注いであの程度ってことなら、他社がやったら 全く話にならん、すぐ潰れてしまうということだろな。
結論書き忘れた、アーキテクチャとしては「使えない」、てことだろう。
いや、IntelはItaniumにリソース割いてないだろ。 あの、ほとんどやる気ないとしか思えない、新製品投入のなさ・・・。
負け犬の遠吠え?
負け犬の遠吠えはSPARC儲の十八番でもあるわけだが
Sun Microsystems 最期の釣堀
>>921 それはここ数年(一昨年くらいか)の話。それまでどんだけ注ぎ込んでると
思ってるんだ。
一昨年とか言ってる時点でニワカ丸出し
なんのニワカだよww バカ丸出しだなまさに
無知を指摘されて逆切れって恥ずかしいね
VLIWはまともに活躍したことないな。
>>928 だからなんの無知だってんだ。しばくぞボケ
わかってないのは本人だけ?
オイ、おまえ。ふざけんな。>926 の説明きっちりしろカス。無脳。
キエッヘヘヘ、ウエッヘヘヘ
ウフフフフ、オホホホホ
フヒヒwwwwwサーセンwwwwwwwwww
最大の暗礁
最大の負犬
クズが。
Sun Microsystems 巨資の注入
Sun Microsystems 大望で翻弄
最大の岩隠
アマテラスか
最小の前隠
Sun Microsystems 最後の舵取
Sun Microsystems 最初の身売り
Niagara系が売れた話は具体例出ないねぇ。まあ、ちっちゃい案件ばっかなんだろうが。
いいじゃんw # 分散メモリ型スーパーコンピュータシステム(理論ピーク性能:33.7TFLOPS) 「X5570(2.93GHz)」「PRIMERGY RX200S5」360ノード(720CPU、2,880コア)+InfiniBand® QDR # 共有メモリ型スーパーコンピュータシステム(理論ピーク性能:4TFLOPS) 「SPARC64 Z」「SPARC Enterprise M9000」×2
富士通は、いつになったらSPARC64VIIIを発表するんだ? あと、いつになったらVIIIfx搭載製品を発表するんだ? まだ評価中なのか。 それともバグ直し中なのか。 歩留まりが恐ろしく悪くて京速以外に回す数が出ないのか。
2年後にはXeonはSandy Bridgeで浮動小数点演算性能が2倍に跳ね上がる。 SPARC64VIIIfxの128GFlopsは、さっくり追い抜かれる。 しかも、Xeonは12コア×8ソケットをグルーレスで実現できるスケーラビリティを持つが、 SPARC64VIIIfxはSMP機能を持たない。 京速専用だな。
出てない製品の話をしてもしょうがないよ
>>950 VIIIの話なんて、出てないよね。VIIIfx出たあとで考えるんじゃない?
歩留まりとか以前に、そういう方針かと思うけど。
うむ、VIIIfxなどという、出てない製品の話をしてもしょうがないな。 出てもいないのに世界最速とか、もうね、アホかと。
Rockはいつ出るんだ?
Rock出したって、富士通のMシリーズのサーバに、信頼性で劣るだろう Rock出したって、スケールアウトならNiagaraシリーズに、スループットで劣るだろう Rockは中途半端でいらない
京速は光速を越えるw
>>956 何言ってるんだ、Rockでは斥候さんが大活躍するんだぞ?
スカウトスレッドの消費電力、 スカウトスレッドによる機構の複雑化による信頼性の低下、 時代にそぐわない
半導体の微細化によってコア数は増える一方だが、メモリのレイテンシはあまり短くなっていない。 ゆえに、L3やL2キャッシュからのロードは無駄に行っても構わないが、DRAMからのロードは無駄に行ってはいけない。 レイテンシの大きなDRAMからのロードに対して、マルチスレッドでレイテンシを隠蔽するのは良いが、 スカウトスレッドによって先回りして投機的にロードを行うのは、無駄なロードが生じるので良くない。
馬鹿乙
だいたいDRAMは秒間20M回くらいしかアクセスできない。 たったの20Mですよ。 それに対してコアが2.5GHz×8個で20G コアとDRAMで、1000倍の開きがある。 ちょっと開きすぎ。
ん、いや8コアならメモリは4chくらいが普通か。 それでも250倍の開きがある。 DRAMアクセスが250クロックに一度しかできないのはキツいね。
だってメモリでもHDDでもバースト転送を稼ぐことしか追窮してこなかったぢゃん
intel tueeeee
TOWNSが3ウェイトだ、って文句言ってたのは遠い昔の事
3ウェイトは、ひ・ど・い 386DXのメモリアクセスは2クロック@ノーウェイトだから、3ウェイトも入れたらトータルで5クロック。 386SXでダブルワードでメモリアクセスして、2回のメモリアクセスになっても4クロック@ノーウェイト。 もしかしてバスが16ビットだったのかな。
遅かろうと何だろうと、386以上が保証されているパソコンであることが重要。 9801もAT互換機も16bit環境だったが、TOWNSは32bit環境。この違いは大きい。
昔話に花が咲く
我々は過去を見つめて後ろ向きに飛ぶ鳥だからな
東京負けたらしいぜ
Sun Microsystems 最大の企業売春
企業売春ってホメ言葉だよな?
売れてるならなw
売春などと頭の悪すぎるスレタイがいいんならすでにあるからそっち行け
Sun Microsystems 最後の虹滝
Sun Microsystems 最後の蒸気機関車
最後の滝汗
>>981 スレタイがクソすぎて見捨てられたクソスレなのでスルー推奨
自社に有利な係数だと他社からイチャモンつかないのかな?
HPやIBMはOracleに頭が上がらないから大丈夫
HPはともかく、IBMはDB2があると思うんだがそれでもなのかな?
それでも。 IBMがやる案件ならDB2で済むかもしれないが、 SI屋がやる案件だと、まずOracleってのが決まっていて。その次に、Oracleを動かすためのハードとしてサーバを選ぶから。