# Understanding the need for Torch.jl?

**URL:** <https://discourse.julialang.org/t/understanding-the-need-for-torch-jl/48824>\
**Category:** Machine Learning\
**Created:** [October 22, 2020, 2:27pm UTC](https://discourse.julialang.org/t/understanding-the-need-for-torch-jl/48824 "2020-10-22T14:27:48Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![jeremiedb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeremiedb/32/29150_2.png) [@jeremiedb](https://discourse.julialang.org/u/jeremiedb)\
**Post date:** [October 24, 2020, 7:00pm UTC](https://discourse.julialang.org/t/understanding-the-need-for-torch-jl/48824/21 "2020-10-24T19:00:49Z")

</div>

I would add that the robustness of basic operators is also problematic.  
For example, vanilla RNN on GPU fails and some pooling layers on cpu show incorrect results.  
So it feels like a problematic situation when what was meant like a core tool such Flux doesn’t support very basic building blocks for NN like RNN and pooling layers reliably both cpu and gpu.

As for performance, my understanding of the approach is to optionnally support the dispatch on specialized backends, for example CuDNN or Torch. I think that such approach where speed can be added incrementally by expanding the bindings is sound in its current form.

Personnally, I’d be ok with some slowdown compared to Pytorch for example (well, not by 10X!) given the appealing Flux framework, knowing that speed could be progressively catch up.  
However, if I can’t trust the quality of what is returned by an operator, then that’s a killer for starting any serious work with it. I think that reliability should be given a higher priority, making it work first, then fast. So I’m still sticking to mxnet for now.

---

<div class="post-metadata">

**Author:** ![dhairyagandhi96](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dhairyagandhi96/32/7589_2.png) [@dhairyagandhi96](https://discourse.julialang.org/u/dhairyagandhi96)\
**Post date:** [November 16, 2020, 4:22pm UTC](https://discourse.julialang.org/t/understanding-the-need-for-torch-jl/48824/22 "2020-11-16T16:22:29Z")

</div>

I would definitely prioritize any incorrect results, we should be able to test these things. The RNNs were fixed as well, just for context.

---

<div class="post-metadata">

**Author:** ![o314](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/o314/32/252_2.png) [@o314](https://discourse.julialang.org/u/o314)\
**Post date:** [October 10, 2024, 9:06pm UTC](https://discourse.julialang.org/t/understanding-the-need-for-torch-jl/48824/23 "2024-10-10T21:06:41Z")

</div>

Edward Yang himself (pytorch coredev) seems to suggest the future of pytorch looks a lot like Julia here

> **[Where we are headed and why it looks a lot like Julia (but not exactly like...](https://dev-discuss.pytorch.org/t/where-we-are-headed-and-why-it-looks-a-lot-like-julia-but-not-exactly-like-julia/276)**
>
> When trying to predict how PyTorch would itself get disrupted, we used to joke a bit about the next version of PyTorch being written in Julia. This was not very serious: a huge factor in moving PyTorch from Lua to Python was to tap into Python’s...

IMO It’s not Julia that would have copycat pytorch, but the converse, pytorch that mimics more and more Julia core itself when it grows up. Finally Pytorch may be understaffed in those land. Julia, now very manpowered, may bring some wins.

Comparison with BLAS (opinion there) may have some biases since one is before the kiss of death era, and hurray, has been successfully funded, coded and deployed. Meanwhile the other is an offspring in the multidispatch all the things time combined with web and github

BTW Edward Yang is the first contributor since 2017, this article is his top link on the forum

---

<div class="post-metadata">

**Author:** ![stemann](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stemann/32/4030_2.png) [@stemann](https://discourse.julialang.org/u/stemann)\
**Post date:** [November 4, 2024, 6:00pm UTC](https://discourse.julialang.org/t/understanding-the-need-for-torch-jl/48824/24 "2024-11-04T18:00:40Z")

</div>

OT: On a related semi-off-topic note: The primary author (at Microsoft) of [TorchSharp](https://github.com/dotnet/TorchSharp) (.NET) is [“a big fan of Julia for numeric workloads”](https://github.com/dotnet/TorchSharp/issues/933#issuecomment-1442220364), and was also [giving Torch.jl a spin some years ago](https://github.com/FluxML/Torch.jl/issues/32#issuecomment-884517079).

… and TorchSharp contains a few Julia-interop bits: [GitHub search: repo:dotnet/TorchSharp julia](https://github.com/search?q=repo%3Adotnet%2FTorchSharp+julia&type=code)

[Previous page](https://discourse.julialang.org/t/understanding-the-need-for-torch-jl/48824.md?page=1)