<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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><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 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 href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-bugs<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></body></html>