iPadで選択した文字列を翻訳するブックマークレットを作りました

昨日はSmiley Hackathon#10 : ATNDに行ってきました。
HackathonではFacebookアプリをつくっていたのですがそれはおいておいて、iPadで選択した文字列を翻訳できるブックマークレットを作ったのでそちらを紹介したいと思います。

作ったきっかけ

iPadでゴロゴロしながら英語のサイトを見たりしたいなーと思ってたのですが、
いざ読んでみると単語を調べる時にアプリを切り替えないといけないので、読むのがつらくなってきました。
iPadSafariでは拡張機能がまだないそうなので、ブックマークレットを作ってみることにしました。

作り方

ブックマークレットの作成はHatena::Letを使い、
翻訳APIMicrosoft Translatorを使いました。
(Google Translate APIはもうすぐDuplicateになるようです)

コード

/*
 * @title translate selected text
 * @description translate selected text
 * @include http://*
 * @license MIT License
 * @require jQuery
 * @private
 */

var appId = 'Bing APIのAppID';
var getText = function() {
    var range = window.getSelection().getRangeAt(0);
    if (range.toString()) {
        var str = range.toString();
        $.ajax({
            type: "GET",
            url: "http://api.microsofttranslator.com/V2/Ajax.svc/Translate",
            dataType: "jsonp",
            data: {
                appId: appId,
                text: str,
                from: "en",
                to: "ja"
            },
            jsonp: "oncomplete",
            success: function (data, dataType) {
                var fragment = document.createDocumentFragment();
                var span = fragment.appendChild(document.createElement('span'));
                span.style.cssText = "background-color:#FFCACA";
                span.appendChild(document.createTextNode(range.toString() + "[" + data + "]"));

                range.deleteContents();
                range.insertNode(fragment);
            }
        });
    }
}

document.addEventListener( 'mouseup', getText, false );
document.addEventListener( 'touchend', getText, false );

使い方

1. 読みたいページを開きます。
2. ブックマークレットを押します。
3. テキストを長押し(選択)すると翻訳したテキストが表示されます。

これでゴロゴロ英語ライフがたのしめます!

第三回 ライブドア・テクニカルセミナーに行ってきた

livedoor Techブログ : 第三回 ライブドア・テクニカルセミナーのお知らせに行ってきました。

内容が濃くてメモしきれないところもあったのですが載せておきます。

