<div dir="ltr">Oops, sent prematurely. <div><br></div><div>`mapStencil2` seems to be allocating one extra machine word per stencil computation. So not entirely unboxed, but much better. </div><div><br></div><div>Latest code is at</div><div><a href="https://gist.github.com/wyager/1c5879660a61c5cd6afaceb3e928d889">https://gist.github.com/wyager/1c5879660a61c5cd6afaceb3e928d889</a><br></div><div><br></div><div>Can anyone explain to me how the Identity monad manages to guarantee the sequencing/non-nesting requirements of computeP? As far as I can tell, it should be reduced to plain old function application, which is the same as nesting computeP, which is what we were trying to prevent.</div><div><br></div><div>In other words, what effect does the Identity monad have over not having a monad at all? Its bind  definition has no sequencing effects or anything, so I can't imagine that it actually accomplishes anything.</div><div><br></div><div>Cheers,</div><div>Will</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 2, 2016 at 3:46 PM, William Yager <span dir="ltr"><<a href="mailto:will.yager@gmail.com" target="_blank">will.yager@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">OK, some interesting things:<div><br></div><div>1. INLINE pragmas seem to have no substantial effect.</div><div><br></div><div>2. Regrettably, using Dimensional does seem to have some negative effect on performance. It's about 1.5x slower with Dimensional. The fragility of our currently used fusion techniques renders empty the promise of "overhead-free" newtype abstractions.</div><div><br></div><div>3. I got a *huge* performance boost by calculating `outputs` through `runIdentity` rather than treating it as an IO action. Several times faster. This makes sense, but I'm surprised the results are so drastic. </div><div><br></div><div>At this point, `mapStencil2</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 2, 2016 at 3:46 AM, Ben Lippmeier <span dir="ltr"><<a href="mailto:benl@ouroborus.net" target="_blank">benl@ouroborus.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On 2 Jul 2016, at 1:34 PM, William Yager <<a href="mailto:will.yager@gmail.com" target="_blank">will.yager@gmail.com</a>> wrote:</div><div><div dir="ltr"><div><br></div><div>My code to do this is as follows:</div><div><br></div><div><a href="https://gist.github.com/wyager/8c468c9d18ad62aff8bc9738aa947ea4" target="_blank">https://gist.github.com/wyager/8c468c9d18ad62aff8bc9738aa947ea4</a></div><div><br></div></div></div></blockquote><br></div></span><div>1) Put INLINE pragmas on all the leaf functions, especially ‘kernel’. If the compiler does not inline these functions they won’t fuse. This is a key problem with the Repa approach to fusion.</div><div><br></div><div>2) The ‘dimensional’ packages wraps a data type around all those values. I’m not convinced the simplifier will be able to undo the wrapping / unwrapping. You’ll need to inspect the core code to check.</div><span><font color="#888888"><div><br></div><div>Ben.</div><div><br></div></font></span></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>