From owner-svn-src-all@freebsd.org Tue May 31 07:20:42 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EB10B552A7 for ; Tue, 31 May 2016 07:20:42 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f68.google.com (mail-lf0-f68.google.com [209.85.215.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD7291B07 for ; Tue, 31 May 2016 07:20:41 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f68.google.com with SMTP id q63so6348310lfi.2 for ; Tue, 31 May 2016 00:20:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QRgzNES30yyAu8fGoBkIXvFKUUDLsBQKrrXUIp5+aIc=; b=GmdcsrvaqmA77crRtPCHCgHg/lLFFlo/M101B6ASLqJcGSdJsKTZbAf5dfN49kjE5P fSUZcmz7G70yU1OYLiqy+Jc6XlUk8FjXFwUacnGY45ZjcDPyy88xgbH6p8ZI5nDiwpPn IAcib/0wc06lJMhZpScgvJRTGOFfLIiG1u9e5DIor23JbKQN164woJwBYB8BhrWEJhE1 IIvKjY3ii8rmNM1te+HZnVdL9HQzqJV6JLie+GrRDBNReUV9H106+qIblW9yXfLr76+s QT7V+J1d+L+zvgL7HJ8R/kjK6XLVx5bMRqRl9ETtuzvkdz5b/DWj8hfTCklAoWn+BumF X/AA== X-Gm-Message-State: ALyK8tIZqf6WQCea9aVSp4LD+6PIhUG2SojvPh4+E4BDkOW2vfOq91ctZxledm4+wiid5Q== X-Received: by 10.25.90.1 with SMTP id o1mr9193265lfb.193.1464679239576; Tue, 31 May 2016 00:20:39 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id n13sm1789264lfb.33.2016.05.31.00.20.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2016 00:20:38 -0700 (PDT) Subject: Re: svn commit: r300965 - head/lib/libc/stdlib To: Bruce Evans References: <201605291639.u4TGdSwq032144@repo.freebsd.org> <20160530122100.X924@besplex.bde.org> <5985bdc1-b821-f352-0bc5-c45c600c5318@freebsd.org> <20160531130326.G1052@besplex.bde.org> <20160531152438.S1534@besplex.bde.org> Cc: Conrad Meyer , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Andrey Chernov Message-ID: <20864fad-e698-31cb-1e52-52db60850356@freebsd.org> Date: Tue, 31 May 2016 10:20:37 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160531152438.S1534@besplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 07:20:42 -0000 On 31.05.2016 8:53, Bruce Evans wrote: > On Tue, 31 May 2016, Andrey Chernov wrote: > >> On 31.05.2016 6:42, Bruce Evans wrote: >>> >>> Er, I already said which types are better -- [u]int_fast32_t here. >> >> [u]int_fast32_t have _at_least_ 32 bits. int32_t in the initial PRNG can >> be changed since does not overflow and involve several calculations, but >> uint_fast32_t is needed just for two operations: > > I think you mean a native uint32_t is needed for 2 operations. > >> *f += *r; >> i = (*f >> 1) & 0x7fffffff; > > This takes 2 operations (add and shift) with native uint32_t. It takes 4 > logical operations (maybe more physically, or less after optimization) > with emulated uint32_t (add, mask to 32 bits (maybe move to another > register to do this), shift, mask to 32 bits). When you write the final > mask explicitly, it is to 31 bits and optimizing this away is especially > easy in both cases. > >> We need to assign values from uint32_t to uint_fast32_t (since array >> size can't be changed), > > FP code using double_t is similar: data in tables should normally be > in doubles since double_t might be too much larger; data in function > parameters is almost always in doubles since APIs are deficient and > don't even support double_t as an arg; then it is best to assign to > a double_t variable since if you just use the double then expressions > using it will promote it to double_t but it is too easy to lose this > expansion too early. It takes extra variables and a little more code > for the assignments, but the extra variables are optimized away in > cases where there is no expansion. > >> do this single operation fast and store them >> back into array of uint32_t. I doubt that much gain can comes from it >> and even pessimization in some cases. Better let compiler do its job >> here. > > It's never a pessimization if the compiler does its job. > > It is good to practice this on a simple 2-step operation. Think of a > multi-step operation where each step requires clipping to 32 bits. > Using uint32_t for the calculation is just a concise way of writing > "& 0xffffffff" after every step (even ones that don't need it). It > is difficult and sometimes impossible for the compiler to optimize > away these masks across a large number of steps. Sometimes this is > easy for the programmer. The biggest problem so far is that fast types for [u]int32_t are exact _the_same_ as not fast for i386 and amd64, see /usr/include/x86/_types.h Without any gain on major platforms I don't think this change is needed.