クラウド時代のWebストレージ/データベース戦略」

  • ライブドアが求めるストレージは?
    • webサービスのメディアストレージ
    • 安価に容量を拡張可能
    • データの冗長化、高可用性
    • 実際の構成は(あまり)意識したくない ※あまり、というのがポイント。自社で使う分にはうすらぼんやり見えているといい
    • 自社で使う向けに作った
  • HTTPを利用した分散ストレージ
  • Pros
    • シンプルなKey-Value
    • クライアントから巨大なストレージプールとして見える
    • 普通のサーバを使用して拡張可能
    • データのレプリケーション
    • Apacheモジュールベースなので拡張可能
  • Cons
    • ファイルシステムとしてマウントできない→コードの書きかえ
    • すでにあるオブジェクトに追記できない
    • オブジェクトの一部書き換えができない
    • パーミッション/アクセス制御ができない
  • REST API
    • GET/PUT/DELETEをサポート
    • バケットの作成/削除
    • オブジェクトの取得/作成/更新/削除
    • レプリカの作成数等はヘッダで指定
  • HTTPヘッダ
    • Content-MD5 これを入れておくことによってファイル欠けを検出することが可能
    • X-Replication-count レプリケーションする数を指定することができる
  • 実装
    • ApacheモジュールをCで実装
    • URI→物理ロケーションのマッピングMySQLに保存
    • MessageQueueを利用した非同期処理 Q4MとかActiveMQ
    • 非同期処理のワーカーはPerlで記述 ※ここが一番要件が変わる部分なのでPerlで書いておいて柔軟に対応したい
  • CAP定理
    • Consistency(一貫性), Availability(可用性), Partition Tolerance(ネットワーク分断の耐性)の3つのうちどれか一つを捨てなければいけないというのがある
    • 今回は、一貫性を捨てている。物理的には一貫性が崩れている瞬間があるけれどもそこを捨てている
  • MySQL/Memcached
    • ディスパッチャ
    • ストレージノード
    • Queue
    • Worker
  • テーブル構成
    • URL: 実体のマッピング/メタ情報
    • storage
    • bucket
    • object: URIとObjectID
      • Auto Incrementではなく、GUID 64bitのintになるように設定(Perlモジュールを移植したとおっしゃってたけど、Data::GUIDのことかな?)
    • entity: ObjectIDとファイル実体
  • mod_stf_storage.c
    • GET/PUT/DELETEメソッドを受け付けてファイルの読み書き
    • GETはdefault-handlerまかせ
    • PUTはRecursiveにディレクトリを作成
    • 同一ファイル名での上書きはできない
      • 更新は一回消して内部的には別ファイルを作成
  • Queue
    • 結果整合性を取るために使っている
    • MessageQueue経由
    • レプリケーション
    • オブジェクトの実体削除
      • 最初にDELETEするときはMySQLでdeleteするだけ→実体は非同期に消す
    • バケット削除時の再帰的削除
    • 使用容量の計算
  • Storage管理用のWebIF
    • Catalystベース
    • 機能
      • ストレージの追加
        • サーバをセットアップしてWebIFから追加
      • 利用状況の確認
      • ストレージのモード切り替え
  • 画像加工はImlib2かImageMagickから選べる
  • Squidにキャッシュしている
  • 今後の展望
    • MySQL依存からの脱却
    • 特定のノードの使用(SSD対応)
      • 最新のものと人気があるものしか参照しないように
  • 現在運用されている状況
    • 20TB〜30TBは用意されていて、運用されているのが10数TB
    • 1TB/月くらいで増える
  • なんでMogileFSにしなかったの?
    • MogileFSはソースが長い。書く時間と読む時間を考えたら書いた方が早い(かっこいい!)

ライブドアクラウド的サービス」

  • 仮想化技術の選定
    • VMware
      • 予算的にきつい
    • KVM
      • RedHatサポート
      • 管理ツールはあるが、X11ベース
      • それぞれのサーバに専用プログラムを導入する必要がある
    • Enormaly
    • Parallels製品に決定!
  • ソーシャルアプリ向けに開発した
  • Spec
    • Parallels Server 4 Bare Metal
    • CentOS 5.4 x86_64
    • OSバーチャライゼーションを使用
      • (HostOSの再起動が不要なため?)
  • 実装
    • リアルサーバの中にインスタンスがある
    • LVSの冗長構成の下にインスタンスを増やしていっている
      • ラックが埋まったらLocal Switch経由で移動
    • ネットワークの区切り方はtag VLANで区切る
    • LVSでスケールアウト
    • スケールアップ
      • ライブマイグレーション
        • UNITに余裕があるサーバにマイグレーションを行ってからスケールアップ
        • rsyncでコピーして、メモリ同期して、ネットワーク切り替えを行う
        • 使用しているディスク領域が多いと時間がかかる
        • 30GBでrsyncに1時間くらいかかるのでちょっといやだ
  • LVSのサーバの性能は?
    • 250台くらいまでは大丈夫だそう。
  • APIでプログラムから叩きたい
    • Parallelは叩くことはできるがサービス的には対応してない
    • API公開は必須条件なので対応していく予定
  • 課金形態は話し合い中
  • フルマネージドホスティングをベースにして、自動化できるところを自動化するというポリシー

