220 30871 article Path: news.gmane.org!.POSTED!not-for-mail From: Joel Falcou Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Detecting compile-time evaluation Date: Sat, 11 Feb 2017 22:54:50 +0100 Lines: 258 Approved: news@gmane.org Message-ID: References: <86a47916-27c3-4e29-862f-9b4e1f105c1c@isocpp.org> <34826fd2-84db-4ce9-b30b-66a95601918a@isocpp.org> <18849693.bqFcfaDNcV@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114488307b319905484843fb X-Trace: blaine.gmane.org 1486850100 11511 195.159.176.226 (11 Feb 2017 21:55:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 11 Feb 2017 21:55:00 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCPININ5TAFRBK4Q73CAKGQE3Q5QMNI@isocpp.org Sat Feb 11 22:54:53 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ccfd3-0002IH-V8 for gclcip-std-proposals@m.gmane.org; Sat, 11 Feb 2017 22:54:50 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id 96sf43989947uaq.7 for ; Sat, 11 Feb 2017 13:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=lgUCAu9omcgeL7q/kqu4V5l2dXN5QlpN4Hd3L3RzL4Q=; b=peisMdyqNpLLHayZjIsX+dl40kplXb5gudO4vLAJnxzD0GO9WGXuB/6m+LIkQYqQnq SmkwHB8xW/HaJMFwPN923+/EJoEs1vKMhvR1GvNYijHvGKKQK06aWIOUzHkSlJOitl92 zZEvrDYAdPm2fdsEVKJEuSUv2mOmYLrH31yPmeUdL2XvsPs407Tx4mPQ32D5CfZ1wdpt r9yHkNwnK54LpduJnVkjuuqF80MC5l4BCQE5xrfiH9OO9wKhqwh3nwWFpZaxpv8trXNW 99xCbX3ac0aK96XKybkjeM6Ch0HenQkMhHdGjCe/f7bz3cQml+w0yOeJgEqykV6hZGvj Sa1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=lgUCAu9omcgeL7q/kqu4V5l2dXN5QlpN4Hd3L3RzL4Q=; b=kuy07UrV83rHjjMeonwHhzlH9oe+Lbd3cZp7SxiH2AMicsxkumMGyVUsejWzqYvPIS p53/TaWypx6NtYBR8X2pVERMavx0oHP0thGWOd9TlZnwm4Dll6ZcH140JnvuiF8NXD57 jZDgBsN85xnwtfYyOfspsTDGWvp9CKfG1XYQ/MAGBYw40zpn27xKDzkEbjBxLf01m+R2 u9e3CfigN4+PHHanrLyTqgM7VgogzC3lU5AkX0TYZkJ3Q0Qghp712kRvgHo2L+zZt3K+ dQhOJpHKyi8CUKe938UQa1+thpniraOkj6RDNN9WYDC0djsNjK/a07w0tIqoN51DalF0 JjCg== X-Gm-Message-State: AMke39nSBqGpdlmoLLu2cueAKMKkwZ2KQTS5Yyx8R9TpoQKDAxvm+3rxe9uompliZXsbhw== X-Received: by 10.159.33.206 with SMTP id 72mr4414198uac.18.1486850095147; Sat, 11 Feb 2017 13:54:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.80.141 with SMTP id m135ls2107002itb.17.canary-gmail; Sat, 11 Feb 2017 13:54:51 -0800 (PST) X-Received: by 10.36.211.213 with SMTP id n204mr14944311itg.49.1486850091107; Sat, 11 Feb 2017 13:54:51 -0800 (PST) Original-Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com. [2607:f8b0:4001:c0b::22a]) by mx.google.com with ESMTPS id l6si6242932iof.240.2017.02.11.13.54.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Feb 2017 13:54:51 -0800 (PST) Received-SPF: pass (google.com: domain of joel.falcou@gmail.com designates 2607:f8b0:4001:c0b::22a as permitted sender) client-ip=2607:f8b0:4001:c0b::22a; Original-Received: by mail-it0-x22a.google.com with SMTP id c7so159853331itd.1 for ; Sat, 11 Feb 2017 13:54:51 -0800 (PST) X-Received: by 10.36.69.145 with SMTP id c17mr35252597itd.111.1486850090541; Sat, 11 Feb 2017 13:54:50 -0800 (PST) Original-Received: by 10.107.32.196 with HTTP; Sat, 11 Feb 2017 13:54:50 -0800 (PST) In-Reply-To: <18849693.bqFcfaDNcV@tjmaciei-mobl1> X-Original-Sender: joel.falcou@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of joel.falcou@gmail.com designates 2607:f8b0:4001:c0b::22a as permitted sender) smtp.mailfrom=joel.falcou@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:30871 Archived-At: --001a114488307b319905484843fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eigen and other expression tempaltes library don't perform computation at compile time, they build a lazy representation of computations at compile time so the actual computations are delayed. I wrote a couple of such library and the only places where constexpr made sense was optimizing matrix size computation when all dimensions where constants. log2 happens a bit in constexpr context becasue finding the closest power of 2 is a task some code may requires. I had myself solved a 2x2 linear system but not much more at compile time. 2017-02-11 21:35 GMT+01:00 Thiago Macieira : > On s=C3=A1bado, 11 de fevereiro de 2017 10:43:53 PST Gonzalo BG wrote: > > @Thiago: > > > We used to have this problem with Clang: for example, > > > qCountTrailingZeroBits wasn't constexpr with Clang until 3.8, becaus= e > we > > > couldn't use __builtin_ctz in a constexpr context. > > > > Given that you have run into the issue, I cannot find the logic in the > > > > following statement: > > > But in our experience, any algorithm that can be complex enough to > > > warrant SIMD optimisation is too complex for a constexpr inline > function. > > > > You seem to be arguing that using __builtin_ctz in a constexpr function > is > > reasonable, but using any other intrinsics while solving problems in an= y > > other domain is not. Care to elaborate on which experience makes you sa= y > so? > > It was a problem, but it's now fixed and we now can use the builtin that = is > constexpr. > > > 1) The post C++11 standard library. Before C++11 I rarely saw people > > reimplementing pow, log, exp, sin, ... After C++11 almost every single > > project had its own pow constexpr implementation because neither the ma= th > > functions from the standard library nor the builtins provided by the > > compilers worked inside constant expressions for years after C++11. The > > run-time performance of these functions was, and still is, horrible. Th= e > > fix for this was to make the math functions in the standard constexpr, > but > > this did not solve the underlying issue (which is being discussed here)= .. > > That's an interesting example, but it doesn't match my experience. I > haven't > seen a lot of people need exponentiation and logarithm in constexpr > constexts. > In regular code, you simply rely on the optimiser propagating constants, > something compilers have done for a decade. > > > 2) Math/Linear algebra libraries like Eigen3, Blaze, ... which have use= d > > expression template hacks for compile-time computations for the last 20 > > years _cannot_ use constexpr anywhere in their API (and don't really us= e > it > > almost anywhere) because somewhere down the pipeline they do use > intrinsics > > (and pragmas and what not) for run-time performance reasons. > > Same as above: I've never seen the need for those operations to appear in= a > constexpr context in the first place. It is as I said: the majority of th= e > operations that benefit from non-constexpr'able code is too complex for > constexpr anyway. > > > Do you consider using a log function (which is implemented using > intrinsics > > in most standard libraries) or multiplying two 4x4 matrices "too comple= x" > > for constexpr functions? > > Yes, in my experience. > > Or, put another way, what use-case warrants storing the result of such an > operation in a constexpr variable? This is a real question, you probably > know > more cases than I do. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > > -- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > To view this discussion on the web visit https://groups.google.com/a/ > isocpp.org/d/msgid/std-proposals/18849693.bqFcfaDNcV%40tjmaciei-mobl1. > --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CAOG9n2H1a8bcWpnU1_EjwAA-h_Bs44zRLOWatZX%3D-mFLT= LhjkA%40mail.gmail.com. --001a114488307b319905484843fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eigen and other expression tempaltes library don= 't perform computation at compile time, they build a lazy representatio= n of computations at compile time so the actual computations are delayed.
I wrote a couple of such library and the only places where constexp= r made sense was optimizing matrix size computation when all dimensions whe= re constants.

