Lawrence Mitchell

> I should also check how long the ast->C step takes... This is fast, however, I attach the profiler report for the first TSFC pass (UFL->loopy). You can see that...

Here are some smaller ones. a curl-curl problem, and then a quad-curl problem (the latter is a bit contrived, but we should have some elements soon where you can do...

Returning to this again, just to keep track of what I should be doing (since we've had some more big kernels that take a while to compile). I attach a...

If I took the first option, the codegen complains because the deviceprogram is no longer a `cgen.FunctionBody`. I applied this disgusting patch because I don't know how to map over...

I don't really like static arrays either, but unfortunately I don't understand the backend targets sufficiently to know how to start implementing the alternative approach.

Can you check the gpuci failures here? https://gpuci.gpuopenanalytics.com/job/dask/job/distributed/job/prb/job/distributed-prb/5098/

> Yeah, I'm still trying to figure those. Unfortunately the tests pass if you run them alone, but there seems to be some leakage from previous tests that cause that...

> @fjetter @jrbourbeau wondering if you could help us figure if something is wrong with codecov, I don't believe this PR alone should decrease coverage, and if I try to...

> I don't believe this PR alone should decrease coverage All the mig-based code (which is more lines, I think) (e.g. https://github.com/dask/distributed/pull/6720/files#diff-457ccaa4d4a70945b095c0460229791e8142c269e9ec781b98ab6d1b1925fd8cR201-R217) will be untested because nothing runs with mig...

A big hammer would be to ignore those files, per https://docs.codecov.com/docs/ignoring-paths (although those patterns don't look like regexes to me) ```patch diff --git a/codecov.yml b/codecov.yml index 319545ae..bf003804 100644 --- a/codecov.yml...