Old Boy

Intractable Diseases

「難病」ってなんだろう、は、社会通念としての、いわゆる「不治の病」が近いですかね。その疾病が「難病」であるかどうかは、時代や医学の進歩によっても変わります。五十年前は、結核は「難病」の代表だったと思いますが、今はそういう感覚ではない。その意味では難病は次々と克服されているんですが、逆に、五十年前には「特定の疾病」だと分類されていなかったものが、病像が明らかになって、「新しい難病」になったりもします。行政的には、難病の中でも、「特定疾患」として、121 の疾病が、いわば認定されていて、ここに List されているものが難病だ、と取り扱われることが多いと思います。

特定疾患の認定基準は、
1. 治療が極めて困難
2. 病状が慢性的で、あるいは後遺症が大きく社会復帰が極めて困難
3. 医療費も高額で、経済的・精神的に負担が大きい
4. 症例が少なく、全国的な規模での研究が必要
です。121 の中には、他の Popular な疾病と病像が似通っていて、なかなか「その病気」だと特定するのが難しい、特定できれば治療は比較的容易だが、似通った Popular な疾病だとして治療されると、慢性化したり、後遺症が残ることが多いので、「特定疾患」として特掲して、情報の提供を行うことが重要、を主な理由として「特定疾患認定」されているものもありますので、全部が全部「とても深刻な疾病」とまでは言い切れませんが... この意味での「難病」では、肝ガンの幕内先生のような「切り札」もないし、専門研究者は居ても、なかなか「専門医」は成立しにくく、地域のお医者 さんがそれぞれの患者さんを Care する、が、基本になる場合が多い。しかし、誰にとっても「稀な病気」ですから、それぞれのお医者さんにとっては、まあ一生で一症例、のような世界であり、個々のお医者さんの (自己経験的な) 技倆だけでは、十分な Care はできません。そこで、症例を持っているお医者さん同士、や、その疾病の専門研究者を結ぶ Community で、経験や知見を共有して、よりよい Care や、少しでも治療法を進展させる、は、とても重要で、尖端医療 Challenger の Community のような、「めざましい進展」で社会に貢献する、ではないかも知れませんが、Internet 上での Community はここでも大きな役割を果たしています。いくつかの「難病」では、お医者さんの Community だけでなく、患者さんや、患者さんの家族の Community も Internet 上に存在しているようです。

ある別のお医者さんが、Web 2.0 のお話、を聞いて「目新しい話、というよ何か、医師の間の Community で昔からやってること、との共通点を感じる」とおっしゃっていました。確かに Long Tail って、稀な病気という意味での「難病」への対処は、何せ「稀」ですから、広い Network 上で、Network で　Enable された「情報の共有」によってこそ、稀であることでの困難を乗りこえることができる、と、本質的には似ているところがありますね。勿論、「それが Business になる」という視点が Web 2.0 なのでしょうから、そこが違うよ、はありますが、Community の力、を、どう活かしていくか、のアプローチとして、や、Community の力を必要とする人 = Community への貢献者、という構造では、お医者さんの Community は、期せずして (必要に迫られて) その辺を実現していた、と言えるかも知れません。

( 9 30 2006, 09:04:10 午前 JST ) Permalink

Liver Cell Cancer

お医者さんの Community は、Internet でも多分最も古い Community の一つだろうと思います。15年前に、高校の同窓生の Mailing List に入ったとき、まあお医者さんになる人が多い学校ではあったのですが、通信や計算機に進む人も多かった筈なのに、Member の半分がお医者さんだったのには、ちょっと驚きました。当時はネットワークのコストも高くて、お医者さんなり、大きな医療機関は、負担力が比較的大きいから、もあったんでしょうが、それだけお医者さんにとって、Internet の介する「Community の力」が有用だったからこそ、でしょう。

医学、特に臨床医学は、科学の領域でも、原理だけで動くものではない、経験科学の色彩が濃いんだと思います。Popular な疾病であれば、原理のところも追求が進んでいるし、個々のお医者さんも自分の患者さんとしての臨床経験を積んでいますから、広く、最善の (最善に近い) 医療が可能 ですが、稀な疾病、では、原理の追求も不十分だし、医学界全体の症例経験も不足している。ましてや個々のお医者さんにとっては、自分の患者さんとして診療に当たることは一生に一例、とか二例、ですから、普通は経験の積みようがなくて、稀な病気、は、もともと易しい病気ではないんですが、「稀であること」が、その病気をますます難しくしています。それでも、その病気に決め手、なり、将来の決め手候補のようなものがあれば、例えば、原発性の肝ガンは、ウィルス性肝炎が広がったことで増加傾向にあって、もう稀な病気とは言えなくなりましたが、切除術が適切な症例 (切除以外の療法が適切な肝ガン、もいくらでもあるのですが) の場合、東京なら女子医大や国立がんセンター、東大幕内外科が「決め手」で、そこに症例が集まる。「決め手」群に症例が集まることで、経験や知見が蓄積されて、治癒成績も上がっていく。そこでの経験や知見が広がって、「決め手」医療機関も増えるし、あるいは、肝ガンの専門家ではなくても、肝ガンが疑われる患者さんに「幕内先生をご紹介します」は当たり前に言えるようになる。肝ガンが易しい病気になった、とはとても言えませんが、昔のようにオーバーに言えば「奇跡を待つしかない」ではなくなりました。

しかし、15年前、はまだまだ肝ガン治療は黎明期で、肝ガン治療に取り組む、は、かなり Challenging な課題だった時代です。肝ガンの治療には、切除以外にも有効な手段がいくつもありますが、世界に散在する「肝ガン治療に Challenge する人」が、治療アプローチ毎に Network 組んで、お互いの経験を共有し、こうすればもっと有効じゃないか、を議論しあう場、当時で言え ば Newsgroup が、治療アプローチ毎の競争のように活発に動いていて、それが肝ガン治療の進化を推進していた。国際学会でこんなことやっているよ、を発表すると、Newsgroup に入れ、と言われて、大学病院であれば、キャンパスまでは Network 繋がっていますし、海外との (年一回の学会と かではない) Realtime で、Interactive な Communication は、共有できる経験や情報がケタ違いですから、特に尖端医療に Challenge するお医者さんにとって、Internet は重要な Tool として広がっていたんですね。

( 9 29 2006, 08:51:00 午前 JST ) Permalink

O-157

日本で O-157 (腸管出血性大腸菌) による食中毒、が発生して、当時の菅直人厚生大臣が「カイワレ大根が原因である可能性を否定できない」発言が問題になったのを記憶していられる方も居られると思いますが、丁度あれは十年前の夏、です。菅発言が名誉毀損に当たるかどうか、は、地裁・高裁で判断が分かれたり、で、法理論的にも難しいところがあったようです。

