Re: [Patch, libfortran] Multi-threaded random_number

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

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 <jvdelisle@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.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