Follow-up from "C exec cleanup"

The following discussion from !195 (merged) should be addressed:

• @inducer started a discussion: (+1 comment)

  cached kernel call result supersedes this

  "supersedes" in what way? Making it hard to see whether it was cached? Or supersedes caching altogether?

@arghdos said:

Errr, I mean the result of the kernel call is cached based on the input args rather than attempting to recompile the kernel and having codepy determine the result is already cached.

I'm trying to think of a clean way to test that we have codepy's caching set up correctly. We can change the args and call an already compiled kernel, or the like e.g.:

knl(a=np.arange(10)) knl(a=np.arange(10, 0, -1))

and then check the log to see if it recompiled or if codepy found the cached version?

Sorry, I still don't know what you mean. Why would the result of the kernel call be cached? Is there anything that would do that? (I hope not!)

@inducer sorry - I was definitely a bit confused last night. I was considering adding a test like this to explicitly test that we have codepy's caching correctly setup (since we're shamefully realizing that not testing caching is... bad... 😄)

def test_c_caching():
    # ensure that codepy is correctly caching the code
    from loopy.target.c import ExecutableCTarget

    knl = lp.make_kernel('{[i]: 0 <= i < 10}',
        """
            a[i] = b[i]
        """,
        [lp.GlobalArg('a', shape=(10,), dtype=np.int32),
         lp.ConstantArg('b', shape=(10))],
        target=ExecutableCTarget())

    # call once to get compiled kernel
    assert np.allclose(knl(b=np.arange(10))[1], np.arange(10))
    # call again to ensure codepy's caching works -- via log check?
    assert np.allclose(knl(b=np.arange(10))[1], np.arange(10))

I did some more testing this morning. What's happening is that the kernel_info is correctly cached -- the call on loopy.target.c.c_execution::409 returns the cached kernel_info -- this means we have a cached CompiledCKernel and hence the compiler.build isn't hit.

The net result of this that I'm not sure if there's a codepath where the compilation call in compiler.build::237:

_, mod_name, ext_file, recompiled = \
  compile_from_string(self.toolchain, name, code, c_fname,
                                self.tempdir, debug, wait_on_error,
                                debug_recompile, False)

would ever result in codepy's cache being utilized.

A minor point, but if there's a way that we'd actually see codepy's caching come into play, we should probably test it!

If you also duplicate the make_kernel, you should see codepy's cache get hit--unless I'm mistaken.

mentioned in merge request !196 (merged)

closed via commit 28b164f3

closed via merge request !196 (merged)

mentioned in commit 0fbdec35