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

PyTorch 2.0

pytorch.org

Post reply on HN
Print view View original

101–110 of 111 posts

Re: PyTorch 2.0

#101

Post by wartijn_ »

roenxi wrote: post #83
vikinghckr wrote: post #70

Earlier quoted context omitted.

What I really find interesting here is that PyTorch, a library maintained by Facebook, is winning the marketshare and mindshare due to clean API, whereas Tensorflow, maintained by Google, is losing due to inferior API. In general, Google as a company emphasizes code quality and best practices far more than Facebook. But the story was reversed here.

Google's stereotype is the company that can handle and manage complexity - things like Kubernetes, indexing the internet, etc. They are clumsy at persuading people to use their products and have a patchy history of launching platforms that people want to use. Google+ and Google cloud vs AWS spring to mind, Kubernetes is a good platform but challenging to learn. Chrome is an unusual aberration where they did a great j…

They did a pretty good job in persuading people to use search, adsense, YouTube, Gmail, Maps and a bunch of other products. Singling out a few couple of the less successful ones to claim a trillion dollar company is “clumsy at persuading people to use their products” seems like a pretty bad take.

Re: PyTorch 2.0

#103

Post by niels_bom »

vikinghckr wrote: post #70
hintymad wrote: post #25

A big lesson I learned from PyTorch vs other frameworks is that productivity trumps incremental performance improvement. Both Caffe and MXNet marketed themselves for being fast, yet apparently being faster here and here by some percentage simply didn't matter that much. On the other hand, once we make a system work and make it popular, the community will close the performance gap sooner than competitors expect. Anoth…

What I really find interesting here is that PyTorch, a library maintained by Facebook, is winning the marketshare and mindshare due to clean API, whereas Tensorflow, maintained by Google, is losing due to inferior API. In general, Google as a company emphasizes code quality and best practices far more than Facebook. But the story was reversed here.

Couldn’t these organizations be big enough to have different technical cultures from team-to-team or product-to-product? If that’s the case comparing FAANG to each other is like comparing Asia to Europe and then taking North-Korea and Portugal as examples.

Re: PyTorch 2.0

#104

Post by roenxi »

wartijn_ wrote: post #101
roenxi wrote: post #83

Earlier quoted context omitted.

Google's stereotype is the company that can handle and manage complexity - things like Kubernetes, indexing the internet, etc. They are clumsy at persuading people to use their products and have a patchy history of launching platforms that people want to use. Google+ and Google cloud vs AWS spring to mind, Kubernetes is a good platform but challenging to learn. Chrome is an unusual aberration where they did a great j…

They did a pretty good job in persuading people to use search, adsense, YouTube, Gmail, Maps and a bunch of other products. Singling out a few couple of the less successful ones to claim a trillion dollar company is “clumsy at persuading people to use their products” seems like a pretty bad take.

