Add tag to store array creation traceback

[matthiasdiener]

Please squash

TODOs as of 11/14/2023:

• Make sure we do not create multiple CreatedAt tags (or overwrite existing ones) for the same node (4ec3cbf)
• Make sure tags propagate correctly through mappers (4ec3cbf)
• More comprehensive performance testing (see below)

---

Simple performance test as of 11/14/2023:

• M1

import pytato as pt
from time import time
import numpy as np

n=50

start = time()
for i in range(100000):
    pt.make_placeholder(name='a', shape=(n, n), dtype=np.float64)
stop = time()
print(stop-start)

Config	Time
w/ CreatedAt	1.48s
w/o CreatedAt	0.35s

---

smoke_test_ks_3d performance as of 11/15/2023:

• M1, 1 rank, CPU, production, MPIFusionContractorArrayContext, LOOPY_NO_CACHE=1

Config	Total time
w/ CreatedAt	463s
w/o CreatedAt	452s

---

Needs:

• Remove tags before restoring pickled ones meshmode#329
• add IgnoredForEqualityTag pytools#134

[matthiasdiener]

This is ready for a first look @inducer @kaushikcfd

[inducer]

• Could you look at the CI failures?
• Could you try to quantify the runtime impact on complex DAGs and add that to the PR description?

[kaushikcfd]

1. I think putting it in Array.__init__ would lead to several of these after a sequence of .map_and_copy's.
2. Having many of these would also affect our DAG visualization.
3. We could probably only attach the first call-frame from outside pytato, but to know these we might have to start attaching them only in the user-exposed function.

[inducer]

Good points.

I think an important tweak is to only add one if one isn't already there (in tags). We're not interested in call stacks of where these get rewritten by mappers (I think).

We could probably only attach the first call-frame from outside pytato

We could, though I'd expect that that might be a bunch of engineering that, ultimately, might not be buying us much.

[kaushikcfd]

I think an important tweak is to only add one if one isn't already there (in tags).

I would be cautious in spending time in the constructor.

We could, though I'd expect that that might be a bunch of engineering that, ultimately, might not be buying us much.

I think at least dropping the frames within pytato would be helpful. Otherwise, they would all be polluted with pytato.array.Array.__add__, pytato.cmath.sin.

[inducer]

I would be cautious in spending time in the constructor.

Argh, that's a very fair point. We shouldn't. The alternative is to splat this into a zillion other places, but I agree that's preferable.

I think at least dropping the frames within pytato would be helpful. Otherwise, they would all be polluted with pytato.array.Array.__add__, pytato.cmath.sin.

Fair, but we can also do that when rendering, which I think will be way less frequent than construction.

[kaushikcfd]

The alternative is to splat this into a zillion other places

#285

Fair, but we can also do that when rendering, which I think will be way less frequent than construction.

Agreed, I'm completely fine with this.

[inducer]

Good points.

I think an important tweak is to only add one if one isn't already there (in tags). We're not interested in call stacks of where these get rewritten by mappers (I think).

We could probably only attach the first call-frame from outside pytato

We could, though I'd expect that that might be a bunch of engineering that, ultimately, might not be buying us much.

[inducer]

LGTM, thanks!