タグ

2016年2月6日のブックマーク (6件)

  • Yajlって速いの? - Qiita

    require "benchmark" require "yajl" require "json" BENCH_TIMES = 100000 hash = { s:"string", ss:["strings"] * 3, n:10, ns:(0..100).to_a.sample(20) } json = hash.to_json Benchmark.bmbm do |bm| bm.report("encode with yajl") do BENCH_TIMES.times do encoder = Yajl::Encoder.new encoder.encode(hash) end end bm.report("encode with yajl 2") do BENCH_TIMES.times do Yajl::Encoder.encode(hash) end end bm.repo

    Yajlって速いの? - Qiita
  • Rubyのスレッド周りの話 - Qiita

    Rubyのスレッド周りを追ってみた。 最も効率が良いスレッドモデルは結論出ないんじゃないかと(物理的な環境、何を実装するか、性能以外の面でメンテナの問題とか)。 Ruby1.8系 「グリーンスレッド」 Ruby1.8ではOSではなくて仮想マシン(VM)上で実装されたマルチスレッドシステムを採用した。 これを「グリーンスレッド」という。カーネルでスレッドがサポートされていなくても動作する。 つまり、OSに依存せずにマルチスレッドを実現する。 メリット スレッドの起動、並列化の性能 Linux のネイティブスレッドの性能を上回る。つまり、ネイティブスレッドより低コストで起動、並列化を行える。 起動については、独自のアドレス空間を確保する必要がなく、わずかな量の仮想メモリを取得するだけ。 並列化については、カーネルレベルとユーザレベルの切り替えが必要ないことなど。 さまざまなOS間で移植が楽 デ

    Rubyのスレッド周りの話 - Qiita
  • RubyにおけるThreadとForkの速度比較 - while(true) ;

    こんばんは、kazunyaaanです。今回は並列処理の速度比較を行います。 (個人的に専門が数値計算で、MPI等でごりごり並列化をおこなっているのでとてもわくわくです(笑)) 前回の記事で、RubyにおけるThreadは多くの場合にて "並行処理となる" ことに簡単にふれてみました。 今回は、Threadだけでなく、Forkも含めた、 Rubyでのマルチスレッドおよびマルチプロセスのプログラムとその速度比較を行ってみたいとおもいます。 まず実験環境 今回は贅沢に Intel Xeon E5-2690 v3 @ 2.60GHz (Turbo Boost時 3.5) 12Core × 1 DDR4 ECC 16GByte @ 2133MHz × 4 の計算機サーバを使って、CentOS7、Ruby 2.2.0 の実験環境を用意しました。 コード 今回は、 Normal : 普通に書いた場合 T

    azumakuniyuki
    azumakuniyuki 2016/02/06
    高速化を目的としたThreadクラスでのマルチスレッドは使い所がかなり限定される
  • Rubyで並列処理が簡単にできるgem parallel - 酒と泪とRubyとRailsと

    require 'rubygems' require 'parallel' require 'open-uri' require 'digest/md5' urls = [ 'http://farm4.staticflickr.com/3052/3086132328_e2041be795.jpg', 'http://farm7.staticflickr.com/6053/6312937936_cebaf2feb9.jpg', 'http://farm1.staticflickr.com/54/131841577_0e67642c02.jpg', 'http://farm3.staticflickr.com/2293/2266151759_058e732577.jpg' ] Parallel.each(urls, in_threads: 2) {|url| puts "start downl

  • マルチスレッド/プロセスまとめ(Ruby編) - Qiita

    知識 プロセス プログラムの実行単位 固有のメモリ空間を持つ(リソースを共有しない) マルチプロセスの場合、物理/仮想メモリ領域間のアドレス解決のオーバーヘッドが高い。 スレッド プロセスの実行単位 共通のメモリ空間を持つ(リソースを共有する) マルチスレッドの場合、物理/仮想メモリ領域間のアドレス解決は発生しない。 ユーザースレッド ユーザー空間(アプリケーションが利用するメモリ空間)を利用 1つのプロセスに複数のスレッドがあっても、1つのスレッドしか実行されない。 OSカーネルを介さないスレッド切り替えのため、スレッド切り替えに伴うオーバーヘッドが少ない。 仮想VM上で実行されるスレッドをグリーンスレッドと呼ぶ。 カーネルスレッド カーネル空間(カーネルが利用するメモリ空間)を利用 1つのプロセスに複数のスレッドがある場合、同時に複数(CPUコア数分)のスレッドを実行できる。 OS

    マルチスレッド/プロセスまとめ(Ruby編) - Qiita
    azumakuniyuki
    azumakuniyuki 2016/02/06
    いずれSisimaiの高速化を検討するときに参考になりそう
  • bounceHammer をインストールして送信エラーメール(バウンスメール)を分類する | バシャログ。

    アップルファンならだいたい注目している年1回のイベントWWDCでiOS 8とOS X Yosemiteの発表がありましたね。あまり詳細を見てないのですがiOS/OS Xアプリ用の新しいプログラミング言語Swiftと、サードパーティ製IMEの登場に注目してます。 今日は、送信エラーメール対策が必要になったときのためにbounceHammerをインストールして試してみましたので概要とインストールレポートとしてまとめます。 bounceHammer の概要 bounceHammer はメールを送信したが相手サーバから戻ってきたメール(バウンスメール)を解析・分類するソフトウェアです。株式会社キュービックルートさんがリリースしているOSSで日の携帯キャリアからのバウンスメールにも対応しています。 ライセンスはGNU GPL v2 または Artistic License の択一ライセンスです。

    bounceHammer をインストールして送信エラーメール(バウンスメール)を分類する | バシャログ。