政治と科学と法理論、は、勿論密接に繋がってはいるのですが、自分は乱暴に言ってしまえば、別の世界、で、それぞれで判断が分かれるのは仕方ないし、逆に言えば、それぞれの立場での「判断の妥当性」の基準が全く同じである、は、ありえない、と思っています。判断の基準が違うからといって、必ず「判断そのもの」が違うか、というと、大抵の場合はそう違いはしないものだと思いますし、それだからこそ世の中は回って行くんですから、違って当たり前、と言っている訳ではなく、「違うことがあり得る」し、「違うことが悪い、ではなく、違うことに意味がある場合もある」とい う程度ですけど... 余り、良い例とは言えないかも知れませんが、菅発言が、食中毒発生の直後で、その蔓延を防ぐため、であれば、あるいはもっと科学的根拠の確実性が低くても、「政治家の発言」としては、やむを得ない場合もある。O-157 の日本ではほぼ初めての流行で、お医者さんの間でもまだ臨床体験がなくて、Risk は今考えるより高かったと思いますから、二次汚染、三次汚染を断ち切る可能性、として、どう行動するか、は、厚生大臣は行政の長でもありますが、それを「政治家」が勤めることの意味、は、「政治家としての判断」を求められる局面でこそ問われる、のだと思います。実際の菅発言、は、流行 Risk も鎮静化し、臨床的な対症方針もある程度固まったところでのもので、タイミングとしては、ちょっと違う、別の角度での判断、も入っているんだと思いますが、その分、「感染経路の推定」の科学性は高くなっている、はあっても、法的な判断としてはビミョーなんでしょう。

O-157 の日本での初めての流行、に際して、その臨床の確立、に Internet の果たした役割は大きかったよ、を、当時の流行の中心に近い地域の医師会で「IT 担当」みたいなことをしていた友人が言ってくれたことがあります。どんなお医者さんにとっても、O-157 の患者さんは初めての体験で、こういう症状だ、こういう対応が有効だった (あるいは効果が疑わしい) の情報は、当初は殆どない。それが、患者さんを抱えている現場のお医者さんから、自分の症例、が、Internet に情報発信されて、情報は「そこにしかない」から、どんどんそこで Feedback が進む、最初は玉石混淆でもそれがスバヤク「集合知」に成長していく。友人は内科医ではなく、自分のところに患者さんが来るわけではないので、患者さんを抱えているお医者さんの情報受発信の「お手伝い」しただけ、と謙遜してましたが、Internet がなかったら、O-157 流行、はもっと深刻な問題になったかも知れない、が実感としてあるよ、と言っていました。

( 9 28 2006, 08:59:57 午前 JST ) Permalink

Sound Science?

確かに、汚染された MMBM から BSE の感染メカニズムが (症例が多いこと、が、期せずして「実験」になっていることもあって) かなり明らかであるのに比較すれば、BSE ウシ -> ヒトの感染メカニズムは、まだ「かなり確かな推定」に過ぎない、という主張は、聞くべきところがあるし、ここの解明への努力は、古典的 CJD のメカニズムの解明にもつながる可能性があって、重要である、はその通りだと思います。

ただ、対策、という話と、科学的な解明が必要、は必ずしも同じではありません。潜伏期間が長いので vCJD が現状の 200例弱でとどまるのかどうか、は、確定ではなく、あるいはこれからも多少の発症を見るかも知れない、はあるのですが、BSE は もっとも High Risk な群であった 96年以前生の英国のウシは殺処分で発症前に処理されたものが相当あると見られ、BSE 発生の 20万頭弱と、vCJD 患者数の 200例弱の比較、即ち vCJD の発生頻度は BSE の 0.1% 程度、という数字は、実際にはもっと低かっただろう、と考えられます。牛肉は食べたいけど、アブナイものを口に入れるのはイヤ、は、ヒトの感情としては当然だろうし、ですからウシ -> ヒト対策、に力を入れて欲しい、は当たり前で、だから BSE 検査、なり、SRM (特定危険部位) の除去なり、ウシ -> ヒトの遮断、が対策として実施されています。これらの対策はウシ -> ヒトへの伝播も Prion 仮説的に起きているとすれば、有効性はかなり高いし、Prion 仮説的に起きているのではない、としても、ある程度の有効性はある、と考えるのが普通なので、否定されるものではありません。しかし、MMBM -> BSE の遮断、に比較すれば、発生頻度から考えても、伝播メカニズムの解明の進み方を考えても、有効性の確度が高いとは言えないことも事実だと思います。

追って見て行きたいと思いますが、国際的には、MMBM -> BSE -> vCJD への対策、は、今でもかなり進んでいる MMBM -> BSE の遮断、をもっと徹底すれば、BSE の発生を Zero に近づけることができる、BSE が Zero に近づけば BSE -> vCJD の Risk は、(その 1 / 1,000 だから) 限りなく Zero に近づく、が合理的だと考えることが多くなっています。ちょっと日本人的には割り切れないところもあるし、MMBM -> BSE の遮断が不完全だった時代の負の遺産、はしばらく残りますから、ウシ -> ヒトの遮断対策は、まだまだ必要と思いますが、国際的にはそちらの方に重点が移りつつあります。

( 9 25 2006, 08:52:43 午前 JST ) Permalink

Sporadic CJD

Prion 仮説が 100% 真であるかどうかは別として、MMBM -> BSE が BSE 流行の中心経路であることは確実であり、BSE を押さえ込めば BSE -> vCJD もないんですから、MMBM をウシに与えることを禁止する、は、vCJD 対策としても有効で、これは、全世界共通で実施されています。(MMBM 禁止、の実施の方法は、各国で濃淡がありますが...)

ヒト CJD の場合は、BSE の発生前から古典的な Sporadic CJD (孤発性 CJD) は存在して、BSE 由来の vCJD はその名の通り variant に過ぎません。その発生を見ても、vCJD は、全世界で今までに累計で 200例弱、その大半が英国で発生しているのに対して、古典的 CJD は日本では年間 100例程度、世界的にみても、ほぼ同じ割合で発生していて、Volume 感で言えば、CJD だって非常に稀な病気ですが、vCJD はそれとも比較にならない位小さいんですね。ヒトの脳硬膜由来の製剤の使用で起きた医源性 CJD が日本でも 60例以上確認されていますから、それと比較しても小さい。BSE はウシには気の毒な話、というか、本来草食動物のウシさんに人間が MMBM なんていう「異物」を与えるから起きてしまった、文明がもたらした災厄だし、その衝撃も大きかったのですが、衝撃が大きかった分、「対策」も大々的に実施されて、それが大流行には至らなかった。対策が取られなかった場合、vCJD はもっともっと蔓延したかも知れないんですが、まあ「文明」のおかげで (効果のある対策、が取れるのは文明のおかげ、ではあるし、発生したのが、総合的に見て 「世界屈指の文明国」である英国だった、も対策の有効性という意味で大きかっただろう) 古典的 CJD は勿論、医源性 CJD と比較しても、ヒトへの影響はよほど小さく食い止めつつある、と言えそうです。

BSE / vCJD は Visual な衝撃性みたいな側面で、これも十分不気味なんですが、古典的 CJD が、何らかの意味で感染性のものであるらしいのに、それが世界的にほぼ均一に発生している、は、科学的な説明がそう簡単に付きそうもないし、MMBM / BSE / vCJD への有力な説明であり、有効な対策の根拠になっている Prion 感染仮説も、古典的 CJD の感染の説明としては、到底十分ではない、ある意味 BSE / vCJD よりもっと不気味ですね。Prion 仮説は、BSE / vCJD 問題で Close Up されて、BSE / vCJD 対策の中で、仮説としても発展しているし、対策の有効性を裏付けてもいます。しかし、Prion 仮説が古典的 CJD を含む、Prion 病全体を説明できるところまでは、まだ至らないことは、Prion 仮説に基づく BSE / vCJD 対策が「完璧」とはいえないとする議論の根拠にもなっています。

( 9 24 2006, 08:54:24 午前 JST ) Permalink

MMBM

今、プリオン病または TSE と呼ばれる疾患は、例えばこのサイトにまとめられていますが、1986年以前によく知られていたものは、ヒトの v のつかない CJD (孤発型クロイツフェルト・ヤコブ病) とクールー症、ヒツジのスクレーピー症です。クールー症は、死者の脳を食する習慣のあった部族で存在した疾患で、特殊な習慣 / 特殊な症例ですから、原因の推定が容易で、ここがプリオン病研究の起点になります。プリオン病が大きな注目を集めるのは、それまではプリオン病の発生が知られていなかった、ウシが発病する BSE の英国での発生で、それが問題になり始めた 86年当時は、狂牛病と呼ばれていたことや、発病したウシの衝撃的な映像を記憶されている方も居られると思います。

BSE を発病したウシが斃死すること自体が、畜産業に対する大打撃ですが、 BSE の原因としてスクレーピー症のヒツジからの伝播が疑われ、その伝播経路と推定される、ヒツジを処理した MMBM (Mammalian Meat and Bone Meal : 哺乳動物の肉骨粉) のウシへの給餌の禁止、が 88年から一次対策として実施され、BSE の発生は鎮静化に向かいます。ヒツジさんの名誉 (?) のために言っておきますと、ヒツジが危ない、だけで MMBM の禁止、ではなく、MMBM の給餌濃度と BSE 発生の強い相関、が、MMBM 禁止の大きな要因であり、また感染物質としてもスクレーピー症ヒツジ、は、発端ではあったかも知れないが、量的には BSE 感染ウシからの MMBM のものが圧倒的だった、と今日では考えられています。

プリオン病の社会的な影響がより大きくなるのは、BSE に感染したウシをヒトが食したことで、ヒトが CJD に罹患したと見られる症例の発見された 96年です。BSE ウシ起源の CJD は、古典的な CJD と異なる病像があり、区分する意味で vCJD と呼ばれます。 vCJD の「異なる病像」は、例えば CJD は 65才を中心に、精々 50才台が発病の下限ですが、vCJD では 30才のような比較的低年齢でも発病する、などがあり、脳波の形も CJE と vCJE では異なるので、区分可能とされます。ただし、100% の致死性、は同じ であり、ウシだけの BSE であれば、発生が一定レベルまで落ちれば、まあ対策は成功といえるのですが、ヒトへの伝播、は話が違って、限りなく Zero に近い、まで行かなとそれは対策として十分とはいえない。88年の MMBM 規制はある意味「しり抜け」の部分もなかった訳ではありませんが、96年以降は MMBM の禁止、は徹底され、また、英国で 96年以前に生まれたウシ (言い換えれば病原体を含む MMBM を給餌された可能性が皆無ではないウシ) の段階的な全面殺処分 (即時、ではなく段階的なのは処理能力の問題もありますが、MMBM を給餌されていないウシの再生産を確保する意味もある) が EU 指令の形で実施されます。

( 9 23 2006, 09:24:49 午前 JST ) Permalink

高木兼寛

科学的な原理の確立よりも、対策、が先行して、むしろその対策が有効だったことが、科学的な原理の確立を導いたのは、壊血病や脚気のようなビタミン欠乏症への「対策」と、その後のビタミンの発見、が、その典型的な例です。ビタミン欠乏症の発生は、別に軍隊に限ったものではないのですが、軍隊は、集団で似たような生活条件と食餌が与えられる場ですから、その現れ方が典型的で、しかもその発症は、大きな戦力低下をもたらします。近代の軍隊は、その戦力の維持のために「軍医」の制度を持っていて、彼らにとっては壊血病や脚気の撲滅は最大の課題であり、ビタミン欠乏症 (であることはまだ分かっていないのですが) への対策、は、主として軍隊で進みます。

脚気が今で言う Vitamin B の欠乏症であることへの「対策」を世界で始めてとったのは、明治海軍の高木兼寛です。高木は海軍から英国留学を命ぜられて日本人で英国医学を体系的に学ぶ最初の人物で、現在の東京慈恵会医大の創立者としても有名ですが、高木は当初脚気がタンパク質とデンプン質のバランスが悪いことに原因があると考え、海軍の兵食の改善を図ります。1883年の、ニュージーラ ンドから南米、ハワイを回航する練習航海で、乗組員 376 名の約半数が脚気に罹病し、内 23名が死亡する、という事件の翌年、高木は練習航海を全く前年と同じコースで、食餌条件を高木の指定で実施する一種の実験、を、強硬に主張して実現させ、食餌条件を守らなかった乗組員で少数の罹病はあったものの、死者はゼロという結果を得、海軍では、白米食から半麦食への転換が定着して、脚気の発生は殆ど皆無となります。この成果は欧米では大きな注目を浴びるのですが、当時はドイツ細菌学の勃興期であり、ドイツ医学の牙城であった東京帝大と陸軍軍医部は脚気細菌説に傾いて、食餌対策を否定します。その結果 1904-5年の日露戦争では海軍は脚気患者が殆ど皆無だったのに対し、陸軍では全戦線で脚気患者を多発させ、実に脚気による戦病死者 27,800 名 (日露戦争の陸軍の戦死者は 47,000 名であり、その数字を比較すると、いかに脚気が深刻だったか、が分かります) という戦慄的な対照になります。この辺の葛藤は、先頃亡くなられた吉村昭さんの「白い航跡」(講談社文庫) に描かれています。

