Hatena::ブログ(Diary)

naoyaのはてなダイアリー

November 19, 2005

大規模サービスを展開する企業が陥るジレンマ

このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。

一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。

はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュースからリンクされるとキーワードページがダウンしたりしてました。(ニュースからリンクされてる記事を見ると、ときおり「現在閲覧しづらい状況が....」と出たりしますが、それはトラフィックに耐えきれずに相手方が落ちているという。) 名付けて Yahoo! アタック。

月間数億のPVを裁いてるサービスですらリンクしただけで落とせちゃう Yahoo! Japan 本体のトラフィックってのはもうそれこそ桁違いなわけで、その運用の様子は想像しただけでも吐き気がしてきます。

となると、Yahoo! Japan みたいな企業は、新サービスを始めたその瞬間から、自社のポータルからの誘導でものすごいトラフィックを稼げるわけであり、これは他社がもたない強力なアドバンテージに思えます。でも、想像してみてください、あなたが明日、Yahoo! Japan でサービスをオープンさせられることになりましたと言って、どんなシステムを用意しますか? サーバーの台数は大丈夫? 負荷分散は十分に行えている? ネットワーク帯域は? 冗長性は...? などなど心配が耐えません。

その一方で、個人でウェブのサービスをリリースするなんてのは、気楽なもんです。せいぜい来ても 100 〜 1,000アクセスかそこらだし、アクセスが増えてきてもサーバーをもう一台追加するとかすれば当分はしのげます。その間に、現在のトラフィック/ユーザー数の背丈に見合った品質確保のためのノウハウを身につけるなり投入するなりすれば良く、それは小さければ小さいほど容易い。

ここにジレンマがあるんですよね。大きな企業で、大きなサービス、強力な導線を持ってる企業ってのは、そのサービスの初期段階からきちっとした設備投資、品質確保を行わないといけない。サービスを少しずつ育てていくということが難しく、リリースした次の日からいきなり運用保守モードになってしまう。

What Is Web 2.0 のなかでオライリーは、早期に且つ頻繁に機能を改善、リリースしていくことが重要だと述べていますが、トラフィックが大量に集まるサービスではその変更がどうしても難しくなってきます。ユーザー数が多いために、新しい機能を追加したり既存の機能を変更したりする場合の影響が大きかったり、あらかじめ十分な負荷分散を見積もらないと変更できなかったり。それから、企業として、求められる責任の度合いがどうしても大きくなる。そういう状況では、どうしても変化に対して鈍くなり、遅くなってしまいます。

たとえばはてなダイアリーは、現在 100 台以上のサーバーで運用されていて、データベースのパーティショニングや、コンテンツキャッシュの仕組みなんかはいたるところにあって、その運用と開発に結構な工数がかかっています。これはサーバーが1台のときから継続的に運用開発をしてきたからできた芸当で、初日から 100 台サーバー用意して、なんて言われてもたまったもんじゃありません。

いきなり100台はオーバーにしろ、大きな企業ではそういうことが常なんだろうなあと。ニフティにいたときも、ココログをオープンするときにはその辺にすごく神経使いましたし。それでも開始早々障害が起こって、何日も会社に泊まったりしました。そういう状況で、早期に且つ頻繁にリリースしる! それが Web 2.0 だ! なんて言われても「オイオイ」って話になるなあと。

大規模トラフィックを処理するっていうのは、ある程度の規模を超えると銀の弾丸は存在せず、Try and Error による泥臭い努力の上でなんとかやっていけるもんだという点は、Inside LiveJournal's Backend (PDF)Flickr and PHP (PDF) なんかを見てもその様子がよく分かります。どこも同じようなことで苦労してるなあ、という感じ。そして、成長に応じて、問題の顕在化がゆるやかだったおかげでそれに対応することができたというのもやっぱり共通点なんですよね。

愚痴ばっかり言っててもしょうがないので、将来のために対策などを考えてもいます。このジレンマに対応するメソッドというのはおそらく過去の事例の中にいくつかあるかなと。そのパターンを洗い出してみたい。

ひとつめ。小さい頃から育ってきてノウハウを身につけ、ユーザーを確保したベンチャー企業を丸ごと買収して自社のサービスに取り込む方法。Yahoo! における Flickr 買収、Six Apart による LiveJournal買収とかそういうパターン。これらの買収の主目的は他にもいろいろあるんだろうけど。まあそういうのもありますよってことで。

