PING?
Also, a minor bugfix on top of the previous patch:
diff --git a/libgfortran/intrinsics/random.c b/libgfortran/intrinsics/random.c
index 9b54a02..21395ea 100644
--- a/libgfortran/intrinsics/random.c
+++ b/libgfortran/intrinsics/random.c
@@ -787,7 +787,7 @@ random_seed_i4 (GFC_INTEGER_4 *size, gfc_array_i4
*put, gfc_array_i4 *get)
init_rand_state (true);
/* Copy p & 15 */
- rand_state.p = put->base_addr[SZ * GFC_DESCRIPTOR_STRIDE(put, 0)] & 15;
+ rand_state.p = put->base_addr[SZ * GFC_DESCRIPTOR_STRIDE(put, 0)] % 15;
}
@@ -862,7 +862,7 @@ random_seed_i8 (GFC_INTEGER_8 *size, gfc_array_i8
*put, gfc_array_i8 *get)
njumps = 0;
init_rand_state (true);
- rand_state.p = put->base_addr[SZ * GFC_DESCRIPTOR_STRIDE(put, 0)] & 15;
+ rand_state.p = put->base_addr[SZ * GFC_DESCRIPTOR_STRIDE(put, 0)] % 15;
}
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