確かに、高木の脚気対策である「半麦食」は、当初はタンパク質に着目した「誤った仮説」から導かれたものであり、科学的ではない、という帝大 - 陸軍側 (その主要な主張者が鴎外森林太郎であったことは有名) の主張は、間違っていた訳ではありません。しかし、誤った仮説に導かれたものであったにせよ、「対策」の有効性は二十年の実績で明らかであるのに、「仮説が証明されていない」ことを理由に「有効な対策」そのものを否定するのは科学的でも何でもありません。この「対策」を巡る論争には、陸軍 vs 海軍、や、ドイツ医学 vs 英国医学、のような、科学というより政治の範疇、も絡んでいて、陸軍側でも緒方惟準のように高木の対策を有効と認めた医官は居たのですが、圧迫されて陸軍を去る、など政治的な対立、でもあったことが、陸軍側の対応を頑なにした、は否定できず、科学と政治、がマズく絡むとトンデモナイ結果をもたらす、も、一つの側面でしょう。

( 9 22 2006, 09:08:32 午前 JST ) Permalink

Edward Jenner

ここしばらく Computer ネタが続いたし、あんまりそればかりでも、で休日ネタ、を考えていたのですが、長いこと「Working Day には更新」をやっていて更新をサボると、何か、とかご心配頂いたりもしますんで...
Topic は吉野家さんの牛丼復活、で、再び盛り上がっている BSE (Bovine Spongiform Encephalopathy : 牛海綿状脳症) / v-CJD (variant Creutzfelt Jakob Desease : 変異型クロイツフェルト・ヤコブ病) 問題なのですが、これは科学的にも、政治・経済的にも、「感情」の側面から言っても、とっても難しいトコロがあり、それが絡み合ってもいますから、とても自分ゴトキに十分な Comment の言えるようなモノではないのですが、断片的な所感を述べさせて頂きます。

BSE / v-CJE がなぜ起きるか、の、現在最も有力な仮説は、Prion 仮説、です。Prion は、proteinaceous infectious particle (感染性タンパク粒子) の略ですが、核酸構造 (DNA や RNA) を持たない、タダのタンパク質 (実際には、タダの、ではないから困るのですが) が感染性を持つ、は、驚天動地みたいな話であり、現在 Prion 病と括られているもの (Prion 仮説に疑問を持つ立場からは TSE = Transmissible Spongiform Encephalopathy : 伝達性海綿状脳症、と 括られる) は、かつては、未知の、潜伏期間の非常に長いウイルス様のモノ、が病原体だと考えられ、スローウィルスなどと呼ばれたりしました。それが現在では「一種のタンパク質」が病原体だとする見方が有力なのは、核酸構造を破壊する外力 (例えば放射線) を加えても、感染性は落ちない、タンパク質構造を破壊する外力 (例えばタンパク質分解酵素) によって、感染力は消滅する、が発端であり、Prion 仮説は今のところもっとも TSE をうまく説明できる仮説なのですが、じゃあ完璧にそれで解けているのか、というと、ほど遠い、が現状で、だから「治療法」もないし、ピンポイントの予防策の妥当性の 100% の証明もない。しかし、完璧に解けないと「対策」を打たないのか、というとそうはいかない。ここが出発点から問題を複雑にしています。

人類の歴史で最も恐ろしい感染症である天然痘に対する、劇的な予防法が Edward Jenner による種痘法であることはご承知の通りです。Jenner が最初の種痘を実施したのは 1796 年ですが、その効果は直ちに認められ、広く普及します。今や我々の業界での方が広く使われているかも知れない Virus という言葉を、天然痘 (や牛痘) の病原体の名称として与えたのは Jenner なのですが、Jenner の時代には Virus は全くの仮説であり、Jenner が Virus がどんな実態をもったモノなのだと考えていたのか、は、今となっては分からないし、「天然痘の病原体である天然痘ウィルス」の実物が確認されたのは、Jenner が最初の種痘を実施してから百年以上後、です。しかし、Jenner が Virus 仮説 (現代の科学でいう仮説、とはちょっと違うかも知れませんが) から導き出した種痘法、が多くの人命を救ったことは紛れもない事実で、(仮説がボンヤリしたものであっても) 仮説から導かれる Action が否定されるものではないことの何よりの証明でしょう。

( 9 21 2006, 08:48:12 午前 JST ) Permalink

Hot Chips Article (3)

Niagara-2 は Memory System でも進化しています。現行 Niagara では Crossbar は、4-Bank (各 750KB) の L2 Cache とそれぞれ繋がっていますが、Niagara-2 では、これが 8-Bank (各 512KB) の L2 Cache と繋がることになります。Thread 数が現行 Niagara の 32 から Niagara-2 では 64 に拡大するのですから、Memory 要求の増加に対応するために Bank 数を増やすのは重要ですが、これは単純に L2 Cacheの総容量 (総容量も 750KB x 4 = 3MB から 512KB x 8 = 4MB で増えていますが) を増やすより大変で、ここは詳しく見ていくと色々面白そうです。L2 Cache は 2-Bank 毎に一つの Momory Controller Unit を持っていて、現行 Niagara の DDR2 から Niagara-2 では FB-DIMM の Controller です。FB-DIMM の Clock は Grohoski の Slide には明示されていませんが、ここでも帯域幅が拡大しています。

また Niagara-2 の Crossbar は PCI-e x8 や 10/1Gb Ethernet の口とも繋がっていて、こうなると本当に "Server-on-a-chip" ですね。I/O を On Chip で持つことは処理の高速化に資することは勿論ですが、Total の System Box での電力消費の削減にも大きな効果があります。これは Memory Controller が On-Chip であることも同じ意味ですね。On-Chip で I/O 系をバッチリ Support していますから、 Niagara-2 の Pin 数 (もうモノとしては Pin じゃないんで、良い言い方ないですかね)が 1,831 というのは驚くに足りないかも知れませんが、Signal Pin はウチ 711 で、残り 1,120 は Power / Ground Pin ですか... まあ Power / Ground Pin を上手に細かく散らしてコントロールするのもワザではあるし、Niagara-2 のフロアプラン (Slide の page 5) 見ると散らしやすい形ではあるんでしょうが、うーんエライ時代ですね。

