[#90865] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been reported by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90877] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been updated by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90895] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
4 messages
2019/01/05
[#90896] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707))
— Takashi Kokubun <takashikkbn@...>
2019/01/05
Thanks to explain that.
[#91200] [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout — glass.saga@...
Issue #15553 has been reported by Glass_saga (Masaki Matsushita).
4 messages
2019/01/21
[#91289] Re: [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout
— Eric Wong <normalperson@...>
2019/01/26
glass.saga@gmail.com wrote:
[ruby-core:90995] [Ruby trunk Feature#6256][Feedback] Slightly improve ruby_qsort performance
From:
mame@...
Date:
2019-01-10 13:51:49 UTC
List:
ruby-core #90995
Issue #6256 has been updated by mame (Yusuke Endoh). Status changed from Assigned to Feedback A volunteer is welcome: update the patch for trunk, test, perform re-experiment, etc. ---------------------------------------- Feature #6256: Slightly improve ruby_qsort performance https://bugs.ruby-lang.org/issues/6256#change-76215 * Author: MartinBosslet (Martin Bosslet) * Status: Feedback * Priority: Normal * Assignee: MartinBosslet (Martin Bosslet) * Target version: ---------------------------------------- Hi all, I think I may have found a way to slightly improve the performance of ruby_qsort. Quicksort running time is slightly decreased if the recursion depth (or in our case, rather iteration depth) is bounded by leaving sub problems larger than or equal to some cutoff bound k untouched and running Insertion Sort on these small sub problems to finalize the sorting. I experimented with this, but to no avail, only marginal improvements if any. Then I remembered that instead of running Insertion Sort on each sub problem, it is equivalent in terms of running time to run one single Insertion Sort on the whole nearly sorted array as a final step. And in practice, this turns out to run faster than without the optimization. In my tests, execution time dropped to about 95% on average with an optimal cutoff (64-bit Fedora 15) [1]. Now this ain't the world - but it is faster, and I could very well imagine that there is still room for improving my code. In my tests, the optimal cutoff seems to be ~13 for Integers and ~8 for Strings and Symbols. I imagine the more costly the comparisons, the lower will be the optimal cutoff. I've tested only on 64 Bit yet, but I will do so for 32 Bit, too. If it turns out that this runs faster regardless of the architecture in use, with an optimal cutoff yet to be determined, do you think this would be a useful addition? I have attached a C extension for testing and discussing, it's mostly a one-to-one copy of the code in util.c. I just added mmassign and insertion_sort plus the few lines that respect the cutoff in rqsort (had to rename it, otherwise it would collide with the real "ruby_qsort"). -Martin [1] https://github.com/emboss/hybridsort/blob/master/hybrid-sort-results ---Files-------------------------------- hybridsort.tar.gz (3.93 KB) rubyqisort.patch (5.04 KB) rubyqisort4.patch (3.66 KB) rubyqisort5.patch (3.69 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>