[#68137] improve semantics of manpages — "Anthony J. Bentley" <anthony@...>
Hi,
1 message
2015/02/17
[#68144] Re: Future of test suites for Ruby — Anthony Crumley <anthony.crumley@...>
FYI...
4 messages
2015/02/17
[#68343] [Ruby trunk - Bug #10916] [Open] What the Ruby? SegFault? — ruby@...
Issue #10916 has been reported by why do i need this acct just to create a bug report.
5 messages
2015/02/27
[#68373] Re: [Ruby trunk - Bug #10916] [Open] What the Ruby? SegFault?
— "Martin J. Dürst" <duerst@...>
2015/03/02
> * Author: why do i need this acct just to create a bug report
[#68358] [Ruby trunk - Bug #10902] require("enumerator") scans LOAD_PATH 2x on every invocation — [email protected]
Issue #10902 has been updated by Aman Gupta.
3 messages
2015/02/28
[ruby-core:68171] Re: [Ruby trunk - Bug #10723] [PERF] bm_tread_create_join 20% slower
From:
Eric Wong <normalperson@...>
Date:
2015-02-18 10:06:56 UTC
List:
ruby-core #68171
Thanks for the info. It seems my patch changes object allocation counts enough to throw GC off for this benchmark. Having more/less threads or other objects changes the effect. But in general, thread scheduler benchmarks with many concurrenty threads are not very reliable in my experience (the mutex benchmarks are notoriously unreliable for me). I think your original bm_thread_create_join is important and relevant since only one thread is running, but scheduling hundreds/thousands of threads becomes highly unpredictable with the GVL (GVL fairness improved greatly in 1.9.3). And don't worry about not knowing C well. I only pretended to know C in the beginning. After several years, I realized I wasn't pretending :)