public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jerry DeLisle <jvdelisle@charter.net>
To: Janne Blomqvist <blomqvist.janne@gmail.com>,
	Fortran List <fortran@gcc.gnu.org>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch, libfortran] Multi-threaded random_number
Date: Tue, 09 Aug 2016 05:01:00 -0000	[thread overview]
Message-ID: <710d21ad-f79e-a681-bf1a-9be40c0382d6@charter.net> (raw)
In-Reply-To: <CAO9iq9F1RRSWDSiKkyOB1KWvKUbXEL_5KABL5Y_sKHLHaf_wHA@mail.gmail.com>

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
>
>
>

  reply	other threads:[~2016-08-09  5:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-24 13:45 Janne Blomqvist
2016-08-01 10:42 ` Janne Blomqvist
2016-08-01 10:48   ` Andreas Schwab
2016-08-01 11:00     ` Janne Blomqvist
2016-08-08 11:01 ` Janne Blomqvist
2016-08-09  5:01   ` Jerry DeLisle [this message]
2016-08-10 11:12     ` Janne Blomqvist
2016-08-11  9:02       ` Janne Blomqvist
2016-08-11 14:55         ` Rainer Orth
2016-08-11 15:39           ` Janne Blomqvist
2016-08-12 10:07         ` Thomas Schwinge
2016-08-12 10:37           ` Janne Blomqvist

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=710d21ad-f79e-a681-bf1a-9be40c0382d6@charter.net \
    --to=jvdelisle@charter.net \
    --cc=blomqvist.janne@gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).