ふたつめ。Google には低レベルレイヤのコア技術がいくつかあるそうですが、そういうものを早期に確立して、技術面での変化に対するリスクを下げるという方法。Yahoo! にも、大量のトラフィックをさばくための独自の技術があると聞いてます。

これからは Binary 2.0 だ! なんてちょっと笑い話っぽいですが、あんがい笑ってる場合じゃないかもしれない。間違いなく、はてなに足りないテクノロジーはこのレイヤにあるし、そこで成果を出すことができればもっと飛躍できるのではないかと思っています。

ただ、全部 C や C++ で作るとかそういうのはアレなので、やはり Lightweight な言語とフレームワークで開発自体はラピッドに、開発者の技術レベルがある程度ばらついてても対応できるような開発体制でいつつ、彼らがそれを意識しなくても良い、低レベルレイヤでそれらアプリケーションを支える特化型の技術を持っているという、そういうのが理想かなと思います。

みっつめ。Google やサイボウズのように、新規プロジェクトや新しいサービスをラボとして、本ちゃんのものから隔離する方法。あまり本サービスからトラフィックを流したりとか、そういうことをせずに小さなところからスタートさせて、少しずつ育てていくと。あんまり本体から隔離させすぎると、ただの研究で終わってしまいかねないので、その辺のバランスの取り方とかやり方が重要になりそうです。

よっつめ。クローズドな環境で育てていく方法。ベータ希望ユーザーにのみ新プロダクトを解放したりとか。GMail が招待制だったりするのもその一例かな。はてなでは以前にダイアリーの管理画面をリニューアルするときに、この方法を取りました。

他にも色々あると思うけど(なんかいいのあったらぜひコメントなりトラックバックで教えてください)、これもやっぱり銀の弾丸は存在せず、Try and Error と組み合わせが重要なのかなと思います。あと、大前提として、そういう類のことを実現できる企業文化を小さなころから大切にすること。

はてなもユーザーさんもトラフィックも増えてきたし、こういうことを真剣に考えていかないと、いずれイノベーションが止まってしまいかねないなと、最近思うのでした。

delta81delta81 2005/11/19 18:51 研究所の話に似ているのですが、化粧品や服のようにブランドを分けるのはどうでしょうか?一つの会社が複数のブランドホームページを持っていても良いように感じるのです。
当然、本サービスに関係するものには何の効果もないのですが、逆に客層をしぼるとか、より効果的なサービスができたりしませんかね?

話がずれていたらすみません(笑)

TigerTiger 2005/11/19 20:11 アイオーデータが挑戦者ブランドでいろいろとやっていまよね。あれも一つの例ですね。あと、モダシンさんに聞いた話ですが、やはり、Binary的手法は効果が大きいそうです。苦労も大きいようですが ^^;

何とか活かせないかなと思うのはP2Pというか、分散処理的方法ですね A^^;;

もう一つは出来るところは余所にやらせるというパターン。フィードの蓄積はBloglinesに、検索はGoogleに・・・はてなマップみたいに。

nonecononeco 2005/11/20 07:49 ネットの分散化。サービスの集約化。蟻が象を倒すこともある。優れた密度のある蟻を育てて欲しい。

neko3hikineko3hiki 2005/11/20 08:20 +1 Tim O’Reillyのように、優れた概念を皆に啓蒙して、その結果が自社をも変化させる、という方法。
+2 自社を売却して、またスタートアップする。
+3 投資家になって、変化を起こしそうな会社にコミットする。

  2005/11/20 20:15 最近驚きのあまり椅子から転げ落ちそうになったBinaryなこと。C#で膨大な量のデータを処理しなければならなくなり、遅くてトロくて吐き気がしてきたので、プログラムをチューニングすることにした。ただ、C#プログラムをみみっちくチューニングするより、Cでネイティブアプリに書き直してしまった方が速くなるに決まっているという「しごくあたりまえのこと」に途中から気づき、まずはどの部分がどの程度パフォーマンスが改善されそうか見積もりをするため、いろいろパフォーマンス調査プログラムを、CとC#の両方で書いて、比較してみた。ところが、ここで天地がひっくり返ってしまった。なんと、おいらの興味があるほとんどすべての項目で、たいした差が出なかったのだぁ!!!結局、C#は、Cと同様、ポインタもunionもstruct配列のメモリブロックコピーも、かなり無節操な型変換もできてしまうので、Cのようにアクロバティックなパフォーマンスチューニングができてしまうし(voidポインタが使えるので)、なにより.NETのJITがすごすぎ。いったいぜんたいどういう魔法を使ったらネイティブコードとほとんど変わらんパフォーマンスがでるんだ? わけがわからない。C#からならネイティブDLLもOSのAPIもいくらでも呼び出せるし、もうCなんていらなくね? VisualBasicとかC#とかJavaとか、簡易言語の時代さね。本格的なプログラム言語の時代は、おいらが龍宮上で飲んだくれてるうちに、いつのまにか終わっちまったんだなぁ。 とりあえず、おいらは、スターリンの銅像を引きずり倒すがごとく、バイナリ教の神様を神棚から引きずり下ろすことにしましただ。