livedoor Readerの新機能とは?」

  • 新機能の紹介
    • livedoor streaming API
    • フィードの更新情報をリアルタイムで取得するAPI
    • 外部ドメインでも普通に動く
    • 非公開フィードの記事はでない
    • ストリーミング、といっても、Readerがクロールしたタイミングにはなる
  • Q4m
  • TokyoTyrant
  • Nginx
    • Streaming APIのフロントエンドとして利用
    • long-pollコネクション可
  • Plack
    • そろそろnginx + Plackに変えたい
  • Coro AnyEvent
  • MySQL
    • 5.0
    • 5.1 記事クラスタで使っている。
    • InnoDB Plugin
      • データを圧縮して、メモリ効率を上げられる
      • 記事データ用に使用
      • Master/Slave 3+3台
  • Perl 5.8.7
  • Q4M
    • クローラとジョブ管理
    • Q4M専用MySQLを2台
    • クローラ専用4台
  • memcachedの代わりにTokyoTyrant
    • HashDB7台
  • Coroで作られたDOSツール
    • 大量のコネクションを張ってテストするのに使っている
  • データ量
  • クローラ
    • メッセージキューを使った分散処理
    • MySQLQ4M
    • クローラを細かいタスクに分割して実行
    • Q4Mでバケツリレー式に処理
  • 処理の内容
    • Brocker
      • クロール対象をキューに入れる
      • cronで1分置きに起動
      • このとき必要なデータをMemcachedに入れる
    • Fetcher
      • Parallel::PreforkとClass::Triggerつかっている
      • daemontoolsで管理
        • 一定件数処理したら死ぬように作っている
      • Coroを使って並列処理をしている。1プロセスで50~100(HTTPDのコネクション)くらい。
      • レスポンスが遅いものがあってもクローラが遅れないようにしている
    • Parser
      • XML::LibXMLとXML::Liberal+独自
        • 独自、というのは、巨大フィードを途中で中断するなど
        • feedburner.origLink保存するなど
      • 一番CPUパワーに依存する処理
      • 並列数増やしても意味がない
    • Updater
      • DBの処理速度に依存
      • 1台あたり10程度
  • 記事の振り分け
    • SKIP
    • INSERT
    • UPDATE
    • SILENT_UPDATE
      • ちょっとしか更新されてない
      • 一定文字数意外更新されたもののみ
  • フィードごとに既出フラグを保存している
    • 既出フラグの保存をmemcachedTokyoTyrantに移行
    • このとき、ストレージとネットワークIOの節約のため、既出フラグをfeedごとにまとめた。
    • フラグだけで5億件!→180万件に減った
  • ハッシュ値
    • 記事ごとにハッシュ値を作る
    • 本文からスペースとタグを取り除く
    • フィードごとに同じ記事は1件のみ
  • XMLとしては変化しているが記事は変更されていないケースが実は非常に多いことが判明
    • 配信元サーバがコメントで書かれてるとか
    • lastBuildDateがアクセス日時になってるとか
    • 独自のネームスペースにアクセス回数やコメント数が含まれているとか
  • そこで前回のパース結果をTokyoTyrantに保存
    • 前回更新時のフィードに含まれていた記事は既出の記事である
    • Parserの段階で不要な記事にはSkipFlagをつける
    • updaterキューへの送信数が半減
  • Async::Queue
    • Perlで書かれたメッセージキュー
    • AnyEvent+JSON RPC
      • 複数のキューサーバを1台に見せかけることができる
    • Q4Mのバグに当たった
      • dead lock接続待ちで応答なし(最新版で修正済み)
      • コンパクションが起こるタイミングでパフォーマンスが悪化する
  • クライアント側は書けませんでしたごめんなさい><

BPStudy #29 TDD

はじめに

tokuhiromさんとペアを組ませていただいたのですが、本当に何もできず(そもそも緊張しすぎてしゃべることすらできず)本当に嫌な思いをさせてしまって申し訳ありませんでした。
そんなごめんなさいエントリです。

お題

LRUCacheをつくる

Limitを決めておいて、そのLimitの数だけ値をsetする
getをすることもできて、getすると使われる(残る)
値をsetしたときにLimitより多くなった場合、古いものから消える

TDDのサイクル

TDDのサイクルは、「動くものを書いてきれいにしていく」というプロセスだそうです。

1. テストを書き
2. そのテストを実行して失敗させ(Red)
3. 目的のコードを書き
4. テストを成功させ(Green)
5. テストが通るままでリファクタリングを行う(Refactoring)
6. 1〜5を繰り返す

