Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

import thunder tries to initialize all native executors #345

Open
kshitij12345 opened this issue May 2, 2024 · 3 comments
Open

import thunder tries to initialize all native executors #345

kshitij12345 opened this issue May 2, 2024 · 3 comments

Comments

@kshitij12345
Copy link
Collaborator

kshitij12345 commented May 2, 2024

import thunder initializes all native executors. I don't think this is desirable as initializing them may not be cheap. Except for default executors, we should load others only when user calls get_executor or get_all_executor.

pythonex = extend.get_executor("python")

def get_executor(name: Any) -> None | Executor:
ex: Executor
for ex in get_all_executors():
if ex.name == name:
return ex
return None

cc @apaz-cli @carmocca @Borda

@kshitij12345 kshitij12345 added bug Something isn't working ux and removed bug Something isn't working labels May 2, 2024
@kshitij12345 kshitij12345 changed the title import thunder initializes all native executors import thunder tries to initialize all native executors May 2, 2024
@carmocca
Copy link
Contributor

carmocca commented May 6, 2024

get_all_executors makes sure that all the 1st party executors are imported:

# manually import all native executors to let them register themselves
from thunder.executors import (
apex_entropyex,
cudnn_layernormex,
cudnnex,
nvfuserex,
pythonex,
sdpaex,
torch_compile,
torchex,
transformer_engineex,
triton_crossentropy,
)
. This is necessary to avoid silently returning None for executors that are importable.

One simple fix could be avoiding get_executor at import time

Still in the long-term, Thunder would benefit from having a cheap way for executors to register themselves in a way that signals "I could be imported". And a different and more expensive check for "I can actually be used (dependencies are available, required hardware is available, ...)"

@mruberry
Copy link
Collaborator

mruberry commented May 6, 2024

triage review — adding a system that lets executors register themselves as "importable" would be a great extensibility point and should avoid actually importing everything at startup

@mruberry
Copy link
Collaborator

mruberry commented May 6, 2024

@ptrblck points out that importing thunder takes significantly longer than importing torch alone; this could be part of that issue

%time import torch
CPU times: user 745 ms, sys: 0 ns, total: 745 ms
Wall time: 774 ms

%time import thunder
CPU times: user 1.57 s, sys: 680 ms, total: 2.25 s
Wall time: 2.28 s

%time import numpy
CPU times: user 1 µs, sys: 1 µs, total: 2 µs
Wall time: 4.53 µs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants