[#33948] Schedule for the 1.8.7 release — "Akinori MUSHA" <knu@...>
Hi, developers,
[#33955] --encoding affects script encoding — sheepman <sheepman@...>
こんばんは sheepman です。
なかだです。
[#33962] Ruby1.9.0でのインタプリタ組み込みについての質問 — Masayuki Yamaguchi <Yamaguchi.Masayuki@...>
山口と申します。
[#33966] Re: [ruby-cvs:22881] Ruby:r15644 (trunk): * test/ruby/test_m17n_comb.rb (TestM17NComb::test_str_chomp): test — Tanaka Akira <akr@...>
In article <200802291457.m1TEv6nh008515@ci.ruby-lang.org>,
まつもと ゆきひろです
[#33974] Test::Unit::Collector::Dirがtest_*.rb以外集めてくれない — "Ken Date" <itacchi@...>
こんにちは、伊達です。
[#33983] Re: [ruby-cvs:22913] Re: Ruby:r15674 (trunk): * gc.c (add_heap): sort heaps array in ascending order to use — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
In article <E1JWAV5-0001MG-9W@x61.netlab.jp>,
[#34011] Should --verbose be equal to -v ? — Yugui <yugui@...>
Yuguiです。
まつもと ゆきひろです
西山和広です。
Yuguiです。
[#34020] MurmurHash problem — Nobuyoshi Nakada <nobu@...>
なかだです。
[#34030] uint32_t — KIMURA Koichi <kimura.koichi@...>
木村です。
[#34037] Ruby performance gains on SPARC — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#34067] Array#take,take_while,drop,drop_whlie — "Yusuke ENDOH" <mame@...>
遠藤と申します。
[#34068] lgamma_r requires _REENTRANT on Solaris — "Yusuke ENDOH" <mame@...>
遠藤と申します。
[#34077] 異なるエンコーディングだと同じバイト列でも==にならない件 — rubikitch@...
るびきちです。
[#34086] extend spawn to change attributes of child process. — Tanaka Akira <akr@...>
spaen, system, exec, IO.popen で、起動する子プロセスの属性を
[#34093] 拡張ライブラリ初期化中でのmodule_eval — Kouhei Sutou <kou@...>
須藤です。
[#34095] (再送) Cygwin で Resolv.getaddress が失敗する — Kouhei Yanagita <yanagi@...>
こんにちは。柳田です。
こんばんは、植田と申します。
柳田です。
[#34105] rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...>
rational と complex が組み込みになったことで、lib/mathn.rb の意義は薄
現時点で rational.rb と complex.rb を残しているのは、それが無難だから
で、かなり選択肢を絞った叩き台です。
けいじゅ@いしつかです.
原です。
> 私も Complex の組み込みは Rational とは比較にならないくらい、仕様が決め
まつもと ゆきひろです
> Mathモジュールは伝統的にlibmのラッパーであったので、それを逸
原です。
> (1) (-8)**Rational(1,2) は複素数1.0+1.7320508*i
[#34109] LP64: date.rb:321:in `convert': integer 86400000000000 too big to convert to `int' (RangeError) — Tanaka Akira <akr@...>
LP64 なマシンで test-all が動かなくなっています。
[#34144] [質問2点] C からの定数参照 & thread switching コストの低減 — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
[#34158] Complex組み込み — Masahiro TANAKA <masa16.tanaka@...>
Complexが組み込みになるそうですが、これはcomplex.rbを踏襲して、
原です。
> 今までの Complex は、complex.rb にほぼ残して、たとえば Rational 成分
原です。
> そうです。Complex が難しい、という話を書いておくと、
まつもと ゆきひろです
> |僕としては、/ 演算子の振舞いについて前向きに検討してほしいです。
まつもと ゆきひろです
> ふむ。では、/ のふるまいを
まつもと ゆきひろです
> |僕は、quo がいいと思います。
まつもと ゆきひろです
> となるようですが、別の実装として、
田中です。
> 最初に言っておきますが、気を悪くされたのならすみません。
村田です.
[#34159] ruby-trunk Marshal.dump bug — nagachika <rucila@...>
nagachika と申します。
[#34163] Array#shift/unshift の高速化 — wanabe <s.wanabe@...>
ワナベと申します。
[#34189] Re: [ruby-cvs:23106] Re: Ruby:r15866 (trunk): * numeric.c (num_quo): should convert its operand to Rational. — Tadayoshi Funaba <tadf@...>
間違って送ったので、再送。
> > > Log:
[ruby-dev:34144] [質問2点] C からの定数参照 & thread switching コストの低減
永井@知能.九工大です.
すみませんが,2点質問させてください.
まず1点目です.
---[質問1]-----------------------------------------------------
C 言語で書かれた関数に "::AAA::BBB::CCC" という形で
定数/クラス/モジュールのパス文字列が渡された時,
対象となるオブジェクトを得るための低コストな実装は
どのように書くべきでしょうか.
ただし,対象となるオブジェクトはこの検索の際に
autoload で読み込まれる可能性があるため,
autoload の機構はきちんと働く必要があります.
また,定数が存在しないなどの例外も捕捉せねばなりません.
単純な方法なら,rb_eval_string_protect(str, &state) かなとは
思うのですが...
----------------------------------------------------------------
次に2点目です.
---[質問2]-----------------------------------------------------
thread A から thread B に処理を依頼し,その結果を thread A で
受け取りたいという場合についてです.
thread B は複数の thread からの依頼を受け付けるため,
thread A からの依頼を処理した後は速やかに別の依頼を
処理する必要があります.
また,thread B には local に処理すべき仕事
(アプリケーション全体で見ても比較的優先順位が高い) もあります.
このような場合の実行コストをうまく低減して,
アプリケーション全体の速度低下を抑えるための
うまい方法はないでしょうか.
thread 切り替えの頻度を下げると,
処理依頼に対する待ち時間が増加して低速化します.
かといって,頻度を上げると thread 切り替えのコストが大きくて
遅くなってしまいます.
thread B には優先順位が高めの local の仕事はありますが,
処理のない「暇」な時間も頻繁に発生します.
しかしその度に他の thread に処理を譲ってしまうと,
優先順位が高めの local の仕事への応答性が低下し,
アプリケーション全体の動作が鈍くなってしまいます.
なお,local の仕事が発生したかどうかを
外部からモニターすることはできません.
Ruby が Giant Lock での thread 切り替え動作である以上は,
こうした速度低下は避けようがないことなのでしょうか.
----------------------------------------------------------------
この2点目は,ご想像の通り,Ruby/Tk の eventloop の処理の話です.
あるスクリプトの実行環境を包み込むために
thread でくるんで実行するようにした場合,
eventloop の thread との間に激しいメッセージの応酬が行われて
目に見えて処理速度が低下してしまいます.
GUI の構築の際には,依頼→戻値受け取り→戻値に基づいての依頼
というのが頻繁に行われるために顕著に遅くなります.
GUI の構築が完了してしまえば,通常はスクリプト側からの
処理依頼は激減するので,速度低下はほぼ問題にならないようです.
現在の eventloop では,連続処理数 (処理がない時には多く増加させる) と
タイマーとの組合わせで,切り替えのタイミングを
スクリプトからある程度コントロールできるようにはしていますが,
どのような値にすべきかの根拠があるわけでもなく,
場当たり的な対応に過ぎないことが気になっています.
ですので,「そうした場合はこうすべき」というのがあれば
ぜひ教えを請いたいと思っています.
よろしくお願いします.
--
永井 秀利 (九工大 知能情報)
nagai@ai.kyutech.ac.jp