Skeletonをつくります

今回はModule::Starterを使いました。pmsetupじゃなくてごめんなさい

$ module-starter --module=LRUCache
$ perl Makefile.PL
$ make test

ということでまずテストを書こう

まずまずテストを書いてみます。自信がまったくないのでgetとsetだけ><

$ vi t/01-main.t
#!/usr/bin/perl

use strict;
use warnings;

use Test::More;
use LRUCache;

my $lru = LRUCache->new(); 
$lru->set('a' => 'TestA');
$lru->set('b' => 'TestB');
$lru->set('c' => 'TestC');
$lru->get('a');

done_testing;


実行してみます。こけます。

$ prove -lvr t/01-main.t 
t/01-main.t .. Can't locate object method "new" via package "LRUCache" at t/01-main.t line 9.
Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run 

Test Summary Report
                                    • -
t/01-main.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output Files=1, Tests=0, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.02 cusr 0.01 csys = 0.06 CPU) Result: FAIL Failed 1/1 test programs. 0/0 subtests failed.

テストに合うように実装してみる

まずは今の状態でテストが通るようにやってみます

package LRUCache;

use warnings;
use strict;

use Moose;

has 'data' => (
    is => 'rw',
    isa => 'HashRef',
    default => sub { +{} },
);

sub set {
    my ($self, $key, $value) = @_; 
    $self->data->{$key} = $value;
}

sub get {
    my ($self, $key) = @_; 
    return $self->data->{$key};
}

1;

いっかい通してみます。

$ prove -lvr t/01-main.t
t/01-main.t ..
ok 1
1..1
ok
All tests successful.
Files=1, Tests=1,  0 wallclock secs ( 0.03 usr  0.01 sys +  0.23 cusr  0.02 csys =  0.29 CPU)
Result: PASS

いったんgetとsetはできました。

LRUになるように変更してみる

まずはテストから。

my $lru = LRUCache->new(limit => 2); 
$lru->set('a' => 'TestA');
$lru->set('b' => 'TestB');
$lru->set('c' => 'TestC');
is $lru->get('a'), undef; # 2こしかないから、cを入れたときにaが消えてほしい

テストを書き始めて、もっと1こずつテストしたほうがいいと気づきました。
いっぱい書いてみます。

#!/usr/bin/perl

use strict;
use warnings;

use Test::More;
use LRUCache;

subtest 'test1' => sub {
    my $lru = LRUCache->new(limit => 2); 
    $lru->set('a' => 'TestA');
    $lru->set('b' => 'TestB');
    is $lru->get('a'), 'TestA';
    is $lru->get('b'), 'TestB';
    done_testing;
};

subtest 'test2' => sub {
    my $lru = LRUCache->new(limit => 2); 
    $lru->set('a' => 'TestA');
    $lru->set('b' => 'TestB');
    $lru->set('c' => 'TestC');
    is $lru->get('a'), undef;
    is $lru->get('b'), 'TestB';
    is $lru->get('c'), 'TestC';
    done_testing;
};

subtest 'test3' => sub {
    my $lru = LRUCache->new(limit => 2); 
    $lru->set('a' => 'TestA');
    $lru->set('b' => 'TestB');
    is $lru->get('c'), undef;
    is $lru->get('a'), 'TestA';
    done_testing;
};

done_testing;

subtestというのは今回はじめて知りました。Test::Moreでできるのですね。
ここでもtokuhiromさんに助けていただくなんて><

http://d.hatena.ne.jp/tokuhirom/20100118/1263800343


ほいで、実装してみました。
教えてもらったのはもっとかっこよかったのですが、申し訳ないです覚えきれなかったのでだいぶひどい感じになっています><

package LRUCache;

use warnings;
use strict;

use Moose;
use Data::Dumper;

has 'limit' => (
    is => 'ro',
    isa => 'Int',
    default => 1,
);

has 'data' => (
    is => 'rw',
    isa => 'HashRef',
    default => sub { +{} },
);

has 'used' => (
    is => 'rw',
    isa => 'HashRef',
    default => sub { +{} },
);

