Hi, thanks for the Ok. However, moments before committing I got cold feet and started digging around; it unfortunately seems that TLS (_Thread_local) is not supported on all targets. So I'll have to copy-paste some configure magic from libgomp/libjava/etc., and provide workarounds for such systems. :(
On Tue, Aug 9, 2016 at 8:01 AM, Jerry DeLisle <jvdeli...@charter.net> wrote: > On 08/08/2016 04:01 AM, Janne Blomqvist wrote: >> >> PING**2 >> > > OK, thanks for patch. > > Jerry > >> On Sun, Jul 24, 2016 at 4:45 PM, Janne Blomqvist >> <blomqvist.ja...@gmail.com> wrote: >>> >>> Hi, >>> >>> the attached patch replaces the current random_number / random_seed >>> implementations with an implementation that better supports threads. >>> It's an improved version of the RFC patch I posted earlier at >>> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02110.html . Please see >>> that earlier message for a longer-winded explanation of what's wrong >>> with the current implementation and how the patch addresses this. >>> >>> In short, with the patch the random number generator state is now >>> per-thread and stored in a per-thread (TLS) variable, enabling a >>> lockless fast-path. This provides up to 2 orders of magnitude better >>> performance on a synthetic benchmark using 4 threads, and provides a >>> more deterministic result as the order that threads are scheduled does >>> not affect the random number streams for each thread. >>> >>> Compared to the RFC patch, a number of minor and not-so-minor bugs >>> have been fixed, so the patch now passes the testsuite (with a few >>> modifications to the suite, part of the patch). Also, for REAL kinds >>> 4, 8, 10 the generated streams are identical (except precision, of >>> course) (like the current implementation), enabling precision >>> comparisons, as requested by Steve Kargl. However, this does not >>> extend to REAL(16) as that would have necessitated doubling the size >>> of the state, along with potential issues of slower escape from a >>> low-entropy state, for a feature that I believe is not used by >>> particularly many users in the end. So if one wants to do precision >>> comparisons with REAL(16) one must employ a wrapper routine. >>> >>> Regtested on x86_64-pc-linux-gnu, Ok for trunk? >>> >>> frontend ChangeLog: >>> >>> 2016-07-27 Janne Blomqvist <j...@gcc.gnu.org> >>> >>> * check.c (gfc_check_random_seed): Use new seed size in check. >>> * intrinsic.texi (RANDOM_NUMBER): Updated documentation. >>> (RANDOM_SEED): Likewise. >>> >>> >>> testsuite: >>> >>> 2016-07-27 Janne Blomqvist <j...@gcc.gnu.org> >>> >>> * gfortran.dg/random_7.f90: Take into account that the last seed >>> value is the special p value. >>> * gfortran.dg/random_seed_1.f90: Seed size is now constant. >>> >>> >>> libgfortran: >>> 2016-07-27 Janne Blomqvist <j...@gcc.gnu.org> >>> >>> * intrinsics/random.c: Replace KISS with xorshift1024* with >>> per-thread (TLS) state. >>> * runtime/main.c (init): Don't call random_seed_i4. >>> >>> >>> -- >>> Janne Blomqvist >> >> >> >> > -- Janne Blomqvist
