Stencil and Co-dfns

Stencil(⌺) is the famous operator adopted in Dyalog APL that enables writing image processing code in a convenient way. An example would be dilation.

dilation←{⌈/{,⍵}⌺(1+2×⍺ ⍺)⊢⍵} ⍝ ⍺ is the radius

The interpreter of Dyalog has a few special code that avoids consing caused by interpreting the left operand multiple times, if it is in one of the following forms:

   {⍵}      {⊢⍵}      {,⍵}      {⊂⍵}
{+/,⍵}    {∧/,⍵}    {∨/,⍵}    {=/,⍵}    {≠/,⍵}  
    
{  +/,A×⍵}    {  +/⍪A×⍤2⊢⍵}
{C<+/,A×⍵}    {C<+/⍪A×⍤2⊢⍵}

Apparently, {⌈/,⍵} is not in it so that is the reason the above APL function would be implemented that way.

With Co-dfns, APL code is compiled to C++ code before execution so the overhead from parsing the dfns content each time applying the function should never be worried. However, current version of Co-dfns does not support using stencil operator directly yet.

{⌈⌿⌈⌿¯2 ¯1 0 1 2⌽⍤0 3⊢¯2 ¯1 0 1 2⊖⍤0 2⊢⍵}
  

This is similar to dilation but with radius fixed to 2, and the image is treated as a torus instead of clipping at edge.

Figure 1. From left to right are original, with dilation ⌈, with erosion ⌊.

Actually, even without been compiled this version is a bit faster than the one uses stencil, which exceeded my expectation. The compiled version with CPU backend is much slower, apparently the plain C++ code lacks the magical optimization done by Dyalog interpreter. (Did I mentioned foreign function call cost?) I don't have GPU so if someone is able to test please help. The benchmark is tested on randomized array of shape 1500 1500.

  co-dfns cpu  → 9.9E¯1 |   0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  interpreted  → 5.1E¯2 | -95% ⎕⎕                                      
* stencil      → 7.9E¯2 | -92% ⎕⎕⎕