log2 happens a bit in constexpr context becasue= finding the closest power of 2 is a task some code may requires. I had mys= elf solved a 2x2 linear system but not much more at compile time.
=

2017-02-11 21:35 = GMT+01:00 Thiago Macieira <thiago@macieira.org>:
On s=C3=A1bado, 11 de fevereiro de 2017 10:43:53 P= ST Gonzalo BG wrote:
> @Thiago:
> > We used to have this problem with Clang: for example,
> > qCountTrailingZeroBits=C2=A0 wasn't constexpr with Clang unti= l 3.8, because we
> > couldn't use __builtin_ctz=C2=A0 in a constexpr context.
>
> Given that you have run into the issue, I cannot find the logic in the=
>
> following statement:
> > But in our experience, any algorithm that can be complex enough t= o
> > warrant SIMD optimisation is too complex for a constexpr inline f= unction.
>
> You seem to be arguing that using __builtin_ctz in a constexpr functio= n is
> reasonable, but using any other intrinsics while solving problems in a= ny
> other domain is not. Care to elaborate on which experience makes you s= ay so?

It was a problem, but it's now fixed and we now can use the builtin tha= t is
constexpr.

> 1) The post C++11 standard library. Before C++11 I rarely saw people > reimplementing pow, log, exp, sin, ... After C++11 almost every single=
> project had its own pow constexpr implementation because neither the m= ath
> functions from the standard library nor the builtins provided by the > compilers worked inside constant expressions for years after C++11. Th= e
> run-time performance of these functions was, and still is, horrible. T= he
> fix for this was to make the math functions in the standard constexpr,= but
> this did not solve the underlying issue (which is being discussed here= ).

That's an interesting example, but it doesn't match my experience. = I haven't
seen a lot of people need exponentiation and logarithm in constexpr constex= ts.
In regular code, you simply rely on the optimiser propagating constants, something compilers have done for a decade.

> 2) Math/Linear algebra libraries like Eigen3, Blaze, ... which have us= ed
> expression template hacks for compile-time computations for the last 2= 0
> years _cannot_ use constexpr anywhere in their API (and don't real= ly use it
> almost anywhere) because somewhere down the pipeline they do use intri= nsics
> (and pragmas and what not) for run-time performance reasons.

Same as above: I've never seen the need for those operations to appear = in a
constexpr context in the first place. It is as I said: the majority of the<= br> operations that benefit from non-constexpr'able code is too complex for=
constexpr anyway.

> Do you consider using a log function (which is implemented using intri= nsics
> in most standard libraries) or multiplying two 4x4 matrices "too = complex"
> for constexpr functions?

Yes, in my experience.

Or, put another way, what use-case warrants storing the result of such an operation in a constexpr variable? This is a real question, you probably kn= ow
more cases than I do.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-propo= sals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isoc= pp.org/d/msgid/std-proposals/18849693.bqFcfaDNcV%40tjmaciei-mobl1= .

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOG9n2H1a8bcWp= nU1_EjwAA-h_Bs44zRLOWatZX%3D-mFLTLhjkA%40mail.gmail.com.
--001a114488307b319905484843fb-- .