This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, libfortran] Multi-threaded random_number
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Fortran List <fortran at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 8 Aug 2016 14:01:31 +0300
- Subject: Re: [Patch, libfortran] Multi-threaded random_number
- Authentication-results: sourceware.org; auth=none
- References: <CAO9iq9FeBPjnwMJScLzhyXANkc=z=0AybdW2dNA0z5FcsMsTGw@mail.gmail.com>
PING**2
On Sun, Jul 24, 2016 at 4:45 PM, Janne Blomqvist
<blomqvist.janne@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 <jb@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 <jb@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 <jb@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