[erlang-bugs] inline & inline_effort

[Björn-Egil Dahlberg]

On 2013-09-10 13:42, Tony Rogvall wrote:
> 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 ?

The compiler is nearly exclusively Björns area, although there are a few 
padawans around also =)

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

// Björn-Egil

>
> Tanks
>
> /Tony
>
> On 10 sep 2013, at 13:32, Richard Carlsson <carlsson.richard@REDACTED 
> <mailto: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 <mailto: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"
>
>
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

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