Oops, sent prematurely. 

`mapStencil2` seems to be allocating one extra machine word per stencil computation. So not entirely unboxed, but much better. 

Latest code is at
https://gist.github.com/wyager/1c5879660a61c5cd6afaceb3e928d889

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.

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.

Cheers,
Will

On Sat, Jul 2, 2016 at 3:46 PM, William Yager <will.yager@gmail.com> wrote:
OK, some interesting things:

1. INLINE pragmas seem to have no substantial effect.

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.

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. 

At this point, `mapStencil2

On Sat, Jul 2, 2016 at 3:46 AM, Ben Lippmeier <benl@ouroborus.net> wrote:

On 2 Jul 2016, at 1:34 PM, William Yager <will.yager@gmail.com> wrote:

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.

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.

Ben.