has 'counter' => (
    is => 'rw',
    isa => 'Int',
    default => 0,
);

sub get {
    my ($self, $key) = @_; 

    return undef unless defined $self->data->{$key};
    if ($self->used->{$key}) {
        $self->used->{$key} = $self->counter($self->counter + 1);
        return $self->data->{$key};
    }
}

sub set {
    my ($self, $key, $value) = @_;
    $self->data->{$key} = $value;
    $self->used->{$key} = $self->counter($self->counter + 1);

    if ($self->limit < scalar keys %{$self->used}) {
        my @store = sort { $self->used->{$b} <=> $self->used->{$a} } keys %{ $self->used };
        $#store = $self->limit - 1;
        my $new_hash;
        foreach my $k (@store) {
            $new_hash->{$k} = $self->used->{$k};
        }
        $self->used($new_hash);
    }
}

1;

setしたりgetしたりするたびにカウンタを増やして、
usedという中にいまキャッシュにはいっているべきkeyとカウンタが入るようにしました。
配列の要素数変更とかかなりごりっとしてて目もあてられない><でもうごくのでいったん。。


テストしてみます。

$ prove -lvr t/01-main.t
t/01-main.t .. 
    ok 1
    ok 2
    1..2
ok 1 - test1
    ok 1
    ok 2
    ok 3
    1..3
ok 2 - test2
    ok 1
    ok 2
    1..2
ok 3 - test3
1..3
ok
All tests successful.
Files=1, Tests=3,  0 wallclock secs ( 0.03 usr  0.01 sys +  0.23 cusr  0.02 csys =  0.29 CPU)
Result: PASS

とおりました。

limitが途中で変わっても大丈夫なように作る

まずまずテストから

subtest 'test4' => sub {
    my $lru = LRUCache->new(limit => 3);
    $lru->set('a' => 'TestA');
    $lru->set('b' => 'TestB');
    $lru->set('c' => 'TestC');
    $lru->limit(2);
    is $lru->get('a'), undef;
    is $lru->get('c'), 'TestC';
    done_testing;
};


実装を変更します。limitが変更したときにusedにあるものを変更したいので、
Mooseのtriggerを使います。
(変更部分のみ記します)

has 'limit' => (
    is => 'rw',
    isa => 'Int',
    default => 1,
    trigger => sub {
        my ($self, $new, $old) = @_;
        return unless defined $old;
        $self->used($self->_used_hash);
    },
);

sub set {
    my ($self, $key, $value) = @_;
    $self->data->{$key} = $value;
    $self->used->{$key} = $self->counter($self->counter + 1);

    if ($self->limit < scalar keys %{$self->used}) {
        my $new_hash = $self->_used_hash();
        $self->used($new_hash);
    }
}

sub _used_hash {
    my ($self) = @_;

    my @store = sort { $self->used->{$b} <=> $self->used->{$a} } keys %{ $self->used };
    $#store = $self->limit - 1;
    my $new_hash;
    foreach my $k (@store) {
        $new_hash->{$k} = $self->used->{$k};
    }
    return $new_hash;
}

最後にテストしてみます。

$ prove -lvr t/01-main.t
t/01-main.t .. 
    ok 1
    ok 2
    1..2
ok 1 - test1
    ok 1
    ok 2
    ok 3
    1..3
ok 2 - test2
    ok 1
    ok 2
    1..2
ok 3 - test3
    ok 1
    ok 2
    1..2
ok 4 - test4
1..4
ok
All tests successful.
Files=1, Tests=4,  1 wallclock secs ( 0.03 usr  0.01 sys +  0.24 cusr  0.02 csys =  0.30 CPU)
Result: PASS

とおりました><やった!


まとめ

もっと教えてもらったものをメモっておけばよかったとか
そもそも書けよとかありますが本当にすみませんすみませんすみません><
しかも教えてもらったことさえ満足にできているか・・・><。。

そしてもっときれいに書ける方法かんがえます。


