<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 2013-09-10 13:42, Tony Rogvall
      wrote:<br>
    </div>
    <blockquote
      cite="mid:3CC4CDFC-2B7E-4AED-8BB5-E61AD573F873@rogvall.se"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      Ah! Its you again! :-)
      <div><br>
      </div>
      <div>I have problems with the value inline_effort, it looks like
        the inliner (or later pass) leave unoptimised code</div>
      <div>after running an otherwise successful  inlining. </div>
      <div><br>
      </div>
      <div>The unrolling is a really cool thing, but a bit hard to
        control (for me) </div>
      <div>I have successfully unrolled a number of examples and I think
        it has a great</div>
      <div>potential in things like code generation and module
        specialization etc.</div>
      <div><br>
      </div>
      <div>Some of my examples lead to (nearly) infinite speedup, the
        result is a precomputed</div>
      <div>module constant :-)</div>
      <div><br>
      </div>
      <div>Who in the OTP team is handling this kind of fun stuff
        now-a-days ?</div>
    </blockquote>
    <br>
    The compiler is nearly exclusively Björns area, although there are a
    few padawans around also =)<br>
    <br>
    If a concise requirement is done, we can estimate and prioritize it.
    But if you really want it in it is probably best to send a patch for
    it. Björn is a bit picky though so you better come prepared =D<br>
    <br>
    // Björn-Egil<br>
    <br>
    <blockquote
      cite="mid:3CC4CDFC-2B7E-4AED-8BB5-E61AD573F873@rogvall.se"
      type="cite">
      <div><br>
      </div>
      <div>Tanks</div>
      <div><br>
      </div>
      <div>/Tony</div>
      <div>
        <div><br>
          <div>
            <div>On 10 sep 2013, at 13:32, Richard Carlsson <<a
                moz-do-not-send="true"
                href="mailto:carlsson.richard@gmail.com">carlsson.richard@gmail.com</a>>
              wrote:</div>
            <br class="Apple-interchange-newline">
            <blockquote type="cite">Ah, memories! It was a long time
              since I implemented that stuff, and I never got the
              unrolling to work quite as I expected it to. I think the
              paper that the algorithm comes from just talked breifly
              about allowing unrolling, and I saw it as a feature that
              would be nice if it worked but not critical, and I didn't
              have time to fiddle too much with it. If someone wants to
              do some more work on that stuff, you're very welcome.
              (Manual unrolling experiments to the depth of 5-10 used to
              show a significant speedup in tight loops, even without
              native compilation, mainly because you avoid reducing and
              testing the reduction counter for each step. Combine that
              with the inline_list_funcs compiler flags and you should
              get pretty nice code.)<br>
              <br>
                 /Richard<br>
              <br>
              On 2013-09-08 22:55 , Tony Rogvall wrote:<br>
              <blockquote type="cite">Hi!<br>
                <br>
                I dont know who is working on the cerl_inline
                functionality but it is really intriguing !<br>
                I have found some problems doing experiments with
                (undocumented) compile attributes<br>
                inline_effort and inline_unroll. No No No do not remove
                them!!!! They just needs to be<br>
                tested and reworked a bit :-)<br>
                <br>
                I am working on a module inline parse transform that I
                need for speed things up a bit,<br>
                specially on modules that I think will not change so
                much over time (think lists module)<br>
                Also, hipe compile on top of this tends to do marvelous
                things with performance :-)<br>
                <br>
                Any way here is a module that when compiled, first of
                all warns about some strange things<br>
                and then generates some "interesting" code.<br>
                <br>
                I guess the ones working on this will see what is the
                problem. And please do NOT remove<br>
                functionality just because I found it, improve it. I
                need it :-)<br>
                <br>
                Thanks<br>
                <br>
                <br>
                /Tony<br>
                <br>
                <br>
                <br>
                -module(example3i).<br>
                <br>
                -export([run/1]).<br>
                <br>
                -compile(inline).<br>
                -compile({inline_size,   500}).    %% default=24<br>
                -compile({inline_effort, 500}).   %% default=150<br>
                %% -compile({inline_unroll, 1}).   %% default=1<br>
                -compile({verbose,true}).<br>
                <br>
                run(V) when is_float(V) -><br>
                    B = vec3f_new(4,5,6),<br>
                    C = vec3f_new(7,8,9),<br>
                    vec3f_multiply(V,vec3f_add(B,C)).<br>
                <br>
                -define(is_vecA, is_float(A1), is_float(A2),
                is_float(A3)).<br>
                -define(is_vecB, is_float(B1), is_float(B2),
                is_float(B3)).<br>
                <br>
                vec3f_new(X,Y,Z) when is_number(X), is_number(Y),
                is_number(Z) -><br>
                    {float(X),float(Y),float(Z)}.<br>
                <br>
                vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB
                -><br>
                    {A1+B1,A2+B2,A3+B3}.<br>
                <br>
                vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA,
                ?is_vecB -><br>
                    {A1*B1,A2*B2,A3*B3};<br>
                vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB
                -><br>
                    {A*B1,A*B2,A*B3};<br>
                vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA
                -><br>
                    {A1*B,A2*B,A3*B}.<br>
                <br>
                <br>
                _______________________________________________<br>
                erlang-bugs mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
                <a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-bugs">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
                <br>
              </blockquote>
              <br>
            </blockquote>
          </div>
          <br>
          <div>
            <span class="Apple-style-span" style="border-collapse:
              separate; border-spacing: 0px; ">
              <div><span class="Apple-style-span" style="color: rgb(51,
                  51, 51); font-family: Geneva, Arial, Helvetica,
                  sans-serif; font-size: 12px; ">"Installing
                  applications can lead to corruption over time. </span><span
                  class="Apple-style-span" style="color: rgb(51, 51,
                  51); font-family: Geneva, Arial, Helvetica,
                  sans-serif; font-size: 12px; ">Applications gradually
                  write over each other's libraries, partial upgrades
                  occur, user and system errors happen, and minute
                  changes may be unnoticeable and difficult to fix"</span></div>
              <div><span class="Apple-style-span" style="color: rgb(51,
                  51, 51); font-family: Geneva, Arial, Helvetica,
                  sans-serif; font-size: 12px; "><br>
                </span></div>
            </span><br class="Apple-interchange-newline">
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
erlang-bugs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-bugs">http://erlang.org/mailman/listinfo/erlang-bugs</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>