220 32882 article Path: news.gmane.org!.POSTED!not-for-mail From: peetpaul69@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: constexpr for loop? Date: Sun, 25 Jun 2017 13:39:11 -0700 (PDT) Lines: 255 Approved: news@gmane.org Message-ID: References: <46c1d5fc-6215-44f5-be84-651085690b0d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1507_901239115.1498423151817" X-Trace: blaine.gmane.org 1498423157 27155 195.159.176.226 (25 Jun 2017 20:39:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Jun 2017 20:39:17 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDG53NMEJEIPBPWAZICRUBFO4UVZK@isocpp.org Sun Jun 25 22:39:13 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f197.google.com ([209.85.213.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPEJI-0006as-J3 for gclcip-std-proposals@m.gmane.org; Sun, 25 Jun 2017 22:39:08 +0200 Original-Received: by mail-yb0-f197.google.com with SMTP id p207sf71964975yba.13 for ; Sun, 25 Jun 2017 13:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=DNqHAe4ftTyseoT6t4KyoYB11fkoOWiWcFGuGTve9u4=; b=wI2i3C8CNuB89u/qra9mirmimoz9jRkRuUiUzaDCWH+ob963txem66C2FopCDmVeeO SLAS8CnftHqlESo50zi5bUlTpzPkXUVTbtYUzNmtl8MblIOXKHYvCWEqiEB+2P/UZUUv QmpmlfNisL36rfd0vm6G6ct9wNzamROnfDd5HnNOy9PdnFF2B9l1Qur5btLiys2spjD/ hvSET1BaE/J+rmzrvn/pKsBVhyFKisJzyOmCDxwXS032GTEYEsvTgJrh9urgNo45V2hs S9oynS8mz7gCQ4OnYLczNvAjNo3/l/tMDPPtTXI2DmLYlo1hrB4CKeg2Lxg4oJL9WzCc uYXQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=DNqHAe4ftTyseoT6t4KyoYB11fkoOWiWcFGuGTve9u4=; b=hTpJUpJTxT+FtIgNdcZ11vGiwObNEwZrIwxm+4wVVMAD0QcKClByHVK6ouH3bh2il0 3dAwUx1mBScc3rpr8/cp4NbB6OyIAnD9vWiTw/MEfS5Hv6YdXeU46M1A7iww+RqqAUmG LBdbUGRH9KogrLbeQu1196dH1ZLeRWrgtED6SkWUMir8RG8ALBFmtLX2hgZEdr0SOQpB 2T53Jfc1vI9qhy5CssIqBsKRfYUdv3kfEReeaZXqZyfE9ZkIzEuMnlGwgpPXUPnJrxfw 8vghiTiduAmT6URPwQQzupNsiMAG88uo8tmR5uldCIZJnEFtL76aB6oDq21D4QWL/7gx 45Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=DNqHAe4ftTyseoT6t4KyoYB11fkoOWiWcFGuGTve9u4=; b=ggn+++RzAzh6lvSIHWObvQN8UAz3uoNY08uN93XP6HWpKDNvkXbROyi+iPjcBLsqSM gcPSgjNErsJeqctWjDjy5rbwGLF+D4nqzEF0D7zqAOZ+lStcV489+GycU35UXks7Qaeq RKwoOtGIBRR79rT9/9d1g4n9udjnPRFAC0L8F6V9kI2qLvT/JrrlHypUKVTZL4Dz3Z1i uHfIe5IgErF4Ym4YLShF+Jz5xz0ZjW4TQelPzd2+jcC1fFCe7ixUiW61hCTs4DZq0OzM kqMmd2FNAufwQCz76YZQ1XeMf8QNpX9WLNsSmiKw3eV9PpvkGW34ToQ8JapvIANqiJhm dSKQ== X-Gm-Message-State: AKS2vOzoXPz9SOxZMDmuyWnyKncoGe0Be/QqySmetoZrumhSuR40bxoj CIJuEecvg0vWJ+0S X-Received: by 10.129.162.194 with SMTP id z185mr10638758ywg.18.1498423153336; Sun, 25 Jun 2017 13:39:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.56.153 with SMTP id p25ls11815632otc.34.gmail; Sun, 25 Jun 2017 13:39:12 -0700 (PDT) X-Received: by 10.157.51.175 with SMTP id u47mr128098otc.4.1498423152349; Sun, 25 Jun 2017 13:39:12 -0700 (PDT) In-Reply-To: <46c1d5fc-6215-44f5-be84-651085690b0d@isocpp.org> X-Original-Sender: peetpaul69@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:32882 Archived-At: ------=_Part_1507_901239115.1498423151817 Content-Type: multipart/alternative; boundary="----=_Part_1508_681461918.1498423151818" ------=_Part_1508_681461918.1498423151818 Content-Type: text/plain; charset="UTF-8" It seems that this could be really useful, especially for static reflection. And actually, there is a fork of clang by Andrew Sutton which basically implements the "constexpr" (evaluation/unrolling at compile-time) loop: Here is a demo: https://godbolt.org/g/maV08o More info: https://www.reddit.com/r/cpp/comments/68ljh4/there_is_no_interface_keyword_in_c_herbsutter/ On Sunday, June 25, 2017 at 2:12:58 AM UTC+2, Evan Teran wrote: > > I was just thinking the other day. Now that we are getting constexpr if, > what else could we allow at compile time? What occurs to me is that we > could have a nice compile time means to do loop unrolling. What I imagine > is something like this: > > > constexpr for(int i = 0; i < 4; ++i) { > whatever(); > } > > > would cause the compile to simply emit: > > whatever(); > whatever(); > whatever(); > whatever(); > > Obviously the loop bounds would have to be trivially known at compile time > for this to work, and should throw a hard error if it isn't. Many compilers > already are doing this analysis that would enable this, so why not make > that analysis able to be leveraged by the developer? > > I know that the conventional wisdom is to just write the loop, and if the > compiler deems it optimal to unroll the loop, then it will. But sometimes, > people just know better. > > I can imagine versions of many algorithms that are functionally identical > the standard ones, but allow the user to specify how much to unroll via > template parameters, like this (parden any typos): > > namespace unrolled { > > template > F for_each_n(In first, Size Count, F fn) { > Size rounded = (count / N) * N; // round count down to nearest > multiple of N > Size i = 0; > > > // do as much as possible in chunks of unrolled size N > while(i < rounded) { > constexpr for(int j = 0; j < N; ++j) { > fn(first[j]); > } > i += N; > } > > > while(i < count) { > fn(first[i++]); > } > } > > } > > Which would enable code like this: > > unrolled::for_each_n<3>(std::begin(arr), 30, [](auto elem) { > // do whatever with elem > } > > > It would be functionally the same as a regular std::for_each_n, but > unrolled into blocks of size 3 as much as possible. > > Thoughts? Is this just not worth the effort? > Evan > -- 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/b4bd172a-05c9-4a92-83fa-beba24150472%40isocpp.org. ------=_Part_1508_681461918.1498423151818 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems that this could be really useful, especially for = static reflection.

