太りすぎは猫でもNGらしい。
« shivakenこういうの大好き。ひさしぶりに爆笑した。
bsdiffとxdeltaを比較してみた
« shivaken昨日の記事で出てきたbsdiff、実際に使ったことがなかったのだが、xdeltaよりも50%〜80%も出力する差分が小さいらしい。
ruby-1.8.7-p160とruby-1.8.7-p174を対象に比べてみる。
まず、元のサイズを調べる。
ruby-p160 949579 bytes (約928KB)
ruby-p174 950091 bytes (約928KB)
じゃあ、bsdiff、xdeltaで差分を作ってみよう。
これはスゴいよ！確かにbsdiffで作った差分はxdeltaによる差分の15%程でしかない。念のため、復元をして、md5をチェックしてみる。
しかし、このbsdiffの10倍の性能を誇るGoogleの技術、スゴすぎる。
ruby-1.8.7-p160とruby-1.8.7-p174を対象に比べてみる。
まず、元のサイズを調べる。
ruby-p160 949579 bytes (約928KB)
ruby-p174 950091 bytes (約928KB)
じゃあ、bsdiff、xdeltaで差分を作ってみよう。
$ bsdiff ruby-p160 ruby-p174 ruby-p160-p174.bsdiff
→ ruby-p160-p174.bsdiff 22152 bytes (約22KB)
$ xdelta delta ruby-p160 ruby-p174 ruby-p160-p174.xdelta
→ ruby-p160-p174.xdelta 152538 bytes (約148KB)
これはスゴいよ！確かにbsdiffで作った差分はxdeltaによる差分の15%程でしかない。念のため、復元をして、md5をチェックしてみる。
$ bspatch ruby-p160 ruby-p174_by_bsdiff ruby-p160-p174.bsdiff
$ xdelta patch ruby-p160-p174.xdelta ruby-p160 ruby-p174_by_xdelta
$ md5sum ruby-p174 ruby-p174_by_bsdiff ruby-p174_by_xdelta
41c7edda80df89b7ca3db108b65b255c ruby-p174
41c7edda80df89b7ca3db108b65b255c ruby-p174_by_bsdiff
41c7edda80df89b7ca3db108b65b255c ruby-p174_by_xdelta
と、ちゃんと差分からruby-p174を復元できる。
$ xdelta patch ruby-p160-p174.xdelta ruby-p160 ruby-p174_by_xdelta
$ md5sum ruby-p174 ruby-p174_by_bsdiff ruby-p174_by_xdelta
41c7edda80df89b7ca3db108b65b255c ruby-p174
41c7edda80df89b7ca3db108b65b255c ruby-p174_by_bsdiff
41c7edda80df89b7ca3db108b65b255c ruby-p174_by_xdelta
しかし、このbsdiffの10倍の性能を誇るGoogleの技術、スゴすぎる。
初代ガンダム無料放送byバンダイ
« shivakenガンダムの無料放送が今日7/20から始まっている。
初代ガンダムを全話、一日一話のペースで見れるらしい。これはすごい。
ブログに張り付けれるっとのことで、コードも取得したけど
初期化に時間がかかりすぎるのでやめた。
実物大ガンダムといい、30周年にふさわしい。
今年はほんとにガンダムの年だ。
初代ガンダムを全話、一日一話のペースで見れるらしい。これはすごい。
ブログに張り付けれるっとのことで、コードも取得したけど
初期化に時間がかかりすぎるのでやめた。
実物大ガンダムといい、30周年にふさわしい。
今年はほんとにガンダムの年だ。
Googleはスピード狂である。
« shivakenGoogleが最新の実行ファイルのアップデート方法を発表した。
[google.com]、[sourceforge.jp]、[mycom.co.jp]
Chromeのアップデートの際に旧版と最新版の差分をこれまでは純粋にバイナリのdiffとして配信していた。新方式に移行することで例えば190.1->190.4への移行に際して以下のようにデータ量を1/10程に出来るという。
ではこの新方式とはいったいなんであろう？
Google Chromeの公式ブログには以下のような説明がある。
まず、サーバ側では旧版、新版ともに逆アセンブルを行い、実行ファイルにコンパイルされる直前のデータに起こしてから、その差分を転送する。
クライアント側では手元にある旧版を逆アセンブルし、ダウンロードしたパッチをあて、アセンブルする。
最適化が施され、大きくなりがちなバイナリ差分よりも、その手前のデータの方が
差分が小さくなるというのは納得しやすい。
デメリットはクライアント側に逆アセンブル、アセンブルを行うプログラムを仕込まなければならないことと、その実行時間がせっかく短縮したダウンロード時間を相殺するのではないかということくらい。
これくらい複雑な仕組みを導入するに足る、転送量が減るということは大きなメリットだ。Chromeはバックグラウンドでアップデートを行うため、CPUを使うのはいいが、ダウンロードは帯域使用によってユーザの環境をも圧迫する。
ところで、Linuxのアップデートに使われるyumにはそのような差分アップデート機能はない。常にフルアップデートだ。そろそろどうにかならないものか。
そういえば7zipと同じ圧縮方式のxzをGNUが採用したらしい。
ringサーバにはcoreutils-7.4.tar.xzがあるとのこと。
coreutils-7.4.tar.gz - 9708910B
coreutils-7.4.tar.xz - 4048924B
gzipの半分以下とは…。
とにかく、Googleのスピード狂、チューニング狂っぷりには執念を感じるほどだ。Page Speedもある。そういった部分、単純に尊敬する。
[google.com]、[sourceforge.jp]、[mycom.co.jp]
Chromeのアップデートの際に旧版と最新版の差分をこれまでは純粋にバイナリのdiffとして配信していた。新方式に移行することで例えば190.1->190.4への移行に際して以下のようにデータ量を1/10程に出来るという。
| Full update | 10,385,920 |
| bsdiff update | 704,512 |
| Courgette update | 78,848 |
ではこの新方式とはいったいなんであろう？
Google Chromeの公式ブログには以下のような説明がある。
server:
asm_old = disassemble(original)
asm_new = disassemble(update)
asm_new_adjusted = adjust(asm_new, asm_old)
asm_diff = bsdiff(asm_old, asm_new_adjusted)
transmit asm_diff
client:
receive asm_diff
asm_old = disassemble(original)
asm_new_adjusted = bspatch(asm_old, asm_diff)
update = assemble(asm_new_adjusted)
※ここでoriginalとは旧バージョンのことと思われる。
asm_old = disassemble(original)
asm_new = disassemble(update)
asm_new_adjusted = adjust(asm_new, asm_old)
asm_diff = bsdiff(asm_old, asm_new_adjusted)
transmit asm_diff
client:
receive asm_diff
asm_old = disassemble(original)
asm_new_adjusted = bspatch(asm_old, asm_diff)
update = assemble(asm_new_adjusted)
※ここでoriginalとは旧バージョンのことと思われる。
まず、サーバ側では旧版、新版ともに逆アセンブルを行い、実行ファイルにコンパイルされる直前のデータに起こしてから、その差分を転送する。
クライアント側では手元にある旧版を逆アセンブルし、ダウンロードしたパッチをあて、アセンブルする。
最適化が施され、大きくなりがちなバイナリ差分よりも、その手前のデータの方が
差分が小さくなるというのは納得しやすい。
デメリットはクライアント側に逆アセンブル、アセンブルを行うプログラムを仕込まなければならないことと、その実行時間がせっかく短縮したダウンロード時間を相殺するのではないかということくらい。
これくらい複雑な仕組みを導入するに足る、転送量が減るということは大きなメリットだ。Chromeはバックグラウンドでアップデートを行うため、CPUを使うのはいいが、ダウンロードは帯域使用によってユーザの環境をも圧迫する。
ところで、Linuxのアップデートに使われるyumにはそのような差分アップデート機能はない。常にフルアップデートだ。そろそろどうにかならないものか。
そういえば7zipと同じ圧縮方式のxzをGNUが採用したらしい。
ringサーバにはcoreutils-7.4.tar.xzがあるとのこと。
coreutils-7.4.tar.gz - 9708910B
coreutils-7.4.tar.xz - 4048924B
gzipの半分以下とは…。
とにかく、Googleのスピード狂、チューニング狂っぷりには執念を感じるほどだ。Page Speedもある。そういった部分、単純に尊敬する。
ノイズキャンセリングヘッドホンの威力
« shivaken車、飛行機、電車の中に溢れる騒音を消すことが出来たら、
どんなに快適だろうか？
実は音に逆相の音をぶつけると消える。波だからだ。
簡単な理屈。でも、これを実際にやるのは難しい。
まず、マイクなどで実際に存在している騒音を捉え、そのデータを元に打ち消す音を作ることになるが、それだけでは正確にキャンセルできない。測定する場所と音を聞く場所が違うからだ。それに音はそんな処理をしている内にもどんどん進んでしまう。
そんなわけで、なかなか実現しないと思われていたこの技術も実はそろそろ商品になって普通に売られるようになった。まずはヘッドホンタイプからだったが、最近カナル型のイヤホンでも出ている。しかも手を出せない値段ではない。
ちょうど6月末にSONYの新商品NC33が出たので買ってみた。
※7/7現在、Amazonで6,811円。
電車の中はもちろん、人の声でガヤガヤしたところ、歩く音が反響するような建物内など、いろんな所でノイズをフーッと消してくれる。突発的な音はある程度残るけど、ずーっと続く音をしっかり捉えて、まったく感じさせなくしてくれる。こうなると、音楽をしっかり聴くことが出来るのはもちろん、騒音がないことで信じられないくらいリラックス出来る。付け加えるとこのNC33、そこそこ中低域も出ていい音。
家の外で音楽を聴くなら、間違いなくお薦めだ。
どんなに快適だろうか？
実は音に逆相の音をぶつけると消える。波だからだ。
簡単な理屈。でも、これを実際にやるのは難しい。
まず、マイクなどで実際に存在している騒音を捉え、そのデータを元に打ち消す音を作ることになるが、それだけでは正確にキャンセルできない。測定する場所と音を聞く場所が違うからだ。それに音はそんな処理をしている内にもどんどん進んでしまう。
そんなわけで、なかなか実現しないと思われていたこの技術も実はそろそろ商品になって普通に売られるようになった。まずはヘッドホンタイプからだったが、最近カナル型のイヤホンでも出ている。しかも手を出せない値段ではない。
ちょうど6月末にSONYの新商品NC33が出たので買ってみた。
※7/7現在、Amazonで6,811円。
電車の中はもちろん、人の声でガヤガヤしたところ、歩く音が反響するような建物内など、いろんな所でノイズをフーッと消してくれる。突発的な音はある程度残るけど、ずーっと続く音をしっかり捉えて、まったく感じさせなくしてくれる。こうなると、音楽をしっかり聴くことが出来るのはもちろん、騒音がないことで信じられないくらいリラックス出来る。付け加えるとこのNC33、そこそこ中低域も出ていい音。
家の外で音楽を聴くなら、間違いなくお薦めだ。
RSS