nob's Weblog
STK5800 信頼性
さて、STK5800（Honeycomb）のどこが新しいのか？
信頼性について
ストレージの信頼性と言えば、ディスクやその他の部品の故障に対して、どのくらいの耐性があるか、ということが気になるわけですが、Honeycombでは、同時に二つのディスク、あるいはディスクを収容しているノードに故障が発生しても、データを失うことがありません。しかも、自動的に修復が行われて、修復後には再び二つの障害同時発生に耐えられるようになるのです。
それらしい用語で言えば、単一故障点が存在しない、ということです。
でも、こういう事って、資料的には簡単に言えるのですが、正直言って自分で試してみないと納得しにくいんですよね。で、現在デモ用のシステムを日本に持ってきているので、近々実際にテストをしてみるつもりです。
まずは、それ用にデータをボンボン放り込まないと……
Posted at 12:45午後 12 06, 2006 by nob in General | 投稿されたコメント[0]
Sunジャージ
やっぱりSunがスキ！でいろいろとSunグッズが紹介されているので、こちらでも少し。
と言っても、通常のノベルティーではありません。社内の自転車好きが集まっているメーリング・リストで勝手に作った物です。
Posted at 09:30午前 11 30, 2006 by nob in General | 投稿されたコメント[2]
STK5800 (Honeycomb) RSNA２００６ でデビュー
自転車の話ばかりでなく、少し仕事の話も :-)
私は、普段はSPARCプロセッサそのものや、Sunのシステムで使用されているマザーボード、あるいは通信向けの組込用の製品を担当しています。
最近では、そのような製品に加えて、ストレージの製品を扱うこともあります。
Sunのストレージ？なんて方もいらっしゃるでしょうね。でも、結構いろいろとやってるんですよ。たとえば、NAS、SAN製品や、昨年来一緒になった StorageTek のテープを使った製品群など。
でも、私が最近関わっているのは、それらとはまたちょっと毛色の変わって製品です。
Honeycomb と呼ばれているプロジェクトです。
この製品は、アプリケーションを意識した、プログラマブルなストレージソリューションです。
Honeycomb ではあるレベルまでのデータ・サービスをアプリケーションサーバではなく、ストレージデバイスに任せられるようになります。しかも、そのデータサービスの性能は、容量とともに簡単にスケールをする。
また、ハードウエア的にも低価格な 構成要素を、うまく組み合わせることによって、高性能、高信頼性を実現しています。
というわけで、 なかなか向いているんじゃないかな、と思うのが医療向けのアプリケーションです。
アメリカのシカゴで今行われている 北米放射線学会でいくつかSunのテクノロジーの紹介が行われていますが、その中でもこの記事に詳しく紹介されています。
この記事にも出てきますが、StorageTek5800というのがプロジェクト Honeycombです。
Posted at 02:29午後 11 29, 2006 by nob in General |
自転車通勤はちょっと厳しいので
知り合いにも、自転車通勤をしている方が結構いますが、私はなかなか難しい。 家からの距離は、20kmもないから手頃なんですけどね。そうすると途中R246を通らないと行けないし、結構なアップダウン。そしてなにより、着いたらきっと汗だらだらなんです。
で、私はどうしているかというと、Sunでは条件次第で在宅勤務を選べる 事があるのですが、私の場合は（特に大きな出来事などがなければ）週に一二度は在宅で仕事をしています。そんな日は通勤時間分位を使って自転車に乗っています。
もちろん、天気が悪かったり、体調が悪ければ乗らないんですが、なかなか快適ですよ。今日は在宅勤務ではないのですが、暖かかったので、朝のうちに３０分ほど走りました。
これから寒くなると、なかなか朝は走りにくいのですよね。ま、今のうちだけでも
Posted at 01:49午後 11 29, 2006 by nob in Bike |
自転車いろいろ
普段はよく自転車に乗っています。
最初は、MTB もどきに乗っていたのですが、いつの間にか４，５台になってしまいました。一番最近手に入れたのが、リカンベントという種類の自転車です。寝そべって、というか、ふんぞり返ってというか、まぁ、そんな格好で走る自転車です。
はっきり言って目立ちます。家の近所で乗ってると、子供や奥様連中に指さされることはしょっちゅう。
でも、気持ちいいんですよ。普通の自転車と違って、前方の視界が広いんです。特に空がよく見える。
Posted at 08:50午前 11 21, 2006 by nob in Bike |
Bigger is better?
ダイ上での集積度と性能についてもう少し
ダイに占めるコアサイズとスレッドごとの相対的な性能値を調べたところ
100%を占有した場合を1とすると、約半分を占有した場合には性能は90%程度になります。そして、ダイ面積の10%を占有した場合でも50%の性能を
発揮できる、という結果になりました。（もちろん、現実にはそれぞれのプロセッサが、いろんな考えに基づいて設計されるので、必ずこうなるというわけでは
ありませんけれど）
つまり、一つのコアで目一杯ダイを使ってしまうのではなく、複数のコアを実装した方が全体の性能を引き出せると言うことになるのです。
Posted at 02:23午後 7 30, 2005 by nob in SPARC | 投稿されたコメント[0]
Niagara on the web
先日、報道関係者向けの技術説明会を行い、その中でNiagaraについて、少々お話をさせてもらいました。
そのときの説明会を元にしていただいた記事がいくつかWeb上で掲載されていますので、お知らせします。
「消費電力あたり処理性能に自信、サンのNiagaraプロセッサ」
ITmedia Enterprise 2005年7月26日
「Niagaraのリリースで効果測定の指標を変えるサン」
ASCII24 2005年7月27日
「サン・マイクロシステムズ、次世代SPARCプロセッサー“Niagara”の技術説明
会を開催——省電力/省スペースの実現と処理性能の向上を両立」
MYCOM PC WEB 2005年7月27日
「最新CMT SPARCプロセッサ「Niagara」は新世代の「エコ・プロセッサ」」
Enterprise Watch 2005年7月27日
「「業界に敵なし」次世代SPARC系CPUの低消費電力をアピールするサン」
でも、まだ詳しいベンチマークの値などを公開できないので、話す方もちと欲求不満でしたが、もうしばらくしたらドーーンとお話しいたしますので、ご期待を。
Posted at 12:22午後 7 27, 2005 by nob in SPARC | 投稿されたコメント[0]
full capacity?
詰め込めばいいのか？
ダイ（シリコンのチップですね）の上にはどのくらいのトランジスタを埋め込めるのか？というのが、動作速度とともに、今までの集積回路の進歩の指標の一つでした。
当然、一つ一つのトランジスタのサイズが小さくなればなるほど、一定の面積に配置できるトランジスタは増えるのですが、その使い道は、問題ではないのでしょうか？
プロセッサの世界で考えると、より賢く処理をさせようと言うことから、
- キャッシュの大型化
- スーパースケーラ化
- Out-of-order 処理の実現
- 周波数の高速化
- より深く、複雑なパイプライン
- 分岐予測に基づくプリフェッチ
Posted at 02:11午後 7 10, 2005 by nob in SPARC | 投稿されたコメント[0]
Comments?
コメントをつけられない？
何か変更があったようで、最初の頃は問題のなかった日本語タイトル（というか、非ASCIIということか）のエントリーへのコメントがうまく働いていないようです。
ですので、以前のエントリーへのコメントがつけられないようになっています。今後のエントリーは大丈夫だと思うのですが、もしも、以前のエントリーへのコメントがあれば、こちらにつけてみてください。
Posted at 11:02午前 6 29, 2005 by nob in General | 投稿されたコメント[1]
End of fiscal year
年度末
Sunでは会計年度が7月に始まり、6月に終わります。というわけで、今月は年度末。来年に向けての準備という感じの期間です。
来年は社内の人間としてもおもしろそうなものがいろいろと出てきそうなので、なかなか楽しみ。
Posted at 02:54午後 6 26, 2005 by nob in General | 投稿されたコメント[0]
Memory doesn't catch up
記憶が追いついてこない
コンピュータの高速化の歴史の中でも、おなじみの問題の一つがメモリ・ボトルネックというもの。
非常に大ざっぱに言うと、処理速度にメモリのアクセスが追いつかないという問題です。今回のプロセッサの例でいえば、命令を処理する部分が高速化されても、メモリへのアクセスによって発生する遅延が短くならない。
もちろん、メモリだって進歩はしているんですが、こちらの方はI/Oのプロトコルの問題や、データ幅の問題などもあって高速化は、せいぜい6年で2倍程度になっています。そうすると、2年で2倍ペースで高速化されている処理との差がどんどん開いてしまう訳です。
このギャップをいかに隠してあげるか、というのが腕の見せ所になる訳です。
一般的には、どうしているのか？
メイン・メモリにアクセスすると遅い訳ですから、一つの手として、なるべくメイン・メモリへアクセスをしない、ということが考えられます。これを実現する
ための仕掛けの一つがキャッシュ・メモリの採用です。つまり、速度の遅いメイン・メモリの内容を高速のキャッシュ・メモリにコピーしておくことによって見
掛け上のアクセスを高速化してあげるのです。
この方法が進んでくると、より高速、大量のキャッシュを置くようになり、その結果キャッシュ・メモリも2段3段と階層化され、容量自体も数kバイト程度
だったものが数Mバイトを優に越えるようになってきました。でも、このまま大きくして行っても、どうやら見返りはどんどん目減りをして行くようです。
しかも、今回考えているような、比較的小さくて、しかも寿命の短いデータ、たとえば認証が済めば捨てられるあるいは転送・処理されたらそれでおしまいのヘッダ情報などを大きなキャッシュにため込んでもあまり意味はないのです。
そこで、出て来たのが、ある処理の単位でメモリ待ちになったときに、次の処理に資源を明け渡してしまうという考えです。そうすることによって、パイプライン、レジスタなどの資源を有効活用しながらメモリ待ちの時間を見えなくすることが可能になるのです。
でも、そんな風にして良いアプリケーションは一杯あるのでしょうか？それはまた次回。
Posted at 09:25午前 6 20, 2005 by nob in SPARC | 投稿されたコメント[0]
give simple tasks simple guys
単純なことは単純なやつに
ここで問題にしているのは、比較的単純な処理を数多くこなす必要があるということです。
実は、今までの大概のプロセッサの高速化では比較的複雑というか、パイプラインをいかに動かし続けるか、というような点に力が注がれてきました。つまり、
命令レベルでの並列化という点に力点を置いて、深いパイプラインを形成する傾向にあったのです。（いわゆる科学技術計算の分野での応用です）
つまり、今考えていることとは根本的に矛盾するんですね。
そこで、大きな発想の転換。
このアイデアを初めて聞いたとき、「本当にそんな簡単なことで良いのか？」というのが私の感想でした。そりゃぁそういうタイプの問題もあるだろうけど、それは汎用プロセッサとして成立するのかい？
それに、問題はそれだけじゃないよなぁ……
Posted at 02:15午後 6 19, 2005 by nob in SPARC | 投稿されたコメント[0]
Niagara
Open Solaris もおもしろいのですが、個人的にはやはり Niagara のデビューが近づいていることでわくわくしています。
32bit時代からSPARCと付き合ってきていますが、今回の進化には正直驚かされています。
CMTつまり、Chip MultiThreading というコンセプトを、とてもシンプルなパイプラインを使って実装することによって予想以上の（自分の予想が甘かっただけですが）性能を引き出せる、というのがうれしい喜びです。
今の時点ではあまり詳しい性能値をお話しできないのですが、現在日本語での資料を作成準備中です。
# 早く話したくてしょうがない……
Posted at 01:45午後 6 16, 2005 by nob in SPARC | 投稿されたコメント[0]
Solaris がとうとうOpenに
とうとうSolarisがOpen化されました。
自分自身は、元々SPARCというCPUに惹かれて仕事をしているうちに、気がついたらSunの人になっていたんですが、SPARCにはいつもSolarisという相棒がついています。（いや、最初はSolarisとか呼ばれていませんでしたけど）
SPARC自体はその仕様も早くからSPARC Internationalで公開されていて、実際にも過去10数社で実装されてきました。その中でいろいろと新しいアイデアや古くからの知恵が活かされてきた結果、いまのSPARCが生まれてきたのだと思っています。
今回のopen化でSolarisも新しい進化に段階にはいるとおもしろいことになる、と思っています。
Posted at 10:27午前 6 16, 2005 by nob in OpenSolaris | 投稿されたコメント[0]