Refactor Hadamard matrices loading

[petrex]

TLDR: Optimize import time

Summary

• Replace the 99k-line literal Hadamard matrix module with a lightweight loader (torchao/prototype/spinquant/_hadamard_matrices.py) that lazily deserializes tensors from _hadamard_matrices.pkl, keeping the public get_hadXX APIs unchanged while avoiding multi‑MB source files.
• Ship the serialized matrices alongside the module by adding _hadamard_matrices.pkl (~345 KB) and updating setup.py so it’s included in package_data.
• Preserve semantics by returning cloned torch.Tensor instances from the cached payload; import time is ~13× faster and git churn drops from 2 MB to 2 KB of Python plus the pickle.

Testing
python - <<'PY' ... (imports old vs new module with a stubbed torch)
Before: 75.9 ms import time
After: 5.7 ms import time

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/ao/3344

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit 1af0bbd with merge base ba6f428 ():
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[vkuzo]

The import time benefit is nice! I do have some questions about including an opaque .pkl file though, seems like a potential attack vector. Is there a way to generate this file dynamically during the setup process using an observable rule instead of generating it offline in a non-source-controlled way?

[petrex]

The import time benefit is nice! I do have some questions about including an opaque .pkl file though, seems like a potential attack vector. Is there a way to generate this file dynamically during the setup process using an observable rule instead of generating it offline in a non-source-controlled way?

good point! just push the change to generate .pkl in setup.py (from json). thanks for the feedback

[vkuzo]

thank you for doing this! two follow-up questions:

1. would we get most of the import-time benefit if we just ship the json and avoid the opaque .pkl / additional setup.py complexity? any take on that?
2. do we have confidence that numerics from using the hadamard transforms are still good

[petrex]

thank you for doing this! two follow-up questions:

1. would we get most of the import-time benefit if we just ship the json and avoid the opaque .pkl / additional setup.py complexity? any take on that?
2. do we have confidence that numerics from using the hadamard transforms are still good

1. Benchmarking shows that loading from JSON is only ~3ms slower than Pickle on first access, which is negligible.
2. Is there any unit test for for this feature? All green in CI.

[vkuzo]

thank you! CI is green, so looks good.