/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Warning: Cannot modify header information - headers already sent by (output started at /customers/4/c/9/iconara.net/httpd.www/blog/wp-content/advanced-cache.php:1) in /customers/4/c/9/iconara.net/httpd.www/blog/wp-includes/feed-rss2-comments.php on line 8 Comments on: Unroll your loops! http://blog.iconara.net/2008/09/07/unroll-your-loops/ Thu, 05 Jul 2012 13:41:39 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Theo http://blog.iconara.net/2008/09/07/unroll-your-loops/comment-page-1/#comment-7596 Theo Sun, 21 Sep 2008 09:30:34 +0000 http://blog.iconara.net/?p=296#comment-7596 <p>The lesson here is that you shouldn't optimize while you refactor.</p> The lesson here is that you shouldn’t optimize while you refactor.

]]>
By: Severin http://blog.iconara.net/2008/09/07/unroll-your-loops/comment-page-1/#comment-7595 Severin Sun, 21 Sep 2008 01:37:07 +0000 http://blog.iconara.net/?p=296#comment-7595 <p>Well, I'd say your guts were right, at least if this code is really a performance bottleneck: if you'd do let's say a 1000000 iterations on doTheThing(), then the first thing would be substantially faster done, at least if there's only a little bunch of items to iterate locally. Why? Because method calls in AS3 are much slower (I'm talking of factor 100) than assignments. But I agree, that - if you wouldn't have to do the thing many, many times - there's only a theoratical difference. Ehm, hope my 2 dirty cents made themselves kind of clear ;)</p> Well, I’d say your guts were right, at least if this code is really a performance bottleneck: if you’d do let’s say a 1000000 iterations on doTheThing(), then the first thing would be substantially faster done, at least if there’s only a little bunch of items to iterate locally. Why? Because method calls in AS3 are much slower (I’m talking of factor 100) than assignments. But I agree, that – if you wouldn’t have to do the thing many, many times – there’s only a theoratical difference. Ehm, hope my 2 dirty cents made themselves kind of clear ;)

]]>
By: bjorn http://blog.iconara.net/2008/09/07/unroll-your-loops/comment-page-1/#comment-7561 bjorn Mon, 08 Sep 2008 06:51:00 +0000 http://blog.iconara.net/?p=296#comment-7561 <p>Good one Theo, my gut told me the same thing yours did .. but when thinking about it I can't see why I thought setting up a loop should be so costly :-)</p> Good one Theo, my gut told me the same thing yours did .. but when thinking about it I can’t see why I thought setting up a loop should be so costly :-)

]]>
By: Theo http://blog.iconara.net/2008/09/07/unroll-your-loops/comment-page-1/#comment-7560 Theo Mon, 08 Sep 2008 05:42:48 +0000 http://blog.iconara.net/?p=296#comment-7560 <p>You're right of course, but it's also a very different example. The point of mine was that the loop body wasn't interdependent. In your example the parts don't do half the work. It's less likely that you'd want to refactor a piece of code that worked like that because the parts depend on each other. I'm not claiming that any loop can be split apart and maintain the same time complexity.</p> You’re right of course, but it’s also a very different example. The point of mine was that the loop body wasn’t interdependent. In your example the parts don’t do half the work. It’s less likely that you’d want to refactor a piece of code that worked like that because the parts depend on each other. I’m not claiming that any loop can be split apart and maintain the same time complexity.

]]>
By: ronen http://blog.iconara.net/2008/09/07/unroll-your-loops/comment-page-1/#comment-7558 ronen Sun, 07 Sep 2008 21:17:09 +0000 http://blog.iconara.net/?p=296#comment-7558 <p>Its all a matter of what is the operation on which your measuring the runtime (summation and max operations in your case), lets imagine a case where you have method calcA and calcB, each cost o(1) used in the following loop</p> <p>int acc=0,temp=0; for(int i=0;i<n;i++){ temp+=calcA(i); acc+=calcB(temp); }</p> <p>The run time is o((1+1)n)=o(n)</p> <p>Now lets unroll this loop into two separate loops:</p> <p>int methodA(int k){ int temp=0; for(int j=0;j<=k;j++){ temp+=calcA(j); }<br /> return temp; }</p> <p>int methodB(int n){ int acc=0; for(int i=0;i<n;i++){ acc+=calcB(methodA(i)); }<br /> return acc; }</p> <p>for each calcB we calcA i times, which makes the runtime: ((1+1) + (1+2) + .. + (1+n-1))=(2+3+..+n) = (n (2 + n)) / 2 = (2n+n^2)/2 = o(n^2) This is quadratic time instead of linear time! Now for simple un-rolling its visible and can be prevented by a worthy programmer the problem is that in real life code isn't as clear as in this case, still you are correct since usually most of the code doesn't reside within the 10% in which the program spends 90% of its processing time (therefor making optimizations worthless).</p> Its all a matter of what is the operation on which your measuring the runtime (summation and max operations in your case), lets imagine a case where you have method calcA and calcB, each cost o(1) used in the following loop

int acc=0,temp=0; for(int i=0;i<n;i++){ temp+=calcA(i); acc+=calcB(temp); }

The run time is o((1+1)n)=o(n)

Now lets unroll this loop into two separate loops:

int methodA(int k){ int temp=0; for(int j=0;j<=k;j++){ temp+=calcA(j); }
return temp; }

int methodB(int n){ int acc=0; for(int i=0;i<n;i++){ acc+=calcB(methodA(i)); }
return acc; }

for each calcB we calcA i times, which makes the runtime: ((1+1) + (1+2) + .. + (1+n-1))=(2+3+..+n) = (n (2 + n)) / 2 = (2n+n^2)/2 = o(n^2) This is quadratic time instead of linear time! Now for simple un-rolling its visible and can be prevented by a worthy programmer the problem is that in real life code isn’t as clear as in this case, still you are correct since usually most of the code doesn’t reside within the 10% in which the program spends 90% of its processing time (therefor making optimizations worthless).

]]>