You'll note that all the examples you're citing were released more than a decade ago (search wasn't even this century!). And YouTube was an acquisition. They were basically the work of a different Google to the one that is walking around now.

The stereotype of Google back then was very different. People would quote things like "don't be evil".

Re: PyTorch 2.0

#105

Post by amitport »

SleekEagle wrote: post #45
hintymad wrote: post #25

A big lesson I learned from PyTorch vs other frameworks is that productivity trumps incremental performance improvement. Both Caffe and MXNet marketed themselves for being fast, yet apparently being faster here and here by some percentage simply didn't matter that much. On the other hand, once we make a system work and make it popular, the community will close the performance gap sooner than competitors expect. Anoth…

Exactly, especially in the age of ridiculously rapid development that we have found ourselves in over the past few years. This is exactly why TensorFlow is dying

I do not believe TensorFlow is anywhere close to dying.

Re: PyTorch 2.0

#106

Post by PartiallyTyped »

carbocation wrote: post #80
PartiallyTyped wrote: post #78

Earlier quoted context omitted.

I found that there still some limitations with functorch's vmap, but I can't recall what it was.

Probably not your issue, but one kind of annoying bit is that the inputs need to be tensors. I ended up calling partial on the function I was messing around with and then vmapping the partial, which seemed to work.

Pretty similar actually, I needed to pass in some parameters as tuples, lists, etc. Partial would have probably worked, but tbh I wasn't in the mood to try harder at 2am.

Re: PyTorch 2.0

#107

Post by lostmsu »

js2 wrote: post #28
belval wrote: post #7

> We believe that this is a substantial new direction for PyTorch – hence we call it 2.0. torch.compile is a fully additive (and optional) feature and hence 2.0 is 100% backward compatible by definition. How about just calling it PyTorch 1.14 if it's backward compatible? Version numbering shouldn't be used as a marketing gimmick.

Dismissive comments like this make me not want to read HN anymore and in addition it’s against the HN guidelines: It’s snarky. It’s incurious. It’s neither thoughtful nor substantive. It’s flame bait. It’s a shallow dismissal. It doesn’t teach anything. It’s the most provocative thing to complain about. https://news.ycombinator.com/newsguidelines.html I’m sorry I had to leave this comment, so let me also try to respo…

Frankly, they are not really showing benchmarks, and given my experience with hyped torch.jit I don't expect much.

Re: PyTorch 2.0

#108

Post by brrrrrm »

brrrrrm wrote: post #81
ansk wrote: post #39

So this looks like a further convergence of the tensorflow and pytorch APIs (the lower-level APIs at least). Tensorflow was designed with compilable graphs as the primary execution model and as part of their 2.0 release, they redesigned the APIs to encompass eager execution as well. Pytorch is coming from the other end, with eager execution being the default and now emphasizing improved tools for graph compilation in…

Some context/history: For compiler people reading this, a lot of common compiler terms have been entirely reinvented in the context of machine learning frameworks. An ML "graph" refers almost exactly to the dataflow graph (DFG) of a program. TensorFlow 1.0 only exposed a DFG, which is well known to be far simpler to apply optimizations to (assuming you have a linear algebra compiler). PyTorch integrated with Python (…

edit: TorchInductor calls into GCC/Triton depending. I mistook it for the various backends TorchDynamo supports (including TVM)

Re: PyTorch 2.0

#109

Post by solarkraft »

vikinghckr wrote: post #70
hintymad wrote: post #25

A big lesson I learned from PyTorch vs other frameworks is that productivity trumps incremental performance improvement. Both Caffe and MXNet marketed themselves for being fast, yet apparently being faster here and here by some percentage simply didn't matter that much. On the other hand, once we make a system work and make it popular, the community will close the performance gap sooner than competitors expect. Anoth…

What I really find interesting here is that PyTorch, a library maintained by Facebook, is winning the marketshare and mindshare due to clean API, whereas Tensorflow, maintained by Google, is losing due to inferior API. In general, Google as a company emphasizes code quality and best practices far more than Facebook. But the story was reversed here.

> In general, Google as a company emphasizes code quality and best practices far more

That doesn't automatically have to mean better DX. For example the API can be clean, but too low level to conveniently accomplish typical cases (I'm not familiar with this example).

Re: PyTorch 2.0

#110

Post by fsociety »

wartijn_ wrote: post #101
roenxi wrote: post #83

Earlier quoted context omitted.

Google's stereotype is the company that can handle and manage complexity - things like Kubernetes, indexing the internet, etc. They are clumsy at persuading people to use their products and have a patchy history of launching platforms that people want to use. Google+ and Google cloud vs AWS spring to mind, Kubernetes is a good platform but challenging to learn. Chrome is an unusual aberration where they did a great j…

They did a pretty good job in persuading people to use search, adsense, YouTube, Gmail, Maps and a bunch of other products. Singling out a few couple of the less successful ones to claim a trillion dollar company is “clumsy at persuading people to use their products” seems like a pretty bad take.

The only products you listed which weren’t acquisitions are search and gmail. Search is exactly the problem Google was made to handle and Gmail.. well I don’t love gmail but it is a good enough product I guess?
Post reply on HN