[erlang-bugs] inline & inline_effort

[Tony Rogvall]

Ah! Its you again! :-)

I have problems with the value inline_effort, it looks like the inliner (or later pass) leave unoptimised code
after running an otherwise successful  inlining. 

The unrolling is a really cool thing, but a bit hard to control (for me) 
I have successfully unrolled a number of examples and I think it has a great
potential in things like code generation and module specialization etc.

Some of my examples lead to (nearly) infinite speedup, the result is a precomputed
module constant :-)

Who in the OTP team is handling this kind of fun stuff now-a-days ?

Tanks

/Tony

On 10 sep 2013, at 13:32, Richard Carlsson <carlsson.richard@REDACTED> wrote:

> 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.)
> 
>    /Richard
> 
> On 2013-09-08 22:55 , Tony Rogvall wrote:
>> Hi!
>> 
>> I dont know who is working on the cerl_inline functionality but it is really intriguing !
>> I have found some problems doing experiments with (undocumented) compile attributes
>> inline_effort and inline_unroll. No No No do not remove them!!!! They just needs to be
>> tested and reworked a bit :-)
>> 
>> I am working on a module inline parse transform that I need for speed things up a bit,
>> specially on modules that I think will not change so much over time (think lists module)
>> Also, hipe compile on top of this tends to do marvelous things with performance :-)
>> 
>> Any way here is a module that when compiled, first of all warns about some strange things
>> and then generates some "interesting" code.
>> 
>> I guess the ones working on this will see what is the problem. And please do NOT remove
>> functionality just because I found it, improve it. I need it :-)
>> 
>> Thanks
>> 
>> 
>> /Tony
>> 
>> 
>> 
>> -module(example3i).
>> 
>> -export([run/1]).
>> 
>> -compile(inline).
>> -compile({inline_size,   500}).    %% default=24
>> -compile({inline_effort, 500}).   %% default=150
>> %% -compile({inline_unroll, 1}).   %% default=1
>> -compile({verbose,true}).
>> 
>> run(V) when is_float(V) ->
>>     B = vec3f_new(4,5,6),
>>     C = vec3f_new(7,8,9),
>>     vec3f_multiply(V,vec3f_add(B,C)).
>> 
>> -define(is_vecA, is_float(A1), is_float(A2), is_float(A3)).
>> -define(is_vecB, is_float(B1), is_float(B2), is_float(B3)).
>> 
>> vec3f_new(X,Y,Z) when is_number(X), is_number(Y), is_number(Z) ->
>>     {float(X),float(Y),float(Z)}.
>> 
>> vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB ->
>>     {A1+B1,A2+B2,A3+B3}.
>> 
>> vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB ->
>>     {A1*B1,A2*B2,A3*B3};
>> vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB ->
>>     {A*B1,A*B2,A*B3};
>> vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA ->
>>     {A1*B,A2*B,A3*B}.
>> 
>> 
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
>> 
> 

"Installing applications can lead to corruption over time. 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"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130910/45ec241d/attachment.htm>