himazubloghimazublog 2005/11/20 21:25 1つ上の匿名の方へ。そのあたりを具体的にブログ等で公開していただけるとより皆様の役にたつのでは。

kdaibakdaiba 2005/11/21 00:17 クローズドな環境で作るという手もありますが,オープンな環境との接点があることを生かすという手もあると思います.例えば,最近のVoIPサービスは既存の電話網とも接続することを売りにしています.そういえば,050番号を提供している電話会社はイノベーションのジレンマに直面して苦しんでる典型だという気がします.

nobuotakahashinobuotakahashi 2005/11/21 14:43 3つ上の匿名の方のお話、大変(ビックリしたとともに)参考になりました。himazublogさん同様、公開されるといいなと思います。 そして「遅くてトロくて吐き気かしていた」点は、どのように解決されたのかも興味があります。

sawatsawat 2005/11/22 10:42 「Cで書いたほうが速いに決まってる!」というのはもはや都市伝説に過ぎないのですね。mallocよりもGCの方が速いという話ですし(⇒ http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml)。動的最適化が進めば、小手先のパフォーマンスチューニングテクニックも全部不用になるでしょう。

記録に挑戦記録に挑戦 2005/11/23 11:09 たいへん申し訳ないですが、それには異論を唱えざるをえません。binary2.0はジョークだけど、ジョークじゃない部分があると、私は思っています。
C言語が不要になるということと、C言語的なパフォーマンスチューニング技法が不要になることは、ぜんぜん別の話だと私は思います。そこのところを混同してはだめだと思うんです。C言語は不要になるし、C#に移行すれば、無意味になるC言語的技法ももちろん多いのですが、「大部分の」C言語的な技法が無意味になるという認識は、少し違う思います。その技法を使用する頻度が少なくなるだけで、完全にその技法なしでやってけるようになるわけじゃないんです。その技法を捨ててしまったら、未来から復讐されることになると思います。「Cで書いた方が速い」という思い込みがもはや通用しないというのは、多分にそうかもしれませんが、「Cプログラマーが伝統的にやってきたさまざまなC言語独特のパフォーマンスチューニング技法が陳腐化する」ことにはならないと思います。
むしろ、CLRやJVMのJITが進化すれば、いわゆるC言語的パフォーマンスチューニングが不要になる、という考え方の方が、よっぽど都市伝説な気がします。現に、上記のC#プログラムでは、SyntaxがC#なだけで、コンセプトや技法としては、伝統的なC言語、というか、むしろアセンブラ的な技法を使ってチューニングすることなしに、劇的なパフォーマンスの改善ができなかった箇所がけっこうありました。それは、コーディング量としては少ないけど、ポイントポイントで、決定的に重要な役割を果たしていますし、一切の希望的観測なしに現実を直視すると、今後もそうでありつづけるとしか思えません。ベタベタな現実として、それを完全に避けて通るのは机上の空論です。そして、それは今後JITやVMが進化することで解消されるようなものでは、本質的にないものだと思います。
実際、その部分のソースコードは、Syntaxまで含めてC言語そっくりで、 bainaryな技法に馴れていない最近のJavaプログラマやC#プログラマ(ソースコードの行間に、それが展開されるマシン語コードやCPUがそれを処理していく様子や仮想マシンの動作イメージやbainaryなメモリ構造イメージを幻視することができないような高級言語な人たち)には、何をやっているのかわけのわからない呪文のようなコードです。むしろ、JavaもC#も知らない職人芸的C言語プログラマやアセンブラプログラマの方が、よっぽどたやすく理解できるとおもいます。
そもそも、あれだけすぐれたJITをもった.NETのCLRが共用体や連続メモリに配置されたオブジェクトを、そしてC#がポインタやsizeof演算子などを導入したのは、もちろんレガシーとのインターオペラビリティーが第一義的な目的ではあるものの、決してそれだけが目的ではなく、そういうパフォーマンスチューニングも含めた伝統的なC言語の技法を、仮想マシン上の仮想マシンコードでも使えるようにするためという目的も強く意識していたということが、開発者たちの発言から伝わってきた記憶があります。彼らもJITやVMによる機械的パフォーマンスチューニングの限界を十分理解しているのだと思います。
なぜ、JITやVMによる機械的パフォーマンスチューニングに限界があるのか、それがどのようなものなのかは、JITやVMを開発している人たち自身がいちばん詳しいと思うので、私ごときがそれについて言及するのははなはだしく僣越であり、素人見解をぐたぐだと詳細を語ってネットのノイズを増やすのもアレなので(「私をたばねないで あらせいとうの花のように」ってどういう意味なんですか?)、これについては、彼ら専門領域の人間とは別の角度から説明をしてみます。
まず、このJIT/VMの限界問題は、企画屋と開発者の関係にたとえると分かりやすいと思います。はてなやGoogleはエンジニアが企画までやりますが、パワーポイントでコンセプトを書き、想定ユーザを決め、デザインをし、画面遷移を書く企画屋と、そこからアーキテクチャ仕様を起こし、プログラミングしていく開発者とが分業している会社もたくさんあります。binaryなエンジニアから見ると、JavaやC#でソースコードを書くというのは、まるで企画書を書いているような感覚があります。高度に抽象的な意味表現を記述するのが、主な仕事で、それを実際のマシン語コードやメモリ構造のビットの世界に落とすのは、すべて仮想マシンの仕事、という役割分担です。
しかしながら、開発者が、設計やチューニングや保守運用で、ありとあらゆる技術とスキルとツールとマシンを駆使しても解決するのにえらく苦労するような難題に直面したとき、企画者がたまたま技術にも深く通じているという特殊ケースでは、企画者が技術的難題を理解し、エンジニアといっしょになって企画としてのユーザ訴求力を維持しながら、劇的に開発生産性・保守性・パフォーマンスを向上させることに成功するようなことがよくあります。企画内容を替えないまま、「パフォーマンスをあげるのは開発者の仕事でしょ。」とはねつけるような企画屋と組んだエンジニアは不幸です。企画内容を固定したまま、実装設計の変更だけでパフォーマンスチューニングをするのは、能率が悪いだけでなく、しばしば劇的なパフォーマンス改善自体が不可能だからです。
JavaやC#のような高度に抽象的な言語と仮想マシン(JVMやCLR)の関係は、これにとてもよく似ています。仮想マシンやOSやCPUなどのbainaryな世界の登場人物を理解しようとせず、一方的にパフォーマンスチューニングはあなたたちの役割でしょと、はねつけると、問題が一気に複雑化してしまうことがあるのです。むしろ、企画屋と開発者の関係においては、開発者が人間であり、実装設計レベルでJVMやCLRにはおよびもつかないような人間の脳特有の高度な創意工夫を行えます。なので、そういう人間ですら、企画仕様を変えずに、実装仕様の工夫だけで問題を解決することが困難なケースが多いのですから、たんなるコンピュータプログラムでしかない仮想マシンなど、なにをかいわんやです。
ちなみに、先日はてなの方と飲んでいてうけた印象ですが、私は、Googleやはてなの極めて重要なコアコンピタンスの一つは、エンジニアと企画が明確に分離していないことじゃないか、という印象を受けました。もちろん、現代社会、というより、人類文明自体が、「分業」という社会モデルにおける超弩級のイノベーションの採用によって飛躍的という言葉で表現しきれないほどとてつもなく飛躍的に発展したのは十分承知しており、分業を否定するつもりはまったくありませんが、一方で、とくに一部の極端に未成熟な産業領域(Googleやはてなのいるあたりとかね)では、そのアーリーステージにおいて分業による弊害が分業が生み出す豊さを大きく上回ってしまうのではないかと思っています。その差分が、Googleやはてななどの企業パワーの源泉の一つだと思うんです。
あと、ついでに、わたしのような低いレベルの人間のもので参考になるかどうかは極めて怪しいですが、伝統的なCプログラマがソースコードの向こうにみているであろう世界をちょっとだけ記述してみます(まあ、トライぐらいはしてみてもいいだろう)。
ヘビーなCプログラマやアセンブラプログラマは、オブジェクトを、たんなるバイトやビットの並びとして見るビューをもっています。ここでビューと言っているのはMVCモデルにおけるビューですね。そして、もちろん、マルチビューなCプログラマの方が多いです。マルチビューというのは、ちゃんとポリモルフィズムとかカプセル化とかデザインパターンとかそういうものとしてオブジェクトを見るビューも同時にもっていて、その複数のビューを同時に脳の中に開きながら、アーキテクチャ仕様書を書いたりコーディングしたりするわけです。で、ビットやバイトの並びのビューを通してオブジェクトを見ると、オブジェクトのフィールドっていうのは、たんなるメモリアドレスにラベルを貼っただけのものなんです。配列も同じです。というか、プログラムコード自体も、ビットの並びでしかなく、すべてのものは、ビットやバイトに別名をつけて、別な扱い方をしているだけのものに見えます。なので、JavaやC#がリフレクションとか言って、プログラム自身の情報をオブジェクトやデータとして参照するのをなにか特別な能力であるかのように標榜するのは、滑稽に思えます。そもそも、バイトビューの世界では、プログラム自身もデータと同様バイトの並びでしかなかったので、プログラムコード自体をデータとして扱うリフレクションプログラムなど、あたりまえすぎるほどあたりまえだからです。
もっというなら、バイトビューな世界から見ると、現在のJavaやC#のリフレクションなど、一方通行の中途半端なリフレクションにしか思えません。つまり、リードオンリーなリフレクションです。ほんとうの(笑)リフレクションは、自己書換えもできなくてはいけません(ここの部分は、かなりジョークね(笑))。人間の脳のような自己書換え系です(もちろん、.NETにはそれを意識したと思われるライブラリ群がありますけど。あと人間にも、何度やっても反省(reflection)せず、何度でも同じ間違いを繰り返す人がいますけど > 実はそれはおれの事なんだけど(笑))。
そして、これはほんの一例にすぎず、ポリモルフィズムとかデザインパターンのビューから見ると進化の歴史であったプログラミング言語の進化の歴史は、バイトビューから見ると、かつてできたことをできなくしていく退化の歴史です。もちろん、その退化によって得られたトータルメリットがトータルのデメリットをはるかに上回ったからこそ、このような歴史的過程を辿ったのですが、多くのものの進化のプロセスがそうであるように、価値あるものを初期のトレードオフ条件によって切り捨てることで進化したものは、成熟するに従って、トレードオフ自体を解消する方法を見いだし、進化によって獲得したものを失うことなしに、進化の初期ステージで切り捨ててしまった価値あるものを復活させることで、さらなる進化をするというのが、とてもよくあるパターンです。
たとえば、産業革命以前は、顧客一人一人の個性に合わせて商品を作る、カスタマイズやパーソナライゼーションなんて、あたりまえすぎるほどあたりまえだったわけです。空気のようにあたりまえすぎて、そういう概念を記述する言葉すら必要なかった。それが、いわゆる産業革命と言われる過程で、パーソナライズやカスタマイズという豊さを切り捨て、画一化・規格化することで、流れ作業と分業による大量生産を可能とし、文字通り空前絶後の目も眩むような生産性向上が行われ、それまで人類が生産したすべての富の200倍もの富をほんの数世紀で創り出して、現在われわれがあたりまえのように享受している現代文明を作り上げてしまったわけです(われわれ=現代日本人ね。サブサハラとかのことを失念しているわけじゃないですよ、もちろん)。しかし、いまや技術およびビジネス技法でのイノベーションにより、このトレードオフが解消され、多数の人々に対するサービスでありながら、同時にパーソナライズもされているというサービスの開発が可能になりました。そして、われわれは、産業文明の進化によって獲得したもの失わないまま、進化の初期ステージで切り捨た豊さを再び復活させようとしているわけです。
また、自己書換え系といえば、分子生物学においてはRNAこそが自己書換え系そのものですが(DNAと違い、RNAは直接RNA自体を合成したり、加工したりする能力を持つので、ソフトウェアの分野におけるアセンブラプログラミングととてもよく似ている)、DNAというイノベーションによって陳腐化されたかに見えるRNAワールドですが、RNAをよく理解することで、エイズなどのレトロウイルスやガンや老化の理解が深まることで大きなイノベーションが生まれ、また、今後もブレークスルーが期待できるのも、イノベーション構造的にはこの問題とよく似ています。
というわけで、もちろん、ソフトウェア工学的には太古の昔に存在したバイナリーワールド(分子生物学でいうところの「数十億年前に存在したRNAワールド」のパクリね(笑))の技法の中には、陳腐化してしまって、いまではジョークのようなものもたくさんある一方で、温故知新というか、今後の情報技術の進化の中で復活したり、ますます重要になってくるものも多いと思います。現代のネットワールトにおける、その主な原動力の1つに、人々の処理したい情報量は、ますます増えるし、その処理の仕方に対する人々のニーズはますます多様化・高度化していくので、それらすべてのニーズの膨張を、ハードウェア的なマシンパワーの増大だけですべて吸収するのは、非現実的だから、というものがあるのではないかと思います。CPUパワーの増大が、むしろ対数で表記した方が分かりやすいのじゃないのかというような増え方をしたとしても(それすらも雲行きが怪しいですが)、社会的リクワイアメントの増大もやはり対数で表記しなければならないようなものになるので、現実問題としては、対数の底の部分が問題になってきてしまう、というわけです。ムーアの法則なんて、対数の公式でもつかって約分すれば、消えちゃうかもしんないんですよ。
ということで、binary2.0な人たちは、まるでジョークであるかのように、自分たちのレゾンデートルを茶化していますが、とうぜん、わかっている人にはあたりまえすぎるので、オイラごときがいうのは恥ずかしいのですが彼らが沈黙しているので、オイラがあえて代弁しますが、それはジョークだけど、ジョークじゃない部分があるんですよ。そして、そのジョークじゃない部分ってのは、現実のリアルな問題における決定的な場面で、ときとしてプロジェクトの命運までも左右してしまうような重大な意思決定に欠かせないような、ものすごくクリティカルなものじゃいかと、ぼくは思っています。少なくともプロジェクトリーダとか、SEとかのレベルでこの部分がかけていると、そのプロジェクトは頓挫しかねないし、CTOのレベルでこれがかけていると、会社そのものがヤバくなりかねないような、そういうたぐいの「意思決定における必要条件の一つ」にときとしてなってしまうんじゃないかと思うんですね。もちろんいまどきこんなもん十分条件でもなんでもないですが。
あー長かった。意味もなくだらだら書きつづけるのって、それはそれでけっこうな労働ですね。でも、これで、はてなのすべてのコメントの中で、最も長い、コメント最長記録を達成したのではないかと思います。ギネスブックには載らないと思うけど、ギネスブックに載りそうなほど、不毛な挑戦ではあったな。
まさか、こんな長いコメントを、ここまで読んだ方はいらっしゃらないと思いますが、もし読んだとしたら、読んでくださって、どうもありがとうございました。お礼に、「はてな一長いコメント記録達成の目撃するほどの暇人」という称号をお送りさせていただきます。

naoyanaoya 2005/11/23 11:19 暇人称号ゲッツ!

すごくいい指摘だと思います

TigerTiger 2005/11/23 21:00 ブラウザだと余りに辛かったので、エディタにコピペして読んでしまいました(笑

sawatsawat 2005/11/24 01:28 全部読ませていただきました。納得至極にございます。

JOJOJOJO 2006/01/28 02:52 僕は高級言語しか使えないのですが、
確かに、究極までパフォーマンスを突き詰めたいときに
最後はアセンブラかなーとか思っていました。
でもJITがすごく進化したら、動的にアセンブラ的な技法を使ってチューニングをしてくれたりするんじゃないでしょうか?
「アセンブラ的な技法を使ってチューニング」がわからない若造なので、
多分それは無理だねって言われるのがオチですが、
JITに期待しています。

asekiaseki 2006/01/28 08:29 「ジレンマ」という言葉の使い方、間違ってますよ。

ほっさんほっさん 2006/01/28 08:49 「はてな一長いコメント記録達成の目撃するほどの暇人」という称号に惹かれて読んでしまいました。
中身も面白かったです、感謝。

suzuryosuzuryo 2006/03/27 22:27 気に入ったコメントに対してポイントは送れないんですか?