And actually, there is a fork of clan= g by Andrew Sutton which basically implements the "constexpr" (ev= aluation/unrolling at compile-time) loop:

Here is = a demo:=C2=A0https://godbolt.org/g/maV08o

More inf= o:=C2=A0https://www.reddit.com/r/cpp/comments/68ljh4/there_is_no_interface_= keyword_in_c_herbsutter/

On Sunday, June 25, 2017 at 2:12:58 AM UTC+= 2, Evan Teran wrote:
I was just thinking the other day. Now that we are getting constex= pr if, what else could we allow at compile time? What occurs to me is that = we could have a nice compile time means to do loop unrolling. What I imagin= e is something like this:


constexpr for<= span style=3D"color:#660">(int i =3D 0; i < 4; ++i) {=C2=A0 =C2=A0 whatever();
}


would cause the compile to simp= ly emit:

whatever();
whatever();
whatever();
whate= ver();

=
Obviously the loop bounds would have to be trivially known at co= mpile time for this to work, and should throw a hard error if it isn't.= Many compilers already are doing this analysis that would enable this, so = why not make that analysis able to be leveraged by the developer?

I know that the conventional wisdom is to just write the loop, and if = the compiler deems it optimal to unroll the loop, then it will. But sometim= es, people just know better.

I can imagine version= s of many algorithms that are functionally identical the standard ones, but= allow the user to specify how much to unroll via template parameters, like= this (parden any typos):

namespace unrolled {

temp= late &l= t;int N= , class In, class Size, class F>
F for_each_n(In first, Size Count, F fn) {
=C2=A0 =C2=A0 Size rounded = =3D (count / N= ) * N; // round count down to nearest multiple of N
=C2=A0 =C2=A0 Size i =3D 0;


=C2= =A0 =C2=A0 // do as much as possible in c= hunks of unrolled size N
=C2=A0 =C2=A0= while(= i <<= /span> rounded= ) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 constexpr for(int j =3D 0; j < N; ++j) = {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fn(first[j]);=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 i +=3D N;
=C2=A0 =C2=A0 }


=C2=A0 =C2=A0 while(i < count) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fn(first[i++]);
=C2=A0 =C2=A0 }
}

}

Which would enable code lik= e this:

unrolled::for_each_n<3>(std::begin(arr), 30, [](auto elem) {
=C2=A0 =C2=A0 // do whatever with elem
}

=

It would be functionally the same as a regular st= d::for_each_n, but unrolled into blocks of size 3 as much as possible.

Thoughts? Is this just not worth the effort?
Evan

--
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 https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/b4bd172a-05c9-4a92-83fa-beba24150472= %40isocpp.org.
------=_Part_1508_681461918.1498423151818-- ------=_Part_1507_901239115.1498423151817-- .