CPU の動作周波数については、この Slide では触れられていないのですが、仮に現行 Niagara と同一としても (1,831 pin でそれはないだろ、はさておいて) Micro-Architecture の進歩だけで、「Total Through-Put で現行 Niagara の二倍以上」の Grohoski のいう Goal は Clear されていて不思議はありません。
Sun の CMT は、順調かつ着実に進歩している、が、よく伝わって来る Slide だと思います。

( 9 19 2006, 08:57:28 午前 JST ) Permalink

Hot Chips Article (2)

Niagara-2 の Core 毎の処理能力の強化で、もう一つ強力なのは、Core 毎に配備される FGU (Floating / Graphic Unit) と SPU (Stream Processing Unit) です。現行 Niagara では、浮動小数点演算 Unit は、Core 毎にではなく、Die に一つ Crossbar 経由で各 Core が共有していて、浮動小数点演算は「例外」というか、全体の処理の 5% 以下 (演算器の数で言えば 8:1 と言えるが、Crossbar 経由だし、頻度のバラツキまで考えると) である前提の用途、を想定しています。実際に Web Service や多くの Bisuness Application では浮動小数点演算は殆ど出てきませんからこれで十分なのですが、自分はこれからは浮動小数点演算を中心としたいわゆる HPC 系の Application も ILP (Instruction Level Parallelism) 偏重から TLP (Thread Level Parallelism) の時代が来る、と思っていまして、Niagara-2 で、Sun は CMT で Web Service や Business Application だけを Focus している訳ではありませんよ、これからどんどん適用範囲を広げていきますよ宣言、だと思っています。

この FGU は浮動小数点演算器としての能力も、現行 Niagara の Shared FPU よりかなり高い本格的なものだと思っているのですが、Sun の Graphic 命令 Set である VIS2 の SIMD (Single Instruction Multi Data) Extention の Thread を備えており、また整数演算命令でも掛け算や割り算の Thread (現行 Niagara でも MUL/DIV は通常の ALU とは別演算器ですが) も、この FGU に含まれています。

SPU もナカナカ優れもので、現行 Niagara でも RSA アルゴリズム処理の専用アクセラレータを持っていて、SSL 通信の負荷を処理しているのですが、Niagara-2 の SPU は範囲の広い Cryptographic Coprocesser で、共通鍵暗号の処理エンジン (RC4, DES/3DES, AES) やハッシュ関数の処理エンジン (MD5, SHA) も備えています。英語の解釈を間違っていたらごめんなさい、なのですが、Grophoski は "Free" Encription と言っていまして、これは回線速度と同じ速度で暗号処理をします、だと思っています。ここで言っている回線速度は、Niagara-2 の持っている Port (10Gbps) のことでしょうから、ええっそんなに、と思いますが、これからはそれ位はヘッチャラじゃないと、という時代なんでしょうね。

( 9 18 2006, 08:50:08 午前 JST ) Permalink

Hot Chips Article (1)

先月 22日の Hot Chips 18 で、Greg Grohoski が Niagara-2 の「構想」を Presentation しているのはご承知の通りですが、そのスライドが OpenSPARC のサイトに出ています。下手な注釈を入れるより直接見ていただくのが一番よいのですが、自分なりの感想を書いておきます。

Niagara の登場は長い目で見て、CPU の歴史に新しいページを画するものだと思っていますが、それは現行の Niagara がいいよぉ、と同時に、この Niagara の Architecture (CMT) が進化していく、も、大きな要素です。CMT の進化の方向性は、相剰的、相補的な部分もあるので、それぞれが独立では必ずしもありませんが、

1. Core の数を増やす
2. Core あたりの Thread 数を増やす
3. Core 毎の Throughput を上げる
4. Core 以外の要素を強化する

ということになります。Niagara-2 で実現しているのは、3. の Core 毎の Thrughput を上げる、と、3. からもたらされる 2. Core あたりの Thread 数を増やす、であり、3. / 2. を支える 4. Core 以外の要素の強化、も同時に実現しています。

Niagara-2 での大きな進化は、Core あたりの Thread 数が、従来の 4 から 8 に倍増したことです。従来の Niagara では FGMT (Fine-Grained Multi-Threading、まあ時分割)での 4-thread の実行ですが、Niagara-2 では 純-SMT (Simultanious Multi-Threading) 的な、それぞれが 4-thread の Thread-group を実行する二組の Stage を持っています。具体的には、現行の Niagara とは若干 Pipeline の構成が違いますが、現行の Niagara で言うと、Instruction Buffer から、Thread Selest、Decorder、Register File、ALU までの部分の Resource を Niagara-2 では二組持っていて、現行の Niagara が一組で4-thread の Thread-group を実行するのに対して、Niagara-2 ではそれぞれの組が、4-thread の Thread-group を実行するので、4 x 2 で Core あたり 8-thread の実行、ということになります。Resource を増やさずに、単純に粒度を細かくして、Thread 数を稼ぐのは効率的といえば効率的なのですが、それには限界がありますから、どこの Resource を増やすか、が Point で、Niagara-2 では、一番オーソドックスなところの純-SMT 的な二重化で手堅く実現している、と思います。

( 9 17 2006, 09:24:04 午前 JST ) Permalink

Software Paradigm (5)

Bill Joy には分かってもキミ達には、に、神妙にならざるを得ないのは、Java のもたらしたもの、の大きさ、なり、広がり、なり、が、おそらく誰にとっても、想像を超えたものだったから、で、でも、それが大きければ大きいほど、うーん Bill Joy はそこまで分かっていたのか、と、ツネヅネ勝手に感動している、があるからです。やっぱり、分かっていたんでしょうかね、 はこちらとしても我が意を得たり、なんですが、お客様のご意見によれば、分かっていたんだろうし、しかもそれを Bill Joy が言う、に値打ちと説得力があるから、世の中を動かした = 結果として実現したんだろう、です。別に、MultiThread 化プログラム、なんて、Bill Joy が言い出したわけでも何でもない、誰もがこれからは必要だ、と思っているんだけど、じゃあどう実現するの、は、Bill Joy なら C でもいくらでも書けるだろう、がむしろ障害になる。これが Multi Thread Program を実現する言語仕様です、には、いや、(俺が) C++ で書けばもっと効率よく実現する、という人は必ずいるものなので、そこは、でも、自分が書けばもっともっと効率よく実現させられるに決まっている Bill Joy でさえ Java で書こうよと言ってるんだから、で始めて話が進む、はあったんだろうと思います。

Java の Feature が、Native な Multi Thread だけではないのは言うまでもないし、だからこそ Java の今日の普及があるんですが、「お客様説」によればそれも「意識しないでも (ある程度) Thread 化された Code がどんどんできるように」という構想の一部なのよ、で、ここまで行くとかなり Unique な視点という気もします。ただ、それも含めて「大きな流れ」を形成した、を否定するものではなく、大きな流れになったからこそ、Java ではないところでも、Multi Thread 化は避けて通れなくなる、原義的な意味での Paradigm になった、は言えるのではないかと。「Java ではないところでも」は、腰が引けてるんじゃないの、とまた叱られそうですが、「Single Thread も、Multi Thread も」から、「Multi Thread での処理能力を優先する」への転換の背中を押すのにそこは小さくないところで、Web Server / Application Server Server (って変ですけど、広義の Application Server ではなく、Middleware としてのApplication Server SW の Platform) 専用機、当時の流行の言葉で言えば Server Appliance 指向ではやっぱり辛い。SAP (SD) や、Notes のようなところも Sweat Spot ですよ、も言えてこそ、Niagara の目指す Multi Thread 処理能力が明確になる、であり、正直自分には SPECjbb よりも SD Bench や NotesBench の方が嬉しい数字でした。

十年前から自明な、「Single Thread 性能より Multi Thread 性能だ」を具現する CPU が今頃やっと出てきた、自分で作った Software Paradigm にようやく追いついたね、は、お叱り、もあるけど、やっぱり慶んでいただいている、が伝わってきて、ありがたいんですが、Java の Paradigm の折り返し点、に留まらず、新しい Paradigm の基点にしないといけませんね。
(来週は遅めの夏休みを取らせて頂きます)

( 9 08 2006, 08:59:08 午前 JST ) Permalink

Software Paradigm (4)

Sun の人間にとっての次の Software Paradigm の実感は、言うまでもなく Java です。本当は「Sun の人間にとって」では Paradigm ではない、SMP だって、Oracle さんなり、SAP さんなり、や、それを通して世の中のご支持を頂く、世の中がそれを必要とする、がなくて、自分だけ Paradigm です、と言っていても何にもならないんですから、「Sun の人間にとって」は意味がないんですが、少なくとも当初は「受けとり方」に微妙な温度差はあったのかな、と。

初期に、これはさる Big User さんのある方に、「Java は Run Anyware と言っていて、それは Client 側ではその通りなんだけど、Server 側で考えれば、もう Single Thread で早い、は捨てて下さい、を強烈に主張しているんだね」を、それも「どの Client でも Duke が手を振ってくれる、のカゲに隠れて」みたいな Nuance で言われたことがあります。その時は、イヤ、もう RISC / Unix の世界では、Single Thread だけで処理性能を求めるには限界がある、は共通認識で、SMP だって SPARC / Solaris の専売特許でも何でもないし、今やシアトル方面だって、Cutler 先生は Multi Thread と言っておられるんだから、「Multi Thread だ」は、囲い込みでも何でもないですよ、と陳弁これ努めたんですが、Native な Multi Threading は最初から強調しているんだし、そこを高く評価して頂いてるつもりでしたから、カゲに隠れて、は結構心外でした。心外だったんで、そこの会話は覚えているんですが、そのお客様は、「CPU Architecture として Single Thread 性能の追求は止める宣言、じゃないの」があったようで、そこは覚えていない、というか、Java の年 (95年) の年末には UltraSPARC が待っていたんですから、Multi Thread では勿論、Single Thread でも最強のつもりなので、耳に入らなかった、なのだと思います。実際、95年当時の Sun の人間のかなりの部分 (自分も当然その一部)、は、Multi Thread も結構だけど、Single Thread の性能も出てくれないと「本業の」Workstation 屋としての商売に差し支える、より差し迫った問題としては、SuperSPARC の WS がリース明けになって、次も SuperSPARC です、なら PA-RISC にするからな、とか、同じお客様 (の別の方) に引導渡されている、が気になってた、も実情 でした。

「心外だった」は微かに覚えているものの、CPU 開発の方向性として、の方はすっかり忘れていたのを思い出させた (正直言えば、思い出した訳でもなくて、当時ならそう言っただろうなぁ、なだけですが) のは、そのお客様で Niagara を Test して頂いたんで、久しぶりにお目にかかった折りに、いやぁナカナカいいよ、を、「ほら、やっぱり僕の言ったとおりだったでしょう」で、お話し頂いたことからです。Workstation が本業ですから、やはり Single Thread も大事なんです、掛け算の世界であり、乗数も被乗数も両面からやっていくんです、なんて言ってたよね、と言われると、はぁ、確かに、とお応えせざるを得ない。Single Thread 性能か、Multi Thread 性能か、なんて、Java が Enterprise Application で当たり前の Paradigm になれば自ずと結論が出る話だ、は Bill Joy だから分かるんで、当時のキミには分からない、は無理ないけどね、を神妙にお伺いする羽目になりました。

( 9 07 2006, 08:56:15 午前 JST ) Permalink

Software Paradigm (3)

RDB の例でいえば、変わっているのは、端的には Software かも知れないんですが、実際に変わっているのは、「世の中」が求めるモノという方が正確なんだろうという面もありますね。HW だけでは、その求めるモノに十分には応えることができないし、応えている、が、スグには見えない。それが見えるのが SW だ、とも言えるかな。とりあえずは HPC や、「今までにない大規模 DB」のように User さんの「これがやりたい」で、動き出した SMP Platform が次の段階を迎えるのも、やはり SW から見ると見えやすかったと思います。

例えば、90年代に入った頃は SAP 使ってます、と言えば、Module で言えば人事や会計で、販売・物流 (SD) は、例えば手形の扱いとか、ナマでは日本では使いにくかった、というのもありますが、やっぱり Computing Resource がケタ違いに要るので、そう簡単には、サクサク動かない、Computing Resource を大きくする、と指数関数的に Cost が増加する、で、少なくとも日本では Popular ではなかった。それが、SMP なら Resource 増強は単純に「足し算」に近く増やせるし、足し算のモトになる単位の Cost も素直に下がっていくから、SD がサクサク動く環境、がどんどん身近になっていく。SD の機能を増やすことで使い勝手が良くなった、も大きいんですが、機能を増やすと Resource Demand も大きく増えるのでそれが足枷になって、ナカナカだった。しかし、増加する Resource の Cost が下がってそれを「足し算」で追加できるなら、積極的に機能を強化することができて、SD 使おうか、も増える。これも Upward Spiral ですね。90年代前半の人事や会計主体 (人事や会計が入っているからこそ、SD も入れようか、になるわけで、そのベースがあったことも大きいんですが) の時代には、殆どお呼びじゃなかった SAP on Sun が 丁度 SuperSPARC -> UltraSPARC の代替わり、で単位 Resource の Power Up とも Meet して、SD の時代、になって日の目を見ました、が、こちらからの見え方、なのですが、これも大げさに言えば新しい Paradigm 、だったと思います。

