-
Notifications
You must be signed in to change notification settings - Fork 212
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
Integration with PyTorch #161
Comments
RE 1): Is the build system supposed to work with any installation of PyTorch? e.g. if users build PyTorch from source, or install using |
It takes several hours to build PyTorch from source. Another problem to build from source is that there is a good chance the PyTorch version K2 uses is different from the one Python uses. The current I have no experience with conda. But I guess it will work. |
Fangjun, how does your pull request relate to this, in terms of PyTorch
versions and compatibility?
I'm not sure that I fully understand what it will be doing from a linking
perspective.. will it try to pick up symbols from the already-loaded
PyTorch dynamic library?
…On Thu, Sep 17, 2020 at 10:39 PM Fangjun Kuang ***@***.***> wrote:
It takes *several hours* to build PyTorch from source. Another problem to
build from source is that there is a good chance the PyTorch version K2
uses is different from the PyTorch python version.
The current CudaContext is a naive implementation. What I want to do is
to change GetCudaContext so that
it returns a pytorch context.
I have no experience with conda. But I guess it will work.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#161 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZFLO75U2OFPUBHO2EFVELSGINRLANCNFSM4RQPJU3Q>
.
|
To the best of my knowledge, there are two approaches to build against PyTorch: (1) Build PyTorch from source. I think only PyTorch developers use this method. The building process can take several hours. (2) Build against cd build/bin
readelf -d cu_array_test prints
Part of the linking commands for
We can see that k2 uses the same PyTorch libraries from the torch package. Note that there are no restrictions on the PyTorch version. Users can choose which PyTorch version to |
Lines 3 to 7 in f784a2c
K2 uses the PyTorch installation information from the pip package, so it's guaranteed that k2 uses whichever version Python Line 36 in f784a2c
|
Fantastic!
…On Fri, Sep 18, 2020 at 3:12 PM Fangjun Kuang ***@***.***> wrote:
how does your pull request relate to this, in terms of PyTorch versions
and compatibility?
https://github.com/k2-fsa/k2/blob/f784a2cc3b8ac698ca99f12a458758cd452c280a/cmake/torch.cmake#L3-L7
K2 uses the PyTorch installation information from the pip package, so it's
guaranteed that k2 uses whichever version Python
is currently using.
https://github.com/k2-fsa/k2/blob/f784a2cc3b8ac698ca99f12a458758cd452c280a/k2/csrc/CMakeLists.txt#L36
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#161 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZFLO6O5KYEHDE3ACDRT7LSGMB53ANCNFSM4RQPJU3Q>
.
|
With the introduction of
k2::Context
, the current mechanism to communicate with PyTorch via DLPack is not sufficient since we need to allocate/deallocate memory on different devices, while DLPack can only pass pre-allocated memory around.I would like to update the build system to link against PyTorch with the following goals in mind:
(1) The build system should be simple. The PyTorch dependency will be installed with
pip install torch
so thatC++ shares the same PyTorch version with Python.
(2) Replace the current
k2::CudaContext
with the one from PyTorch, which is much faster with memory caching.The text was updated successfully, but these errors were encountered: