fouronnes3
11 days ago
I work on differentiable geometric optics with PyTorch. Seeing a list like this is really illustrative of the power that PyTorch provides when you start considering it like a general purpose GPU-enabled state of the art numerical optimization framework.
One thing I wonder is why no one has made a fork of PyTorch yet that removes all the API surface that doesn't produce GPU friendly code. Make dtype and device arg mandatory without defaults, remove in place operations that trigger a CPU sync, etc. This would increase confidence that written code will run on the GPU and pass torch.export() on the first try.
jamessb
11 days ago
Rather than forking PyTorch (which has issues like continually needing updates), could you create a set of linter rules instead?
rhdunn
11 days ago
It's useful to be able to run models/code on the CPU or split between CPU and GPU, especially for models that cannot fit into the GPU's VRAM, if you are running multiple models, or if you have training data that you need to move between CPU and GPU.
earthnail
11 days ago
All of that would be possible with the changes parent poster proposes. See the gotchas section in JAX, which is exactly these limitations:
https://docs.jax.dev/en/latest/notebooks/Common_Gotchas_in_J...
WhyNotHugo
11 days ago
> One thing I wonder is why no one has made a fork of PyTorch yet that […]
Try and compile the stack from source and you'll find out why nobody is making forks with small divergences.
DonsDiscountGas
11 days ago
Seems like you could write a simple source code checker program to check all of that. Making an extra library just for some (user hostile) tweaks seems like overkill.
northzen
11 days ago
Hi!
I'm curious to hear about your work geometric optics with PyTorch. May I ask you to share some examples of something you are working on right now?