YAPCの時にMooseを教えてもらったときにテストを埋めるように開発するスタイルを教えてもらっていたので
なんとか復習することができました。ありがとうございます。
超てんぱっている中優しく教えてくださって本当にありがとうございました。


そういえばTDDで教えてもらったことをメモってたのに全く書いてないですね。

「ふるまいベースのテスト」ということがとても印象的でした。
実装の細かいやりかたのテストはふつうにwarnとかで出して、
入力、出力はこうあるべきというところだけテストで書くんだというのがわかりました。
昨日ちょうど、テストに何を書いたらいいのかということを社内で話していたので今回わかってよかったです><


ねむむい明日合宿なのでもう帰ります@マクド

2009年の振り返り

そろそろ2009年も終わりということで、この1年間であったことを振り返りたいと思います。

チーム結成

2009年のはじめに、それまで仲の良かった開発メンバーとチームを結成しました。
メンバーの中には開発が初めてだった子もいて、
チームの平均年齢が24歳という超未熟者のチームで、
本当にプロジェクトをやりきれるのか不安だったときもありました。

実際やってみると、そんな不安も軽く払拭してくれるくらい優秀なメンバーばかりで、仕事しやすくて楽しくて、あっという間の1年でした。


良いチームを作るために守ってきた2つのこと


チームを結成してから、2つだけ守ってきているものがあります。
それは、チーム定例会議とチームtracの2つです。

チーム定例会議

今までいろんな定例会議をやってきましたが、たいがい形骸化しがちでした。
そこで、チーム定例会議では構成を見直しました。


定例会議の構成

  • 先週やってきたことと今週やることの報告(短めに)
  • ソースレビューや勉強してきたことの発表、設計の相談など(長めに)


仕事内容の報告は、マネージャたるもの常に把握しておくべきで、他の人も空気感が見えている状態なので、あえて短めに設定します。
現状では4人〜6人報告しますが、いつも30分以内で終わらせるようになっています。
「わかっているけどやらなきゃいけない状況(=省略可能な状況)」というのが形骸化の一番の要因だと思っているので、
他の人と協力したり、見てあげてもらいたいポイントのみ抑えておいて、あとは簡潔に簡潔にします。


残りの時間を使って、ソースレビューをしたり、設計の相談をしたりします。
この時間でソースレビューをすることによって、この1年で確実にソースレビューの機会が増えました。
わざわざ会議を設定しなくても良い手軽さがポイントのようです。
ソースを見ながらみんなでわいわい言い合うのでとても楽しいですし、逆に定例会議自体のモチベーションにつながります。

チームtrac

かねてからチームで見合える自由に書ける場が欲しいと思っていたのでチームtracを作りました。
新しくやったこと、勉強したことを当たり前感覚に書けると良いなと思っていたのですが、
メンバーを絞って習慣化したことで書きやすくなり、その内容を新しいメンバーが見て追記し、、という良い循環が生まれています。

継続すること

定例会議とtrac、これ自体はとても小さいことですが、1年間継続してきたことで良いサイクルが生まれてきました。
忙しくなってくるとこれら以外にも優先順位が高いものが生まれてくるのですが、
そこで意義を見返して、適宜コンパクトにまとめたり意義に合わないものを削いできたことでブラッシュアップされてきたような気がします。


YAPC::Asia2009でうらやましがる→勉強会に行くように

YAPC::Asiaでメンバーが発表させて頂いているのを聞いて、うらやましくって、
2009年後半からは勉強会に積極的に参加させて頂くようになりました。
普段プログラムは書かせてもらえないので、負い目を感じますし、わからないことも多いですが
積極的に恥をさらしに行くんだと思うと、変な気負いがなくなって楽にさせて頂いています。


基本的に、チーム内やプロジェクト内に問題がなければマネージャの負担は減るわけなので、
来年は、良いチーム、良いプロジェクトになるようにがんばっていって、
空き時間をいっぱい作って、いっぱいプログラミングできるようになりたいです!



今年ももうあと数分で終わりますね!
周りのみなさんのおかげで本当に楽しく充実した時間を過ごすことができました。1年間ありがとうございました。