違う意味での Paradigm Shift は、例えば Lotus Notes ですね。90年代前半の Notes は、まさに「グループウェア」で、グループと言っても意識されていたのは、グループ交際、ほど小さくはなくても、まあそんなに大きいグループが意識されていたわけでない。それはネットワークがコストは高いし、通信速度は低い、があって、LAN で閉じた範囲の中で、それに規定されたグループの範囲、が自ずと限定される。極端には、Printer Server と Notes Server が、似たようなサイズのグループの面倒見ていたりしました。回線の Price Performance が劇的に下がって、情報のやりとりも Printer Server 共有している同士、から、部門またいで、地域またいで、会社またいで、が当たり前になると、Server が散在してます、では捌けなくなって、WAN wide での Server 統合、に向かいます。情報のやりとりの範囲が広がると、Client 当たりの Transaction も増加して、掛け算で負荷がかかりますから、ここでも SMP の出番、がやってきます。さすがにグループウェアでもあるまい、で、ハイカラな Collaboration Suite なんて言い方、はあんまり定着しませんでしたが、初期の Notes Server って(少なくとも台数では) OS/2 が圧倒的、は、一瞬のうちに大過去、でした。ここの Paradigm Shift は、OS/2 か Solaris か、というより、世の中の Paradigm Shift への対応、が、タマタマそこに顕れた、でしょうけど。

( 9 06 2006, 09:02:33 午前 JST ) Permalink

Software Paradigm (2)

Sun の人間にとって「Software Paradigm 論」の実感は、Intel さんとは大分角度が違いますが、SMP と Oracle DB でしょう。Sun の最初の MP は 91年ですが、これは、とにかく MP 機を早く世に出そう優先、CPU も OS も SMP 用には不十分、で、随分お叱りを頂いたものなのですが、CPU と OS が SMP 用に使い物になって、Compiler の Threading Option もそこそこ機能する、になっても、じゃあ 8-CPU とか 20-CPU できっちり Scale する市販アプリケーションがあったかというと、一部のテクニカル系のシミュレーション位で、その分野では IBM さんの RS/6000 SP も色々やって居られるし、ベクトルのスパコンも健在でしたから、チョボチョボ、だったんですね。今となっては SuperSPARC の 20-CPU ゴトキの Computing Power は、掛け算すれば 1GHz 以下で、どうってことないんですが、当時は、そんなの何に使うの、もありました。そこに「SMP の真価」を発揮させて頂いたのは、Oracle DB (正確には Oracle DB だけではなく、他の RDB もですが) のプラットフォームとして、でした。

大規模な DB にバンバン Transaction が飛んで来て、Dynamic に捌く、は、CPU Box 屋としても勿論 DB 屋さんにとっても「夢」なんですが、なかなかそうは行かない。これは、Technology の問題もありますけど、一つはお金の問題もあります。Disk 一つとっても、Spindle の一本当たりの容量だって、単価だって、今とは桁が違いますから、大規模の「規模感」をお金に換算すると、今や Memory に載ってしまう当時の 10GB が、今の 100TB でしょうか。少なくとも GB と TB よりは大きかったと思います。User さんのメンタリティ、だって、当時の水準では、大規模・速・確実な DB をという Project がある、を嗅ぎつけて、SMP (といっても 4-CPU とか、ですが) / RDB でご提案に参上して、お話は聞いて頂けるんですが、帰りに、今回は ISAM でやりたいと思ってますので、と言われて、がっかり、と言う時代です。(当時、ISAM というと、COBOL の索引ファイル、が語感で、Sun は COBOL がない訳じゃありませんが、まあないに等しくて、Sun が ISAM だと思っているモノは、日本では C-ISAM と称して「別もの」でした) そのお客様から、三年後にはお名指しで SMP / RDB の提案して頂戴、が来るようになって、ウーン Paradigm 変わったな、が実感、でしたね。

Oracle さんが SMP での Scalability に力を入れて頂いたのは、取って付けたような話でもないし、Sun の SMP にそれほど感動して頂いた訳でもなくて、Sun の SMP より以前から Sequent さんとやって居られたり、IBM さんが、RS/6000 SP と DB2 の組み合わせで撃って出られていることへの対抗、とか、の要因も勿論あります。しかし、卵が先か鶏が先か、みたいな話ですが、IT 側が進んでくることで User 側もその気になる、も、あるにしても、どちらかといえば、User 側から本気で要求が出てくるから、IT 側もそれに対応して実戦で鍛えられて進歩する、のような Upward Spiral が推進力になる、それが Paradigm という言葉にふさわしいかな、と。通信関係で言えば 113 サービス (故障対応) の DB は、局ごとの加入者情報 DB Serrver があって、局に窓口があって、でまかなえるから、それでも当時としては「小規模」ではないし RDB への Paradigm のハシリだったんですが、自ずと上限はある。ところが携帯電話の加入者 DB を考えると、局とかの範囲ではないし、天井が非常に高いから Scalability への要求は真剣になる。実戦で鍛えられる、は、逆に言えばお客様には最初はご迷惑お掛けしている、でもあるのですが、それが新しい Paradigm への原動力になって行ったと思います。

( 9 05 2006, 08:54:21 午前 JST ) Permalink

Software Paradigm (1)

Software Paradigm って、前にご紹介した Intel の Pat Gelsinger さんの Stanford での講演で、何で Intel さんは Multi-Core で遅れを取ったのか、に、シアトル方面も Clock の方が良いよ、だったし、CPU 屋がいくら Multi-Core が良いと思っても Software Paradigm が付いてこないとそっちへは行かない、はあるから、を言って居られて、そこがウケテいたのですが、確かに大きなところです。しかも Pat さんはどんな OS が飛んでくるか分からないところで、CPU 設計して居られる訳で、Sun にいる人間にとっては、Solaris は SPARC の最大の味方であり、SPARC は (結果として Solaris の足を引っ張っている、は皆無とはいわ ないまでも) Solaris の最大の味方で、まあお互いにお互いを前提にしているから、実感として分かりようのない部分もあるんだろう、と思います。

