Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of Deep Learning frameworks

neel04.github.io

Post reply on HN
Print view View original

51–60 of 113 posts

Re: The future of Deep Learning frameworks

#51

Post by josephg »

bob020202 wrote: post #15
josephg wrote: post #14

Earlier quoted context omitted.

You don't think its possible to (even theoretically) improve on javascript for its intended use case? What a terrific lack of imagination. Typescript and Elm would like a word

No, I said there's nothing that exists right now that's theoretically better. Typescript isn't. It'd be great if TS's type inference were smart enough that it basically takes no additional dev input vs JS, but until then, it's expensive to use. It's also bolted on awkwardly, but that's changing soon. Could also imagine JS getting some nice Py features like list comp. Also, generally when people complain that JS won t…

> No, I said there's nothing that exists right now that's theoretically better.

That might be what you meant, but its not what you said. Thanks for clarifying.

Re: The future of Deep Learning frameworks

#52

Post by hatmatrix »

funks_ wrote: post #39
hatmatrix wrote: post #30

Earlier quoted context omitted.

It seems like an experimental research language. Julia also competes in this domain from a more practical standpoint and has less limitations than JAX as I understand it, but is less mature and still working on getting wider traction.

The Julia AD ecosystem is very interesting in that the community is trying to make the entire language differentiable, which is much broader in scope than what Torch and JAX are doing. But unlike Dex, Julia is not a language built from the ground up for automatic differentiation. Shameless plug for one of my talks at JuliaCon 2024: https://www.youtube.com/live/ZKt0tiG5ajw?t=19747s . The comparison between Python and…

Ah I had not realized I was corresponding with the author of that talk - I'd followed it back when it was happening as I'm particularly interested in adapting AD.

Where do you feel Julia is at this point in time (compared to say, JAX or PyTorch) from a practitioner's standpoint?

Re: The future of Deep Learning frameworks

#53

Post by dwattttt »

bob020202 wrote: post #35
dwattttt wrote: post #32

Earlier quoted context omitted.

I see this a lot, and I want to find the right words for it: I don't want the types automatically determined for what I write, because I write mistakes. I want to write the type, and for that to reveal the mistake.

If you explicitly mark types at lower levels, or just use typed libs, it's not very easy to pass the wrong type somewhere and have it still accidentally work. The most automatic type inference I can think of today is in Rust, which is all about safety, or maybe C++ templates count too.

I actually write a fair bit of Rust, and there I'll still explicitly add types. Not always (in particular where I have an IDE that'll show me the inferred type & it's trivial), but in particular if any more complicated inference is happening I'll constrain it.

Re: The future of Deep Learning frameworks

#54

Post by deisteve »

sva_ wrote: post #28
deisteve wrote: post #20

i like pytorch because all the academia release their code with it ive never even heard of jax nor will i have the skills to use it i literally just want to know two things: 1) how much vram 2) how to run it on pytorch

Jax is a competing computational framework that does something similar to PyTorch, so both of your questions don't really make sense.

can i run pytorch code on jax?

if not im not interested. i'll keep using pytorch.

i hope this answer makes more sense for you.

Re: The future of Deep Learning frameworks

#55

Post by deisteve »

etiam wrote: post #37
sva_ wrote: post #28

Earlier quoted context omitted.

Jax is a competing computational framework that does something similar to PyTorch, so both of your questions don't really make sense.

Maybe deisteve will answer for himself, but I don't think that's meant to mean how to run Jax on Pytorch, but rather the questions he's interested in for any published model.

if a paper releases code in PyTorch im not going to sit there and complain Jax is more efficient

its like fretting about how everything should be written in C++ instead of Python/Javascript

I don't care.

Re: The future of Deep Learning frameworks

#57

Post by kaoD »

bob020202 wrote: post #35
dwattttt wrote: post #32

Earlier quoted context omitted.

I see this a lot, and I want to find the right words for it: I don't want the types automatically determined for what I write, because I write mistakes. I want to write the type, and for that to reveal the mistake.

If you explicitly mark types at lower levels, or just use typed libs, it's not very easy to pass the wrong type somewhere and have it still accidentally work. The most automatic type inference I can think of today is in Rust, which is all about safety, or maybe C++ templates count too.

TS has type inference on function return types while Rust forces you to type the whole function signature (for a good reason, TS's return type inference is a footgun).

Other than that, I haven't noticed their inference capabilities being any different.

So I don't get your point.

Can you give a single example where Rust has more automatic type inference compared with TS? (honest question, maybe I'm missing something)

Re: The future of Deep Learning frameworks

#58

Post by pineapple_sauce »

semiinfinitely wrote: post #6

PyTorch is the javascript of ML. sadly "worse is better" software has better survival characteristics even when there is consensus that technology X is theoretically better

How is Jax theoretically better than PyTorch? The author is ignorant of torch.compile and biased as other commenters have pointed out.

Re: The future of Deep Learning frameworks

#60

Post by wafngar »

PyTorch is developed by multiple companies / stake holders while jax is google only with internal tooling they don’t share with the world. This alone is a major reason not to use jax. Also I think it is more the other way around: with torch.compile the main advantage of jax is disappearing.
Post reply on HN