まだまだ足りないところばかりですが><また来年も、どうぞよろしくお願いいたします!!

UnixBenchでベンチマークをとってみる

会社からデスクトップPC+24.1inchディスプレイもらった!!わーい!

Core i7のメモリ8GB!!すごい!
雑用係なのにこんなプレゼントもらってすみません><。。
せっかく頂いたものなのでF12をいれてUnixBenchとってみました。

UnixBenchでベンチマークをとる

googlecodeからダウンロードして展開します。

グラフィックテストはしないので、MakeFileを修正します。46行目をコメントアウト

 46 #GRAPHIC_TESTS = defined

あとはRunするだけ。

./Run

結果は以下のとおりでした。

                                                                                                                                              • -
Benchmark Run: 土 12月 26 2009 09:37:52 - 10:06:06 8 CPUs in system; running 1 parallel copy of tests Dhrystone 2 using register variables 27238941.7 lps (10.0 s, 7 samples) Double-Precision Whetstone 3349.2 MWIPS (10.0 s, 7 samples) Execl Throughput 2437.5 lps (29.9 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 518330.8 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 135950.5 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 1467674.4 KBps (30.0 s, 2 samples) Pipe Throughput 1133356.9 lps (10.0 s, 7 samples) Pipe-based Context Switching 318292.0 lps (10.0 s, 7 samples) Process Creation 9577.0 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 6068.7 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 2682.0 lpm (60.0 s, 2 samples) System Call Overhead 1736366.4 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 27238941.7 2334.1 Double-Precision Whetstone 55.0 3349.2 609.0 Execl Throughput 43.0 2437.5 566.9 File Copy 1024 bufsize 2000 maxblocks 3960.0 518330.8 1308.9 File Copy 256 bufsize 500 maxblocks 1655.0 135950.5 821.5 File Copy 4096 bufsize 8000 maxblocks 5800.0 1467674.4 2530.5 Pipe Throughput 12440.0 1133356.9 911.1 Pipe-based Context Switching 4000.0 318292.0 795.7 Process Creation 126.0 9577.0 760.1 Shell Scripts (1 concurrent) 42.4 6068.7 1431.3 Shell Scripts (8 concurrent) 6.0 2682.0 4470.1 System Call Overhead 15000.0 1736366.4 1157.6 ======== System Benchmarks Index Score 1200.3
                                                                                                                                              • -
Benchmark Run: 土 12月 26 2009 10:06:06 - 10:34:28 8 CPUs in system; running 8 parallel copies of tests Dhrystone 2 using register variables 123625220.3 lps (10.0 s, 7 samples) Double-Precision Whetstone 22497.8 MWIPS (9.9 s, 7 samples) Execl Throughput 19358.9 lps (29.9 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 442342.6 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 116750.0 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 1478120.1 KBps (30.0 s, 2 samples) Pipe Throughput 4699885.7 lps (10.0 s, 7 samples) Pipe-based Context Switching 1362642.7 lps (10.0 s, 7 samples) Process Creation 72309.0 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 25468.3 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 3627.0 lpm (60.1 s, 2 samples) System Call Overhead 8168509.5 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 123625220.3 10593.4 Double-Precision Whetstone 55.0 22497.8 4090.5 Execl Throughput 43.0 19358.9 4502.1 File Copy 1024 bufsize 2000 maxblocks 3960.0 442342.6 1117.0 File Copy 256 bufsize 500 maxblocks 1655.0 116750.0 705.4 File Copy 4096 bufsize 8000 maxblocks 5800.0 1478120.1 2548.5 Pipe Throughput 12440.0 4699885.7 3778.0 Pipe-based Context Switching 4000.0 1362642.7 3406.6 Process Creation 126.0 72309.0 5738.8 Shell Scripts (1 concurrent) 42.4 25468.3 6006.7 Shell Scripts (8 concurrent) 6.0 3627.0 6044.9 System Call Overhead 15000.0 8168509.5 5445.7 ======== System Benchmarks Index Score 3657.0

前のPCでF12入れたときの結果が338.5だっただけに超すごい><ほぼ10倍!