Pat さんの Software Paradigm 論がウケルのは、IA-64 が、こっちに Software Paradigm 動かそう、として構想されて、ある程度は動いたけど、結局は動かし切れなくて、が背景にあるから、もあるんでしょうね。VLIW は CPU Architecture としては、一つの有力な考え方であり、それが実現するかどうかは、CPU 屋さんの腕にもよるところは随分あるんですが、CPU の上で動くモノ、が VLIW を意識して呉れるかどうか、に懸かっている。詳細を知っているわけ ではありませんが、VLIW Solaris やろうよ、という Love call を頂いていたのも、その一環でしょう。2,000年の夏頃、何か HPC 系の Application Vender さんの User Event の Dinner Sponcor だったかを、Intel さん、Compaq さんとお引き受けしたことがあります。Dinner の前に三社でUser 会会長さんにご挨拶、の時に、会長さんも「なかなか珍しい組み合わせですね」に、こっちは「いやいや Intel さんには半導体設計で結構ウチの機械も買って頂いてまして」とか当たり障りのないことを言ってたら、Intel さんの方から、「Itanium で Solaris やりましょうよ、を随分お願いしてたんですが... 実現していたら、最強の組み合わせだったんですけど」と、食事前にしてはアブラコイお話が出て、ドキっとしましたが、当時の Intel さんとしては、Software Paradigm を、が、最優先課題だったから、ツイツイだったんでしょう。会長さんはできた方で、そういえば Project Monterey って進んでるんですか、と、 Compaq さんに話振って頂いて、ほっとしたのを覚えている (振られた Compaq さんは、いやぁアレは... とも言えず、困っておられました) のが、自分の唯一の微かな「Intel さんの Software Paradigm 攻勢」体験です。

あの Power 4 を準備して居られた IBM さんでさえ、Project Monterey なんて保険掛けて居られたんですから、前世紀の「Itanium って凄いんだぞ」感が如何に高かったか、は分かりますね。まあ、IBM さんは初代 Itanium である Merced の実像が見えてきたところで、さっさと Project Monterey からは Drop されて、あんまり逃げ足早かったから、かどうか、Project Monterey で一山当てそうとされていたかに見える SCO さんから、「あれは SCO の Property を AIX (や Linux?) に取り込もうとしたんだ」とか、訴訟起こされたり、で、Project Monterey はむしろそっちで歴史を飾っているんですが、Merced が出てくるまでまでは、本当に Software Paradigm がそっちへ動くか、 は、なかったとは言えません。

( 9 04 2006, 09:04:20 午前 JST ) Permalink Comments [2]

Summer of Servers

「最後の NetBurst」である Tulsa が発表になって、これで Intel さんの「まともな Product Line」の役者が揃いましたね。Tulsa の Performance は、まあ、予想通り、というか、コア毎に Opteron 同等の 1MB の L2 キャッシュを持っていて、プラス 16MB の共有 L3 キャッシュ、ですから、「キャッシュ の威力」でモロモロを隠蔽して、現行 Opteron よりとにかく早い、という狙いは達成されている、敗戦処理というと Stefan Rusu さんに気の毒ですが、その責は果たした、のでしょう。大半がキャッシュの分にしても 13億トランジスタと膨れあがっていますから、ここでジャジャ漏れだと大変なのですが、On-Off があんまりないトランジスタはゲート長を「心持ち」長くしたり、で、リーク電流を抑えて、13億トランジスタでも TDP 150W は、Sun の人間としては、「何だ、まだそんなにあるのかよ」と言わないといけないんでしょうが、L2 キャッシュ 2MB x 2 (L3 なし) の Paxville MP より低いのは、頑張った方だと思います。

もともと x86 の 4-Socket Server は、HP さんというか旧 Compaq さんが強かったところで、その HP さんがすっかり Opteron 4-Socket 気に入って居られたので、が大きいと思いますが、4-Socket の x86 は AMD 入りが当たり前になってしまって、Intel さんとしては指を銜えたまま、という訳にはいかない。Merom 系は、多 Socket を念頭に置いていませんから、13億トランジスタの出番なのですが、別に Pentium 4 だって多 Socket をそんなに意識していた訳ではない、そこは Itanium のハズだったのが、Itanic になってしまったからピンチヒッターの色も濃いので、どうしても無理はありますよね。13億 トランジスタで $1,980 って、一ドルで 65万トランジスタか、そりゃちょっと前の RISC CPU 全部のトランジスタ数じゃないか、と変な割り算してみたりするんですが、Opteron 8xx に楽をさせない、が目的ですから、儲かる、儲からないは別として、値段のことも言ってられません。Tulsa の Press Release で、Bench の数字が出ているのは、Fujitsu-Siemens さん、Dell さん、IBM さんの三社で、x86 / 4-Socket 最強の HP さんはエンドースだけ、ってちょっと気になる (4-Socket 以上なら、今は HP さんに負けてないつもりの Sun は、エンドースも出してませんが...) ところではありますが、Intel さんの "Summer of Servers" (と、ご自分で表現しておられます。やっぱり暑いんだ、とか突っ込み入れられない自信がおありなんでしょう...) も、無事三幕開いたところに値打ちがあります。

現場は、ちょっとやそっと突っ込みドコロがあっても、まともな役者が揃う、は、それだけで嬉しいものです。途中経過、は、まだ辛抱できるにしても、「x86 の Dual Core 第一号だ」と言いたいから、の XE840 とか、Marketing 的な妖怪みたいなものが手を変え品を変えて出てきても、 それを売ろうとしない訳にはいかない。Intel さんですから PC Vender さんも多少の無理は聞いて頂けるんでしょうけど、仏の顔も三度まで、とか Texas 方面の会社に言われたり (?) もしてしまいかねない。やってられないし、Intel ジルシが入っているからと言って、そうそう売れるものではないから、在庫だって溜まって来てるんじゃないの、が Earning Report にホノ見えたりもします。この Tulsa の発表で、当面の一押し、が with 「そこそこ (以上) の説得力」で揃う、まあしばらくは溜まっているモノも捌かないといけない (これは PC Vender さんも同じ なので、そこへ Intel さんで溜まっているモノを持って行くのはしんどいと思いますが) とかあるにしても、そこは何とかしようじゃないか、も含めて元気の出る話です。「インテルにとって、歴史的な“サーバーの夏”は続いています」(日本での リリース、ご本社の Release は Summer of Servers が Headline になっているんですが、日本ではそれは蒸し暑すぎるから本文の中だけ) には、何かその辺の気分も顕れているような気がします。

( 9 01 2006, 08:54:45 午前 JST ) Permalink