タグ

ブックマーク / imaya.blog.jp (9)

  • zlib.js の Inflate 実装を JSX-lang に移植しました : document

    5月1 zlib.js の Inflate 実装を JSX-lang に移植しました はじめに JSX 速いという話を聞いたので、zlib.js を移植したらどうなるのか興味があったので試しました。 https://github.com/imaya/zlib.jsx お詫び JSXがリリースされた直後に少し触ってみたのですが、最初期のバージョンでは素のJSとの連携が取りにくかったので、自分の用途には少しマッチしないなと敬遠気味でした。 その認識は最近まで続いていたのですが、現在は export なども出来るようになっているのでライブラリなんかも簡単に作れるようになってます。 (おそらく実装されたのは 2013-04-30 にリリースされた v0.9.27 ?) 何度か飲み会などで「素のJSとの連携が取りにくいからなー」とか言ってしまって誤解を与えてしまったのをここでお詫びします。 (exp

    gfx
    gfx 2014/05/01
  • Emscripten によって生成された asm.js 対応コードは本当に人間が書いたコードより速いのか? : document

    12月2 Emscripten によって生成された asm.js 対応コードは当に人間が書いたコードより速いのか? はじめに 先日、いつものように Twitter 監視業務に勤しんでいたところ、下記のような発言を見かけました。 asm.jsは対応してないブラウザでは読めないし遅いって説明をされることが多いけど、ams.jsはJavaScriptの中で高速実行可能なものだけを使って更に少し制約を加えて底上げをしてるものなので、多のブラウザであっても普通に人間が書いたコードよりも速いっすよ— dynamis (でゅなみす) (@dynamitter) 2013, 11月 29 なるほど、機械によって生成された asm.js 対応のコードはどんなブラウザでも速いよという主張です。 自分は JavaScript で高速に動作するように注意して書いた zlib.js というのを作っていたので、zl

    gfx
    gfx 2013/12/02
    “asm.js が有効になっていないブラウザ(Chrome, Safariなど)では zlib.js が有利な結果になり、asm.js が有効になっているブラウザ(Firefox)では zlib-asm が有利な結果となりました”
  • Zopfli を Emscripten で移植した際の備忘録 : document

    3月10 Zopfli を Emscripten で移植した際の備忘録 Emscripten で Zopfli を移植した際のメモを残します。 思ったより簡単に使えましたが、知らないとハマることも結構多かったです。 導入 自分の環境(Mac)では以下のような感じでやれば OK でした。この辺りは情報が豊富なので適当です。 JS Engine は NodeJS だけで良いっぽいです 必要な環境は homebrew 環境なら brew install llvm だけ? あとは emscripten を clone するだけ clang, clang++ の位置が llvm-link と違う場合はシンボリックリンクを張るなどして合わせる 使い方 C プログラムから JS へ変換 $ emcc *.c -o hoge.js ライブラリの場合 通常だとリンク時最適化(LTO)によりエントリポイント(

  • ブラウザのデコード機能を利用した Shift JIS などの読み込み : document

    3月12 ブラウザのデコード機能を利用した Shift JIS などの読み込み はじめに JavaScript でバイナリから文字列を取り出したら Shift JIS だったなんてことよくありますよね。 そういう文字列もさっと表示したいことがあります。 読み込む方法はいくつかある これらの文字列を読み込む方法はいくつかあって、自分が把握してるだけでも以下のものがあります。 Shift JIS と UTF-16 の対応表をつくる ぽりごんさんの文字コード変換ライブラリ Blob, File API を使って読み込む 右京さんの javascriptのnative APIで任意の文字コードからutf8に変換 script, Data URL を使って変換 1, 2 の方法についてはそれぞれ解説や実装があるのですが、3 の方法については見当たらなかったので説明してみます。 準備 念のため 2 段

  • Zopfli を Emscripten をつかって JavaScript に移植しました : document

    3月9 Zopfli を Emscripten をつかって JavaScript に移植しました はじめに Zopfli が公開されてから zlib.js の Deflate 処理と比較したいなーと思っていたので、 Emscripten を使って JavaScript に移植してみました。 Emscripten を使うのは初めてのためいろいろ手間取りましたが、とりあえず動作するようになったのでご報告です。 zopfli.js というわけで、JavaScript に移植したものを以下の場所で公開しています。 もし良ければご利用ください。 使い方は zlib.js と似せています。 https://github.com/imaya/zopfli.js zlib.js を使って簡単なテストも行っていますので使用できないほどのバグはないかと思いますが、何かあればお知らせください。 デモ せっかく移

  • Zopfli を使って PNG の再圧縮を行ってみた : document

    3月1 Zopfli を使って PNG の再圧縮を行ってみた はじめに Google から Deflate 互換の圧縮アルゴリズム実装 Zopfli が公開されました。 「Deflate 互換ってどういうこと?」って方もいると思いますので簡単に説明します。 符号アルゴリズムは同じ(LZSS + Huffman符号) RFC では、 LZSS はこんな感じで Huffman 符号はこんな感じと大体のやり方が書かれている RFC に書かれている方法とは異なる手法でより最適な LZSS + ハフマン符号化を行うのが今回の Zopfli Kflate との比較 PNG の圧縮界隈では、一部で Kflate と呼ばれる Deflate 互換実装が圧縮効率の良いものが知られています。 (この実装は PNGOUT として PNGGauntlet や ImageOptim で使用されている) 今回は Im

    Zopfli を使って PNG の再圧縮を行ってみた : document
  • jsPerf, JSPerfView を使った、JavaScript コードのベンチマーク計測とブログなどで計測結果を利用する方法 : document

    8月17 jsPerf, JSPerfView を使った、JavaScript コードのベンチマーク計測とブログなどで計測結果を利用する方法 jsPerf とは JavaScript のコードスニペットに対してベンチマークを計測するサービスです。 一般的に、コードの速度を計測する際は console.time, console.timeEnd を使う事が多いと思いますが、 実行するたびに結果がブレたり、短い処理では正確な比較ができなかったりします。 jsPerf では何度か同じ処理を実行して最終的に一秒間に何回実行できたかをスコアにするので、実行時間が 1ms より小さい処理でも計測できたり、ブレがあっても大体のスコアが分かったりします。 このスコアを計算する部分は Benchmark.js というライブラリで書かれていますので、サーバサイドの JavaScript コードの速度を計測する

    jsPerf, JSPerfView を使った、JavaScript コードのベンチマーク計測とブログなどで計測結果を利用する方法 : document
  • JavaScript で書かれた ZLIB の伸張速度比較 : document

    8月15 JavaScript で書かれた ZLIB の伸張速度比較 はじめに 最近、Inflate 実装のチューニングを行うことが多かったので、現状でどの程度の速度が出ているか把握するため、他の実装と比較してみました。 比較に使用した ZLIB ライブラリ 今回の比較では、以下のライブラリの存在を確認しています。 uncompress.js に関しては、今回入手できなかったため比較対象からはずしています。 名前 Input Output 名前空間 ライセンス ファイルサイズ pdf.js Uint8Array, Array, ArrayBuffer(*) Uint8Array FlateStream, Stream, DecodeStream, etc... MIT stream.js: 80,349 zlib-js String String ZLIB zlib zlib-inflat

  • JavaScript のビット演算子に unsigned を期待してはいけない : document

    2月4 JavaScript のビット演算子に unsigned を期待してはいけない はじめに ビット演算を利用するケースでは unsigned を期待することが多いと思うのですが JavaScript ではその期待は捨てたほうが良いです。(ただし >>> 演算子を除く) ここではその具体例と対策、簡単な説明をしていきたいと思います。 具体例 ではさっそく、例として 0x12345678 ^ 0xFFFFFFFF を見てみましょう。 (なぜ 32-bit かというと JavaScript のビット演算は 32-bit で行われるからです。) 0x12345678 は 2 進数表記にすると 0001 0010 0011 0100 0101 0110 0111 1000 になります。 これを XOR 0xFFFFFFFF で反転させるのですから、 下記のように計算して期待する値は 0xEDC

  • 1