ユメのチカラ: Rubyで習作の性能評価
うひょ〜。大変なことになった。手習いで書いた初めてのRubyプログラムが大御所によってたかって添削指導をうけている。 確かに突っ込みどころ満載のゆるゆるのコードなので、弊社のrubistからの突っ込みくらいは想定していたが、まつもとさんや弾さんの登場までは想定外であった。多くの皆様のコメントに感謝したい。 実装についても、ArrayやらHashやらSetやらいろいろあった。そこで、ちょっと性能評価をしてみた。 具体的には time ruby -rprofile でruby自前のプロファイルをとってみた。 Array#includeはコストが高い。実行時間が21秒〜24秒くらいとなっていて、そのうち12秒〜13秒をArray#includeで消費している。 表の見方なのであるが、コストのかかっている処理のトップ3を表示した。左から、全体から比率、累積実行時間(秒)、実行時間(秒)、呼び出し回
ユメのチカラ: MySQLのマルチコアスケーラビリティとLinux
スラッシュドットの情報。FreeBSDとLinuxでsysbench(MySQLを利用している)の結果が出ている。結論から言うと8コアのAMD64のマシンでスレッド数を上げていくと8スレッドまではLinuxでの性能が良かったが、それ以上になるとがたっと性能が劣化して、FreeBSDのSMPngの実装が勝つ。 下記を参照してほしい。 http://jeffr-tech.livejournal.com/6268.html MySQL 5.0.2xではSMPスケーラビリティに問題があることは、われわれの性能評価でもあきらかになっていたが、(例：MySQLに対応した評価ツールDBT-1を利用したハードリソース変更によるパフォーマンスへの影響の考察を参照)、OSのSMPスケーラビリティ問題というよりMySQLの実装上の問題だと考えていた。 linux 2.6.18/2.6.20.1上でMySQL 5
ユメのチカラ: Community Based Development
オープンソースソフトウェア(OSS)の力はバザールモデルとして知られるコミュニティによる開発(Community Based Development)だと思う。 OSSの特徴としてフリーなライセンス(利用、変更、再配布の自由など)があげられる事が多いが、それはあくまで必要条件であって、十分条件ではない。ライセンスをフリーにしたからと言って、コミュニティが自然発生するとは限らない。商業ソフトウェアベンダは自社製品をプラットフォームとするために、あの手この手を使ってコミュニティを形成しようとするが、それには相当なコストと時間がかかる。 大雑把にソフトウェアを分類してみる。 最初のカテゴリは、プログラム。これは実行可能なソフトウェアで、趣味で作ったり学校の課題で作ったりする小規模なものとする。規模も小規模でせいぜい大きくても数千〜数万行程度のものである。おもちゃのプログラムに毛がはえた程度のもの
ユメのチカラ: 日本Ruby会議2007
行ってきましたよ。Rubyの祭典。日本Ruby会議2007。400以上のRubyistが集まりましたよ。御茶の水に。 2007年6月9日(土)、10日(日)という土日を2日間つぶすという会社員にとっては、それはそれなりに厳しいスケジュールであるが、仕事というよりも、ファンの集いみたいなものだから、這ってでも参加しないといけない。前日飲み過ぎだとしても。 それはともかく、参加記念のRuby会議公式トートバックをもらってうきうき、初日ささださんのRuby 1.9のお話などから聞く。ささださんの開発版(1.9)と卜部さんの安定版(1.8)それぞれのメンテナのお話はコードを書いてメンテナンスする人のご苦労がしのばれた。いろいろ大変なんだろうなあと。青木さんのリファレンス・マニュアルのお話も量的な問題があり、相当大変だというのはよくわかった。JRubyはSunがRubyの実装をするとこうなるよとい
ユメのチカラ: BITS2007
恒例のパネルディスカッションに参加した。メインフレーマーの経験、知恵とオープンソースとの融合などが課題となる。 メインフレームの時代には、ハードウェア、OS、ミドルウェア、SI、すべて一社で供給していた。オープンシステムの時代になって、それぞれ別々のベンダーから調達し、SIベンダーが供給するようになった。各コンポーネントは標準化されていて（デファクト標準）、価格競争力がないと競合に置き換えられてしまう。その結果、メインフレーム時代に比較して、リーズナブルな価格になった。 問題はそのように作られたシステムでなんらかのトラブルが発生した場合である。プロプライエタリな製品で構築されていると、その製品にトラブルが発生するとSIベンダーには手も足もでない。垂直統合型（メインフレームの時代）の場合、自社ですべての製品を提供しているので、OSだろうがミドルウェアだろうが、トラブってもどうにかするのである
ユメのチカラ: 技術は会社のものではない。みんなのものだ。
技術は会社のものではない。みんなのものだ。 プロプライエタリな世界に長くいると、上のようなことを言うと、こいつおかしいんじゃないかと思われてしまうが、オープンソースの世界にどっぷりつかっていると、「技術は会社のものではない。みんなのものだ。」というのはおかしくともなんともない。至極普通のことと思う。 企業がオープンソースに関わるとき「技術は会社のものではない。みんなのものだ。」ということを理解できているかどうかというのが成功のポイントになるような気がする。理屈の上では理解していても企業、組織として理解できているかは別の話である。 例えば、オープンソースソフトウェアを共同して改善する場合、そのプロセスそのものを公開できるか。密室で改善するのではなく、公開のメーリングリストなどでオープンに議論しながらパッチを作るとかを、最初っから実践できるか。そもそも開発を公開のメーリングリストでするという発
アジアのペンギン: アセンブラの勉強方法
ダンプを解析するときなどはアセンブラを理解していないといけません。勉強しようと思っても最初は意味不明でやりづらいのですが、簡単でわかりやすい方法があります。実務的にはこれで十分だと思いますのでご紹介します。 この方法ではLinuxマシンを用意すればいいだけです。(本を探したり、購入する必要もなし) アセンブラを理解するためにはCPUのレジスタなどを理解する必要があります。私が実際にダンプを解析するときに見るのはEIP、ESPぐらいです。アセンブラからソースコードを解析する場合は少しアセンブラ命令の意味を理解していれば、レジスタは汎用的に使用されるため特別な知識はあまり必要ありません。 まずは下記のようなソースコードを作成して、コンパイルします。( Fedora Core 5 32bit の場合 ) # cat assemble.c #include <stdio.h> int globa
ユメのチカラ: テストカバレージ
先日Ottawa Linux Symposiumに論文のproposalがとおったという話を書いたが、論文を鋭意執筆中である。今回crackerjackというリグレッションテストのフレームワークをうちの若手のkyagiさんがばりばり作ったのであるが、それから呼ぶbtraxというカバレージ測定ツールがこれまた凄い。これは日立の藤原さんというハッカーが実装したのだけどなかなか金銭ではなく琴線に触れるツールである。 ハッカーのバイブル、IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guideの15章はおなじみのDebugging and Performance Monitoringである。わたしもhardmeterを実装する時は読みに読んだ。マニュアルがボロボロになるまで読んだ
ユメのチカラ: YAPC::Asia 2007
Yet Another Perl Conference at Asia (YAPC::Asia) に参加した。 技術系カンファレンスというのは何のためにあるのか考えるいいきっかけになる。 なぜ、技術系カンファレンスに時間を作ってもいかねばならないのか。楽しいから、新しい技術を勉強、ネットワーキング、旧友にあう、有名人のサインをもらう、オライリーの新刊を立ち読みする、初対面の人となかよくなる、技術的な議論をする、気分転換、カーネル読書会の宣伝、技術系カンファレンスの運営について学ぶ、ついでにリクルーティングなどなど。 参加者はざっとみて400人弱くらいか。Shibuya Perl Mongersの人達が主体となってボランティで運営開催されている手作りのカンファレンスである。Ruby会議やPHPカンファレンス、LLなどと規模や運営方法が似ている。Linux World Expoのような企業によ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第三のペンギン: Linux パフォーマンスチューニング (入門書を卒業した管理者が次に読む本) その２