https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112015-01-09T09:40:09ZRuby Issue Tracking SystemRuby master - Bug #10723: [PERF] bm_tread_create_join 20% slowerhttps://redmine.ruby-lang.org/issues/10723?journal_id=508832015-01-09T09:40:09Ztgxworld (Guo Xiang Tan)gxtan1990@gmail.com
<ul></ul><p>Opps it should bm_vm_thread_create_join.rb</p> Ruby master - Bug #10723: [PERF] bm_tread_create_join 20% slowerhttps://redmine.ruby-lang.org/issues/10723?journal_id=510482015-01-16T10:08:34Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>Related, but I do not read Japanese:<br>
<a href="https://bugs.ruby-lang.org/issues/10297" class="external">https://bugs.ruby-lang.org/issues/10297</a></p> Ruby master - Bug #10723: [PERF] bm_tread_create_join 20% slowerhttps://redmine.ruby-lang.org/issues/10723?journal_id=510662015-01-17T03:17:28Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>Minor micro-optimization, I could not find much improvement while<br>
keeping functionality:</p>
<p><a href="http://80x24.org/spew/m/thread-microopt-v1%40r49282.txt" class="external">http://80x24.org/spew/m/thread-microopt-v1%40r49282.txt</a></p>
<p>target 0: 2.1.5 (ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-linux]) at "/home/ew/ruby-2.1/bin/ruby"<br>
target 1: trunk (ruby 2.3.0dev (2015-01-16 trunk 49282) [x86_64-linux]) at "/home/ew/rrrr/b/i/bin/ruby"<br>
target 2: built (ruby 2.3.0dev (2015-01-16 trunk 49282) [x86_64-linux]) at "/home/ew/ruby/b/i/bin/ruby"</p>
<p>2.1.5 1.0573025540215895<br>
2.1.5 1.0493981029139832<br>
2.1.5 1.0576379200210795<br>
trunk 1.2876477020327002<br>
trunk 1.2424484699731693<br>
trunk 1.2432217099703848<br>
built 1.1531978889834136<br>
built 1.137529328931123<br>
built 1.1509092160267755</p>
<a name="Elapsed-time-10381246521-sec"></a>
<h2 >Elapsed time: 10.381246521 (sec)<a href="#Elapsed-time-10381246521-sec" class="wiki-anchor">¶</a></h2>
<p>benchmark results:<br>
minimum results in each 3 measurements.<br>
Execution time (sec)<br>
name 2.1.5 trunk built<br>
vm_thread_create_join 1.049 1.242 1.138</p>
<p>Speedup ratio: compare with the result of `2.1.5' (greater is better)<br>
name trunk built<br>
vm_thread_create_join 0.845 0.923</p> Ruby master - Bug #10723: [PERF] bm_tread_create_join 20% slowerhttps://redmine.ruby-lang.org/issues/10723?journal_id=510812015-01-18T01:55:37Znormalperson (Eric Wong)normalperson@yhbt.net
<ul><li><strong>Assignee</strong> set to <i>akr (Akira Tanaka)</i></li></ul><p>akr: any comments? I'll commit my patch in a few days, but I hope we<br>
can recover more performance. Thanks.</p> Ruby master - Bug #10723: [PERF] bm_tread_create_join 20% slowerhttps://redmine.ruby-lang.org/issues/10723?journal_id=515402015-02-18T05:31:36Ztgxworld (Guo Xiang Tan)gxtan1990@gmail.com
<ul></ul><p>Eric Wong wrote:</p>
<blockquote>
<p>akr: any comments? I'll commit my patch in a few days, but I hope we<br>
can recover more performance. Thanks.</p>
</blockquote>
<p>Hi Eric,</p>
<p>Just wanted to bring your attention to bm_vm_thread_pass_flood. <a href="http://rubybench.org/ruby/ruby/commits?result_type=vm_thread_pass_flood" class="external">http://rubybench.org/ruby/ruby/commits?result_type=vm_thread_pass_flood</a></p>
<p>before_patch: 0.079s<br>
after_patch: 0.086</p>
<p>The benchmark got slower after your patch so I thought you might be interested in knowing that. Not really a report but just to bring your attention to it since I don't know c well enough to actually understand how Ruby is implemented. Thank you! :)))</p> Ruby master - Bug #10723: [PERF] bm_tread_create_join 20% slowerhttps://redmine.ruby-lang.org/issues/10723?journal_id=515482015-02-18T10:08:40Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p>Thanks for the info. It seems my patch changes object allocation counts<br>
enough to throw GC off for this benchmark. Having more/less threads<br>
or other objects changes the effect.</p>
<p>But in general, thread scheduler benchmarks with many concurrenty<br>
threads are not very reliable in my experience (the mutex benchmarks<br>
are notoriously unreliable for me).</p>
<p>I think your original bm_thread_create_join is important and relevant<br>
since only one thread is running, but scheduling hundreds/thousands of<br>
threads becomes highly unpredictable with the GVL (GVL fairness improved<br>
greatly in 1.9.3).</p>
<p>And don't worry about not knowing C well. I only pretended to know C<br>
in the beginning. After several years, I realized I wasn't pretending :)</p> Ruby master - Bug #10723: [PERF] bm_tread_create_join 20% slowerhttps://redmine.ruby-lang.org/issues/10723?journal_id=517152015-03-01T06:04:22Zktsj (Kazuki Tsujimoto)kazuki@callcc.net
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-4 priority-default closed" href="/issues/10922">Bug #10922</a>: TracePoint#binding may return nil in Ruby 2.2</i> added</li></ul> Ruby master - Bug #10723: [PERF] bm_tread_create_join 20% slowerhttps://redmine.ruby-lang.org/issues/10723?journal_id=798672019-07-23T15:09:34Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul>